Do you understand what it is all about ?

I want to be sure the title of the blog will not be misunderstood: when I say "Think before coding", I don't mean you should prepare everything before and the start coding like a robot. This is what is called waterfall model, and  and it has always been considered as as non-working model, even by its author.

Programming is not applying a technique. When confronted twice to a problem, the programmer should not use the same solution, but understand what make both problems so close and build something that solve this class of problems. It can be a simple helper function, a small library or a big framework. This is the DRY (Don't Repeat Yourself) principle.

We all learnt how to implement a Quicksort algorithm at school. When was the last time you had to implement it? Personally I use the Linq Sort() extension method and it does the trick for me.

If you have to implement it for a specific reason, it should be because you understood that your problem was not exactly the same as the one handled by existing implementations.

This is why programming is not about technique or algorithm, if you're smart enough, you can adapt almost anything to any language or technology.

There is still one thing that tools and technology can't do for you :  understanding.

Programming IS about understanding

• Understand the problems
• Understand the processes,
• Understand the people,
• Understand the other programmers,
• Understand yourself!

You should have a deep understanding of the problems and processes.

This is the base of modeling, wether it is domain models as in Domain Driven Design or infrastructure framework creation, through Separation of Concerns.

You should understand people.

Because they are the one that ultimately will use what you're building. People are usually hard to understand. This is all the matter about User Experience (UX), but even when programming a framework, you should understand how other programmer will use it and understand it, and how they'll build on it software for other people with their one expectations.

You should understand programmers.

You rarely write your code only for you, and you should write your code so that other programmer have the better understanding of what you intended to do, and what you understood about the problem you're solving by writing this code.

You should understand yourself.

Even when you write code only for yourself, you should understand what you wrote in the first place, as Andy Hunt and Dave Thomas say :

All Programming is Maintenance Programming

Bill Venners: You say in your book, The Pragmatic Programmer (Addison-Wesley, 1999), that "programmers are constantly in maintenance mode." Why?

Dave Thomas: All programming is maintenance programming, because you are rarely writing original code. If you look at the actual time you spend programming, you write a bit here and then you go back and make a change. Or you go back and fix a bug. Or you rip it out altogether and replace it with something else. But you are very quickly maintaining code even if it's a brand new project with a fresh source file. You spend most of your time in maintenance mode. So you may as well just bite the bullet and say, "I'm maintaining from day one." The disciplines that apply to maintenance should apply globally.

Andy Hunt: It's only the first 10 minutes that the code's original, when you type it in the first time. That's it.

But you should also understand how you do things, how you did things, how you changed, and how you will change in the future.  Things are moving so fast that you can not simply stay with your current knowledge and expect it to be sufficient in two years.