Think first, code later(24ways.org)
24ways.org
Think first, code later
http://24ways.org/2012/think-first-code-later/
7 comments
Its funny. Having kids has forced me into doing this. When at home, I rarely have more than an hour of uninterrupted coding time. So when I have an idea, or get stuck, I'm forced to get away from it, letting my brain naturally chew away at it. I have less time to code, but my time spent is more efficient.
If your code ends up like that you probably missed having a sustainable rate, pair programming, code reviews, refactoring and writing testable code. So you missed a lot.
Unfortunately, the reality is that any code base that is maintained and developed over an extended period will "decay", even if you don't do anything wrong.
This is a simple consequence of the fact that you usually don't know everything and can't create an idealised long-term plan up-front. Instead, you start with certain goals and try to implement a sensible system that meets those goals. As time goes by, your goals change or you add new ones, and you have to adapt that existing system to match.
Often, during the time since the initial development was planned out, you may have developed newer techniques for solving your problems, or you may have new tools available that weren't before, or you may have worked with some new people who have better ideas about something. In short, you may have a better way to do things than before. Now you have exactly three choices:
1. Stick to your existing design/ideas and don't use the better ways. (Pros: Maintains consistency and doesn't incur (re)training overheads. Cons: May cost more and/or get worse results for the new work, or may simply not be possible if you need a new approach to satisfy your new goals.)
2. Use the better ways, but only for new/future work. (Pro: Best cost and results for that new work taken in isolation. Cons: Might mean an entire new design co-existing with your previous one(s), with potential compatibility problems, integration costs, future maintenance overheads, etc, and might cost more to implement separately than it would have done if you'd known ahead of time and created a more general design to support both the old and new parts earlier.)
3. Switch everything to the better ways, a.k.a. The Big Rewrite. (Pros: Keeps your entire system using the best possible tools/ideas, and keeps the whole code base consistent and systematically designed across the board. Cons: Can be extremely expensive relative to incremental changes, you can easily lose little fixes/improvements that had been carefully worked into the original code base over time, and you may have to retrain some of your team before they can work with the new version.)
This is an exhaustive set of your options if you're going to do that new development but your team and the world have moved on since the original work. Every one of them has at least one serious downside, and unless you do a full rewrite across your entire code base every time you develop any improvement, those downsides always include some degree of inconsistency or stagnation.
This is a simple consequence of the fact that you usually don't know everything and can't create an idealised long-term plan up-front. Instead, you start with certain goals and try to implement a sensible system that meets those goals. As time goes by, your goals change or you add new ones, and you have to adapt that existing system to match.
Often, during the time since the initial development was planned out, you may have developed newer techniques for solving your problems, or you may have new tools available that weren't before, or you may have worked with some new people who have better ideas about something. In short, you may have a better way to do things than before. Now you have exactly three choices:
1. Stick to your existing design/ideas and don't use the better ways. (Pros: Maintains consistency and doesn't incur (re)training overheads. Cons: May cost more and/or get worse results for the new work, or may simply not be possible if you need a new approach to satisfy your new goals.)
2. Use the better ways, but only for new/future work. (Pro: Best cost and results for that new work taken in isolation. Cons: Might mean an entire new design co-existing with your previous one(s), with potential compatibility problems, integration costs, future maintenance overheads, etc, and might cost more to implement separately than it would have done if you'd known ahead of time and created a more general design to support both the old and new parts earlier.)
3. Switch everything to the better ways, a.k.a. The Big Rewrite. (Pros: Keeps your entire system using the best possible tools/ideas, and keeps the whole code base consistent and systematically designed across the board. Cons: Can be extremely expensive relative to incremental changes, you can easily lose little fixes/improvements that had been carefully worked into the original code base over time, and you may have to retrain some of your team before they can work with the new version.)
This is an exhaustive set of your options if you're going to do that new development but your team and the world have moved on since the original work. Every one of them has at least one serious downside, and unless you do a full rewrite across your entire code base every time you develop any improvement, those downsides always include some degree of inconsistency or stagnation.
Code. Think (on the toilet). Code.
The main takeaway from this article for me is the part about questioning the use of jQuery.
jQuery is a great tool for doing things, but in the context of a rich javascript application, its tight coupling - and the even tighter coupling its plugin style encourages - lead to very hard to test code.
For example: jQuery.each is a fairly nice iterator function, and since you're going to use jQuery anyway - lets us that!
But then you want to try and test something in isolation, and you suddenly find that in order to iterate over an array, you need to load jQuery - which means you need a whole DOM environment!
jQuery is a great tool for doing things, but in the context of a rich javascript application, its tight coupling - and the even tighter coupling its plugin style encourages - lead to very hard to test code.
For example: jQuery.each is a fairly nice iterator function, and since you're going to use jQuery anyway - lets us that!
But then you want to try and test something in isolation, and you suddenly find that in order to iterate over an array, you need to load jQuery - which means you need a whole DOM environment!
For us younger programmers, 'Think first, code later' is without a doubt the best advice you can give someone going for their first interview. I still shudder thinking back to an interview when I threw myself straight into coding the solution to the given problem.
Stand back. Think. Draw/Design the solution. Code
Stand back. Think. Draw/Design the solution. Code
Don't forget to document too :)
I am somewhat past the middle of a career as an analyst/programmer of various flavors. As I look back on the previous quarter-century, I find that the software I am most proud of is that in which the development effort was punctuated by frequent spells of pushing the chair back from the desk, getting up, and going for a walk about the facility. No destination in particular, just putting one foot in front of the other, probably with a glazed look on my face. Thinking about the project, the current hurdle, and various means of jumping it. Eventually I would surface from these cognitive dives, floors away from my workspace, with a decision on the optimal way to solve the problem. One of these projects is still running a global datacenter, largely unchanged, 20 years post-implementation.
Time to think is the most precious resource an analyst has.
Time to think is the most precious resource an analyst has.
Yes.
As a 39 year old programmer the most important thing I've learned is that my subconscious brain is way smarter than my conscious brain and the best way for me to solve a difficult problem is to think about it for a little bit and then not think about it for a while.
Later when I'm walking or in the shower or just waking up from sleep, a solution far better than any I came up with using focused thought will suddenly appear nearly fully formed in my head.
As a 39 year old programmer the most important thing I've learned is that my subconscious brain is way smarter than my conscious brain and the best way for me to solve a difficult problem is to think about it for a little bit and then not think about it for a while.
Later when I'm walking or in the shower or just waking up from sleep, a solution far better than any I came up with using focused thought will suddenly appear nearly fully formed in my head.
I've had that experience, and it's truly awesome. But I've never figured out how to make it happen on my timetable. :)
Agreed. For me however I push myself to talk to others I respect about my work. This forces me to articulate what it is that I'm doing and why I'm doing it the way I am. I found this technique priceless.
Indeed--I find it works best when the person I'm talking to doesn't know anything about software, so that crucial points don't get hidden beneath a layer of shared abstract understanding.
Time to think is the most precious resource an analyst has.
Which is another reason why the "normal" 50+ hour working week is so harmful to startups.
If all you're doing is coding and sleeping you're not leaving any time for thinking.
Which is another reason why the "normal" 50+ hour working week is so harmful to startups.
If all you're doing is coding and sleeping you're not leaving any time for thinking.
The whole process of doing minimal viable planning is profound, and a huge time saver when working with multiple people. If people have a rough idea of how the code will interface it helps them avoid lots of churn that doesn't really have any benefit.