Comments on: Broken state programming

By: Emmanuel Lecharny

Emmanuel Lecharny — Mon, 02 Feb 2009 10:26:50 +0000

I share almost every single feeling Com’s is having. And I also agree with the two camps thing. Professional writers have a special expression for this ‘starting pain’ issue : they call it ‘fear of the blank page’. When it comes to write down the first sentence of a book, you just know that you have so much to write that you just don’t know how to start climbing the montain.
When it comes to code, it’s about the same. Some of us can start immediately, some other need to wait, wait, wait until they get a clear picture of the whole thing. Fixing broken code is also something I like, because it’s like working in a frame you know, and you immediately see where it’s broken, or where it can be repeared.

I like to see the coders as either visionaries (those who can write a prototype from scratch), and executors (those who transform this prototype into a decent piece of software). A very few peeps are talented enough to be a mixture of both, but so far, it’s very rare, because cleaning code is so time consumming that it kills imagination at some point.

By: Dave Concannon

Dave Concannon — Sun, 01 Feb 2009 13:51:04 +0000

… of social networking, mail, etc might prevent me getting into a pattern of
thought that’s useful for more important work.

By: Dave Concannon

Dave Concannon — Sun, 01 Feb 2009 13:50:43 +0000

I’d agree with Jeroen too, though from the perspective of someone who works from home full-time your method has merit. Unless I’m in the middle of something supremely interesting, my usual start to the day involves picking an easy-to-fix bug from the company bug-tracker to get the day started. Without being able to pick something simple to kick-start my brain the normal distractions

By: Kae Verens

Kae Verens — Sun, 01 Feb 2009 11:51:42 +0000

I agree with Jeroen – interest is what helps me get some of the more difficult tasks finished. If I’m not interested, it’s going to take a long time for me to get around to it, even if it only takes five minutes to write.

When I started programming, I would start something by writing it in commented-out pseudo-code, then replace the pseudo-code with real code, testing all the while. Hmm… can’t see what I’m typing now – I think you need scroll-bars on this thing…

Anyway – that allowed me to walk off or be interrupted without losing anything – the train of thought had already been written in pseudo-code, so people were free to interrupt me.

By: jeroen

jeroen — Sun, 01 Feb 2009 00:39:31 +0000

Hmmm… for me the trick seems to be purely one thing: Interest.

As long as I am interested in solving a problem (as that is how I see ‘programming’, just a way to solve a specific set of problems) I will keep biting on it till the problem is resolved, generally that means that it will be resolved in a very very short time. When I loose that interest though I probably will not even look back at it again unless for some reason I get interest again.

Interruptions don’t seem to be a problem for me, because I will simply pick it up again, and there will always be interruptions.

Meh, it is all difficult, but just keeping interest helps for me ;)

By: Andy

Andy — Sun, 01 Feb 2009 00:36:23 +0000

hey Colm,

Its an interesting perspective.. It certainly wont be mentioned in any “Agile” development books, but I’ve come to the conclusion they don’t work for me.

I’m not even a pretend developer mind you, but I do notice I end up being a lot more productive when I start off fixing a genuine/obvious problem – once that’s done, its easier to get stuck in with the rest.