We're All Developers Now
Companies spend a lot of time trying to have everyone from the CEO down understand their business. And rightfully so. Trivial as it may sound, I’m persuaded that knowing why you’re doing your work makes you more productive and happier. Even if you’re doing something that seems like it’s happening in the background, like washing dishes at a restaurant or working the assembly line manufacturing sheet glass.
But I’ve also long had the feeling that organizations miss pushing people the other way, too. It’s pretty common to set the expectation that people on the “technical” side understand the “business side.” Making engineers sit in on sales calls or do customer service. Giving lectures to people on the technical side about the company’s financials.
Whereas I’ve seen many people on the “business side” of the fence get away with murder in not understanding the product or the product’s technical underpinnings. I’ve been in so many meetings where a salesperson shuts me down because I try to explain why we can’t deliver something to let them close the deal that week, with the complaint that they only wanted a “yes or no answer.”
If you’re working at Airbus, you should have an understanding of how airplanes work. If you’re working as a waiter in a restaurant, you really ought to know something about food. Knowing your product makes you better at selling it and finding the right fit for your potential customer. Knowing your product makes it easier to figure out the right people to hire or where to find operational efficiencies.
So it’s been fascinating to watch as “non-programmers” get their hands dirty with the recent explosion of LLM-based tools that offer new ways to write custom software.
Whatever people may be saying breathlessly now, I’m persuaded that people who dabble with these tools are ultimately going to realize that software engineers are more valuable than ever. At least in the long run.
When you know how to write your own software, you very quickly learn that you want to avoid writing code at all costs. Simple problems quickly become complicated. And it’s the maintenance and ongoing bug fixes that really kill you.
If I wrote my own newsletter platform, it would be better, at least along some dimensions. The tool I use doesn’t have a feature to let you build nicely formatted tables of data. But I’ve written enough custom systems to host my various writing projects over the years, I’m now very happy to use a standard off-the-shelf system that I know will work.
This isn’t to say that no one should ever bother trying to write something new. Or that you’re never justified in doing your own thing. Great companies have been built on that low-grade annoyance.
Rather, it teaches you that it’s not the end of the world to accept something that’s pretty good without a seriously strong justification for going that extra mile. As much as you may want to complain about QuickBooks or Gmail or Adobe Photoshop, unless you’re doing something really exceptionally special, you probably don't need to write your own accounting software. Even if you think it will only take you a few hours using Cursor, or whatever the flavor of the month is.
It’s been interesting to watch non-programmers come to this well-understood realization. At first, they’re seduced by the idea of finally having a seemingly affordable way to make a tool that’s, to their relief, finally works exactly the way they’ve always wanted it to. Then they realize how much work goes into something even a little bit complicated, and go back to buying a fully-baked solution already on the market.
Whether you’re writing code directly or with an LLM-based tool in between, there are certain gaps that the best system can’t fill in for you. What happens if someone tries to sign up and they’ve already registered? Should you let them register again and ignore them? Give them an error message? What should the error message say?
People are learning what those of us who can code have known forever. It’s really not that hard to get something about 85% of the way there. But that last 15%, covering the weird cases that don’t fit the obvious and most straightforward uses, that’s what takes time and craft.
It’s hard to cook up a new algorithm to process images or detect fraud in financial transactions. But it’s also a lot of work to take that new algorithm and turn it into a product that can be used outside an R&D setting. Whether that’s building a user interface that lets the intended users effectively use the new algorithm, connecting it to the right systems, or covering all the exceptions that matter for a live application but that weren’t important in developing the core technology. Or indeed all the sales, support, and operations that have nothing per se to do with the code.
Ideas are cheap. Execution is hard.
The new breed of LLM-powered tools are incredible for accelerating development. I use them all the time now to write boilerplate code or the skeleton of a function that I’ll customize and tweak to get just right. In the same way that something like ChatGPT is really just advanced spell check, these LLM tools are really the advanced version of code autocompletion that’s existed for decades. Now, instead of only automating the creation of a Java class definition with your required getters and setters, if you can describe how data should be retrieved and set, the tools can start to fill in the application logic for you.
The LLM tool can help you write the code to do what you want. But supposes you know what you want to happen. Which is the essence of writing software, and why it’s ultimately so hard to do well.
Lovely as these LLM tools are, there must come a point where I have to imagine it’s easier to read the code directly rather than having it mediated through the giant probabilistic machine that is an LLM.
While it’s maybe not the way I would have hoped, apparently the advent of these tools is finally helping bridge the empathy gap. They’re powerful enough to finally strip away enough of the mysterious complication of writing code that people are willing and able to try developing software on their own. When people work with a supplicant chatbot that doesn’t really push back on bad ideas, I suspect people will finally realize the whiny developers aren’t so whiny after all, and are, in fact, asking good questions.
It’s another good illustration of the lesson I keep learning, that as much as we humans pride ourselves on having the ability to imagine, ultimately you do have to live through certain experiences to truly understand them. We’re all developers now.