It’s not the “programming industry” that OP hates, it’s the “corporate world”. I’ve worked with (and have been) developers who have mismatched expectations on what “the real world” wants out of them.
The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code. They care about finding developers who will pump out features to the business requirements. Some human beings in that cog (managers, directors, peers, etc) may allude to enabling developers to actually practice the “art” of programming but the bottom line is if you aren’t moving the needle economically for the company, you’re a liability.
Find comfort in programming outside of the corporate world and practicing the art but don’t expect the “industry” gives a damn about the how or why of programming, mearly the characters we punch onto the screen into cash. Once you come to terms with this, life gets a lot easier, less frustrating and you can actually find fun in the work (albeit, not necessarily “art”).
I think “industry” strongly implies “corporate world”.
However
> The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code.
Guess I’m the corporate world then! Listen here, dear colleagues: Before attempting any finesse, abstraction, wit or beauty, maybe first try to make it work to spec. Because otherwise it is entirely worthless.
If you are reasonably good at making it work, you can then make it right and maybe even fast.
In my professional experience, the only spec you get is a wishlist, never quantified, always vague. Half the work is figuring out what the customer wants.
The only metric that anyone cares about is speed. You need to go fast, but to where? There is no consensus.
An order of magnitude is a bit much. I'd say quick and dirty gets you 3 shots, while slow and beautiful gets you 1. And if you succeed, it means the result is dirty/ugly code that must be maintained forever.
Doing it many times tend to be much cleaner than trying to get it right the first time. So fast -> clean, slow -> ugly code, as long as you use the speed to redo and clean things up.
The PoC becomes a pilot becomes production becomes an exit becomes someone else’s problem. That’s the SLDC that has gotten us to a place with endless amounts of terrible software everywhere you look.
Though, I’m optimistic that at some point, the software industry will be so saturated, all the products have all the features, and the only place left to differentiate or disrupt will be quality.
Well if you don’t have a pretty good idea of the problem you’re solving for the customer, you’re much better off trying as many things as you can, quickly and cheaply, to figure out.
I don't see how that's a problem. It's not for everyone, yes, but I like it a lot. Talking directly to the customer allows me to create exactly what the customer needs, without any convoluted process.
If that's not for you, you need at least a requirement engineer between you and the customer. That's also okay.
From my experience, getting things done quick is almost never relevant. Getting things done “cheap” is.
If a large portion of software development is the attempt to discover what is a minimally viable product, then software development is not pure software development. It would be startup business development. That makes real programming to be something like obscure operating system development.
So it's a conflict of names, a matter of proper identification.
This is the way to do it. First you want as complete coverage as possible with a unit test showing that the implementation is sound. Then you can try things and refactor for performance, checking as you go that you didn’t break anything.
In my experience, most of the corporate world seems to care more about their aesthetic notions of the Platonic ideal of what code should look like than whether or not it works or whether or not it is efficient. Certainly that's my experience from interviews.
Maybe the people who care about business value should be the engineering managers not the people who equate their personal aesthetic preferences with the only right way to write code?
I’ve had the opportunity to work with lots of mechanical engineering corps to date, and I can confidently tell you: Even if they had some platonic ideal, they would never be able to follow through. The mediocrity of their software development practices is… profound. On all levels of the hierarchy. Sure they care about the ideal of sustainable software development, but they just can’t do it.
On the other hand, my employer advertises clean code as a service, and this attracts the kind of developers you describe.
Capital-C Clean Code? Hell no. This is code that looks clean only on the surface, but in practice it only works on toy projects. Anything big enough is impenetrable for debugging and a performance catastrophe.
Lowercase "clean code" from people who heard the above but never even read the book? What's that anyway? Nine out of ten times, this is just developers putting aesthetic preferences in front of correctness, simplicity and performance.
Wrong. Performance and correctness/cleanness go together. Perhaps you have never tried generating correct code that is ways faster than what you can write by hand.
Once again: what even is “cleanliness”? Are you writing it in lowercase on purpose, or are you unaware of methodologies that share the term? Or are you talking about Uncle Bob’s but refusing to capitalize?
“Clean” is a horrible qualifier for code. It is either too subjective/broad, or too loaded.
OK, I realized it was about something else. I don't follow Uncle Bob, and was referring to some people justifying "unclean"/incorrect shortcuts to gain performance.
I totally agree with you in that regard, "readable" and "performant" often go hand in hand. My gripe is with the "Clean" adjective, that often indicates code that actually isn't readable and is also low performant.
Code is run more than it is read especially if you count users. And so-called "clean" code is a performance disaster[0]. It's also, if that link is an accurate representation of what "clean" code is, a readability disaster. The more readable code, in my opinion anyway, is the version that is also an order of magnitude faster.
Counterpoint: The MVP is usually what ends up in production. If your code is a heap of garbage but chocolate-coated on the outside, you're gonna impress management and they'll want to push it live asap. Then the issues start exploding.
yes, a shitty foundation leads to shitty feature implementation. I've seen this everywhere from startups to Fortune 500 companies. Nobody cares about code quality, except maybe the one self-annointed gatekeeper who thinks he's making a difference and shitting on everyone's PRs delaying features. Get rid of that guy he serves no purpose
Yeah, if the indentation style, variable name capitalization rules, structure of commits, 100% unit test coverage the guy knows is the absolute truth and top priority, a collapse of everything is imminent.
People don't care about quality in general unless it affects the bottom line. Not just code quality, but product too. Bugs? Who cares unless it costs us money. Security holes? only a problem if they're exploited... And it costs us money.
> If you are reasonably good at making it work, you can then make it right and maybe even fast.
Whuahaaaha ... If only that was so easy. Once you get it working, it will in most cases be torn from your hands and you will not get to touch it again any time soon. So what one does to find even a little bit of joy is to try to get some sense into that code right away, because you don't usually get a second chance.
If I knew, that at a later point in time I will only have to ask and sure enough I will get the opportunity to make things well-made, then I would be much more willing to not spend any additional time into making things well in the first run.
Making things well requires knowledge and craftsmanship, while making things merely as shoddy as possible but according to spec will requite a bunch of interns making a pile of unmaintainable crap. Code only written with the next goal in mind, not looking out for the casualties along the way.
I may not have communicated this well enough. I wasn't referring to a multi-step process where I hand over the solution in between. I was referring to getting good at making in work, right and fast in one step (at least as far as the customer is concerned).
Many try do it all at once and then end up with… nothing.
I just wanted to make it more explicit since this issue isn't specific to software developers, every career grapples with the "right way" versus the "economically prudent way" in our (US) capitalistic society. That in and of itself isn't bad, take capitalism however you want, but the point is managing expectations to the reality that exists in front of us, not the one you wish it could be.
Or simpler than that, surprise, work is less fun than hobby.
Even if you work for yourself doing what you love, even say it's making furniture or whatever, there's always going to be things like customers want the 'wrong' things, or won't pay extra for the nicer exotic material, etc. doing purely what you love as a hobby with no work aspect is always going to be better.
Because in a hobby you are your own master and in a job someone else is your superior and orders you to do things. If you are lucky many of these things are what you would like to do anyway.
Yeah. It's extremely rare to be able to do exactly and only what you want to do and be able to make money from it. Even the big YouTube celebrities face pressure to make the videos their audience wants to watch. When they go off the rails the views take a nosedive.
> Find comfort in programming outside of the corporate world
This is indeed the bitter truth I've learned this last decade in the industry.
You're paid to deliver. Whether its efficient, it solved the problem, made any money, ticked some boxes isn't yours to bother or control. Plan tour stuff, do your stuff, be nice to others and sign out at 5.
Don't underdo by writing bad code, or not caring of the downstream consequences of your decisions etc. People do get fired for this.
More important, don't overdo. Don't try to predict how the product evolves and catch those scenarios, don't fight for your obviously better design, don't try to deliver faster, don't try to fix that bug you found while working on something else you are tasked to deliver. Chasing a promotion is one of the worst kind of stress I brought on to myself.
Know the kind of project you're in (high intensity, high growth, mature, next on the chopping block) and act accordingly.
Further, take credit and be seen. Do a demo once every quarter, review people's code, show up for design meetings and ask a question, reply to emails/IM's (that show up before 5pm) quickly, deliver on what you said you will. Be seen as a useful resource but push back (with your actions) on the slightest sign of pressure to deliver.
Finally, always be prepared to land your next job interview in 2 weeks.
Its your workplace. Not your family, nor a body shop.
Hope it's okay to self-plug here (seems highly relevant): what you say is a big reason why I organize the Handmade conferences for a living and why they're free of sponsors [0].
An implicit goal is to grow popular enough to the point that enough programmers collectively agree they should have a say in the "corporate world," such as demanding that we slow down "pumping out" new features and make greater investments in software quality.
This looks interesting, but why is 75% of your landing page your bios? When clicking the link, I definitely didn't have in mind "I wonder who founded this and what their background is". I now know a lot about who organizes this and what their reasons are, but I don't know anything about what it is.
To be fair, that's the about page, not the landing page. And their goals and reasons for organizing it are commendable.
Abner, I'd be interested to hear more about what it was like working with Jonathan Blow. (Maybe your project's about page isn't the place to go into it, but possibly here, your personal blog, or private email.)
I'd love to see his reaction to watching the Game Helpin' Squad's tutorial, "Time Travel Understander"!
My favorite, which you have to pause to read all the hilarious popup text and chat that goes by quickly, is the Game Helpin' Squad's "World Quester 2" tutorial:
That's the about page. The landing page has more info:
> We are the largest indie conferences for low-level programmers. This is your portal to meet with folks into graphics, game engines, kernels, compilers, and more!
Corporate? I think ultimately we’re talking about any business here. And a business doesn’t exist to facilitate engineers to go back and forth on a PR for a week, or to fantasise about abstractions all day.
The entire problem is the vast majority of engineers have an inability to recognise the business function of their output. They live in their own worlds with tunnel vision on minutia. I can’t pin point when this happened but engineering is a complete circus in most companies.
The horrifying thing is there is buy in at senior management, like the engineers have convinced everyone that it should take weeks to deliver some trivial feature, because God forbid they don’t deliver it by using every dogmatic and koolaid driven process they’ve picked up from others over the years.
You work for a business that’s trying to make money, not a software engineering sandbox charity. Of course there needs to be some balance, but boy is it skewed one way for most right now.
> The entire problem is the vast majority of engineers have an inability to recognise the business function of their output.
Who would have thought this would happens when actual business talks to a business analyst, who talks with a product owner, who talks with the engineer (when a PO proxy didn't manage to squeeze in between them).
I’m sorry but I think it’s cultural, I’ve worked in enough early stage startups where the first engineers are working directly with CXOs, and they’re still firmly living in lala engineering land.
> if you aren’t moving the needle economically for the company, you’re a liability.
I would add, moving the needle in the short term. A business taking a long term view would care more about quality (reliability, security maintainability).
What I mean by long term here is more than two or three years.
> So the company's shareholders might only want the term to be just long enough to cash out.
Which means they need to sell to people who think the business has enough of a future for them to cash out. That stretches the terms a bit, but not long enough from the point of view of employees, customers, or what is good of the economy as a while.
Depends on the composition of shareholders too. One thing I recall from my time in investment management was the problem of clients who were reluctant to sell because it would create a capital gains tax liability. At the other extreme are fund managers whose most pressing concern is where they will appear in this year's performance league tables.
Wouldn’t you think this would mean government-made code would be of higher quality (in theory, and ignoring when govt code is made by private contractors)? It seems to be the opposite
Governments are often sort termist too. For politicians next year's election is often what matters. They also have layers of management, in some countries they are frequently moved around so the long term (from any given manager's point of view) is someone else's problem.
From what I know academics in computing fields tend to write high quality software. Not all not Donald Knuth level, but they seem to mostly care about quality.
Not all developers are equal. Government work pays a third or less what private industry pays. You’re never going to get extreme competence from a government software employee.
Never? You don’t think NSA or Israeli 8200 has preeminent software developers? I think your assumption hinges on people being motivated solely by money. That may be largely generalizable, but I suspect there are relatively large exceptions to that rule.
I think they have the benefit of mystique. I don’t think you’d find their code quality any better than the average. I also think you’d find the same rush to market mania that plagues the rest of the software industry.
Not all competent people are driven by pay. I'd say the most competent usually are not. There are a lot easier and safer ways to get paid well than competence.
From what they wrote, "small startups" are part of that "corporate world."
From my experience, the cultural differences between large corporations, and smaller startups, is night and day.
Often, neither one is functional; but they are dysfunctional, in different ways.
For myself, I was never happy until I was able to helm my own ship. A lot of folks think that this means "hobby programmer," but I don't actually fit that template.
> It’s not the “programming industry” that OP hates, it’s the “corporate world”.
To add to this, the "industry" is very big and fundamentally quite diverse in character.
But right now we're on the tail end of a big surge in growth, and those surges tend to introruce a lot of uniformity in their wake. Processes and practices of the orgs are taken as some part of the secret to their success and are adopted by competitors and newcomers, and after a while everybody-ish doing work adjacent to the booming sectors within the industry are approaching it similarly and procedurally. The focus is on outmaneuvering competing businesses for a slice of the growiing pie, and matters of concern of the craft itself or long-term engineering vision are generally deprioritized.
This is not a permanent condition or a universal one.
All along, there were still people and orgs and departments doing things differently, but they did become harder to spot amidst all the boom chasers.
And as the boom tapers or bursts, with competition having less at stake, even the homogenized orgs and departments start having the headroom to take a second look at their processes, procedures, and priorities and again start to diversify.
It's reasonable to get discouraged if you've only ever seen the kind of orgs you can't stomach anymore, but a little patience can find you with opportunities you're more comfortable with. Some dedicated pavement pounding and deep digging for the orgs that never hopped on the bandwagon can make it happen to.
Different kinds of orgs are out there now, and more will come to look different again in some coming years.
> the bottom line is if you aren’t moving the needle economically for the company, you’re a liability.
That's fine. The issue comes when you fail to explain how stuff like keeping recent versions of your software or taking some time to fix (at least some of) the bugs moves the needle to people that would never fly a plane that doesn't receive maintenance.
The issue, in economic terms, is that a significant share of our industry's sponsors are the kind of clients that make a market for lemons.
It's not just the corporate world, it's capitalism in general.
I could point out a million people who have made rhyming criticisms of this type before programming even existed. Until those criticisms are met with widespread solid agreement instead of outright hostility or even a resigned "well, it's better than all the alternatives" then nothing will change.
Ive lost count of the number of times Ive seen programmers complain bitterly about e.g. alienation, forever oblivious to the fact that they are rehashing Marx. This post is no exception. When push comes to shove though, 0 of these people would actually dare to call themselves a Marxist.
> Find comfort in programming outside of the corporate world and practicing the art
It's hard to practice the art on the side when you already work hard in corporation.
However, I think it's possible to have a bit of fun programming in the corporate world. Besides, the incentives between managements and programmers do overlap. It's not like all managers are stupid. If the codebase is too messy, or lead to too many productions incidents, it makes sense to clean it up and refactor, or use different tools or languages.
Best job I ever had with regards to coding was for a small family business. I had to meet the requirements, of course, but otherwise I had total liberty.
OTOH, nowadays I also have to deal with young (and not so young) coders that insist on very baroque designs that don't really help to achieve business goals and actually hinder progress.
The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code.
Right, but that wasn't what the OP was talking about. In fact the issues they were concerned about were pretty much orthogonal to that. You're trying to make their complaint sound lame and pollyannaish, but really it wasn't.
That is true. But the way you present the reality of the industry makes it sound like anyone could do anything. That is, obviously, not the case. For example, research lab code usually sucks big time, while other industries might higher standards. Some teams try to make up for lack of personnel by implementing extreme level of automation, in that case you need high quality code, with well thought abstractions and there are only so many engineers who will deliver that.
So it’s not just “coffee -> code” machine. But the idea that a suit cares about the implementation details, programming languages and such is obviously not true and this community sometimes make it seem as if these things matter. They do to us, engineers, no one else cares much like my wife couldn’t care less about LBJ being better than MJ at basketball (he is not, obviously).
This. I've been very happily working in a small company and we recently got a new CTO. In a couple of days we will find out which 6 of us are being terminated. Corporate fat trimmings and all that.
And this is general approach, nothing malevolent against IT geeks like some less experienced try to project themselves. They want plumbers also just to keep things running and implement requirements, not have academic discussions about fine art of optimized water flow.
Companies are there to make money for the owners and thats it, not on some altruistic missions.
I think OP could be better served in academia as long as he keeps greed for money at bay, which some manage better than others over time.
Nope. Academia has a very sad bottom line as well.
What OP needs is enough financial stability and political will that they can do whatever they want. This can be slowly achieved by grinding at a corporation, taking political control and grinding or by violence / threat of violence.
Academia can be pretty great if you can live with economic uncertainty, non-unreasonable pay and aren't interested in careerism or that your work has any real impact outside handful of other academics.
There's of course a lot of bullshit, but you can sort of choose the tradeoff between bullshit and career development/stability. If you're OK with a high chance of never getting a permanent job, in many places you can do practically whatever you want.
And if you e.g. know how to code, you can usually go to the industry churn as a backup when your grant streak runs out.
But yes, in the bigger picture, the latter are the sustainable course of action. There's only so many, or rather frew, grants.
Programming without moving the the needle on _something_ is, ultimately, ugly. Granted, not all needles are worth money. But for the subset of needles that do, you can bang out all the beautiful code you want, and you will get respect for it, in a functional org, even corporate. Abstractions for abstraction sake are frowned upon for good reason.
I was coming to say something very similar. The hard truth is that the society-changing projects this person wants to work on are exceptionally rare, and most work boils down to selling products to consumers. Not that I'm saying this is ideal, but if it were easy to create deep and inspiring work that paid well, everyone would be doing it.
A part of the problem is, no user ever look at codebases. Unlike you da a PCB, make an electrical machine, build a bridge, people see the result. In software people see the UI. Also because copying is free, in PCB for ex. every jumper wire cost you, in software they are for free. So why fixing things truely.
Copying isn't free though. Every front-end application built on Electron or running in a container that duplicates half of the OS stack burns more memory on my computer, forcing earlier upgrades of either the entire machine or RAM with each year that passes.
It's free to produce, but the cost of running more copied software always increases.
I think there are a number of per-unit costs of software, because your edge cases get tested more frequently. The risk goes up for users finding bugs and incompatible working environments. They demand more unusual features. If successful, your growing user base attracts the attention of competitors.
If coupled with hardware, the rising complexity of software makes the hardware more costly to develop and sustain. It may delay the introduction of newer or more valuable hardware features and products.
When consumer software still came on physical media, nearly everything advertised the amount of ram and minimum system and cpu requirements necessary to run the software.
That just isn't the case nowadays, so you don't know there will be trouble until it occurs at runtime.
I can limit the memory available to ALL the tools I use every day (I only do it for docker and jvm stuff), set priority levels, etc., but it feels very weird for a brand new laptop to hit swap after a few days of uptime.
Yeah, maybe they don't care about abstraction and beautiful code, but they suddenly start caring when technical debt caused by absence of these things starts to hit, but they are too often unable to see that the two are related.
In my personal project I spend a huge amount of time tidying things up, abstracting, cleaning, commenting and that has really started to pay off as the project grew. If I'd let it deteriorate into a random bowl of software stew, I have come to a dead end by now, eternally firefighting instead of progressing.
> if you aren’t moving the needle economically for the company, you’re a liability
> If I'd let it deteriorate into a random bowl of software stew, I have come to a dead end by now, eternally firefighting instead of progressing.
It's real. It's what I'm doing at work now.
Every few months we start a new big project. Sometimes they're business-driven (end users can now have many X instead of one X), sometimes they're compliance-driven (we now need to block users who associate with users in blocked countries), sometimes they're tech-debt-driven (migrate from self-managed VMs into a dedicated provider).
We keep finding missing parts we overlooked. Sometimes it's from us having rushed it, other times it's from consultants getting fired while they're working on it, and others struggling to continue the vision in the right direction. Sometimes it's bad tooling - our new managed Kafka host has a mirror-maker tool that doesn't quite mirror properly, or intellij/gradle will flag that a class is missing, but not why (i.e. which dependency is missing!).
Id argue that there is art in figuring out how to continuously churn out features. Its really hard to write your code in such a way it can handle being jerked around, all while not wasting time on what might happen.
depends on your manager! I just recently told an engineer "well this is more art vs science, so paint the picture anyway you want" and left it to them to write the code the right way.
> Sometimes the compromise may be less money but a more fulfilling role
Once one reaches a point in their career where they have options this is almost universally true. It's in fact the reason why some jobs pay more, because they need to for people to do them instead of something more fulfilling.
I've had jobs where I thought with a few changes this would be awesome, but eventually realized it's those few differences that mean someone is going to pay me well to do it. Depending on many things, this may be worth it to you or not.
Fair point. Maybe it applies to more experienced people who can afford to pick and choose.
The article didn't mention their financial circumstance, I got the vibe it was someone younger. It read a little disjointed and it's hard to tell whether they sought jobs they believed in or whether they were satisfying an imperative financial need.
I don't think it's "corporate world", but just capitalism. Non-corporate companies often have thinner margins than corporations and thus skimp on "extras" such as quality, craftsmanship etc. even more.
I wish I had this corporate experience. We focus on finesse, abstractions, witty or beautiful code. I keep being forced to optimise things that we haven't measured, add new lines to places to make the code pretty, rename variables, functions and avoid using Javascript arrays and use the "more performant" sets, etc etc.
All of this at the price of the god damn feature never being able to land and my PR staying in limbo for weeks.
But this is just another end of the spectrum I guess.
I've been a developer for 30+ years and unfortunately there's not a lot in the OP that I can disagree with. I wish I could.
Young people get told that building tech and software is a creative endeavour where they can apply their innate passion. Certain kinds of minds get attracted to work that is based on symbols and abstraction and repetitive activities. Years pass and the shareholders get fat.
The truth is that software development is almost entirely an economic activity, and an extractive one at that. The working environment is certainly better than mining gold or bauxite, but almost all of us are hacking code out of the code-face merely to enrich other people: the people with the corner offices, and the people above them with the yachts. Those people don't care about what we do, or our pretentiona about it being an art or a craft, or what we think is important. And in fact they mostly think we're losers for wasting our time doing it [1]. Some of these people have pretty much told me this to my face.
Other posters here are correct that the underlying error is looking for meaning in (corporate) work. But people need meaning, and we have to expend so much of our only lives working, that there can be few alternatives. I don't have any answers to that.
> And in fact they mostly think we're losers for wasting our time doing it
True, this happens enough places to be a thing.
Of the people who think the software "little people" are losers, I think there's at least two versions:
* They think the work is skilled, and that the worker has valuable expertise, and is worth listening to. Even though they still think the person is a loser for being a salaried commodity rather than a "smartest guy in the room" or "leader", like them, who's a real player with the big rewards.
* They think software work is low-skilled grunt, the workers are a temporary evil, are uppity about compensation and loyalty (this is 'improving' recently) and don't know their place, and their input has no value. And of course software workers are losers in the world of business, because they don't operate and profit personally like real players do.
> almost all of us are hacking code out of the code-face merely to enrich other people
Colloquially known as "work". The thing we all do in order to have nice things and a society.
> to enrich other people: the people with the corner offices, and the people above them with the yachts
Good! That would mean the thing I produced had value. I hope everything I create has value. One day I hope that I've practiced enough, learned enough and gained enough experience and savings that I can employ others responsibly.
If I have good ideas and do it right, there's a chance that I could have that yacht. It's what we call economic incentive, or "motivation".
An economic system that, for all its flaws, has proven to be the most successful for the most people in all of human history? I guess so. But happy to hear about proven alternatives.
> I hope it sustains you over the long-term
Well, I'm about 50, started from very little, worked hard my whole life, and have managed to find a degree of success. Seems to have worked out so far. I hope it continues.
Certainly better than the alternative - blaming everyone else, the successful, and "the system" and not doing as much as I could to take responsibility and better myself.
I would describe "where the industry is heading" and has been heading as becoming infiltrated by imposters. There is tremendous value to be created by writing software, and the high salaries in tech reflect that. That wealth attracts all sorts of imposters.
We see this most straightforwardly as the cat and mouse game that is hiring qualified engineers. Top of funnel to bottom of funnel ratio has never been higher. Less obviously, there are now entire "Imposter Roles" like Product Manager, scrum master, etc. Once they're in, they bring more because there is safety in numbers.
Smart people, capable of innovating, now have to hand-hold a cast of incompetent characters through the experience of creativity, innovation, research, discovery, engineering, etc. Often because these incompetent characters have the final say on what the smart folks are allowed to spend their time on.
Maybe you've been in a meeting where the engineers spend the first 10 minutes talking and know how to fix the customer's problem, then the product managers come in round-robin to get hand-held to the same conclusion? That's what this looks like.
The imposter invasion has an even more insidious effect: the creation of software that sounds great (because making it sound great was its authors' forte) but actually sucks to work with (because making good software was not their forte). It has performance issues, security holes, no observability, doesn't scale well, has insane configuration or dependency issues, etc. FAANG companies in particular are full of this crap, written for the "brag post" so the author could get their promotion, then effectively abandoned as they went elsewhere before all the cheesy shortcuts became apparent. Slick talking has replaced sound design as the most valuable skill a software engineer can have, and it shows everywhere.
> Only thing I care now is a paycheck with ridiculously high salary.
... and also about minimizing the amount of stress experienced. Mostly through simply doing the bare possible minimum, but sometimes also doing a bit more to prevent stress down the line.
Caring-just-enough-to-not-care-a-lot-later-driven development I call it.
I spent 40 years as a programmer, but I always looked for ways to use creativity and imagination and never be a rote coder. Despite having success in my last job leading a small team building a strategically important piece of code (if it didn't work all the time, there would be 100,000 angry people every day, not to mention a whole cast of angry executives), I finally got tired of working so hard and decided to retire. You must find a new way or place to be a programmer if your job is not motivating (like starting your own company or trying something new) or finding another line of work. Reinventing yourself isn't easy and is much harder today, but you can do it if you want it enough.
Programming, even when in service of my corporate overlords, is invigorating. Coaxing the machines do my bidding never gets old. I could do it all day and not get tired. During those rare times where much programming is needed, I often lose track of time only to realize I've been at it for 15 hours straight. Its been this way for the nearly 20 years I've been doing it.
Sadly, programming is only a minor part of the job. The further I get, the more that is true. I might only actually program an hour or two a week. The rest is spent in ridiculous meetings, hand holding people who fail to read, trying to coax others to coax the machines to do what is needed, "planning", and similar noise. The only rewarding part is mentoring younger programmers.
I continue to do it because its a safe path to retirement and I am nearly there. My plans for retirement: program stuff I want to program for the pure joy of it.
> 90% of the time when I read descriptions it is excruciatingly obvious to me that whatever code the chosen candidates will end up writing at this job will be completely removed from any important problem not only humanity, but even any individual human has ever had. Startup culture is shamelessly at the forefront of this industry’s ‘produce more code and ask less questions’ policy.
I would suggest that part of the problem is that many developers wish they could work on meaningful projects with good people at the pay rate that they are currently getting at $FAANG or with the amount of equity they'd be getting at $STARTUP.
In practice, employees treat meaning, independence, agency, and work-life balance as currency and are willing to take a pay cut in order to secure a meaningful job. Better jobs are out there (I found one), but if you're currently working for an adtech company or an AI startup you will almost certainly need to be willing to look at a much lower salary than you might be accustomed to.
I'm one of those people who will happily take a pretty big pay cut for my sanity 9 times out of 10. I grew up in a low income household and have lived on very little at several points in my adult life, it comes naturally to me and I almost prefer it in some ways. My mental health is more likely to be threatened by over-stress or a lack of meaning than by having to stretch a shoestring budget.
The only time staying in a job I don't have many positive feelings about (or worse, only negative feelings) makes sense to me is if I have very specific plans for the extra money I'm making and very good odds of seeing the plan through.
Such a way of life isn't for everyone, but I strongly advise those who maybe lean less materialist than the norm and/or aren't afraid of more frugal living to consider it. Especially if you've been asking yourself more than once a week lately how much more of 'this great job you have' you can tolerate without a breakdown.
I'm a software engineer at a large construction company and find my work deeply meaningful. We make sure people building actual stuff stay safe with our tools, and work more efficiently. It's so cool to see mind blowing, tangible projects get built.
You're right, FAANG comp is definitely way higher, but I really enjoy where I work and it's the first place in a long time I haven't felt an urge to start looking for something else a couple years in.
> I'm a software engineer at a large construction company and find my work deeply meaningful. We make sure people building actual stuff stay safe with our tools, and work more efficiently.
And if the management is seeing your work and appreciates it, that's pretty much a dream job. Good for you.
Agreed, there are plenty of small companies out there. Early startups, pre or early product-market-fit, etc. Mostly can't afford to pay large salaries. Need people who are interested and self-motivated. Willing to be flexible in various ways – a lot more is negotiable with small companies.
They aren't going to get in front of your face easily – you'll need to seek them out.
Solution: go independent, work on your own ideas, and sell them to consumers. That might be your own start-up, but for me it was to become an indie game developer.
One of my games, YOYOZO, was featured in Ars Technica's "Best Video Games of 2023" so I feel my decision was the right one.
I funded myself with the proceeds of earlier games. The game in question took only 23 days to make. I'd say I make one game every couple of months.
The initial short ramp up to the first game sales was funded by COVID-19, some freelance, some savings, some ebaying. But on the whole my game sales fund the next game.
How did you do this transition? How did you feel about your decision before your game was featured? I've been thinking about this path, but I feel too hesitant to jump.
I made the decision in early 2020, shortly the first C-19 lockdown happened in the United Kingdom. I had extra time every day given that my usual routines, childcare, etc were disrupted. And I had a Playdate developer preview unit. I switched from web and app development to purely games. I'd previously made games but only occasionally, as a hobby. Though I do live and breathe classic video games.
During lockdown I created many prototypes and a couple of them showed enough promise to become full games. That was the point I went all-in and I haven't looked back. It took time for the device to launch, but again largely coinciding with C-19 restrictions. Through itch and Playdate's Catalog store I make enough money for my modest way of life, so I'm happy. Life gets in the way occasionally, but I keep pushing forward.
The accolade was a complete surprise and very encouraging.
Thanks a lot for sharing. I love your approach for smaller games with faster cadence, and that it worked as full time job. I know the market is tough, but I hope you can make it work as long as you want.
Just say no to it. I decided to go public and add on my LinkedIn and now on GitHub too a disclaimer (see here https://github.com/mihaitodor) that I refuse to do Leetcode-style interviews or anything like that and I'm happier since. Sure, there are companies which will refuse to talk to me because of this, but that's fine. I never passed one of those interviews anyway and always had to take jobs where I didn't have to live code during the interview.
Yeah the problem these kind of interviews don't even test how well you think about a problem and how capable you are of designing the solution. The expectation is that you basically perfectly memorize the optimal solution (which was probably found by some Ph.D. working on algos). And in the end you're end up implementing some endpoints for a 1k MAU CRUD.
Startup time! Has its own tradeoffs but you get to go compete with the system that is maddening. Imagine them trying to run a race against people who are actually trying? That's why startups are able to win against huge companies with seemingly unlimited resources. They use those resources to fight internally over who controls the resources.
Startups have their own perils of course. But you get to do work. Real actual work.
Seeing a lot of agreement here, so I thought I’d post to say that I don’t agree with much of this. I don’t think the problem is “industry”, and I think open source is often similar.
I wrote a short series of blog posts a while ago (in need of revision, but good enough for now…) about decisionmaking in software: https://prog.blog/essays/decisions/
The upshot is that decisions in software are creative products—there isn’t usually a “right answer”, only benefits and drawbacks. And one decision’s consequences become the next decision’s parameters. The reason businesses don’t like it when you start re-litigating old decisions is that the alternatives to what was chosen are typically not strict improvements, and implementing them would require re-making a bunch of other downstream decisions.
It’s fine to feel that your new company’s codebase is ugly, but recognize that it got that way because creative professionals needed to make a decision in their codebase with their own backgrounds and limited information about who would be using their software and how. I think that maybe the only alternative is to set up shop as a solo dev.
(By extension, I think software developers will be better understood—and we’ll better understand ourselves—once we start seeing our industry as a creative industry and ourselves as creatives. This post feels to me a little bit like a screenwriter complaining that most TV is bad and most screenwriters are forced to crank out episodes and most shows are not solving humanity’s fundamental problems)
My take on this is that engineering used to be more involved in the product side of the house, but that went away with the rise of PMs and designers. Remote work has made it a bit harder to collaborate, and companies are more willing to hire developers across timezones to save a buck.
Figma made it really easy to create high fidelity mockups, which took away UX decision-making from engineering. Many developers are happy to oblige, not wanting to be a part of any discussions.
So, what to do about this? That is probably a whole nother series of blog articles.
Huh, I guess this is just totally misaligned with my lived experiences working for startups. It's the only environment I've ever worked in where engineers are allowed to do engineering. I don't just write code, I get to be the architect of a broader system.
If you don't want to work for a company that makes meaningless bullshit, then... don't. There are plenty of companies making things that are actually useful to society. Go work there instead.
Sounds like you might be better suited for working at a company that doesn’t do products but rather projects for others. Plenty of architecting to go around. Any if you get to work on enough new projects, you actually get the chance to make projects succeed faster by iterating on initial architecture and project setup.
It’s still all meaningless bullshit of course, but it’s others’ bullshit.
I've found much the opposite. I love working for product companies, because the vision is clear. There's an actual goal in mind, not just "keep the customer satisfied."
I helped my last company build the world's first fully wireless neonatal ICU. I help my current company keep people in austere environments connected with each other. If that isn't meaningful stuff, I don't know what is.
Is this a geography problem? I feel like I hear complaints about meaninglessness of work from my peers on the west coast far more often than I hear them from my neck of the woods.
This is part of the programming industry, but it's not the whole thing. I'm reminded of the story of a bunch of blind people all describing different parts of an elephant. You move your hand around a bit and it sort of all feels the same, but that doesn't mean you've touched the whole elephant! Elephants are big.
This part in particular stood out:
> thousands of lines of unmaintainable spaghetti code engineers were bullied into writing in weeks instead of months using arbitrary trendy technologies.
This is not my experience at all.
I have 2 part-time jobs writing Perl code, and at both of those jobs the people I encounter are thoughtful and intelligent and want to do a good job (including managers).
Nobody is bullied into anything. Nobody wants thousands of lines of new code. We have enough thousands of lines of old code that nobody understands :).
Your experience of the programming industry very much depends on what part of it you work in, and specifically who you work with. But I think if you want to "quit the rat race", Perl is a good choice, because everyone who wants to rush around chasing fashion trends left Perl behind a long time ago. Also, I'm told Perl developers are getting harder to find so salaries are going up.
As a software engineer, your craft is about the breadth of software engineering, and embracing professional pride and dedication in doing that well. Well implies towards the goals of the organization.
Programming is only one piece, and not the most important.
And the nature of the programming you do changes because of the software engineering concerns. (Examples: on a given project, a goal might be that the code be maintainable long-term, or maintainable by others, or not disrupt an interface with another team, or delivered in a certain short timeframe, or work the first time and every time.)
Where it gets much more complicated is that a lot of companies are highly inefficient or dysfunctional internally, and don't really permit doing software engineering well. So, you might find yourself not only not allowed to do programming like you love, but also not able to practice or even recognize the craft of software engineering.
If you love programming, find a job that will let you do some of what you love, or save your love for your own time. If it's your own time, have especial fun with it, and don't turn it into a job without pay (unless you can also turn it into a paying job, like a startup).
This feels like the author simply went for the entirely wrong jobs. It sounds like what he wants is to make decisions, and those you can only make in small teams, small companies, and in lead positions. Going for any sort of FAANG or corporate job is the opposite of this - and that is not specific to programming jobs in any way. Nobody is 'free to just improve the world' in a large group.
Rewrite the flagship app from the ground-up in a new framework. It's a little easier if most functionality is behind APIs. The requirements are already concrete: make it look and function the same.
Express the common business flows with a novel algebra (types). Make logic errors be type errors [1].
These pull requests may never get merged; the feature branch may age for years; at least you gave it an honest go.
[1] When people say, "but most business logic bugs aren't type errors," I just want to show them how to make bugs into type errors. -- Matt Parson, from Thinking in Types (2018) by Sandy Maguire.
I have experienced these sentiments at various jobs and times. I've also varied my types of jobs to be exploring new areas and higher challenges. Other times, I've found interesting/challenging ways to get work done which may (or may not) pay off in the future--things like code analyzers/generators, etc. On the other extreme, I was terminated early from a contract position for "doing math at work after hours"--I was bored and doing Project Euler with a random new language. I totally understood my work was done and was highly paid, so any excuse to cut costs made sense.
There's many kinds of 'programming' and the OP only seems to have done standard applications. Maybe get a job at Jane Street and they might be challenged. I myself don't think I'd qualify but I don't complain about the banality of mundane tasks--I find interesting and challenging ways to make software tools that help devs and/or help customers.
Somehow I've almost always managed to find a balance of keeping employers happy while carving out time to do experimental work. It's probably a combination of communication, alignment, and trust. Start small, show value in the kinds of things you're talking about, and demonstration is key--talk/complaining won't move the needle. And don't delay key deliverables to do something excessively unusual.
Side topic, corporate vs. non-profit sector:
Downside:
75% lower rate than standard industry rate (5% lower rate of pay than "80%-Compa").
Upside: 38-hr work-week instead of the corporate-standard 50-hr week - effective hourly rate is 5% higher.
Plus: Set my own pace, nobody's getting rich at someone else's expense. Rarely, if ever, are there mass layoffs.
A tip for those who still have the chance to change careers and want to do programming instead of whatever it is that done in vast majority of industry: switch to academia.
You won't be paid that much, your employment situation will usually be unstable and you'll have to do some boring bureaucracy like beg for funding and play politics, and will likely have/get to teach.
But you'll get to do more or less whateber you want, or at the very least get to decide how to do it. Most projects are greenfield and they work well enough when they work for your purposes. The programming is about the problems, not making yet another CRUD. What you do probably doesn't have much effect on anything beyound your small bubble of collagues, but at least it's usually not actively harmful to society in the way a lot of industry is. You can mostly say and think whatever you want without corporate gagging.
I made the switch almost 20 years ago and I'm very glad I did.
Or as an alternative, switch to companies that don't sell software only. Of course that is easier if you have a rudimentary technical background, but the industry seems much less "corporate and bullshit" and you learn much from adjacent general engineering, which keeps work interesting.
The usual software house is a good way to get sensible development experience about tooling and development organization. Perhaps sometimes also about how not to do it, but it often can help.
Scrum seems to be the symptom of bad management though. I have a good manager nowadays and we don't use scrum, but it's because the guy is a good manager.
It's easy to draw lines to other industries from this too, mainly to music one. The mainstream does not produce or provide to those that would rather do something more interesting or niche, unless the niche becomes popular enough that the mainstream wants to usurp it, thus killing the original interesting ideas in the first place (see: corporations and their pseudo-"open" source projects for example).
At the same time there's a race of who can sell out the fastest, turning their ideas into corporations and playing the mainstreams game or (most likely) fail trying.
Luckily there's always those that choose otherwise and I'll always have more respect the anime avatar person with a nickname that chooses to spend their time on something like improving Atari Jaguar emulators than the "indie hacker" who sold their email marketing scheme to Google for 10 million bucks.
This post has an odor of dogmatism. The author seems both legitimately brilliant and a huge pain in the ass to work with. At some point along the path toward "senior engineer" and beyond, failure to persuade others of one's value hierarchy says as much about the individual as the group.
"remember that historically the most groundbreaking achievements in early computing have happened in the service of the greater good. This is what I really want to do: I want every how - from the programming language and paradigm, architecture, down to every line of code and piece of syntax - to be informed by the why of the system that is being built. And I want that why to be a reflection of a genuine existing need, not some bullshit business metric which pretty much exists for its own sake."
That's a pretty achievable goal, work in the defense industry and the public sector. Programmers are in high demand, the economic incentives align with building things correctly and don't consist of shipping AI powered coffee machines in the next four weeks and the technical work is usually complex and interesting.
I’m coding for my own projects and care about code quality a lot and maybe too much, however in my opinion as a collective our biggest weaknesses is that we are political about everything. If we have a job or a goal this should be our main decision driver. That sometimes means to push back for quality but sometimes just getting the job done. Our goals should be aligned with the companies goal and still we need to accept hierarchies.
Stubborn coders can kill a company but coders that can suck their ego will be paid a lot more over time.
Not saying you have to, whatever feels right in your life’s philosophy but if you take a job the job is determined by company interest and not your interest. You are free to leave if you don’t like.
I honestly think this is best for the society as it makes us productive.
This tug of war between individual satisfaction and monetization exists in all industries and not just SW engineering. There are very few areas where there is an overlap between solving problems benefits all of humanity while being able to monetize it for a sustainable business(finding a cure for cancer for ex). It's not the fault of any industry or economy etc, it's just a mismatch of expectations vs reality.
The same kind of introspection lead me to create civboot.org[2] I'm currently creating a Lua-based development environment from scratch in (nearly) pure Lua[3].
There are others out there. You're not alone.
PS: Why Lua? Because it's small and readable and makes a great extension language.
An interesting article and discussion points. Like all theatres of tech, there are great companies and terrible companies to work for. The terrible (big) ones usually pay very well, but they want their pound of flesh and you are there to generate revenue.
One thing I do know after 30 years in tech - recruitment is completely, utterly and fundamentally broken!!
Even if you 'quit' corporate, it will be the VCs (if startup) or clients (if consulting). People who care about the craft will suffocate in envs which care about what the craft can do.
One way may be to mentally separate the two kinds of programming. At work, code for the org. After work, code for craft.
The issue is that at its purest, programming does not sustain itself financially, or it does but not in the short term. The programming industry is designed to be financially profitable (let alone sustainable) even if it's a conceptual dead end when it comes to groundbreaking stuff.
Yeah I feel like this article would benefit from some concrete examples of what it is the author is actually envisioning. Products that truly benefit humanity in the strict sense are few and far between.
> 90% of the time when I read descriptions it is excruciatingly obvious to me that whatever code the chosen candidates will end up writing at this job will be completely removed from any important problem not only humanity, but even any individual human has ever had
> ...
> So far I haven’t had the chance to actually meet someone who would share these values in any significant sense and would want to do this kind of engineering work
There are countless such places!
There are NGOs that desperately need good engineers to build software that's essential to helping people. There are labs that do research on various disorders, or on hard engineering problems that need desperately software engineers.
This is an incredibly selfish and childish demand. Except of doing the really hard work of finding and CREATING meaning in your everyday life by understanding the problems of other people you want to re-enact with the benefit of hindsight the people that did this successfully in the past. Most people in your corporate job actually are making the same mistake as you, maybe it is time you wise up and call them out on it. Before you can do this at least admit to yourself that you don’t know what to do next either.
We were for a time a small company, and we broke off to become an even smaller company. I had a pretty big (perhaps oversized) say in the way things worked, UI, UX, architecture, and had the power to affect and stop decisions I thought would be bad for the users, etc. Working with our designer was a collaborative process.
We got bought out by a much bigger company a number of years ago. The pay is better, but the amount of say I have has slipped away basically to almost nothing.
We just get told what to build and how it should work and look by people with no actual connection to the product. People who frankly have barely used it and just got assigned to design a new feature, and have very little idea how it fits into the bigger picture.
I feel like now I'm only here for my ability to code and not my mind more generally and it's frankly kind of soul crushing.
I've considered leaving, but I'm getting old and a well paying job is a trap, doubly so when you now have kids.
I have had the same thoughts. In my opinion, from the developer's perspective, there are two issues in the industry:
1. Conveyorization of development process.
Developers write code, that's it. Most what I have done for the past 6 years was do ticket-based work, constantly moving from project to project. Ironically, at the start of my carreer, I was responsible for an entire internal application (including designing new features, being on-call, and talking to end-users), so I grokked the entire setup and purpose.
2. Self-perpetuating push for constant change for the sake of change.
Producer (e.g: tech corporation) releases an update to their product to improve some internal metric or make more money -> Consumer updates their product (or jumps on the hype for next big thing) -> Producer metrics go up -> Repeat. This keeps both Producer's and Consumer's developers employed while providing very marginal benefits.
While this is a bit of a strawman, think of how many versions (and names!) Of .NET, or React, Angular, Vue or any other framework there has been over the last 10 years and whether each version improved much.
Combine the two, and, as a developer, you don't know how what you're doing matters, nor why you're doing it at all.
I used to think like that but no more. We're currently working on a new product. One that most the team would like to own and use when/if it gets to market. I'm very much contributing in my area of expertise, and yet... I've had to make some compromises to make target dates. Those dates are not all arbitrary - we need to be at certain events to stir up connections, interest, and get feedback on what we're doing. Half the code is written by another person with vastly different ideas and style, yet we've formed a decent boundary that's stable and we stay on our side. None of it is perfect, but I'm excited about the product. I'd say "hey come work with us" to this guy but I honestly don't think he'd be happy. That frustration is coming from inside.
in 1950 in the book "the human use of human beings", the famous mathematician Norbert Weiner pointed out your exact sentiment. Complaining that instead of solving problems, or doing anything new or interesting, people were using these "computing machines" to increase the efficiency of the parts of the capitalist machine that caused the problems in the first place.
You may find the world of “Civic Tech” better aligned with your values. Look into organizations like
Code for America, Center for Humane Technology, the U.S Digital Service, 18F, The Berkman Klein Center, and the Public Interest Technology Initiative at UMass.
I've had a bunch of different roles through the years. From programmer at the bottom of the totem pole to being CEO or CTO in my own company and having my own department in a large corporation. The perspective in these different roles tend to be very different and I have learned a lot in each of these roles.
Being at the bottom of the totem pole is the easiest job of the bunch. Your focus is gloriously narrow and straight forward: deliver value within some set of constraints and try to enjoy yourself.
Being a leader in charge of people who deliver value is a lot more complex. Especially if you have experience being one of those who you are tasked to lead. You remember what it was like being them, but now you have a wider range of concerns to balance. Yes, there's delivering value, but you also have to take care of your employees, investors and customers. And these concerns will come into conflict with each other.
I've spent a lot of time evaluating companies, products, codebases, practices, leaders, developers etc during technical due diligence projects. This has also been a great learning experience to me: the chance to get an intimate glimpse of other people's shops without having to work there.
I can recommend doing this kind of work because it is easier to see clearly what is going on when you are not part of it.
A lot of problems tend to stem from imbalances. For instance, sometimes I come across companies with problematic leaders who "rule" their fiefdoms rather than involve the people working for them in decisions. I also sometimes see the opposite: a breakdown in discipline where developers lack direction and everyone does their own thing - either because there is nobody to lead them or because developers can't take direction.
It isn't uncommon for investors to require companies to replace managers that perform poorly before investing in companies. It is less common to require the removal of problematic developers. Quite possibly because tech DD processes often aren't thorough enough to discover what goes on in the bowels of the beast.
I've actually written tech DD reports where I've made both types of recommendations: both recommending getting rid of bad leadership (which is usually an easy recommendation to make), and I've had cases where I have concluded that sometimes entire software teams need to be restructured. In the latter case it is devilishly hard to actually come up with recommendations for how you fix broken teams.
In the corporate world (of large companies) these things are harder because you will encounter more ineffective middle managers (and layers thereof) and quite often, that more senior management have their positions not on merit, but due to political games. To make positive change in large corporations is harder. But it can be done. However it will fail 100% of the time if one resigns oneself to "I'm just a minion - I have no power".
From personal experience though: it is hard to make change from the bottom without somehow disappearing into management. Corporate cultures tend to assume that only certain types of "officer class employees" can make decisions. (Which is how I wound up as a programmer in a large corporation with a VP title. Yes, it was confusing and weird)
Nicely put. I also spent decades in the SW industry, tried about a dozen things, but chose to stay out of management. For me, business and engineering are two completely different areas, often conflicting, and my training is extensively in math and engineering. Trying to do both ends up with mediocrity almost certainly.
Welcome to post-capitalism. We’re no longer in the realm of free markets for goods and services. We now make up new markets and deal in abstract commodities such as attention and relationships. The need we are building things for is capital: profits over people.
It’s not all bad though. “The industry,” is a big place. There are companies out there that might share a good number of your values.
Unless you’re in a certain privileged position in this world you may have to compromise on a few principles here and there on your journey.
Though I should add, never give up on your principles. We may have to make compromises with ourselves because we live in a society in which it costs money to live. Your job isn't your identity though and there are some lines which aren't worth crossing.
It's also hard to sustain a career in this environment alone for long periods of time. Consider your relationships as your most important asset. And consider organizing.
Differences can be made. Programming computers won't get you there. It will take some changes to the social environment around you.
The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code. They care about finding developers who will pump out features to the business requirements. Some human beings in that cog (managers, directors, peers, etc) may allude to enabling developers to actually practice the “art” of programming but the bottom line is if you aren’t moving the needle economically for the company, you’re a liability.
Find comfort in programming outside of the corporate world and practicing the art but don’t expect the “industry” gives a damn about the how or why of programming, mearly the characters we punch onto the screen into cash. Once you come to terms with this, life gets a lot easier, less frustrating and you can actually find fun in the work (albeit, not necessarily “art”).