This post originally started off with a focus on solely perfectionism. The ironic part is in the quest to perfect the post, I took a step back, and realized it should focus more on the balance and continuous battle between knowing your craft and perfection. Full circle…
I’ve spent countless hours doing it. Staring at my screen even though I know what I’m working on is complete. But is it? You know, that feeling when you keep working on something until it’s “perfect”? Yeah, the compulsion is overwhelming. And if you’re someone that’s experienced it, you know the extremity it’s holding you back and actually doesn’t help you to make any progress at all.
One recent scenario a couple of months ago stands out to me. I was working on an accessibility feature for Iris and wanted to ensure it was perfect (code-wise). I changed the implementation of the feature 4 times. The 4th time? That time I was really satisfied with the result. And then I realized, I did it again.
Being introspective in both worlds
Programming is a craft and when I’m working on a refactor or building a new feature, I always try to find the easiest and most elegant solution for the problem. It’s a weird combination since many people confuse easy with being scrappy but that’s not the case. Many times in programming the easy solution to a problem is the most elegant as well.
The last couple of years I’ve tried to not focus on everything being perfect for a variety of reasons. The main work-wise being : I’m working on mobile products and the feedback loop is so immediate I need to ship early and often so I can receive feedback from users and iterate on the product.
My recent behaviour got me thinking though. Why am I trying to keep up with this behaviour even though I know it’s not good for me? Why now? What triggered that feeling of mine?
You see for 3 years now I check in with myself regularly, try to understand what makes me uncomfortable and why under certain circumstances I feel stressed, annoyed, etc. In other words, I try to understand myself better.
After I finished with the 4th implementation and I was satisfied with the result, I checked in with myself and asked: “Why did I have to change the implementation of the feature 4 times so I can be satisfied with it?” And then it struck me.
My code was a reflection of my feelings at a specific moment in time. I remembered the time I was working on the feature I was feeling super tired and life was heavy. A lot of things were compounding at the time. That made sense and I was pretty happy I was going somewhere with this “exercise”. But something was still a bit off. I knew it wasn’t just that.
Digging a bit deeper and I thought of trying something else. I saved the code of the first 3 implementations just for a reference and also to compare them with my 4th one. So I decided to open a PR and before I hit Create a Pull Request I reviewed my own code. I tried to ask some questions and see if the answer was a Yes or a No.
- Is this API testable?
- Can someone work on that implementation and improve it in the future? In other words: Can the code be understood by everyone?
- How easy or hard is to break things working with such code?
Well as you might have assumed, it was a pretty hard NO for every single question. Then I was sure I had to revisit the problem and see if I can come up with the better solution. I followed this method every time I worked on that implementation. The 4th time the answer was a YES for every single question and I was happy with the result as well.
Was it my need to perfect or was it my growth in craft as an engineer subconsciously forcing me to dig deeper?
Work experience and code quality
I was at the point where I started connected the dots. If I wrote that code 4 years ago when I was starting out I would be more than happy with even the first implementation. So what changed? Experience. All those years I got a lot of experience working with other engineers and on my own projects. I’ve been introduced to a lot of new concepts, have seen beautiful, well documented and easily understandable code. And most importantly, in doing all of this, I’ve learned to ask different questions.
The code I wrote a while back, now it seems really bad but then it was the starting point for me. Time passed and now I expect a lot more from the code I write and from myself. Yeah code’s not going to be perfect by any means but still I can apply some principles and make it a lot better.
Perfectionism was what led me to be relentless and discontent with my work and my understanding of the craft allowed me to see what caused that discontent and how to fix it. In working on myself, I’ve come to discover that any extreme is never healthy. Extreme perfectionism would be my downfall but paired in a healthy dose with my ability to truly learn the fundamentals of my craft as an engineer have helped elevate me in a multitude of ways – not only professionally, but personally as well.
What do you think? Are you a perfectionist yourself? and how you deal with it? Let me know - along with your questions, comments or feedback - on Twitter or email.
Huge thanks to Cat Noone for proofreading the post.