Tuesday, 25 September 2007

Waterfall Programmer

A Programmer who writes bunches and bunches of code. Compiles. Debugs and Debugs.

Having interviewed quite a few people over the last few years, this seems to be relatively common and it's very very painful to watch. This is a pattern that can turn really smart people into really bad programmers. In fact, its quite possible that the smarter you are the worse waterfall programming can bite you in the butt. The problem comes with the "unchecked" assumptions you build into the code. The more complex / cleverer your idea of how to solve a problem where you don't validate your assumptions the harder it gets to undo it later (both emotionally and technically)

Tuesday, 4 September 2007

To Post or not to post that is the question

Lately I've written a lot of blog posts but haven't actually published them.

Mostly they are posts with a key "idea" and then I've built up some discussion around that idea, however I find that I really want to write comprehensive essays around the topic. I eventually give the post up and leave it as a draft as it turns into a mini project :-)

I'm wondering if I should still publish unfinished posts? Or is better to keep them in draft till you can present a complete idea?


My unfinished posts are :-

Product Development
Value Stream Mapping
Cross Functional Teams
Maintaining Design Options
Design Patterns - Smart soloutions for bad languages?
How to screw up your design
Technical Debt
Whats really going on? How we end up deluding ourselves

Saturday, 1 September 2007

Brain Strain

Another excellent article from Paul Graham, this time on holding a program in one's head ( http://www.paulgraham.com/head.html )

This is definitely a trait I've noticed in good programmers, they keep a problem and the code in their head. The more you can stuff in your head the better off you are. The higher the liklihood you will understand the consequences of changes, etc

Paul gives a number of points to help with keeping things in your head....

Avoid Distractions

I think this is really important. The consequence of this is, if you start doing something else when you get a break in your flow ( a long build ) such as IM / Web / Email it will start blanking out the problem / program that's in your head.

This can be a problem with pair programming at times also, sometimes the pairing can interfere with getting a problem / program into both your heads. If two people get into the same headsapce however, it can be really powerful.

Use succinct languages

succinct language and code! Building up good abstractions is very useful, if you you have good abstractions it can be very easy to express a soloution to a problem in minimal amount of code.

Having a language where you don't have to write a lot of crap to express an idea is of course very useful as well, but often the choice of language is not an option.

though I'll plug Lua once again for any C/C++ programmers out there