Postmortem culture

Things go wrong. This is something that we can try to control, anticipate an plan for. But ultimately we will fail and we won’t be prepared for it. If we consider the amount of interactions we have, the amount of changes by so many people, and the limited amount of resources we have, it should be clear that if we don’t hit some bumps, we’re just going too slow.

One thing that we can do though, is to better handle problems after they happen with a good postmortem culture.

Common project usage: Makefile API

It’s common for me to jump around between projects. For example, I may be working on a backend service and need to jump to a frontend SPA to help the team on some deadline or other specific goal.

But cloning a new project always gives me bad memories. Not being able to run the tests (or not having tests at all), not knowing how to start/run the project (it may have docs for it if I’m lucky). And the worst part: not knowing how to deploy/publish a new version.

First impressions: mutation testing

I was curious about Mutation Testing and the value we can take out of it. So I took an hour to play with it and try to understand it better.

What’s mutation testing?

In mutation testing we have a program that changes our application’s code and then runs the tests. If no tests fails, it means that we may have a problem. In practice this means that we don’t have a full coverage on that code. This is not about the typical 100% code coverage metric. Because we can have some code that is 100% covered and still find problems with mutation testing.