Think about that for a moment. How long has it been since programmers have had to worry about the size of their code? Front-end developers do this all the time, but to anyone else it’s crazy.
I don’t think like that anymore. My rubric for good code is how well others can readily understand it. I no longer consider something useful until someone else has successfully modified it. And still, the finish line keeps speeding away from me. There is always a way to be better.
When I moved from a large place like Yahoo, where I rarely had other kinds of engineers looking at my code, my code habits had to change. Other kinds of engineers — especially more polyglot engineers — were looking at my code. I found I had to explain myself constantly.
Their acceptance of my crazily optimised code was tepid. Over time, the craziness started to wear on me. Every time another programmer had to interact with my code I had to explain everything to them. I felt like a baboon pounding my chest then leaning over and saying “see, it’s simple, right?” — it wasn’t! And I had to admit, the blame did not lie with the language or the environment. I am sure that I had become lax in my syntax, and my code wasn’t as clean as it used to be. When there is no one to call you on your habits, you slide a little.
I was the only front-end developer for a while, but even that wasn’t the worst part. The biggest failure was forcing other kinds of engineers to accept the craziness, and not taking their code habits into consideration. I thought that was how it has always been done, and will forever be done. My coworkers enlightened me. In a small but diverse team, shared code habits might be the most important key to understandable code.
During the transition I began to realize the reasons other programmers reel away from front-end code. Engineers who are fully capable of writing code for the web will be turned off by the syntax. It might even stop them from writing web code. Then, even if they do write some code, they switch off their analytical brains when using something they don’t like. They’ll just do what they need to do to get the job done. You won’t get them to help you make the code better. In the end you took someone who could have been a net positive on code quality, and created a net negative on code quality. And for what; smaller code?
One of the best things we did was to switch to intermediaries. Uglify.js is a great example of an intermediary code processor. We have begun to use a number of these tools. Basically, you can use something like Uglify.js or CoffeScript to bridge the gap of understanding. You can turn something that people found ugly, into something beautiful. And then you start to switch the editorial part of their brain on.
None of this means that I don’t care about optimizing code, or keeping things small. This is important for everyone, and especially so for high-traffic websites like Yahoo. It is not a means to an end. It’s that 90% of my checklist has been replaced by code compressors like Uglify.js. I don’t know what I would have done at Yahoo code reviews if we started using Uglify.js. It would have been a lot of latte sipping, and crying as the company crumbled around me.
We should have used better tools, and spent more of our time learning better ways to code.