Tenacity in Programming

Introduction

Unhealthy relationships can be formed with programming rather easily despite your enjoyment o of it. I would like to address some of my run-ins with certain negative feelings surrounding myself and programming. This isn’t supposed to be some perfect solution to the problems but just my experience with them and possible ways of combatting them.

Imposter Syndrome

Despite showing that you are good at programming, it can feel as if you’re a fraud waiting to get found out by people who are actually good at programming. Blog posts similar to the ones I make can contribute to this feeling. Seeing all of the impressive things other people do can make them seem much better than they are.  This is especially true when they gloss over the time and hard work they put into it. To help dampen my effect on such negative feelings I will briefly go over some challenges I had regarding the water simulation and pathfinding projects.

Getting the water simulation to the state it’s in now took about two months. It took two weeks to get the initial very basic simulation working with another two weeks of debugging and adding additional features. Despite having some compute shader experience, converting the code into shaders took an additional two weeks. Implementing SIMD operations also took another two weeks as I hadn’t heard of SIMD until that point.

The pathfinding implementation took only about two weeks total. Shortest path algorithms are covered quite a bit at my university and in programming practice websites. The reason why the base pathfinding part was so easy was because I had done it many times before. The path compression and further optimizations took the longest as it involved things I had never done before. I had only thought of the grid reuse strategy a few months after first implementing the algorithm while debugging it.

The point is that these projects didn’t happen in a day. They took quite a bit of time, effort, and prior experience to get right. They also had plenty of bugs an unexpected behavior that comes with exploring new territory. Being a good programmer doesn’t mean doing everything right on the first try or never making stupid mistakes.

Burnout

I’ve heard that burnout is partially caused by your brain thinking that what you’re doing isn’t worthwhile. I believe that acting on your burnout is important in ensuring it doesn’t happen again. Even though big changes might have to be made to escape burnout it’s up to you to figure out if they are worth it. I know for me the changes I made definitely were worth it.

Before I started making my own game engine, I felt a little burnt out with game development. It wasn’t as fun as it once was and I didn’t know how to improve at it. I didn’t have much passion left for writing little C# snippets in Unity. When working on the game engine, I am more productive than ever before and really enjoy the challenge and control it brings.  

Stress

When faced with a hard problem, it can be tempting to just try to pound away at it until it becomes solved. This strategy is pretty risky as it can easily go wrong and leave you feeling like an idiot. Solving some of the hardest problems I have faced has involved healthy gaps of time where your mind can relax. The water simulation and pathfinding projects weren’t all done in short time span but with month long gaps between sets of progress.

Conclusion

Programming can get kind of depressing if done incorrectly. It’s both important to not put so much pressure on yourself and to work hard to learn and improve your skills. Solving hard problems is a great way to feel like what your doing is important and that you’re good at it. If you feel down about yourself I recommend doing something to more objectively assess your skill.