Lessons Learned in Software Development

All the advice is well-worth reading. Number 16 ("Rubber Ducking") is my particular favorite. It kills my ego every time, but the thought process involved in explaining the goal, attempted solution, and the problem seems to make the problem clearer. Explaining it in writing does not seem to have the same effect for me. It has to be audible.

I wish I would have had something like this when I first started developing. 90% of what's in here are things I learned over time (and some at great cost).

One I would add is to not throw a fellow dev under the bus when talking with a user. Give praise to specific team members but take the hits as a team. It helps build comradery when you see a colleague take the hit for you and builds a certain trust amongst the team knowing that others have your back.

> First understand the existing code.

I think it is a chronic weakness of even good developers to write too early. First read!

My first year programming a project manager remarked, "I've never heard a programmer praise another's code. It's always, 'This is crap!'". That really stuck with me, and I've tried hard to be charitable and to really understand things before making changes. It's served me well now that I consult and freelance, but it also makes me less patient with programmers who dive in to existing codebases and immediately start making changes. In marriages they say "Seek more to understand than to be understood." There is something like that in software too.

I would like to add to this advice to always start with pen and paper. To see your high-level design gives a different perspective, improves discussion and works much faster than changing your design in code. Furthermore, it's easier to spot common patterns, which improves code-reuse and naming.

This article should be "22 Developer Commandments" Just add "You shall ..." before each one :-) I'm proud to say, I've followed most of this from the beginning. Thank you for the article.

No myths, no buzzwords, no methodologies. This is good, solid advice.

Plus one for adding logging and error handling early. Seen a few projects made into a dog's breakfast trying to bolt error handling on later.

I would also add working out your security model early (e.g., Which users have access to what functions in your application.)

Great post! Tons of useful information in an easy to digest format without too many words.

It was really a great post, I haven't ranked any of the points he made. I liked especially the authors point of looking at the timestamps, and the lack of coincidence in stuff, and getting a good nights sleep.

IMHO, the strongest points:

6, 9, 18-22