I'm Anders Sundman, and this blog is a collection of my musings on programming, software engineering, and craftsmanship. I write about how we developers conjure things into existence from technical, social, and philosophical perspectives.
After writing code for 30+ years, I'm starting to get the hang of it. Currently, I'm building eye-tracking software as the principal architect and developer excellence lead at Tobii. My experience as a developer is mostly in systems programming and working in the embedded space with signal processing. However, I've also built distributed backend systems (before they were called microservices) and DDD-inspired desktop applications.
For the past 20+ years, my native languages have been Python and C++. Lately, I've been flirting with Rust, and I'm loving it!
Code review is an indispensable practice in any self-respecting software engineering organization. We get higher quality code and knowledge sharing. It's awesome. But, it’s also not awesome. To be honest, it can be a nightmare. Sometimes we get blocked for days waiting for approval or end up in a never-ending context-switching game of review ping-pong.
Class design in C++ is hard. Really, really, hard. I love C++ but, sadly, all the defaults are wrong.
Your coding conventions, branching strategy, and review guidelines may seem like superficial policy hygiene. But these, along with seemingly random and disconnected activities like fixing a flaky unit test, are connected and can have a profound impact on how your team works with code.
Software development is about making choices. But available options change and so do the tradeoffs. Are you up to date with the best practices for creating a Python application in 2024? Let’s take a look at some great default choices.