Personal blog of Alexander Murmann. Software Engineering, book reviews
My current setup uses mostly Claude Code to write code which I then review line-by-line before it gets commited. However, a while ago I got curious and had Codex review it first. This was a huge success. Codex found a lot of issues before I ever took a look. Time safed for me! Some of the issues also were issues I am not sure I would have found at all if I am honest. Since this was useful I made…
“You are not allowed to ask for better people. The right system makes the wrong people do the right thing.” — maybe Russ Roberts on Econtalk1 If you follow any discussion about AI coding agents, you’ll notice a strange disconnect. Critics point to real weaknesses. Accumulation of dead code, bad architecture, etc. Proponents claim they’re 10x more productive and can’t imagine going back. I think…
This document is heavily influenced by a similar document Ben Horrowitz wrote many years ago for product managers and that was also printed in his book “The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers” as well as on a modified version that was co-authored by David Weiden The original article was recently discussed on Hacker News. Someone mentioned a version for…
As part of my series on trade-offs in software development, I want to discuss what might impact how much and what internal documentation a team should write. As with any piece of this series, many things in here might not matter to you and your team. Yet something that’s a key factor for you, might be missing. The world is complex and diverse, but this article will help you get thinking about the…
There is so much good writing about best practices in software development. There are articles telling you about the virtues of test-driven development, refactoring, different types of documentation, formal verification, Agile, but also technology choices. I wish there was more discussion of the trade-offs these practices make and how the context in which you apply them affects their value. This…
Over at simplermachines.com Nat Bennett published an excellent draft article on what management at Pivotal was like. Every choice comes down to trade-offs. As Nat pointed out, these practices originated in a consulting environment. I want to look at what practices translated well into other contexts and why or why not. Hopefully this will allow others to pick the right practices for their…
In this post I will be going over basic communication practices for new managers. Embracing these practices will help to Make your point Avoid creating a unsafe work environment Avoid upsetting your team If you have managed people before this will be boring for you. Recognize the power dynamics Getting an email from someone with an intimidating title can create stress. No matter what the content…
During the first half of my career I mostly worked on SaaS products. When I started working on a on-prem system with many large enterprise customers, I quickly learned a few important differences that changed what tradeoffs need to be made every day: Addressing Bugs SaaS: Our dev team develops a fix and deploys it On-Prem: Our dev team develops a fix; we make one or more patches available to…
TL;DR Many companies still follow policies from a pre-remote world Remote labor will be it’s own market The remote labor market will set a new floor in many locations Roles that must be in a specific location still might be able to command a higher salary than the remote equivalent Time zones might end up still matter, even for remote roles. Every few weeks an article like this one will pop up…
Hacker News recently had a discussion of a fairly popular Tweet on the meaning of SemVer. Absolutely. The thing about semver major version numbers are that they don't mean new stuff, they're a permanent reminder of how many times you got the API wrong. Semver doesn't mean MAJOR.MINOR.PATCH, it means FAILS.FEATURES.BUGS— Will McGugan (@willmcgugan) August 6, 2021 There is a lot of truth in…