
Lessons Learned in Software Development - henrik_w
http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/
======
bpyne
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
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.

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

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

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

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

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

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

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

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

------
sarreph
IMHO, the strongest points:

6, 9, 18-22

