I recently found out about the book Developer Testing – Building Quality Into Software by Alexander Tarlinder, and I immediately wanted to read it. Even though I am a developer at heart, I have always been interested in software testing (I even worked as a tester for two years).
I think the subject of the book, developer testing, is timely. There seems to be a broad trend where more and more responsibility for testing is given to developers. It follows from the move towards micro services, dev ops and the “you built it, you run it” principle. Another driving force is the prevalence of developer testing frameworks that started with JUnit and now includes many more. These frameworks encourage and help developers write automatic tests.
Despite this trend of increasing developer testing, my feeling is that many developers still don’t test their programs well enough. For example, they may test the “happy path”, but not the different error handling cases. That is why I was excited about this new book explicitly addressing developer testing. Continue reading
In my experience, code can rot in two distinct ways. The first case is code that hasn’t been used in a long time, but where the environment has changed so it is no longer possible to run the code. In the second case, the code still works, but has gradually become complicated and hard to work with. The first case is unusual, but straight forward to fix. The second case is very common, but unfortunately hard to fix if left for too long.
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
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: