It is interesting thinking about the career path that a Modern Developer may have. Perhaps what seems like not all that long ago, sitting in a classroom studying algorithms, before that maybe making a robot whirrr in Scratch in middle school. Sometimes it is the puzzle solving that draws folks into computer science. Sometimes it is the instant gratification: Look at what I Built!. On occasion, the lure of money.

But now, that same developer may feel that things are bleak. Half a million layoffs in the past two years. The inevitable promise that all programmers will be replaced with a subscription to some AI company that doesn’t require benefits. Those skills that one worked so hard to shape and polish are now embedded in a chat interface and accessible by 12-year olds: those who should be building robots that dance are instead vibe-coding DeFi Apps, whatever the hell that means.

One may realize at this point that the future of the developer is quite bleak. Any effort we may engage in is meaningless, like annotating our code changes with “fixing typoe [sic]” that was rebased out of history, never to be seen. Or the emotional toil that somehow, generating hundreds of checkins with minor variations guessed in panic, will simply be reduced to an emotionless “fixing bug” line and forgotten forever. There is no sweat or tears in commit history (or any fluids, thankfully). So much we have given to the void and yet it takes everything, regardless.

For younger folks, it might be possible to “pivot” as they say, and maybe pursue other endeavors that are far away from the stretching silicon hands that grasp for our livelihoods. Mining, for instance, and spear-fishing. But older folks may think that toiling in a mine is a young man’s game, and spear-fishing likely requires a different pre-workout routine than we are accustomed to.

Some developers are seeing themselves as elevator operators, descending both in economic necessity and self worth. This feels like a different form of meaninglessness. At one point, computer-science was considered a “write your own ticket” scenario and now we are pondering a dark, grim future. Perhaps this should be pondered over an omelette.

Any notion that we can return to the past is ridiculous of course. The only way out is through the void, somehow, and whatever that means.

But I don’t think it is as bad as it looks. It does not appear as if there will be hundreds of Python developers floating about highway intersections with cardboard signs begging for bugs to fix, or like the old joke, “Please help, my paradigm shifted.”

In the early days of computing, software had to be re-wired: as I hear it, unplugging everything and re-wiring the system for a new task could take weeks. Likely each operator had a specific pre-workout routine to prevent injury. As time progressed, we saw machine code, then assembly language which was assembled in to machine code, and then high level languages that are compiled (either into machine code or assembly). It wasn’t that long ago that there was a little bit of an expectation that application developers could understand disassembled code. Today, there are still positions where being able to write and read assembly is required. For the most part, it is a rather arcane magic that is left to specialized wizards and engineering students, but it still has uses. This means that the introduction of high-level languages did not render knowledge of the lower stuff obsolete. Err, at least not totally obsolete.

I suspect that some reading this will observe that they have never written software in assembly. And this is fine of course: if you are writing software that runs in a browser then the super-tricky speedy stuff was already written!

Attention Space

This uncovers an interesting trend: the more focused our attention is, the narrower our output is. Assembly is super focused, it depends on different computer and CPU architectures. Different CPUs have different assembly languages (SPARC vs. x86). Meanwhile, Javascript is broad: the same program can run on a myriad of browsers. In the amount of time it takes for me to write an assembly program that targets a single machine, I could write an in-browser program that can run on every phone, tablet, and personal computer in the world.

I am not suggesting that assembly programming is more difficult than Javascript development. Both skills require knowledge of the environment, syntax, and fundamental computer science. In both cases it’s also about knowing what not to do rather than how to do something. The idea is that Javascript and Front-end development on average requires more breadth but less depth than bare-metal assembly programming. The on average part is important! If you are writing a javascript engine you will need to go a lot deeper than someone hacking a React application.

Of course we won’t be able to replace our assembly with Javascript. In the times we still need to talk to the bare metal, we need specific attention to the hardware and a very narrow output that is only for specific hardware¹.

The idea of narrow attention = narrow output holds in “backend” computing as well. The ability to write a database driver requires specific level of detail that using a database driver does not require, but one can write a Spring Boot application that targets several different databases with only superficial knowledge of any particular database.

So let’s call this stuff that you have to think about to get your job done “Attention Space”.

When we fold LLMs into “attention space” we see that Generative AI from Large-Language Models is the next level: we are now expected to think very broadly both in our vocation (programming, or building software) and our domain (what we’re building and what it does). This is a bit of a shift. It changes our understanding of how we build things. It may look superficial though; after all, software engineering itself hasn’t changed. But there are more tools, and the tools don’t behave the same way from person to person, or week to week. These tools are changing rapidly, and may approach the point where the author of software only needs to focus their attention the “what”, not the “how” of an application.

What it means for the gainfully employed

The point of such a shift in Software Engineering isn’t that generative tools will replace software engineers, it’s that our attention can expand, and that means that so can our output. But one should immediately ask what “expanded attention” means because it sounds absolutely fake. Some would also suggest that “more” is not always “better.”

Let’s pretend for a moment that there is a company that refuses to hire generalists. Any programmer can only do one thing (but they are really good at it) So a front-end developer can only work code that ends up on the website, and the backend developers can only work on APIs that are called by the front-end. Mysteriously, both teams are equally apt at disparaging the company’s implementation of “Agile” but that is not strictly a programming skill.

At any rate, as time passes, the members of these teams become masters of their technical vocations. Given enough time (perhaps an infinite amount of time), they would absorb all accumulated knowledge on this subject and become something of a monk, maybe even the kind that floats. But the work that they did, and the output that they made, would not grow.

But if this pretend company were to break the barriers in a way where the programmers are actually empowered to work across their previous boundaries, then they would be able to expand their technical attention, and thus be able to build bigger things (front-end and backend!), and their output would increase.

So this means that the Modern (Existentialist) Developer ought to be embracing this. We still need to know the details of what we make and how it works, but when building we can spend our attention at a higher level: higher than the programming language, at least.

There is a warning sign though: just like there were occasional compiler bugs in the 90s, today’s Large Language Models are not infallible. Sometimes they generate esoteric or anachronistic patterns, and who would be able to tell that if they are not already experts in the field? There is also a matter of every tool behaving slightly differently. I believe this causes a discrepancy among opinions: two different users getting very different results.

Guard-rails help: instructing agents to generate integration and unit tests, and to use those as a feedback loop, will improve the trustworthiness of the code. Also helpful is to write test-critics that examine and report on the usefulness of these tests.

Giving agents short, sweet instructions rather than massive one-off fantasies is also effective. Broadly scoped tasks can be broken up.

While the paradigm might be shifted, traditional software development techniques are tried-and-true for the past 100 years, give or take, and should be celebrated even if our attention is elsewhere.

■

But what if I’m wrong

Most of this assumes a “Spherical Programmer” if you will, where ideally they are able to perform at the top of their vocational level always. But this is obviously not the case: There are always discussions on what to build, and how to build it, and those take up time and space for actually writing code. This is probably a good thing because a company that makes “Product X” would want developers to work on “X”. But it also means that there is a practical limit that a single programmer will be able to achieve, unless they work in multiple business domains.

It should be noted that technical acumen does not predict productivity.

The term “output” is treated as a single dimension, but in reality there are lots of things that compose output: fitness and quality are the ones I consider but there are others.

There is also a note on how Large Language Models work where we have to assume that the output is not that of the top-tier programmer, and that assumption is because most of the code that is in its corpora is not written by top-tier programmers. This could make novel programming with LLMS difficult as there will be an attractor to a prior solution. Or so it would seem.