WTF Per Minute — An Actual Measurement for Code Quality

Have you ever heard the joke about a way to measure code quality is using WTF/minutes (WTFPM), which stands for “Works that Frustrate” that the developer can read per minute.

It’s kind of a common thing that exists in many places. And I’m dead certain it happens in our workplaces as well.

Now, the real question is how to cope with this and reduce the number of WTF/minutes that the developer reads, whilst we have no capability to make improvements to our codebase.

There are several activities we can do, including:

1. Let the others review our codes. Make a code review every time we finish working on something, this can be done through the pull request then ask our colleagues to provide feedback and comments to our code. But if you’re the kind of person who likes a real-time discussion, then do pair programming. Two heads are better than one, right. With this kind of technique we can develop faster and higher quality code.

2. Standardize all code and stick with it. Don’t reinvent the wheel and Don’t let the standardization of every project be made based on the demand of every developer who is responsible for the project, because the submission that occurs will create a high learning curve. Especially if it turns out that the standardization made by the developer is not optimal, then it will be a fatal backfire for us

3. Practice, Learn, Practice. Yes, to make good code, we are required to learn from previous mistakes, but this is inadequate. We have to learn new things, learn a lot with more skilled seniors, and put this into practice. As an analogy, even though we know the theory of painting, we may not be able to paint.