For the first time ever, I was laid off, and had to find a new software developer job. I managed to find a new one, but it took longer than I thought, and it was a lot of work. I was in contact with 30 companies, got a no from 8 companies, no reply from 6 companies, and offers from 3 companies. Here is what I learnt from the process. Laid Off At the end of October last year, I lost my job. I was completely surprised, but in retrospect, maybe I shouldn’t have been that surprised. The times were getting tougher, and many companies had been laying off people during all of 2023. If the company is ..read more

“Software design is preparation for change; change of behavior” Tidy First? is a new book by Kent Beck. It is a short little book, only about 100 pages (and lots of white space on them), but it contains some deep insights about software development. The book has three parts, going from concrete to abstract. First there is a list of 15 tidyings, which are small refactorings. The next part, Managing, discusses how and when to perform the tidyings. The final part, Theory, presents a great framework for how to think about software development, using the concepts of time value of money and optional ..read more

I really like this quote from Jeff Bezos: “Anybody who doesn’t change their mind a lot is dramatically underestimating the complexity of the world we live in.” Lately I have been thinking about what I have changed my mind about in software development. Here are the things I came up with: Self-documenting code. I used to think that the names of the classes, methods and variables should be enough to understand what the program does. No comments should be needed. Over the years I have realized that some comments are needed and useful. These days I add comments when there is something particularl ..read more

Two months ago, I was a guest on the Maintainable podcast. The first question the host Robby Russell asks is “What are a few characteristics of well-maintained software?”. This is such a great question, and I thought I would expand a bit on my answer from the show. That software is well-maintained only matters if you need to change it. If you never have to change it, it doesn’t matter how it is done, as long as it works. However, in pretty much all cases you do need to change it. For me, well-maintained means that it is easy to change. And for the software to be easy to change, it must first ..read more

I really enjoyed reading Algorithmic Trading: A Practitioner’s Guide by Jeffrey M. Bacidore. Before starting, I imagined it would cover various strategies for trading in the markets, along the lines of “buy on this condition, sell on this condition”. But that is not what this book covers. What trade to make is always a given, typically from a portfolio manager. Instead, the book is all about how to make it happen, almost always by portioning out the trade little by little, while trying to get the best price. It is fascinating how many factors come into play when implementing this seemingly sim ..read more

Every time I hear about software maintenance as a distinct activity, I cringe. That’s because it is based on the outdated notion that first software is developed, then it is maintained. But that is not how software development works today. Software development does not have the two phases development and maintenance – it is a continuous process. Software maintenance is simply software development. It is fairly common to come across the concept of software maintenance. Recently I have seen it in posts on LinkedIn (how developers leave if they have to do maintenance), in books (“it is well know ..read more

A few months ago I switched to working in Go. Before that, my main language was Python for many years. The change to Go has been very smooth, without any major surprises or stumbling blocks. This may partly be because in the past I have also worked in both C++ and Java. Even so, Go (the parts I have used so far) is quite straightforward. Before I started in my new role, I read through The Go Programming Language, which is quite good. Otherwise I have mostly used online resources when I have needed to learn how something works. Both A Tour of Go and Go by Example are good. Here is a list of thi ..read more

I recently finished Effective Software Testing – A Developer’s Guide by Maurício Aniche, and I really liked it. I have been coding for a long time and I think I have been writing pretty good tests for the features I have implemented. Even so, I found this book quite valuable. Particularly the chapters on how to systematically come up with test cases based on the specification, inputs, outputs and the structure of the implementation. The book also covers many other common topics relevant for developers writing automatic tests, such as: test-driven development, mocking, designing for testabilit ..read more

There seems to be an established truth in programming that code reviews find a lot of bugs. An example is chapter 18 (Modern Code Review) in the book Making Software. This is however not my experience – I rarely find outright bugs when reviewing changes. But I still think code reviews are useful. Below are my thoughts on the value of code reviews, and how to make the process efficient. Very few bugs found. When I review code, it is quite rare that I find bugs. By bugs I mean cases where the program would do the wrong thing. I don’t count things like poor variable names, missing test cases, or ..read more

I really liked A Philosophy of Software Design by John Ousterhout. It is compact and short, only 170 pages, so it is a quick read, but it contains many good ideas. The focus is on how to structure systems to make them easy to understand and work with. The author is a professor of Computer Science at Stanford, but he has also spent 14 years developing commercial software. What I Liked The Most Complexity The book starts with a good chapter on complexity. The author defines complexity as anything related to the structure of a software system that makes it hard to understand and modify. There ar ..read more