Chief Technology Officer of ConnectWise.
Ask your average manager what they’re looking for in an employee, and you’ll get a set of standard responses: reliability, speed, results. These are all sensible answers. And yet, there are some jobs where the conventional priorities don’t apply—where it can actually be harmful to incentivize rote, mechanical task completion to the exclusion of other ways of working.
Coding, I think, is one of those jobs.
The argument I’m about to make hinges on one key contention: namely, that coding is an art form, closer in spirit to poetry than what generally goes on in an office setting. If that’s true—and I strongly believe it is—then managers need to reconceptualize how they treat their engineers. The impulse to get things done as quickly as possible is understandable and widely shared—but in a coding context, it can be deadly.
Why Coding Is An Art Form
To understand why coding is an art form, it’s worth examining the differences between good code and bad code.
Good code, in my opinion, shares a few key characteristics: It’s concise, it’s readable and it’s durable. The tech industry, as most people know, has one of the highest turnover rates of any sector. Good code is code that can be easily understood (and maintained) by the next engineer to join the company—even if that engineer could never have written the code themselves.
Bad code, on the other hand, is sloppy. The sense of being rushed and not properly thought through radiates off it like stink lines in a children’s cartoon. Ironically, despite this rushed quality, it’s often much longer than good code, filled with nested conditionals, shortcuts and redundant comments. It might get the job done in the short term and help the programmer meet their deadline, but it does the company no favors in the long run. The lights might work in a house with rushed wiring, but you can bet that renovations will be difficult down the line.
It is in the difference between good code and bad code that the art of the thing becomes plainly evident. As in, say, poetry, the goal of good code is to achieve the desired effect with a minimum of extraneous material. It requires thinking through the problem at hand and arriving gradually at the most elegant—the most right—solution.
Letting ‘Art’ Flourish In A Workplace Setting
Of course, a business isn’t an MFA workshop. Managers don’t want their engineers dreamily looking out of the window all day, lost in contemplation. There will always be deadlines to meet; a tech career will always be, definitionally, high-stress. But there is a way, I think, to balance these imperatives—to ensure the job actually gets done without accidentally incentivizing rushed, sloppy code.
Obviously, your engineers are just one node in a larger ecosystem, practicing their craft alongside product managers, customer experience experts and so on. Usually, all of these people are working on multiple projects at once. There are moving parts within moving parts, and alignment can be difficult.
To that end, before coders can really feel the freedom to work through a thorny problem, the whole company needs to be synced on priorities. As any artist—whether a painter or an engineer—can tell you, it’s impossible to truly create in the midst of chaos. Clearly communicated expectations and priorities can help create the mental space for quality work to get done.
That means, for one thing, being a bit more flexible on timing. In too many workplaces, the factory mentality prevails. This might make sense when you’re making widgets to order, but code is a different beast: Done right, it takes as long as it takes. You can absolutely speed up the process somewhat by clearly communicating the desired time frame and helping to clear the engineer’s plate of extraneous tasks. But you do have to accept the fact that things can only be sped up so much. Building realistic expectations into your road map will only improve your product down the line.
And speaking of extraneous tasks: It’s important to build some degree of autonomy into the process. Make sure your engineers have a clear sense of what’s needed and then let them work, without endless check-ins, meetings or planning sessions interrupting their workflow. In coding, as in art, it is in the flow state, the state of pure and multidirectional concentration, that the best work inevitably gets done. Interrupting that state to discuss the work at hand might make the manager feel productive, but it is not conducive to actual productivity.
Of course, if coding is an art form, it’s an art form with incredibly high stakes. A bad novel might tank an individual writer’s career. Bad code can leave your company open to malicious actors across the globe. With so many endpoints now outside the network perimeter in the WFH era, the need for flawless, secure code is higher than it’s ever been. It might take a little longer to produce, but that’s often the cost of getting things right.