Lessons Learned in Software Development(henrikwarne.com)
henrikwarne.com
Lessons Learned in Software Development
http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/
10 comments
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 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.
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.
> 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 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.
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.
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.)
I would also add working out your security model early (e.g., Which users have access to what functions in your application.)
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
6, 9, 18-22
No myths, no buzzwords, no methodologies. This is good, solid advice.
Great post! Tons of useful information in an easy to digest format without too many words.
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.
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.
> 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.
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.
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.