I tend to stick to the objective. Obviously, if the time spent starts to go way beyond reasonable, then there must be something wrong in either the objective or the mean to achieve it. But on average, i tend to thoroughly continue working on it up to the point where the idea is either invalidated or successfull.
The main reason for it is that i don't want the idea to continue haunting me later on. It must be "finished business".
I nonetheless agree with your evaluation : this time is probably borrowed from other activities, which could have been more usefull.
It's nice to get a single part working in a way that's cleverer than it's been done before, but there are many other aspects that you can improve to have something people find useful.
Programs need to be easy to use, save people time, etc. and in the end, if you had infinite time, yes you could make every single component state-of-the-art, but by then it'd be too late. Too much focus on a single piece may lead you to neglect what makes people want to use your resulting work.
I like research-style, 'out in the weeds' kind of coding, but sometimes software really does need a damn GUI. :)
I completely agree about losing a lot if you 'just come back later'. Wish I had any advice there, just seems to be the way it goes...
October 24, 2011 at 3:26 PM
One of the things I've really struggled with in the last few years at RAD is the trade off between wasting time on a side shoot
of the main code line vs. really wrapping something up while your focus is on it.
Generally after I've spent a week or two on a topic I start feeling like "okay that's enough time on this I need to move on" ;
I guess that's my internal project manager watching my schedule. But on the other hand, there's such a huge advantage to
staying on a topic while it fills your mind. You just lose so much momentum if you have to come back to it later.
For example I wish I had finished my JPEG decoder back when I was working on it, that was an important piece of software I believe,
but I felt like I needed to move on to more practical tasks, and now it's all out of my head and would take me several weeks to
figure out all the nuances again.
Currently I'm working on a new way to do LZ optimal parsing, and I feel like I need to move on because it's not that important to
my product and I need to get onto more practical tasks, but at the same time I hate to leave it now because I feel close to a
breakthrough and I know that if I stop now I may never come back to it, and if I do it will take forever to get back into the flow.
"10-18-11 - To wrap it up or move on"
2 Comments -
I tend to stick to the objective.
Obviously, if the time spent starts to go way beyond reasonable, then there must be something wrong in either the objective or the mean to achieve it.
But on average, i tend to thoroughly continue working on it up to the point where the idea is either invalidated or successfull.
The main reason for it is that i don't want the idea to continue haunting me later on. It must be "finished business".
I nonetheless agree with your evaluation : this time is probably borrowed from other activities, which could have been more usefull.
October 21, 2011 at 5:16 AM
It's nice to get a single part working in a way that's cleverer than it's been done before, but there are many other aspects that you can improve to have something people find useful.
Programs need to be easy to use, save people time, etc. and in the end, if you had infinite time, yes you could make every single component state-of-the-art, but by then it'd be too late. Too much focus on a single piece may lead you to neglect what makes people want to use your resulting work.
I like research-style, 'out in the weeds' kind of coding, but sometimes software really does need a damn GUI. :)
I completely agree about losing a lot if you 'just come back later'. Wish I had any advice there, just seems to be the way it goes...
October 24, 2011 at 3:26 PM