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).
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
When I graduated from university with a degree in Computer Science, I wanted to continue and get a Ph.D. But I also wanted to work as a software developer, so I worked for five years in industry before going back to do a Ph.D. I spent one year as a Ph.D. student before deciding that I liked professional software development better. Even though this was many years ago, I think some of the lessons I learnt still apply. Continue reading
I regularly get emails from recruiters trying to get me to change jobs. Unfortunately, many of the emails are not very good, wasting my and the recruiters’ time. So here are 5 tips for recruiters on how to write a good email, as well as some advice for developers. Continue reading
Here is my list of heuristics and rules of thumb for software development that I have found useful over the years:
1. Start small, then extend. Whether creating a new system, or adding a feature to an existing system, I always start by making a very simple version with almost none of the required functionality. Then I extend the solution step by step, until it does what it is supposed to. I have never been able to plan everything out in detail from the beginning. Instead, I learn as I go along, and this newly discovered information gets used in the solution.
I like this quote from John Gall: “A complex system that works is invariably found to have evolved from a simple system that worked.”