These days it is common to hear arguments that software development is becoming gig based. In other words, companies will not hire programmers for permanent positions. Instead, they will put together temporary teams of independent contractors from anywhere in the world to complete projects.
This is no doubt true for some software development tasks. However, for companies whose core product is software, this model makes very little sense. Continue reading
Last month we finished reading “The Effective Engineer” by Edmond Lau in the book club at work. It is a great book full of practical advice on how to get more done as a software developer. In fact, it is one of the three books I think all programmers would benefit from reading (the other two are Code Complete and The Pragmatic Programmer).
Recently @ThePracticalDev asked people on Twitter for typical things programmers say:
There were a lot of great answers. Here are my favorites: Continue reading
For several years now, we have been running a developer book club at work. We pick a book relevant to software development, and read a chapter a week. Every other week we meet for 30 to 45 minutes and discuss what we have read. It is quite popular and useful, so I thought I would describe how we do it, and why having a book club at work is a good idea. Continue reading
In the book club at work, we recently finished reading Release It! by Michael T. Nygard. It is a book I have been meaning to read for a long time, but somehow I never got around to it until now. It was written in 2007, and it is starting to show its age in several respects. Despite this, there is still a lot of relevant advice on how to make software work well in production.
In Learning From Your Bugs, I wrote about how I have been keeping track of the most interesting bugs I have come across. I recently reviewed all 194 entries (going back 13 years), to see what lessons I have learned from them. Here are the most important lessons, split into the categories of coding, testing and debugging:
Bugs are great learning opportunities. So how do we make sure we learn as much as possible from the bugs we fix? A method I have used for more than 13 years now is to write down a short description of the bug, the fix, and the lessons I learned.
Way back in 2002, I came across a blog post (that I unfortunately can’t find again) that described this method. I have used it ever since, and I believe it has helped me become a better software developer.
Every time I fix a particularly tricky or interesting bug, I take a few minutes to write down some facts about it. Here is an example of a typical entry: Continue reading