I once told software engineers on my team: “We’re not here to write code”. They were flabbergasted. But I strongly believe that our job is not to write code but to solve problems. It just so happens that for many problems, code is the best, if not the only solution.
We often get this backwards. We identify as software developers, we love writing code so we will write code whether it is needed or not.
Years of experience taught me to think about a problem before writing a single line of code. I usually try to answer two questions:
- does this problem need to be solved now or, even at all?
- can this problem be solved without writing code?
Surprisingly often, this exercise allows me to discover alternative ways of solving a problem that are more effective than writing code.
Not all problems need to be solved
Sometimes, assessing the importance of a problem is difficult, especially when done in isolation. The issue might seem significant, prompting us to solve it with code, only to realize after the fact (or maybe even not) that this work didn’t yield any noticeable improvement.
Consider a service making blocking I/O calls. Such a service won’t scale well. However, if it receives only a few requests per minute rewriting it to improve its throughput won’t have significant impact and is not necessary.
While many such problems will never require further attention, some might need to be revisited. If the service mentioned above needs to be integrated with a system generating many requests per second, fixing the blocking I/O calls could be a top priority. So, it is important to stay on guard and address issues that were initially punted if they resurface again.
Not all problems need to be solved with code
Many problems can be solved without writing any code.
There is an entire class of problems that can be mitigated by changing the configuration of the software. For example, if your streaming service occasionally crashes due to the Out-Of-Memory exception when processing spikes of data, reducing the maximum allowed batch the service fetches for processing could be a perfectly valid solution. Processing the spikes may take a little longer, but the overall processing time may not be affected in a noticeable way and the issue is fixed without changing the code.
Often, you can solve problems making careful design choices. Take user accounts on a website, for example. When deciding how users log in, there are two common options: using their email or letting them create a unique username. Coming up with unique user names can be challenging for applications with millions of users, so many of them suggest an available user name. Using an email as the user name is an elegant way of solving the problem of unique user names without writing any code. It also simplifies the account verification and password recovery flows.
What’s the problem with writing code anyway?
In my perspective, code should be treated like a tax. Just as taxes, once code is added, it is rarely removed. Every person on the team pays this tax day in and day out because each line of code needs maintenance and is a potential source of alerts, bugs or performance issues. This is why I believe that, as software engineers, we should opt for no-code solutions when possible, and write code only when absolutely necessary.
Top comments (2)
This gets into the realm of craftsmanship and not writing code for the sake of writing code because that's what's in your job description (and hate to use the buzzword here, but this also touches on first principles).
Probably fair to say quite a bit has changed in tech since the ~1 year you initially wrote this post, but not much in the way of a principled or disciplined approach of writing no-code or even just less code to solve problems another way (at least not by observation for my specific domain of software). It's a hard sell, but the point you are making here is valid in my opinion.
You can write good code. You could even write great code, but you can't anticipate every possible edge case, dependency change, architecture change, platform change for the long haul unless you are in complete control over all those details. Every line of code you produce for a system introduces risk to the system and then to the organization or end-user (and it's large part of why it costs aviation software $100-200 per line to produce it under strict standards and regulation -- risk). So code is a tax absolutely...and a liability in general.
Might take a shift in the designation of "software engineer" or "software developer" such that it's called and defined as something else more in line with this way of approaching problems to at least get the ball rolling towards it being the expectation. Not a one-shot solution, but at least getting the frame to shift a bit around what a software professional should be aiming for in the interest of the end-user, organization, and sanity of the teams responsible for it (that's a bit idealistic, especially once you've seen how the "sausage is made", but for this particular engineering discipline, one can hope that it matures into something similar to this ideal). Anyway, thanks for the post, Good topic.
Thanks a lot for reading and a thoughtful comment!