When I started out programming, I was so happy just to get things working. I was sometimes a little mystified when some book or blog or coworker told me that one way of doing things was better than another way. The joy of seeing my little creations run on their own, reacting to different situations perfectly every time, was so much greater than what I felt when looking at “good design.” Their corrections often seemed like “six of one, half-dozen of another.”
Then years went by. I read code that made things really obvious and code that was filled with lies, surprises, and coincidences. I tried to extend code that had the wrong abstraction. I spent a day writing a feature that got the job done, then spent a month chasing down bugs and explaining to my poor colleagues how it worked.
The more times I felt the pain that followed bad design, the more problems I saw in the code I read and wrote. Now I understood what people were talking about when they critiqued the tangled code I wrote starting out. But this didn’t feel like a great trade off emotionally. The joy of getting things to work was dulled somewhat, and in its place was a lot of dissatisfaction and criticism.
At a certain point, I started to re-evaluate my attitude toward “bad design.” Rather than just noticing the pain it caused, I could decide to focus on having encountered a new example of what good design can fix. Part of this shift was deciding to write articles for this blog. One concept I use a lot is that your code should “express truth, not coincidence.” I’ve been working on an article about it for a while, but I haven’t quite found the right examples. When I do find one though, I get really excited! Examples are what turn something from an abstract concept into a tool that can be used. They allow me to show my coworkers what I’m talking about, and being understood for whats important to us is one of the great joys in life.
Thats the line of thinking that has helped me turn myself into a Happy Perfectionist. There’s joy in discovering a new generalization, or finding a new example of a concept I’ve been chewing on. When I focus on how terrible things are, I get bitter and I can’t expect anyone to be excited about hearing me complain all day. When I’m happy to find a way of making improvements, people come away from code reviews feeling better about themselves and the work we do together.
As software developers, we create abstractions that allow for automation. A good general principle like “replace conditionals with polymorphism” does a similar thing for our thinking. Presented with problem, we now have a shortcut we can take to get to the solution. The joy I used to get from seeing the results of my code, I now get from seeing the results of my mental abstractions. Work feels like a treasure hunt, where I’m looking for new principles that will help me write better software and communicate more effectively about software design. I spend more smiling, and less time mumbling profanities at my screen. I’d say thats an improvement.