Recipe for a bad programming day

Do you want to have an non-productive and bad programming day? I can help you! Keep reading, be my guest. Everything will go bad, don’t worry!

First of all, and for this particular example: you need a bug. A non trivial one and a bit obscure is better. Let’s say that to test if the bug it’s fixed you need to do a few steps involving the mouse.

Recipe for the bad day:

1. Ignore your existing unit tests. Don’t even compile them
2. Don’t add a new unit test to reproduce the bug. Anyway, you have some steps (more or less) for this, right?
3. Don’t think of the root of the problem. Just use the debugger and change some code here and there (try changing multiple things at the same time)
4. Don’t think of the consequences of your changes. Just change it
5. Use the staging servers for the testing, that ones that they are being changed too. Don’t write fake/mockups/double classes for the tests

When you are believe that everything is working: run the existing unit tests. See how a few of them fails. Start again. You can spend a full day or even more.

When tired of this programming by coincidence try a better approach:

1. Step back and think of: what’s the root of the problem? Ask yourself “Why” a few times, not only once (5 whys?)
2. Write a unit test that fails because this bug (this will help to understand the problem, possibly with an Eureka moment where you will see a very simple fix)
3. Fix the problem

I still wonder why I tried the incorrect approach that day.