Lessons Learned in Software Development

http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/

by henrik_w • 11 years ago

165 12 11 years ago

henrikwarne.com

tempodox• 11 years ago

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

bucky• 11 years ago

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

paco3346• 11 years ago

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.

mcdougle• 11 years ago

Give praise to specific team members but take the hits as a team.

Yep. That goes beyond just development -- that's a huge management/leadership technique and is very important for any team, regardless of what they're trying to accomplish.

edejong• 11 years ago

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.

bpyne• 11 years ago

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.

amyjess• 11 years ago

I like to call this the House Method.

Because it's been established that Dr. House can only work if he has someone to bounce ideas off of, even if that person is the janitor.

sarreph• 11 years ago

IMHO, the strongest points:

6, 9, 18-22

McUsr• 11 years ago

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.

tux• 11 years ago

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.

pjungwir• 11 years ago

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.

anotherevan• 11 years ago

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

Lessons Learned in Software Development

Related Stories