Clever code might be a source of pride for some, but it’s also the bane of clarity — just ask Andrew Proksel, director of site reliability engineering at BlackLine.
“Clever code is fun to write and leads to fantastic bikeshedding conversations,” Proskel told Build In LA. “But the fun factor is rapidly diminished the next time it needs to be updated.”
What is bikeshedding?
While there is a time and place for penning an artful flourish of brilliant code, the mental gymnastics required often hamstrings large-scale projects. Instead, Proskel challenges his teams to “get less clever” and think more simply.
“By ‘clever,’ I mean authoring code that, while interesting or even ingenious, is hard to digest, hard to maintain, or uses programming concepts that are unnecessary or obscure,” Proskel said.
The goal is to streamline the code-writing process and create a product whose beauty lies in its legibility and scalability. Built In LA sat down with Proskel to learn more about how to put the powerplant ahead of the bike shed — and prioritize clarity over cleverness in coding.
BlackLine strives to automate and control financial close processes for midsize and large organizations.
When it comes to writing clean code, what are some best practices you follow?
Software engineering is when programming becomes a team sport. With that in mind, writing clean code is analogous to being a good teammate.
I believe good teammates should focus on writing code that is:
Stateless. State is hard, and avoiding it can be even harder. But your team and future self will thank you if you can avoid it wherever possible.
Easy to understand. That doesn’t mean over-commenting the code or spending hours finding the best naming pattern. It means using those tools and more to make your code understandable by the next human who will read, use and extend it.
Well-tested. Test what matters using the less complex process, don’t target a number. Target value in the test.
Writing clean code is analogous to being a good teammate.”
How does your team make clean code a priority?
Prioritizing clean code is difficult. Code reviews can quickly fall into the “Looks Good To Me” (LGTM) pit. Pair programming can get over and underused quickly.
Instead, I prioritize my teams and our cooperative teams’ clean code by being stewards — leaving the code we touch better than we found it. This incremental, collaborative process seems to be the easiest to sustain. It allows work to get done without establishing draconian processes and empowers team members to find what works for them. It also lets them figure out how to be better teammates based on their own strengths.
