Burnout is common in our field [1] [2] [3]. If you work with programming for long enough, I am sure you already experiment some level of burnout yourself. So the question is, how not to burnout working on hard problems?

Over the years, I have built a reputation as a go-to person for hard problems. Problems that other senior developers have already given up or say it is not viable to implement. Here, I share some secrets to work and fix these problems and not burnout on the way.

First, let’s define what hard problems means?

• Problems that will take too much time to fix (big refectories, migration, etc.).
• Bugs hard or impossible to replicate, requiring weeks of debugging.

I have seen a pattern in the last 15 years of working in this field. Even senior engineers will burnout in the face of challenging problems.

If I had to choose one single metric to find what burns developers out it would be big feedback cycle. Bigger feedback cycles will lead to burnout more often.

Think of an imaginary situation

• When you approach a hard problem, you may change multiple places in the application.
• After 3 or 4 weeks, you realize you are not near the end and still changing more and more code each day.
• By this point, you open an Merge request with WIP, and you can barely remember why you changed half of the files you changed up to this point.
• You realize that other modules need changes to accommodate the change you need.
• You get yourself thinking about how many tests you will need to make sure no regression was introduced.
• The Merge request is already too big, and you start to think if you will ever be able to get it reviewed and approved by the other senior developers.
• Urgent bugs and tasks start to take your attention, and you need to be days off the project, and you feel lost and hopeless when you get back to your task.
• At this point, lots of people drop the project and realize this change will not be worth it for the moment

You consider leaving the project, the company, and changing teams and feel like a failure because the project (the task you are working on) did not succeed. Even worst than that, the problem you were trying to solve will still exist until other people decide to try to fix it.

No one wants this outcome, so how can we avoid it?

1. The key to success is to measure often!

Start by making sure your dev environment is ready for the task. Set up dependent services. Make sure your editor, linter, and any other tools you need are in place. Make sure not to spend too much time on this. 4 hours is usually enough.

You do not want to lose focus after being in the middle of a relatively deep debug just because you need to run one extra docker container.

2. Split the problem into smaller problems

Start by defining smaller parts of the problem. Define one milestone for each part. Then, define how you measure success for each part. Ideally, success would be a test passing.

3. Grantee each step won’t regress what you have already implemented

Every problem you fix left one test passing, guaranteeing what you implemented won’t regress. Run this test every next step.

This way, you guarantee the next steps are progressing. You don’t want to be worried about the next change if it will break what was already fixed.

4. Bring others to help from time to time

If you are stuck for more than one day, bring one person for a couple of hours to help. Sometimes explaining the problem to others is all we need. Start explaining from the test. The test will concentrate the conversation on the problem you are trying to solve at the moment.

5. Show progress and pair program with others often

Demo your progress to others at least once every two weeks.

• Show how it is going where the weak points and the strong parts of the implementation.
• Tests are passing
• Tests failing etc

Each test passing will play an essential role in your motivation. When you feel insecure, run all the tests, and they will pump confidence that you did not break anything up to this point.

Every time you feel you are not making progress, stop for a while and write new tests.

Tests are usually easier to write than the fix. When you implement a new test, it will feel like progress and give you confidence to move forward.

6. Takes notes: Keep journaling about the task you have been working on

Take notes very seriously. For hard and long tasks, there will be leads that you will follow and abandon during the time you worked on the task. If you don’t take notes, you may repeat investigations repeatedly.

In this image I am showing an example of my notes related to each task I have worked on:

Use notes as your second brain.

• What have you already tried?
• Useful queries to find data.
• Links to blog post questions or documentation that are useful.
• What have you did not try yet?
• Daily notes on progress (write at the end of the day).
• To-do list left behind and important information you want to remember when the Merge request is open. The notes will relive your brain from remember all that information. And it will serve as a track for what you have tried so far. With that, your brain just needs to focus on what you are doing now, the past and future you know is safe on your notes, and you can go back and read when needed.

Keep these notes for the future. Over time, you start to have the personal collection as tricks that you can search. For example, I add an [mono] and [query] to my notes every time I add and useful query to any task. This way, I can search for that keyword in the future if I remember I need a query that looks like something I did in the past.

Make sure your notes are safe and versioned. I take notes with vim and save them on a private personal project with Git.

7. Learn how to identify the diminishing return point

This one will require some experience. The diminishing return is the point where the changes you are trying to make will start to cause more problems than improvements.

It is not simple to see this at the start of the changes, but it is usually easier to see when you are already in that situation. If you are working for two days on a problem and it seems like nothing has changed, will two extra days actually make a difference?

Here again, the tests are your ally. When you get to a point where nothing else makes sense, if you have the past successful changes covered by tests, it is easy to return to a working state. The last working state may be a deliverable, and you may still be able to deliver partially the project. If you don’t have tests to cover your ass at this point, your energy level and morale may lead to giving up on delivering anything.

Conclusion

Yes, tests are the key not to burnout. To keep you motivated. Reduce the feedback cycles from weeks or months to one keystroke.

The tests will also help you when you have the time to integrate the change, others will feel more comfortable reviewing your code from the tests, and they will know the code works.

I am sorry if your current project does not have a test first mentality. Be you the first one to start doing it then. I have never seen a Merge request rejected because it has too many tests.

If your project does not have space for tests, write the tests in secret. Once you have enough tests, it will look like you have superpowers. When people ask how you are so productive, you can then show them your tests and scripts and make them the standard for the project.

Avoid burnout. Make tests first. Take notes as you make the progress. Collaborate with others. See you in the next post.