This content originally appeared on Level Up Coding - Medium and was authored by Ted Bendixson
The collapse of software
How a manufacturing mindset is driving talent away

I am writing this while waiting for Xcode to compile and transfer a simple Apple Watch app to the watch on my wrist. In principle, this ought to be fast. We’ve got amazing computers capable of ridiculous computation and data transfer speeds.
But of course it isn’t, and I’m currently staring at one step of the data transfer process that is taking far longer than it needs to, simply transferring one file.
I have no idea what’s going wrong. I don’t know where it’s stuck. There’s zero transparency in why simply using the tools I’m being told to use seems to take ages. I’ve been waiting several minutes by now, long enough to be inspired to write something or watch a YouTube video.
I resent this lack of productivity, but the odd thing I’ve noticed is how I didn’t use to resent it. Not too long ago, I accepted the slowness as a fact of life. These tools take as long as they take.
But then the tools got worse, the problems more glaringly obvious, and the time delay between reporting a problem and it getting fixed much longer.
Then they introduced React Native, and it started replacing many mobile app developer jobs. If you were working as an iOS or Android app developer, the change would have been subtle at first. You would see a few more jobs popping up here and there using the tool.
And I have used it, and it’s not that bad. But it’s also really really bad in the way it makes app development far more complicated than it needs to be.
If everything in the complicated stack of libraries React Native depends on comes into perfect alignment, it can be almost sublime to see an app coming together so quickly.
The problem is, because it is a complicated stack of abstractions built on top of abstractions, it rarely does come into alignment, and I spend most of my time assuming something’s going to break. And it always does.
The only thing React Native doesn’t fail to do is fail.
My clients have neither the time nor money to fix these problems. So I just deal with whatever thing is misbehaving, and I don’t look too deeply into it.
When I write about this experience or talk about it with other developers, it really feels like I’m striking some vein of truth. I get so many nods of agreement, as if I have touched on some demon they’ve been wrestling, something that runs core to their identities as software engineers.
And if I were to sum up what that feeling is, I would have to say it’s a kind of resentment.
You see, I went to university and studied computer science. We took classes on algorithms, data structures, low level assembly programming, and some higher level languages like C and C++. The goal of that education was to become a software engineer, someone who understands software at multiple levels and is therefore able to truly design software systems for all kinds of goals.
But then I entered the job market.
At first, I didn’t quite notice the dissonance between the engineering principles I was taught and the jobs available for people who have my skill set.
I was taught to engineer from first principles, but many of the jobs are such that someone else has already chosen which tool you’re going to use, and you simply have to use it whether you think it’s a great choice or not.
Of course, you have the freedom to leave a job like that, and many engineers do once they’ve saved up enough money, but we also struggle with having to set aside our own values just to make a buck.
We wanted to be engineers, but the job market wants factory workers.
There really isn’t any way around that, and I hope I’m not coming across as someone who doesn’t at least try to understand why the job market would operate that way. But I think on some deep level, many software engineers have an unconscious feeling that we were lied to.
The university lied and told us we would be engineers, and the recruiters lied about the jobs being innovative and interesting. In truth, only a very small percentage of those jobs are interesting, deep, creative, and meaningful.
We work on side projects because our main employment isn’t interesting enough, and I think this bleeds into our personal lives in some fairly stark ways. How do you have a deep relationship with someone you love when you also feel this burning desire to do something creative and meaningful on the weekends and evenings?
The hunger and striving never ends. We can’t sate our appetities for meaning, and the jobs we do consistently fail to give us the feeling of autonomy and purpose we naturally desire. We want to be engineers, but the software market doesn’t want that for us. It is being driven the opposite way.
Naturally, something’s gotta give. Because software engineers want to have happy fulfilling lives, and their jobs aren’t quite giving that to them, other points of conflict start to arise in their personal domain.
Your spouse isn’t going to like the fact that you feel like you need to spend the weekends doing some meaningful project. So what are you going to do? I suppose you could end the relationship. That obviously has some pretty bleak consequences.
You could quit the job. That also has consequence you probably won’t be happy with. I myself have quit jobs becuase they weren’t challenging enough, and then a few months later I would feel kind of lost and without purpose.
You could try to find a part-time working arrangement, one where you have enough time for your creative projects. I believe this is ultimately what we are striving for, but it’s also very clear to me that many workplaces don’t quite understand why software developers, or creative people in general, find this so important.
Here is my bold prediction, and as predictions go, it can be wrong. So be warned.
I hypothesise that the software ecosystem as we know it is in a state of collapse. It is a slow-moving collapse propagated by internal forces.
Here’s the short way to put it. At one point, we said, “software is eating the world.” Now I would like to posit that software is eating itself.
How could this be? What would that look like?
In an effort to turn software roles into something more like manufacturing, companies have driven out the very talent that enabled this manufacturing mindset. As a result, we keep building software on shakier and shakier foundations.
When we build software on shaky foundations, it is often slow and frustrating to work with. I believe this causes burnout for the professionals who have to work with it every day or face the consequence of having no income.
Burnout is a funny thing becuase it is additive. You might be willing to accept some frustration with some tool not behaving and your general inability to fix that tool. But if you deal with it long enough, and you don’t get an opportunity to do the job of an engineer and fix it, the feeling gets swept under the rug and becomes resentment.
I believe many software engineers have mental health problems because they aren’t confronting the resentment they feel with their boring manufacturing-oriented jobs. I believe these mental health problems have manifested in an overall decline in software developer productivity, which perpetuates itself as we build ever more complicated towers of abstraction.
We ask many impossible things of software engineers, and we don’t train them to separate what’s impossible from what’s reasonable.
If all you ever knew was React Native, you wouldn’t have the context to understand that your tool is built on top of Objective-C frameworks, which themselves are built on top of C, which itself is compiled into assembly language and has to run on actual computer hardware. That’s not to mention the Javascript bridge between React Native code and Objective-C.
It is impossible to expect anyone to be competent with React Native because it is such a complicated tool that no mere mortal could understand how all of the packages interact with one another.
And the expectation of competence with increasingly complicated tools leads to resentment because the idea we have of ourselves as smart engineers runs straight into the reality of trying to build functioning software with broken tools. It just can’t be done, and we don’t know how to deal with that on a psychological level.
I believe that a combination of psychological pressures which most software engineers feel eventually builds up, and the outcomes can be potentially devastating if engineers don’t have ways to mitigate it.
I also believe these feelings are the reason why so many software jobs have such high turnover, and why so many software projects fail. In a nutshell, we aren’t empowering engineers to truly be engineers. We aren’t giving them opportunities to fix the problems and to be the creative geniuses we say they’re going to be when we write the job description.
The drive to build more software in shorter timeframes has driven out the talented engineers who don’t feel respected in these narrow roles we have defined for them.
I like to say most software developer jobs are like that of an Ikea furniture assembler. We can do whatever we want with the five or six pieces in the kit, but we can’t ever drop below the level of the kit and fix the problems.
Culturally, this manifests itself as the blindly accepted axiom “don’t reinvent the wheel.”
The process of trying to turn software development into manufacturing accelerates due to the feedback cycle it creates, and the sphere of our control as so-called engineers keeps shrinking.
The endgame is a Dilbert-esque situation in which we have no control while also being asked to deliver ten impossible things each day. This simply cannot sustain itself.
I make this prediction knowing it could be wrong and also not really knowing how the natural conclusion of this process will play out.
Will software engineers quit en masse? It seems like we are uniquely positioned to do such a thing if we want to do it. These manufacturing-style jobs do pay more than they should for what is essentially Ikea furnitue assembly.
I think it’s no surprise that the FIRE (Financial Independence Retire Early) movement is mostly made up of disenfranchised software engineers. There’s a Venn diagram of intersecting traits. Software engineers have the resentment necessary to feel like they want to quit their jobs, and they have jobs with a high enough income to make it possible to do so within an achievable time frame, like ten years.
One natural way to resolve this psychological conundrum is a kind of stoicism. You deal with today’s pressures by saving and investing your capital, knowing the day will come when you can finally retire from this phony career. I myself have pursued this strategy, and I have many thoughts on whether it is as effective in the short-term as some might hope (although it is obviously effective in the long term).
As an off-the-cuff observation, it seems evident that many once-respected companies like Apple and Microsoft are being hollowed out. Their software gets worse with each new update.
With Apple in particular, I see a decline in their ability to design software that I want. This seems to have happened not too long after Steve Jobs death.
For example, my iPhone should never prompt me to subscribe to Apple Music when I am simply trying to use it to play songs I already own. This design decision deeply offends me, and I believe it would have offended Steve Jobs. They have kept this pernicious pop-up in their music player for six years now, and it makes me question everything about what’s going on in their organization. I don’t trust them on their most basic business proposition, that they would make something I want.
Perhaps this is also the natural path software had to take. As more and more of it comes into the marketplace, a certain kind of devaluation occurs. People feel rushed to put anything on the market at all, and because software engineers have such a high expectation of pay, the profit margin keeps shrinking for many software projects.
Apple feels like they can no longer simply make great products. When the iPhone was new, that strategy worked. But now that everyone has one, most people don’t feel the need to upgrade. Apple would then need to change its course and focus on something else in order to increase returns for shareholders.
Put bluntly, Apple’s stock price can’t keep ticking up and up without it also stabbing itself in the back and diluting its product strategy. They feel such a need to promote Apple Music that my own needs as a customer are pushed to the background. The Apple Music pop-up in my music player app is a microcosm of the shareholder pressures they face.
I think if Steve Jobs were alive today, there’s a decent chance he would have been ousted a second time, and someone would try to put a positive spin on it so people could stay invested in Apple.
I have endeavored to stake out my current understanding of the unique psychological pressures software engineers face in today’s environment.
It is my hope that today’s disenfranchised software engineers can take their hard-earned money, invest it, and retire from their false careers into real ones.
I hope this wave of early retirement turns into a golden age of new software and hardware companies that aim to replace the dying incumbents.
I also hope we can find a way to return to our origins, knock over the tower of abstractions, and build great things on a new foundation.
But I am also reminded of history and how past civilizations have failed to adapt to changing circumstances.
Sumeria fell into decline after centuries of sea salt building up in their soil. In the early days, it wouldn’t have been so easy to see the problem. Some crops didn’t grow quite as well as they used to, so they shifted to other crops that could grow into the somewhat saltier soil.
But over time, it soon became impossible to grow the most basic crops in that soil, and ancient Sumeria fell.
Today, the great ziggurats of Sumeria are surrounded by desert in all directions. Their cities were completely abandoned.
We can almost graft our current situation in the software world directly on top of the story of Sumeria’s decline.
The soil of software engineer productivity is being utilized without being replenished. Because we have spent the last two decades solely focused on delivering software as quickly as possible, we have ignored the engineering skill which gave us that productivity.
Our failure to invest in the development and sophistication of our engineering talent means we have failed to pass on relevant engineering wisdom from previous generations.
The current generation is now presented with a learning landscape bereft of deep programming knowledge, and only a handful of folks (in my opinion Jonathan Blow, Casey Muratori, and Mike Acton) are willing and able to shoulder the burden of passing on the deep knowledge they have acquired over the course of their careers.
Perhaps more troublingly, that knowledge is drowned out by all of the clickbait garbage that makes its way to the top of Google and Hacker News. An individual trying to make a good faith effort at understanding the fundamentals of great software engineering now has a hard time being pointed toward good learning materials and mentors.
Software is slowly dying. And we, like the Sumerians, can’t quite see it yet.
We have apps that mostly work. We can kind of get stuff done. However, the frustration is mounting, and it has only just begun.
We take our technological and cultural sophistication for granted. But it is not guaranteed. If we don’t elevate math and engineering to a respected status (not just a highly paid one) within our own culture, we will witness a rot from within, and I believe it will threaten the foundation of civilization as we know it.
By the way, Xcode is still trying to transfer that file to my Apple Watch. Something’s broken, and I’m not given the power to fix it. I’ll probably just quit and do something else.
The Handmade Revolution, and What It Means For The Future of Software and Civilization As We Know… was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Ted Bendixson

Ted Bendixson | Sciencx (2021-03-08T22:47:40+00:00) The Handmade Revolution, and What It Means For The Future of Software and Civilization As We Know…. Retrieved from https://www.scien.cx/2021/03/08/the-handmade-revolution-and-what-it-means-for-the-future-of-software-and-civilization-as-we-know/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.