It is not always possible to write pure functions. Still, the properties of pure functions can help us write testable code.

Don't let frameworks interlace with the domain code. Keep them separate and working with the codebase won't require super powers.

Unit tests are the playground where code learns to behave. If the code is both easy to test and easy to use, it has shown to be reusable.

Design the code so that as little as possible needs to change when the world changes.

Anti-work in an organization will spread to its customers. No defect is too small to lower the quality of life for people a bit, and combined it is an unnecessary burden for the often already disadvantaged.

What does too many stakeholders do to a piece of code?

Learning to refactor instead of rewriting preserves the domain knowledge build into the old codebase while it can keep making money. The skill of continuous improvement is important for developers, and might be neglected in a "rewrite" culture.

Being good at things nobody should ever have to do is a tricky thing. This is a text about wishing for a better world, also when you don't yet have the skills needed to perform well in that world.

A cognitive tool in shape of a list of things that often go wrong when writing code. Nice to have when you get stuck.

Test Driven Development (and unit testing in general) is easier when some things are avoided or encapsulated. Here are four problems faced when unit testing and their solutoins.

A list of aspects to consider when getting to know a new software project and assessing how easy it will be to work with.

Our mind also has ergonomics. Software interior design is about designing our code, and our systems around it, to make our work easier.

Three benefits from doing test first, one test at the time are: specific feedback, design guidance and finding the right amount of tests.

How Theory of Constraints leads us to move the verification step in front of the production step, and keep shrinking the batch size.

In test driven development the tests, even before they even test something, guides our steps. The trick is to take really small steps, and let code and tests evolve together.

Use a linter for your code! And fix all(!) errors and warnings. Your brain will thank you.

User research can save as much effort in the IT-industry as QA before a bottleneck does in manufacturing.