Articles written for technical practitioners.

These articles explore how to solve specific problems. They assume you are the person executing a change in your own behavior. They also describe techniques for influencing your leaders and organization to make changes they can’t yet see.

Sadly this Legacy Code Works. How Do I Get Permission to Fix It?

I got a good legacy code question today in the Code by Refactoring Slack channel. We have a code module called the state machine which is poorly written and has no tests. We all (we the engineers) agree that we should rewrite the state machine from scratch. However, the current implementation ‘works’, and we are not adding states or other stuff to that module. Here’s the questions: a) Do we need to add tests (unit & integration tests) at all? If yes, […]

Naming as a Process (Article 1)

We all know naming is a pain in the ass and you can’t trust the names in your code. But it doesn’t have to be that way. Many people try to come up with a great name all at once. This is hard and rarely works well. The problem is that naming is design. Here are the things you are typically trying to do all at once while naming: Deciding the things the code should do Deciding which things go […]