The Most Valuable Code Is the Code You Should Not Write

In my previous articles, I wrote about maximizing your competitive advantage as a human software developer against encroaching AI. I illustrated why it will always be hard to write useful software, with or without machine assistance. One thing I didn’t address is how all this may just take away the joy of writing code. I don’t mean your lovingly crafted Open-Source projects. Please continue doing that. I mean the enterprise behemoths we write and maintain for a paycheck. To recap the discussion about efficiency and effectiveness: if AI can write that code similarly well (right now, it's still an if), it will nearly always be cheaper than hiring you to do the job, as well as more reliable (no sick leave) and more flexible (unlimited overtime/no onboarding required). Sorry about that.

Mechanization relieves us of manual work that is either too strenuous, dangerous, or dirty. No medieval peasant liked pulling a cart. So, we used horses and other animals. We invented tools and machines, and not just for replacing muscles. Granted, while some mental labor can be mind-numbingly boring, most of it isn’t especially dangerous or dirty. There are uncomfortable exceptions, like social media moderation, but much of it is challenging and good for your brain. So why should we let AI do something that humans already like to do and do well, like writing screenplays or writing songs? A cynical bean counter would argue that it makes no sense to do anything by hand if the machine can deliver acceptable quality cheaper. There’s a niche market for hand-knit garments, but not enough knitters to keep the world clothed.

If you have a good employer, they’ll care about your health and well-being, but their prime concern is not to ensure you a non-stop joy of coding experience, especially not when AI can eventually produce it at a fraction of the cost. Code is a means to create value, but it is also a liability. It’s expensive to create and maintain if we can realize the same value with less (or no) code, so much the better. 

I don’t know when skills in traditional coding languages (with classes, types, variables, and control structures) will be obsolete, but I predict it will be well before my retirement. Until that singularity comes, traditional coding prowess (brain teasers like the Advent of code) will increasingly become another mental challenge that computers can do better. We practice it for fun or in competition with other people. Like chess and go.

Meanwhile, please keep this stuff out of technical interviews. It doesn’t matter anymore, and I don’t believe it ever did. Knowing how to write a shoddy implementation of an array list or a merge sort on a whiteboard tells you what, exactly? That you can re-invent the wheel. Congratulations, but I believe a more valuable skill for a senior developer is knowing when not to code. That’s why I present the no-code interview, based on a coding challenge where the wisest decision should be to leave well alone.

It could go like this.

The No-Code Interview

Interviewer: “Suppose we have a stand-alone application written in Java 6 with a very basic Swing GUI that reads an XML file, transforms, and enriches the data by doing several database lookups and produces an Excel report. It was built and maintained by a developer who left us a year ago. Our senior architect had a look at the code and decided that quality was seriously below par. It’s the usual spaghetti, with hardly any unit tests. How would you go about improving it to bring it up to a good standard?”

Applicant: “Before I look at the code base, I would first like to get a feeling of how urgent and how important this refactor is. Because they’re two different concerns.”

Interviewer: “How so?”

Applicant: “Well, my annual tax return is very important, but since it’s not due for another six months, it’s not urgent. Then again, if I want to get a theater ticket for tonight, that’s urgent but not very important. So, how important is this tool to the organization? How much benefit does it give, and how much damage can it do? What happens if users can’t access the tool for an hour? How about a day, a week? What if it produces wrong data? How many users rely on this? How often does it run? And with urgency, I mean, how long can we afford to postpone the work? Do the end users have a problem right now? Does it perform reliably in production? Have there been any incidents with it recently? How frequent are requests for change? How stable are the input and output specifications? Does it rely on any legacy technology that is soon becoming obsolete and needs to be upgraded? Or does company policy require it?”

Interviewer: “Very good questions. Let me summarize: the application is used twice a year to produce the input for an in-house questionnaire. The incoming file is a dump from payroll and is very stable. Feature requests come in three/four times a year. I believe it’s written in Java 6, and it runs on a developer’s machine.”

Applicant: “About these feature requests: how awkward is it to make changes?”

Interviewer: “Apparently, it’s a big hassle. We had two separate developers doing minor changes recently, and they both complained that they could have been done in a fraction of the time had the code been more readable.”

Applicant: “Were these feature requests similar?”

Interviewer: “Yes. It’s mostly adding or removing a column to the output.”

Applicant: “And yet developer number two still complained that it took too long. Is it fair to assume that developer number one did not document its process and didn’t do any refactoring?

Interviewer: Touché

Applicant: “That's your first small win already. But I get the impression that a full overhaul is neither important nor urgent, so I would not advise it. The effort should go towards making incremental changes less painful. Refactor with a focus on that.”

Interviewer: “I like your answers so far. Now, suppose I told you the tool is very heavily used, and errors are unacceptable. Say we’re a bank, and it calculates a percentage for a loan offer. An error could mean we over- or undercharge customers to the tune of millions. Feature requests are frequent and varied, and the company demands that we bring it up to standard. How would you set about it?”

Applicant: “How about unit-test coverage?”

Interviewer: “Less than 20%”

Applicant: “If an employer were that cavalier about such a business-critical component, I don’t think I’d want to work for them. So, I’m glad it’s only hypothetical. We need to tackle test coverage before we touch any sources. The risk of regression is too great if you start refactoring without it. Making detailed unit tests is probably not feasible if everything is tightly coupled. Let’s start with a single black-box component test. The code base is fragile, so with every change, we should ensure we haven’t broken anything.

Create a representative XML input file and a containerized database. Run the application once and take the Excel file it produces as a baseline. Now, whenever the component test runs the application with the same input and database state, the output should match the reference file bit by bit (unless it relies somewhere on the current date/time). Now, you can start decoupling file I/O and database access from the business logic and create proper unit tests without the risk of breaking anything. But since you’re adding tests as an afterthought, forget about TDD orthodoxy. The benefit of writing tests in tandem with production code is already gone. You’ll probably find that your single component test already boosted coverage by 30 percentage points.”

Interviewer: “My last question. Don’t you like good code?”

Applicant: “Of course I do. But I like useful software better. I’m sure there are great applications with terribly unclean source code under the hood. Same here. The code may hurt our sense of craftsmanship, but it’s not broken unless we have an acute or imminent problem. And that can happen after a well-intentioned improvement. Make these improvements only in response to actual feature requests. Timebox your efforts, in that case. It’s tempting to bring an F up to an A, but it’s rarely good business sense.”