
Think first, code later - steverydz
http://24ways.org/2012/think-first-code-later/
======
R_Edward
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.

~~~
georgemcbay
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.

~~~
R_Edward
I've had that experience, and it's truly awesome. But I've never figured out
how to make it happen on _my_ timetable. :)

------
glenjamin
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!

------
strictfp
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.

~~~
Silhouette
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.

------
fitzpasd
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

~~~
ramayac
Don't forget to document too :)

------
jhartmann
While I'm not sure if I agree with every detail here, great article. For
example I think the coding to design thought process has served me very well,
you just have to have the right attitude about it and be willing to throw it
away. My way to critically think is to put pen to paper, but other peoples
brains might not work that way.

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.

------
johnpolacek
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.

------
zachallia
Code. Think (on the toilet). Code.

