And most people problems are communication problems. Engineers aren't engaged with the product vision or the customer base, and are allowed to silo themselves. Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop. Sales and CS fail to understand the cost of their promises to individual customers to the timelines of features they're hungry for from the product plan. Goals and metrics for success fail to align. And thus everyone rows in their own direction.
The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.
This is why I built out a Shadow Sessions program for our internal tooling teams at my BigCo.
The users are right there, go make friends. Learn what they're doing day to day. And how it fits into the larger picture.
These sessions are lightweight, and auto schedule every three weeks with no required action items and people come out of it amazed every time, lots of little bugs have been fixed, and connections are being made.
The culture of not engaging with the end users when they're so readily available is an odd one to me. And you can really get to say 80% of macro picture understanding and user experience design fundamentals with a fairly low lift.
To do this I created a sign up form and an auto scheduler that interacts with the Slack API. The scheduling and getting folk on board is the hardest part. Also finding time if you do things outside the product road map.
100% this. Go and spend time with the people using your software. Even better, use it yourself.
One of the companies I’ve worked for did food delivery, and in food delivery during Christmas week everybody works operations - either you’re out in a van with one of the regular drivers helping them carry orders that are three times larger than any other week, or you’re handling phone calls and emails to fix whatever problems arise. Either way without fail January every year would see a flurry of low effort/high value updates to the software those parts of the business used. Anything from changing the order of some interactions to fit the flow of dropping a delivery to putting our phone number in the header of every admin page.
Absolutely nothing beats going out there and doing the job to discover where the tools you’re responsible for fall over. Bonus points if you can do it at the most stressful time of year when if anything is going to fail it probably will.
Not using it themselves is why my managment at various companies wouldn't let anyone do sensible things.
Companies that sell to other companies .... don't care about the users. It's one bunch of managers sleezing up to another to make a sale. Whether the product is good to use doesn't matter to them because none of them use it.
A "good" company wouldn't allow this to happen but it happens often enough.
Another bad smell is when developers themselves never use the whole product and simply work on their little bit.
Eat ones own dog-food, or in other words, get the company cooking something great together and sharing the results.
A great company basically opens on its first day and 48 hours later there are a ton of well fed customers who come back, not incidentally, again and again for what they perceive, is great.
But apropos feeding customers, if you can't 'eat your own food' dog or otherwise, why expect the user to want to do it ..
And it's such a blind spot in the industry that the people most able to build and estimate features and software are left to be the least equipped to see through the end user's eyes.
As such, when you encourage user oriented engineers, these common and often low effort issues can be avoided at the outset which improves velocity organizationally and results in better software and user experiences for projects now and in the future.
A bit more heavyweight, but we implemented a rotation program when I was managing an internal tools team at a previous company. We'd trade an engineer from our team with an engineer from a feature team for a quarter.
The amount of improvements to our collective understandings was super valuable. Feature devs got to help fix problems with their tools more directly (while also learning that it's not always as straightforward as it may seem), and we brought back much stronger insights into the experience of actually using our tools day-to-day.
This is evidence that there is a prior element to this 'problem', which is that - in order for Technology to exist, Ethics have to be aligned well enough to deliver, effectively, the result of the technology: a product.
The user, ethically, is another piece of evidence - especially in real time and at huge scale.
So you are so right about the user. The user comes first, the technology second, and when the service of the latter benefits the former, greatly, at scale, the people problems become, well, people solutions - i.e., the user.
I think it’s because companies don’t incentivize people listening to each other. Management doesn’t listen to the underlings and the underlings have to compete to get noticed.
I have only a few people with whom I can discuss something in depth without anybody pushing an agenda. With most people it’s just about pushing through what you want to do.
I am just going through a bunch of sessions where a director has engaged consultants to change our stuff to use a new platform. Nobody who works on the system thinks it makes sense but it can’t be stopped because of the director and a few yes men. Nobody listens.
Makes me think of something my dad and I both talked about with our time in the military. He was Army and I was Navy. But when the ability to promote is tied with ranking against your peers, if you really want to game the system, you essentially sabotage your peers. Which is the exact opposite you want in the military or really any organization. You want to foster a, rising tide lifts all boats with getting the work done. But it hard when your performance evaluations are the complete opposite of that, and I have seen people do it.
I got qualified on our equipment quick and was in a position where I was training my peers who I was ranked against. If I were an asshole, I would have trained them poorly and drug it out. I didn't, but someone who is goal oriented to climb through the ranks as fast a possible, it is a logical action that I could have taken.
> If I were an asshole, I would have trained them poorly and drug it out.
That's of course the obvious way this goes wrong. Bad intentions. The much more insidious version is that you could have just been a terrible teachers, maybe you suck at training your peers, and you don't know.
The end result is the same. You look like the only person who gets it amongst the riff-raff, but in this case you don't even have a choice. The system has produced a poor outcome not because anybody abused it, but because it was a bad system.
Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop.
Because they want to feel superior as the ‘this was my idea and you executed on my idea’ nonsense. Their answers to most ‘why are we doing this ?’ ‘trust me bro’. I am perhaps generalizing and there are outlier product managers who have earned the ‘trust me bro’ adage, but most haven’t.
This PM behaviour will never change. Engineers have said enough is enough and are now taking over product roles, in essence eliminating the communication gap.
In my experience development has become too compartmentalized. This is why this game of telephone is so inefficient and frustrating just to implement basic features.
The rise of AI actually is also raising (from my observations) the engineer's role to be more of a product owner. I would highly suggest engineers learn basic UI/UX design principles and understand gherkin behavior scenarios as a way to outline or ideate features. It's not too hard to pick up if you've been a developer for awhile, but this is where we are headed.
If it's been around for a while, look at the last year's worth of projects and estimate the total delay caused by the specific piece of tech debt. Go through old Jira tickets etc. and figure out which ones were affected.
You don't need to be anywhere close to exact, it's just helpful to know whether it costs more like 5 hours a year or 5 weeks a year. Then you can prioritize tech debt along with other projects.
It takes guts to say “this 1 month feature would be done in a couple days by a competent competitor using modern technology and techniques”, and the legendary “I reimplemented it in <framework> over the weekend” is often not well received.
But - sometimes drastic measures and hurt feeling are needed to break out of a bad attractor. Just be sure you’re OK with leaving the company/org if your play does not succeed.
And know that as the OP describes, it’s a lot about politics. If you convince management that there is a problem, you have severely undermined your technical leadership. Game out how that could unfold! In a small company maybe you can be the new TL, but probably don’t try to unseat the founder/CTO. In a big company you are unlikely to overturn many layers above you of technical leadership.
This is why I incessantly preach to my coworkers: "you are not your job". Do not attach to it emotionally, it's not your child, it's a contraption to solve a puzzle. It should be easy and relieving to scrap it in favor of a better contraption, or of not having to solve the problem at all.
This is actually harder for more senior/managerial folks, as often they'll build/buy/create something that's big for their level and now they're committed to this particular approach, which can end up being a real problem, particularly in smaller orgs.
Once upon a time, I worked for a lead who got really frustrated with our codebase and decided to re-write it (over the weekends). This person shipped a POC pretty quickly, and got management buy-in but then it turned out that it would take a lot more work to make it work with everything else.
We persevered, and moved over the code (while still hitting the product requirements) over a two year period. As we were finishing the last part, it became apparent that the problem that we now needed to solve was a different one, and all that work turned out to be pointless.
but it is their code. It's their achievement. It's their mark on the world that says they were needed and did something useful. They struggled and their passion gave them the strength to get through it.
It's how they get to be the experts that are needed.
Replacing their code IS replacing their expertise and therefore them. How would you expect words to change that?
There's very few people whose brains work like this, it requires constant maintenance and people are ready to fall into the trap easily because they are held accountable for the outcomes, and its easy to pretend your ideas would have saved you from the certain disaster your fellows brought you to.
Just like every league of legends game, it's not possibly your fault!
If there's a legit, measurable performance or data integrity problem, start with that. If most of your production bugs come from a specific module or service, document it.
If it is only technical debt that is hard to understand or maintain, but otherwise works, you're going to have a tougher time of building a case unless you build a second, better version and show the differences. But you could collect other opinions and present that.
Ultimately you have to convince them to spend the time (aka money) on it and do it without making things worse and that is easiest to do with metrics instead of opinions
That’s wishful thinking but not in the way you think. A lot of engineers just want to finish their tickets and get out of there, that’s the reality. They don’t want to be in more meetings with the end user or product. You might have 10% of folks that actually love the job and want to build products at most places.
And all communication problems involve one or more senders and one or more receiver. The issue is you only got to be in control of one side. And even flawless massaging won't save you from incapable or unwilling receivers.
As someone who has worked in IT support I have seen users habitually click away clearly formulated error dialogs that told them exactly what the cause of their problem was and how to address it. Only problem? They did not read it, as became clear when I asked them what it said.
I have had people who I repeatedly had to explain the the same thing, made sure they got it by having them do it twice and a week later they would come again with the same question like sheep, not even aware they asked that one before.
Some problems are communication problems. Others are actual people problems that could indeed be solved by getting better people. Anybody who says otherwise is invited to do first level support for a year.
Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.
Ironically many of the first to be laid-off in a company are those that do this. That's why many companies flail during economic downturns and the problem exacerbates until better economic conditions prevail.
100% agree. Sadly, I have realised fewer people actually give an F than you realise; for some, it's just a paycheck. I am not sure what has happened over the decades regarding actually being proud of the work you produce.
I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down, and so want to make sure you don't end up in that position again. Covers all areas of IT from Cyber, DR, not just software.
When I have moved between places, I always try to ensure we have a clear set of guidelines in my initial 90-day plan, but it all comes back to the team.
It's been 50/50: some teams are desperate for any change, and others will do everything possible to destroy what you're trying to do. Or you have a leader above who has no idea and goes with the quickest/cheapest option.
The trick is to work this out VERY quickly!
However, when it does go really wrong, I assume most have followed the UK Post Office saga in the UK around the software bug(s) that sent people to prison, suicides, etc. https://en.wikipedia.org/wiki/British_Post_Office_scandal
I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Simple:
1. People lost ownership of the things they work on. In the early 1900s, more than half of the workforce was self-employed. Today, it is 10% in the US, 13% in the EU.
What you produce is not “yours”, it’s “your employer’s”. You don’t have ownership, and very limited to no agency.
2. People lost any tangible connection to the quality and quantity of their output.
Most workers don’t get rewarded for working harder and producing more or better output. On the contrary, they are often penalized with more and/or harder work.
To quote Office Space: “That makes a man work just hard enough not to get fired.”
3. People lost their humanity. They are no longer persons. They are resources. Human resources. And they are treated like it.
They are exploited for gain and dumped when no longer needed.
One weird thing about software jobs as opposed to other crafts is the persistence of the workpiece.
A furniture maker builds a chair, ships it out, and they don’t see it again. Pride in their craft is all about joy of mastery and building a good external reputation.
In most software jobs, the thing you build today sticks around and you’ll be dealing with it next month. Pride in your craft can be self serving because building something well makes life easier for future-you
> Pride in your craft can be self serving because building something well makes life easier for future-you
Yeah I did that in my last job as a platform engineer, I particularly intented for other teams to be able to work in parallel and also not blocked on me so I have more time to refactor or generally things to make life easier for future-me.
That only applies if you expect to be at one job for a long time. Current business culture makes that a poor bet, both due to pernicious Jack Welch style layoff management and the career and salary benefits of changing jobs every few years.
I think this ignores the codebase churn in Big Tech. The code you write today probably won't be there in ten years. It will be heavily refactored, obsolete, or the product will be outright canceled. You can pour your heart in it, but in all likelihood, you're leaving no lasting mark on the world. You just do a small part to keep the number going up.
Tech workplaces are incredibly ephemeral too. Reorgs, departures, constant hiring - so if you leave today, in 5-10 years, there might be no single person left who still remembers or thinks highly of the heroic all-nighters you pulled off. In fact, your old team probably won't exist in its current shape.
If you build quality furniture for your customers, chances are, it will outlive you. If you work on some frontend piece at Amazon, it won't. I think the amount of pride in your workmanship needs to scale with that.
Well said. I’ve always also thought that writing code and craftsmanship is a forced metaphor. At most, the product is the craft, not the code. And a product is exactly as good as people’s experiences of using it and how well it solves their problems. The underlying code quality is correlated with these things, but let’s be honest a badly designed product that doesn’t meet the customers needs can have PERFECT code and zero tech debt and still be a bad product because of it.
Also you know what, some code is disposable. Sure, we all want to craft amazing sculptures of metaphorical beautiful wooden chairs that will last a lifetime, but sometimes what the customer needs is a stack of plastic chairs, cheap, and done next week. Who cares if they break after like 1 year.
So, sometimes when I accept that my boss wants something rushed through, I don’t complain about the tech debt it’ll cause, I don’t fight back about how it should’ve designed to have wonderful code… not because I have no pride in my work, but because I understand the businesses needs.
And sometimes the business just wants you to make plastic chairs.
> Pride in your craft can be self serving because building something well makes life easier for future-you
But, it doesn't. It's not as if you get to sit around doing nothing if you did a great job, you just get some new software project. The company gets to enjoy the benefit of a job well done.
Getting a new software project beats the hell out of going back and digging through the cruft of a legacy software project. At least the new software project offers the chance to learn current tech.
I feel like to some degree, things have gotten less affordable. And I have seen a big push of the idea that “a job is just making money, find your happiness somewhere else”. Which led to more and more people looking for a job that pays well with less thought about whether they enjoy it at all. Many professions had an influx of people in for the money, not the passion.
Now of course you I can’t blame people for wanting more money and better standards of living, and that’s always been a thing. But many jobs that used to afford you a middle class life don’t anymore for young people.
I saw my engineering school software engineer department going from the least sought after specialty to the most in one year. The number of people passionate about tech didn’t suddenly jump, but each year we have a report about the last promotion average starting salary and software engineering was at the top for the first time.
The stuff we don’t really need (TV etc) has become much more affordable. The stuff we can’t live without (food and shelter) has become less affordable.
This is almost certainly a nice story we tell ourselves about a mythical past that just didn't exist.
It can be annoying to say, but modern factory produced things are in an absurdly higher quality spectrum than most of what proceeded them. This is absolutely no different from when machined parts for things first got started. We still have some odd reverence for "hand crafted" things when we know that computer aided design and manufactured are flat out better. In every way.
As for ownership, I hate to break it to you, but it is very likely that a good many of the master works we ascribe to people were heavily executed by assistants. Not that this is too bad, but would be akin to thinking that Miyazaki did all of the art for the movies. We likely have no idea who did a lot of the work we ascribe to single artists throughout history.
On to the rest of the points, even the ones I somewhat resonate with are just flat out misguided. People were ALWAYS resources. Well before the modern world.
Computer and machine manufactured parts can be better, but it's a mistake to believe they always are. Take two contrasting examples.
In guitar manufacturing, CNC machines were a revolution. The quality of mid-range guitars improved massively, until there was little difference between them and the premium ones.
In furniture, modern manufacturing techniques drastically worsened the quality of everything. MDF and veneers are inherently worse than hand-crafted wood. The revolution here was making it cheaper.
CNC and other machining techniques raise the high bar for what's possible, and they have the potential to lower costs. That's it. They don't inherently improve quality, that's a factor of market forces.
I would wager that the general change in availability of wood is by far the biggest driver in difference for the markets you are describing?
Particularly, furniture benefits greatly from hard wood. At least, the furniture that is old that you are likely to see. It also benefits heavily from being preserved, not used.
> MDF and veneers are inherently worse than hand-crafted wood.
Generally incorrect, but it depends. Wear can cause mdf/veneer to have "bad optics" compared to solid wood, but mdf/veneer can have more suitable physical properties and enables more consistent visual quality and design possibilities.
I suppose it depends on your definition of worse. It is more versatile. It's also toxic and fragile, and far more likely to break in ways that are hard to repair. I can only think of one object I own where the physical properties of particle board or MDF are a positive: a subwoofer where its consistency helps with acoustics.
If the cheap thing replaces the expensive thing and there is no same-price comparison, is it absurd? My point is that many products that were handmade at high quality no longer exist because of modern manufacturing. If you want a chair or, say, a set of silverware at the same inflation-adjusted price it would have been available for seventy years ago, you can't get it because the market sector has shifted so thoroughly to cheaper, worse products (enabled by modern manufacturing) that similar quality is only available through specialty stores at a much higher price.
This happens even if the specialty stores are using computer-aided techniques and not handcrafting, because of the change in economics of scale.
The catch here is that most people did not have high quality hand made furniture. Most people had low quality hand made things. Pretty much forever. And is why they aren't here for you to see them.
Modern process controls allow us to hit intended outcomes consistently at lower costs. But that doesn't mean the intended outcomes are always better that what you would aim for with less capability.
There are real customers that want cost reductions that lead to reduced lifetimes, because they have no intention of using the thing they are buying for decades. It isn't just manufacturers looking to make money through planned obsolescence.
>1. People lost ownership of the things they work on. In the early 1900s, more than half of the workforce was self-employed. Today, it is 10% in the US, 13% in the EU.
At a high level nobody works smarter and harder than people working for themselves because they see the direct results in near linear proportion. So basically half the workforce was in that situation vs a tenth. Say nothing about taxation and other things that cost more the higher up you go and serve to fractionally break or dilute the "work harder, make more, live better" feedback loop.
By "self-employed" - are you referring to subsistence farming? Everything I know about subsistence farming makes it appear much more precarious than corporate work; where hard work is especially disconnected from your rewards; governed by soil conditions, weather, etc.
It says early 1900s, so no. It does largely refer to farming, but farming was insanely lucrative during that time. Look at the farms that have the houses of that era standing on them and you'll soon notice that they are all mansions.
Remember, subsistence farming first had to end before people could start working off the farm. Someone has to feed them too. For 50% of the workforce to be working a job off the farm, the other 50% being subsistence farmers would be impossible.
> Look at the farms that still have the houses of that era standing on them and you'll soon notice that they are all mansions.
Those are usually large plantations, and the people who owned them weren't just farmers but vast landholders with very low paid labor working the farm (at one time usually enslaved). I doubt they were representative of the typical turn of the 20th century farm.
If we're speaking from vibes rather than statistics, I'd argue most 19th century farmhouses I've seen are pretty modest. Not shacks, but nothing gigantic or luxurious.
There are no plantations around here. This was cattle and grain country in that time. Farmers got rich because all of sudden their manual labour capacity was multiplied by machines. The story is quite similar to those who used software to multiply their output in our time, and similarly many tech fortunes have built mansions just the same.
> Not shacks, but nothing gigantic or luxurious.
Well, they weren't palaces. You're absolutely right that they don't look like mansions by today's standards, but they were considered as such at the time. Many were coming from tiny, one room log cabins (stuffed to the brim with their eight children). They were gigantic, luxurious upgrades at the time. But progress marches forward, as always.
> Farmers got rich because all of sudden their manual labour capacity was multiplied by machines.
This sounds like a semantic disagreement.
I think you are using the word "farmer" to mean "large agricultural landlord". Today, those terms may have a lot of overlap, because most of us don't work in agriculture like we did then, but in the past, it wasn't so much the case.
Back then, the landlord who had the "big house" wasn't called a farmer, but often a "Lord" or "Master".
"Farmers" were mostly people who worked as tenants on their land. The confusion in US history started early as the local feudal lords of the time (the founding fathers) rebranded themselves as farmers in opposition to their British rulers, but the economic structure of the societies was scarcely different.
In the 18th and 19th centuries, slavery and sharecropping were primary forms of agricultural labor.
Those are far closer to medieval feudal peasantry than 20th century industrial labor, regardless of the lack of an official hereditary aristocracy in the US.
> Look at the farms that have the houses of that era standing on them and you'll soon notice that they are all mansions.
> There are no plantations around here.
FWIW you haven't really stated where "here" is for you. It's not necessarily going to be the same for everyone, and based on the parent comments, the potential area under discussion could include the entirety of the US and Europe (although the initial comment only mentioned UK specifically, it doesn't seem clear to me that it's explicitly only talking about that). I'm not sure you can categorically state that no one in this conversation could be talking about areas that have plantations.
> It says early 1900s, so no. It does largely refer to farming, but farming was insanely lucrative during that time. Look at the farms that have the houses of that era standing on them and you'll soon notice that they are all mansions.
> Look at the farms that have the houses of that era standing on them and you'll soon notice that they are all mansions.
TLDR: survivorship
The typically large farms with nice houses were making reasonable money, and in a lot of places, only the house remains of the farm. My old neighborhood was a large farm, subdived into about 1000 postage stamp lots around 1900; the owner's house got a slightly larger lot and stuck around as your mansion.
The small farms that were within the means of more people tended to have shanty houses and those have not persisted. If the farm is still a farm, it's likely been subsumed into a larger plot.
That is wildly inaccurate. Do you think people were flocking to cities to flee the "insanely lucrative" jobs they already had?
Farm labor paid significantly less than industrialized labor at the time. I suspect in addition to just making things up, you're looking at a few landowners who were quite wealthy due to their land holdings (and other assets) and what they have left behind while completely ignoring the lives led by the vast majority of farmers at the time.
I read the thread. I don't see where that's addressed
I also see survivorship bias keep coming up. Each time it claims to be have been addressed in the original comment, and that's that. Yet I don't see how the existence of surviving mansions today proves anything about the prevalence of wealthy farmers at the time
Similarly, there's no inherent reason subsistence farming should prove or disprove work outside the farm. The existence of farms large enough to grow and sell surplus food, that doesn't mean all farms could do so
No, I absolutely read the thread. You either are just refusing to accept you're wrong, you have an exceptionally incomplete definition of farmer you refuse to share (which is really just a specific form of wrong that seems likely in this case), or you have some very exiting undiscovered data to share about life in the early 1900s in the US.
I was about to say, it's not like the early 1900s were particularly great for a lot of people... especially people whose ancestors were, uh, not in the country of their own volition.
Edit: I'm already down one - for people that don't read wikipedia here are the 4 dimensions of alienation of a worker as listed in the wiki:
1. From a worker's product
2. From a worker's productive activity
3. From a worker's Gattungswesen (species-being)
4. From other workers
Edit2: People [in America] will moan about their jobs, their bosses, their dwindling purchasing power, their loss of autonomy, etc etc etc but then come back as champions of capital. You see it all the time - "my job sucks but entrepreneurialism is what makes America great!!!!!!!". I've never seen a more rake->face take than this (and on such an enormous scale). It's absurd. It's delusional.
I don't specifically disagree with Marx's theory of alienation. However I disagree with communism. I think communism makes the problem worse, not better.
Identifying the bad stuff is not hard. Marx is far from unique in being able to do that. I find his class framing and assessment of the roles the various classes do in the status quo to be particularly good even if it ought to be deeply unflattering to the HN tax brackets.
Advising on where to go from there in an actionable way that produces good results is the hard part. Marx didn't do it. Those attempting implementation of his ideas have an exceptional record and not in a good way. And worse still, some of the worst aspects of those movements are the ones that stuck around to be peddled again and again under different brands.
I mean, there's a really simple solution between "Ayn Rand cinematic universe" and "abolishing private property" that gets you downvoted to oblivion: suggest forming a union. No communism required, just workers with bargaining power, like in other developed nations (Germany has very strong unions. Coincidentally, they also have a high quality of life and infrastructure that works). Instead, you get a bunch of people making six figures who sit around either whining or hand-wringing about losing their jobs, while continuing to support the economic system that is abusing them. After a certain point, you just have to throw your hands up and hope that people someday realize the power they have.
The sentiment is shared with Jean-Jacques Rousseau, Adam Smith, Wilhelm von Ketteler, Louis Blanc and probably lots of other less known people. Marx's theory of alienation is far more developed and nuanced than the generic cog-in-the-machine critique that is explored by many other people of various political inclination, not only Marx.
> Jean-Jacques Rousseau, Adam Smith, Wilhelm von Ketteler, Louis Blanc
...
> generic cog-in-the-machine critique that is explored by many other people
literally only one of the names you mentioned were writing post industrial revolution - the rest had literally no notion of "cog in the machine"
you're trying so hard to disprove basically an established fact: Marx's critique of exploitation of labor post industrial revolution is certainly original and significant in his own work and those that followed.
Exactly. That's why you can't jump from "people don't feel like they own their labor" and "people bemoan their boss" to Marx's theory of alienation.
> literally only one of the names you mentioned were writing post industrial revolution - the rest had literally no notion of "cog in the machine"
But the very framing that this is an ill that is unique to industrial society is Marxist. Slavery, corveé labor, taxes, poor laborers, marginalisation existed for thousands years in one form or another.
> you're trying so hard to disprove basically an established fact: Marx's critique of exploitation of labor post industrial revolution is certainly original and significant in his own work and those that followed.
I don't dispute that Marx's critique of exploitation of labor post industrial revolution is original or significant. I dispute your claim that people who share similar sentiment have to agree with Marx's theory of alienation.
The bad idea from Marx that lead him astray into pseudo-science territory wasn't worker alienation. It was the labor theory of value (and the other stuff he created to make it looks like it works).
Worker alienation is perfectly visible on the real world. I don't think anybody disagrees it's common.
But software development is different. There has been many decades where software developers suffered very little alienation. It only changed with the universal adoption of "corporate agile".
At age 62, I'm wondering which mythical decade did not alienate software developers?
There was a brief ray of hope in the late 90s, with the startup gold-rush idea that we would all be millionaires soon. Then the I realized the founders had 4000x my equity those companies...
Developers used to be freer to choose their tools, organize their routines, decide the result of their work, acquire transferable knowledge, and had access to their tools without any link to any organization (though that one has been steadily improving instead of post-peak).
My 40 years of alienation was not about equity, I was pointing out that the optimistic "We are all going to be rich" vibe of the 90s was wishful thinking due to the massive inequality in the tech world.
Few teams other than green-field start-ups have flexibility regarding tools or technology. My first job was COBOL, 'nuff said about that. Even at start-ups the leads / architects choose most of the technology, and many of my ideas were shot down, such as using C++ in the late 90s, and using Scala in 2010.
People seem to think agile has increased alienation, when in fact the pre-agile world was also terrible. What matters is the quality of the team, not the methodology.
> But software development is different. There has been many decades where software developers suffered very little alienation. It only changed with the universal adoption of "corporate agile"
Lol are you really gonna go with "I'm a software developer, fuck all the restaurant workers, teachers, plumbers, janitors!"
This is why Marx's ideas failed in the West - toxic individualism - and flourished in the East.
I don't know how delusional you have to be to look at the conditions behind the Iron Curtain, where nations had to build walls to keep their citizens from leaving and a meaningful number of people were willing to risk death to get out, and say they were flourishing, but I'm glad I don't have what it takes to get there.
Name the Eastern nations plural that built these walls please. As far as I am aware, the G in GDPR stands for Germany, a country/nation/state which is (and always has been) firmly Western. People on here have such an infantile recollection of actual history.
Anyway, leaving aside debates of where the prime meridian of West vs East falls, it should've been manifestly obvious that in 2025 I was talking about China...
You mentioned one, which is North Korea, and I'm sure you're going to concoct some story to deflect the fact that China only began moving towards any semblance of prosperity after ditching Mao's fundamentally flawed economic policies, so have at it.
As Sartre said - it's pointless debating people like you because you're just amusing yourself and it's only my responsibility to use words responsibly.
What happened is that most companies do not care about their employees, and their employees know it.
If anything happens, the company will lay off people without a care for what happens to them.
Even when they do care, such as in a smaller company, their own paycheck is being weighed against the employees, and they will almost always pick themselves, even if they caused the problems.
CEOs making millions while they lay off massive amounts of people is the norm now, and everyone knows it.
You can't blame the employee for not caring. They didn't start it.
There is no employer loyalty, that died in the 90s.
My dad worked as an engineer in the same firm for 30 years and retired. The company was founded before his father was born, and was publicly listed before he was born.
Substantially every company I have worked for didn't even exist 30 years before I joined, let alone before I or my father were born. Most won't be around in 30 years.
Several employers nearly went out of business, had substantial layoffs, or went thru mergers that materially impacted my department/team/job. The guys at the very top were always fine, because how could the guy in charge be responsible?
Even within the companies I stayed 5 years, I had multiple roles/bosses/teams.
>There is no employer loyalty, that died in the 90s.
As a millennial kid at the time, I remember the 90's movies and sitcoms (Office Space, Friends, the Matrix, Fight Club, etc) where the biggest problem GenX had at the time was, *checks notes*, the lack of purpose from being bored out of their minds by a safe and mundane 9-5 cubicle job that paid the bills to support a family and indulge in mindless consumerism to fill the void.
Oh boy, if only we knew that was as good as it would ever be from then on.
I remember the mass layoffs Yahoo had at the dot com bubble crash, when they had a 5-15 minute 1:1 with every worker they laid off. Now you just wake up one day to find your account locked and you put it together that you got laid off, then you read in the news about mass layoffs happening while they're now hiring the same positions in India and their stock is going up.
No wonder young people now would rather just see the whole system burn to the ground and roast marshmallows on the resulting bonfire, when you're being stack-ranked, min-maxed and farmed like cattle on the altar of shareholder returns.
The problems GenX had to deal with was watching Boomers, who enjoyed all the benefits of post-WW2 expansion of infrastructure and social services, pull the rope ladder up behind them once they got well-paying jobs.
The 80's and 90's saw the beginning of the "fuck you, got mine" mentality that pervades all but the most egalitarian societies. Reagan and Thatcher deregulated and privatized everything, and as a result a select few made a mountain of money and destroyed the middle class. "Shareholder value" and mass layoffs became the order of the day way before the dot com bubble burst. GenX knew we'd never have it as good as our parents - we just didn't know how fucked we were going to end up.
>The problems GenX had to deal with was watching Boomers, who enjoyed all the benefits of post-WW2 expansion of infrastructure and social services, pull the rope ladder up behind them once they got well-paying jobs.
No, I agree. But pulling the ladder from under them is not the biggest issue per se since every generation after them did them same if they could get on the ladder, the big problem with boomers is their immense hypocrisy.
GenX and Millennials knew that the situation was every man for himself grab everything you can while the going is still good, but crucially IMHO they didn't try to gaslight the next generations that this system of gains is somehow fair or the result of hard work and self sacrifice.
But boomers indulged in the period of sexual liberation and drug use, while then preaching about conservative family values and war on drugs when they got older, they enjoyed crazy good housing market and unionized jobs while preaching you should pull yourself by your bootstraps for a job that treats you like a disposable cog and won't buy you a house, they vocally hate socialism while depending on a generous social security system they designed for themselves and costing the taxpayer a huge amount on socialized government healthcare programs paid by the younger generations, etc the examples could go on. You can't hate boomers enough for this. Granted, not all are this hypocritical, but enough for the dots to form a line on the graph.
To be fair, the actual lesson of Fight Club is that maybe you do need a woman in your life. :D (That and don't delude yourself into believing the fascist inside of you.)
What really killed corporate loyalty for a lot of us was the lack of jobs that have lifetime pensions, if I understand it correctly. Why would I agree to work somewhere til retirement if I would be better jumping somewhere else to make more money now?
I think too much "caring" can also be negative. I do not want employees so "loyal" to the company that they don't consider changing for another. I do not want companies so "loyal" to all employees such that they would go bankrupt rather than keep 50% of people active.
I would hope people would be more responsive to the actions of companies. Earlier in my career I looked for another company when the discrepancy between CEO bonus and employee bonus was larger than what I found reasonable.
>I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Because there's still people doing less work than you do for a bigger paycheck
Because you'd get fired or laid off for someone working for 1/2 to 1/4th of your pay
Because they make you jump through multiple rounds of interviews and technical tests while people above you have a far less barrier to being hired
Because someone stole credit for your work
Because you'd get re-hired and find a mountain of shit code from a company that off shored their dev team
Because companies stopped giving significant raises that didn't keep up with major inflation in the past few years, while your work might have gotten them many multiples more of profits
And why? Not for any good reason, no. Just because they can. Your landlord isn't content when you pay $2,500 per month for an apartment, no. They need $2,600. $5 isn't enough for a dozen eggs, it needs to be $6. And what if we slapped 10-200% tariffs on random things, depending on the day? Wouldn't that be neat?
The collective delusion it requires to not see what the problem is is astounding. It's actually quite depressing, because it makes me think we're never going to meaningfully solve this problem. Maybe companies have to start executing employees or something, I don't know. Maybe then people will be bold and decide to re-organize society.
People have to be interested in their jobs to care about it. Corporations know that people rarely get to do whatever they want, so they assume (correctly) that most workers do not care, so they move on to care about processes, workflows, which makes even less workers care about their jobs.
For individual workers, the best thing is to work @ something you love && get good pay. Like a compiler engineer, a kernel engineer, an AI engineer, etc.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Many employers actively discourage people from doing work that they are proud of. You cannot be proud of something that is built as cheaply as possible.
You can get employees to care about customers or the product, you cannot get employees to care about profits and dividends.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Anecdotal, but I used to be proud of the work I produced, and then it got old and repetitive. However, as it was getting old, I was earning more. Now I'm in a place where if I were to quit and find something I could be proud of, I would have to accept a huge reduction in compensation. No thanks.
I'd rather have a much higher "just a paycheck" and find things to be proud of outside of work. Plus no one else cares anymore so why should I? Just pay me a lot and I'll keep showing up.
I'd really wish there was a better way to allocate compatible people together.. the distribution is often subpar.. lazies with motivated people drowning to fill in. If you change the ratio and let creative / driven / team-spirited work together you get exponentially better results.
> Or you have a leader above who has no idea and goes with the quickest/cheapest option.
This leader is not going with the quickest or cheapest option. Doing so would probably be laudable. They are going with the claims made by someone that a certain way is going to be quicker or cheaper. It doesn't matter if it actually is, or ends up being, quicker or cheaper. One plan is classified as meeting the requirements while another plan is classified as being cheaper, the cheaper one will be chosen even though it doesn't meet the requirements.
> for some, it's just a paycheck. I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Hard to be proud of the work you produce when you have no ownership over it, and companies show less and less loyalty and investment in their employees. When, at any random time, you can be subject to the next round of layoffs no matter how much value you contributed, it's hard to care.
So yeah, for most it's just a paycheck unless you are working for yourself, or drank a gallon of the koolaid and seriously believe in whatever the company's mission is/what it's doing.
I'm proud of my own work and projects I do for myself, tech or otherwise, and put great care into it. At $dayjob I do exactly what I am paid to do, nothing more nothing less, to conserve my own mental energy for my own time. Not saying I output poor work, but more so I will just do exactly what's expected of me. The company isn't going to get anything extra without paying for it.
Didn't used to be that way, but I've been burned far too many times by going "above and beyond" for someone else.
If employees had more ownership and stake in the companies they work for, I think the attitudes would change. Likewise, if companies went back to investing in training and retention, loyalty could go both ways again.
> I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down…
To the great surprise of my younger self I have never seen “it all come crashing down” and I honestly believe this is extremely rare in practice (i.e. the U.K post saga), something that senior devs like to imagine will happen but probably won’t, and is used to scare management and junior devs into doing “something” which may or may not make things better.
Almost universally I’ve seen the software slowly improved via a stream of urgent bug fixes with a sprinkle of targeted rewrites. The ease of these bug fixes and targeted rewrites essentially depends on whether there is a solid software design underneath: Poor designs tend to be unfixable and have complex layers of patches to make the system work well enough most of the time; good designs tend to require less maintenance overall. Both produce working software, just with different “pain” levels.
I've worked on two different systems which were built in weakly-typed languages that just got too difficult to reason about and fix bugs, so we ended up porting to Java. Customer-facing bugs that the guy who built the framework couldn't figure out.
Sometimes people make such a big mess you have to burn it down and start over.
> Sadly, I have realised fewer people actually give an F than you realise; for some, it's just a paycheck.
I found that most of the "people problems disguised as technical problems" are actually generated by people who get far too invested in their work and let it define them. They get territorial, treat any lost argument as an attack on their whole self, etc. They also lose perspective, getting into flame wars over indentation styles or minor API syntax quibbles.
People who show up for the paycheck are usually far more reasonable in that regard.
What is wrong with just wanting to work for money?
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Maybe if wages kept up with inflation people would still care. You know, when I was young, I was able to rent an apartment while being a cashier in a grocery store.
> What is wrong with just wanting to work for money?
Imagine a society where your work was an opportunity for you to provide products/services for your community, where you could earn a reputation for craftsmanship and caring, and where the real value was in the social ties and sense of social worth-- your community cares for you just as you care for it, and selfish assholery has high costs leading to poverty.
Now imagine a society where the only measure of social worth is a fiat currency, and it doesn't matter how you get it, only matters how much you have. Selfish assholery is rewarded and actually caring leads to poverty.
Which society would you rather live in? Which society is more emotionally healthy?
So the question is, is our current society the one we want to live in? If not, how do we move it closer to what we want?
Our current society can and does have room for both, which is great since some people want to live to work, and some just want to work to live. I don't see a problem with either, as long as it makes one happy.
And there's another group, grifters, who are neither living to work nor working to live. They are the parasites, and our current society rewards grifters by not putting them in check. Probably because so many want a piece of the grifting pie, in the same way many people see themselves as temporarily embarrassed millionaires.
Don’t forget another group, permanently disenfranchised, who are working to barely live. They are the unsung heroes of our society, who for a brief year or two recently got celebrated as key workers, got claps and applause, and then forgotten again once normality resumed.
"Show HN: I drive a garbage truck" wouldn't make the front page, but the world would grind to a halt tomorrow if those people stopped showing up for work.
The NYC garbage truck people are more than content to be paid handsomely in dollars instead of claps and cheers. Their union has the city by the balls and they know it, and they abuse that power to block modern trash containerization improvements. I wouldn’t have any qualms about personally automating their job
Frankly, people for whom the work is "just a paycheck" I know in real life are simultaneously happy and simultaneously frequently produce actually good reliable work.
Work being "just a paycheck" does not mean you hate it or half ass it. But, it means you do go home to get rest, you do socialize outside of work instead of irrationally pushing it and then using meetings for socialization. It means you do not have ego tied to it so much you throw temper tantrum when things are imperfect (which is not the same as being able to change things for the better).
Then pay people so they have a reason to care their work. This is like a wife beating husband wondering why his wife to care more about him.
every company in the united states could become a co-op and nothing would change for the business and everything would change for the workers. And everyone would be much happier at work and you would have the caring people you want.
It is the system that is the problem, not the people.
There's a difference between caring about your personal work product (and reputation), your colleagues on a personal and professional level, and your employer as an entity.
I expect my employees to show up to work and put forth a solid effort on a regular basis. Note that this doesn't mean a constant death march towards some unreasonable objective, or anything even close to it. Just apply yourself using the skills we agree you have for the pay we also agreed upon for 8 hours a day on average. In my field, this means you have pay that is well above the norm for an average software developer, and the working conditions are good or better.
A shocking number of people are incapable of this, and generally are also the same people who would claim that "they didn't start this".
I don't know how to explain any better that, if given the choice, I would simply not do what I do for the company for which I do it. Full stop. Somehow, when we talk about companies laying off thousands, that's "business as usual" and "nothing personal". But when an employee acts like the robot the company sees them as, suddenly people get upset! Why is it so hard to understand that people work because they have to, and not because they want to? Why is that so threatening to your worldview? Is it because, deep down, you know it's true?
I used to cope like that. I told myself that I could throw myself into my work, maybe stand out and make a difference. Guess what? I was overworked, burned out, and laid off right as I worked a few weekends and pushed through a crazy (and arbitrary) deadline. I still haven't recovered emotionally. I was sort of believing the lie, for a bit, but this severed the last thread.
My story isn't unique or special, but then I come on HN and I get told that I just have to "take pride in my work", like I'm not checking my e-mail every day to see if I even still have a job, during the worst cost of living crisis since 2008. I'm sorry, that's a fucking joke.
There are a million other things I'd rather be doing all day than this. And a lot of them involve programming a computer! But not things that allow some suit to send me a smarmy e-mail about "making 2026 our best year ever", no. Things that help me, my friends, my family, my community. Those are the only things that matter. Work exists because my landlord wants to retire comfortably in Florida. Bully for him. The rest of us, well. We have to grind it out and hope we make it to the finish line.
I believe that seeking external validation, inspiration and/or reason is not robust and a path to unhappiness. IMO, it's better if the reasons for you to care come from within.
The reasons to care are personal pride in the quality of your work, understanding that your lack of effort has a negative impact on your colleagues, and your continued employment.
And if you hate your job, but are completely unable to find alternative employment (which is what you should do if you hate your job), you probably should reconsider how much you hate your job.
If you can't find a better job, you should probably appreciate the one you have and not try to skate by with the bare minimum, if for no other reason than you're likely to miscalculate at some point.
Ah, noble poverty! Be grateful to tha masta' for providing you the scraps he can provide! Your paycheck is the beautiful work you produce for tha masta'!
Seriously, pay people what they are worth and they will care. It is not that hard.
The vast majority of people significantly overestimate their worth, yet people with your attitude seem to believe it only exists with respect to highly compensated employees.
I agree with your second sentence, but it's harder than it should be due to what I said above.
Pride in the quality of my work is a phrase to make one feel bad about themselves. I take pride in my hobbies and in my hobby projects. I take pride in my family and friends. I do not take pride in being exploited for my work so some higher up can buy a new car every year.
And again, someone comes and makes a comment that proves my point. Unless you are working in very unusual (and illegal in the developed world) circumstances, you are not being exploited in any real sense.
In the end this depends on your definition of "fair". What percentage of your generated production do you think is fair for the company to take? 95%? 50%? 10%?
That depends on the value of your generated production, among many other things, and ultimately isn't the right question to ask.
Can an employee obtain better employment terms elsewhere (which is a complex concept to define in itself)? If so, they are underpaid, if not, they aren't.
You were talking about exploitation. Using the fact that the employee cannot obtain a better employment elsewhere to extract as much of the production or value from the employee smells a lot like exploitation to me.
If an employer offers an employee $100 per hour, and the next best offer that employee can obtain elsewhere is $90 for an otherwise equivalent job, should the employee take that job for granted? Is the employer exploiting them with their pay rate?
In my humble exploited worker opinion, you resemble Samuel L Jackson in Django Unchained. You dont even realize in what position you are in. Get back to the ground bootlicker.
> You know, when I was young, I was able to rent an apartment while being a cashier in a grocery store.
You still can almost everywhere outside of places like SF? I just spot-checked some data, and in Minneapolis for example currently available apartments are comparable to what they were when I was looking 10 years ago, cashier wages have gone up 45%, and that often comes with healthcare benefits now. It's not an especially wealthy life, but a single person should be very comfortable (that's a comparable hourly wage and apartment cost to what I had delivering pizza at some other part of my life, and I lived comfortably and was able to save up to splurge on a nicer used Miata and the down payment for a small house).
So I believe it actually worse that the article makes it out to be.
Currently AI "solutions" being implemented in places like call centers are often technical solutions attempting to pave over organizational problems. Many IT solutions are like that. We refuse to fix the underlying problems, so we layer software on top, so we won't notice the stupidity below.
IT companies will happily take the money and write the code, broken as it might be, because the real problems aren't actually resolved. That to me is a problem. Companies needs to be way better at saying no, and offer help address the underlying issues instead, even if they aren't technical in nature.
> I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect
I recall there was a whistleblower Richard Roll who said that engineering did know of the bugs and flaws
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Millions of boocampers and juniors trying to make a quick buck; any tech work that is not “make it, and make it quick” is punished; tech debt swept under the rug; any initiative is being shut down because status quo is more important; “we’ll optimize when it becomes a problem” on 15 seconds page reload; dozen of layers of parasites and grifters making your life hell, because their paycheck depends on it; salary bumps that don’t even cover inflation – the only way to actually move in life is to join, raise as much hell as possible in 2 years and jump ship leaving the fallout for the next SOB in the line.
And that’s just what I bothered enough to type on bad iOS keyboard.
Work is just a paycheck because I am just a number for my employer. Why would I be proud of my work when apparently according to management I should be replaced by AI at some point because im just a cost factor.
Why would I care about the business at that point? Fuck the higher ups, I'll be proud of my work and actually put in effort if I can afford a house.
Frankly, something that I don't see discussed enough is the truth that many people are plain stupid. If my position in the company depends on stupid people, then this completely changes the game, because then good engineering isn't the best way to maximize my status anymore. That's how you get smart people spend their time coming up with elaborate tactics to appear productive while in reality they aren't and play office politics. All successful corporations understand this and build processes around the assumption that their workers are idiots, which has the side effect of suffocating smart workers, but the truth is, ten thousand morons is a bigger force than a hundred geniuses.
Say this in an interview and its a perfect way to fail, even though its true. Its sad how interviewers often take pleasure in pointing out that anything said outside their packets is a signal for lack of technical knowledge. I've been in and passed several tech interviews. I've also interviewed plenty of people, if someone points out the human aspect of a problem, I actually award points. Sad how often I have to fight with my colleagues.
"But what about using a message queue.."
"Candidate did not use microservices.."
"Lacks knowledge of graph databases.." (you know, because I took a training last week ergo it must be the solution).
In my most recent role, everyone interviewing me gave me a thumbs up. Except one engineer.
I remembered our conversation well, because it left me a little confused. We were talking about handling large volumes of messages. And when I said "well it really depends on the volume, you could be fine with batch processing in many cases" he jumped on it like I had never heard of a queue.
Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues. He flat out rejected the claim (because that didn't fit the current system design).
Guess what we're discussing now and have spun up a whole team to complete? Forcing every micro service to use a single API rather than elasticsearch directly, because of scale.
> Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues.
There's a small but substantial number of engineers out there who haven't operated at the kinds of scales where hyperscalers' limits become normal architectural problems and don't have the humility to imagine that it could be the case. (e.g. blob stores do in fact have limits you can hit, and when you operate at petabyte scales you have to anticipate in the architecture that you can hit them for even trivial operations.) I also work on petabyte datastores and have encountered a bunch of those engineers over time.
To be fair though, that's the small minority of engineers I've encountered, and if it wasn't arguing about the types of scale problems unique to petabyte scales, it'd be about some other nuanced subject matter. It's a humility problem.
Its also a math problem. The kind I've encountered that make bad decisions are also the ones shockingly bad at doing back of the envelope calculations.
Honestly failing candidates in an interview put of a sense of superiority is just about saddest thing I've heard. I mean how lonely do you have to be ?
I've found presenting arguments from both sides, i.e. presenting the tradeoff, to be effective in interviews. Especially because if the team I'm considering doesn't recognize the tradeoffs, then I can avoid joining up with them.
As a data engineer in big tech, the two hardest problems I deal with are:
* Conway's law causing multiple different data science toolchains, different philosophies on model training, data handling, schema and protocol, data retention policies, etc.
* Coming up with tech solutions to try to mitigate the impact of multiple silos insisting on doing things their own way while also insisting that other silos do it their way because they need to access other silos' data.
And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs. As someone who gets to see all of those approaches - most of their approaches are both valid and flawed and often not in the way their leaders think. A few are "it's not going to work" levels of flawed as a result of an architect or leadership lacking operating experience.
So yeah, it might look like technical problems on the surface, but it's really people problems.
- Requirements are rarely clear from the beginning;
- We (DE) are not enabling self-service and automation so we are drowned in small requests (add this column for example;
- Upstream rarely notify us about the changes so we only know when downstream alerts us. We end up building expensive pipelines to scan and send alerts. Sometimes the cost of alerts > cost of pipeline itself;
- We have so many ad-hoc requests that sprint is meaningless. If I were the manager I'd abolish sprint completely;
- Shadow knowledge that no one bothered to write down. I tried to write down as much as possible, but there are always more unknowns than knowns;
Working in DE definitely gives me enough motivation to teach myself about lower level CS.
That's the mother of all people-space problems in IT, right there.
To solve this, one can be an instrument for change. Network, band people together, evangelize better ways forward, all while not angering management by operating transparently.
Sometimes, that can work... up to a point. To broadcast real change, quickly, you really need anyone managing all the stakeholders to lead the charge and/or delegate a person or people to get it done. So the behavior of directors and VPs counts a lot for both the problem and the solution. It's not impossible to manage up into that state with a lot of talking and lobbying, but it's also not easy.
I'll add that technological transformation of the workplace is so hard to do, Amazon published a guide on how to do this for AWS. As a blueprint for doing this insanely hard task, I think it holds up as a way to implement just about any level of tech change. It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow. https://docs.aws.amazon.com/prescriptive-guidance/latest/clo...
> It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow.
Yup, this is the key issue and what makes it primarily a people problem. Technical solutions don't work if the main problem is getting buy-in to spec/build/adopt one, unless you're willing to build a lot of things you end up throwing out. So instead the bulk of the high risk work is actually negotiation between people.
> And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs
I work in implementation of large enterprise wide systems. When I do projects that span departments/divisions/agencies what you’re describing is the biggest hurdle. The project always starts with “we’re bringing everyone together into one solution” but as time goes on it starts to diverge. It’s so easy to end up with a project per department vs one project for all. You have to have someone with the authority to force/threaten/manipulate all the players onto the same page. It’s so easy to give in to one groups specific requirements and then you’ve opened Pandora’s box as word spreads. It’s very hard to pull off.
I think public sector (governments) is the hardest because the agencies seem to sincerely hate each other. I’ve been in requirements gathering meetings where people refused to join because someone they didn’t like was on the invite. At least in a for profit company the common denominator for everyone is keeping their job.
Jerry Weinberg, Secrets of Consulting (1985) - "No matter how it looks at first, it's always a people problem." - no matter how technical a problem seems, its root cause always involves people—their choices, communication, management, or skills—making human factors central to any solution, from software development to complex systems
I worked as an analyst on a team doing a system replacement.
The old system assigned work cases out in a plain round robin system - Person 1 got Case 1, Person 2 got Case 2, etc, regardless of what people already had on their plate.
The new system looked at a number of factors and assigned a new case to people who had the least amount of overall work in their queue. So if Person 1 had 2 cases and Person 2 had 10, then Person 1 was getting the next case.
Management in one division came to us after a while and said the method of assigning cases was broken, and cases were not being assigned out "fairly." They wanted us to implement the old system's round-robin assignment method in the new system.
After some investigation I determined that workers had figured out ways to game the system in order to seem more busy than they actually were and therefore receive less new cases. As a result efficient workers who were actually doing their jobs were getting punished with new cases while inefficient workers were getting rewarded.
I, another analyst from that division, and my management laid out a very clear case that if employees were not properly handling their cases, and not being monitored on their progress (by all the new monitoring tools the new system provided) then changing the method of distributing cases wouldn't fix the underlying problem.
We were overruled and forced to implement the technical solution to the human problem.
Jerry Weinberg wrote a number of books to this point, starting with 1971's 'The Psychology of Computer Programming.' Here's what he had to say a decade or so later...
"The First Law of Consulting: In spite of what your client may tell you, there’s always a problem.
The Second Law of Consulting: No matter how it looks at first, it’s always a people problem." [0]
Everything he wrote is worth the time to read.
[0] Weinberg, Gerald. "The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully", 1986
There are other ways to look at it. Back in the old days when computers required lots of planning to program, the technical problem of having a buggy program was also a people problem of not planning carefully enough. But now we have fast computers and cheap storage and version control and autosave and so many other things, such that perfectly conscientious human planning of the activity of programming is no longer necessary. In many cases you can just bang stuff out by trial and error.
My point is, we have often discovered technical solutions for things that used to be regarded as people problems.
So maybe a lot of things are just problems, which may be solvable through either technical or people means.
I think I'm mostly of the opinion these days that there is no such thing as an "outdated technology". There are technologies that are no longer fit for purpose but that is almost never because of their age. It nearly always because of one of as examples: Needing to run in an environment it can't support, Having bugs that are not getting fixed/no longer maintained, Missing features necessary to solve new problems or add new features, Hitting scale limits.
Outdated may sometimes be a euphemism for one of the above but usually when I see it in a discussion it just means "old" or "out of fashion" instead.
I'd also add "there are almost no developers using it on the job market" to the list why some technologies are no longer fit for purpose. It's a major one.
Sort of tied to the ecosystem (no devs - not many things get mantained/created).
I do think that holds more water than just "It's old".
However for pretty much any dev I would hire for a job they can get to grips with a technology that's older pretty quickly. Where it does get dicey is when good dev just refuses to work with it. For those devs, I think, when they hold that opinion it typically means one of those other reasons is behind their refusal.
>one of those other reasons is behind their refusal.
I mean, one of those reasons is "When I leave this job will I be able to get another job" is a huge deeply life affecting one.
If you want me to work on COBOL from 1988 then you've limited my work prospects to one of a very few employers in the country at a very specific pay range. If I instead tell you to eat a fat one and go with $language_de_jour the number of employers and potential salary range is much, much larger.
Haven't you seen job offers where X years of experience in XYZ is a must?
It's like most of them. Never got one without this actually.
Gotta have this experience from somewhere.
I know devs like to say they would hire anyone, but they're not the ones hiring.
At best you get to interview people already prefiltered by HR which... looks for keywords in CV.
My personal anecdotal experience is considerably different. I've worked multiple places where I had to learn the stack on the job. Up to and including the language at least once.
I've never found it too difficult to get hired even when the requirements don't list something I've done already.
At this point I'm fairly senior and work directly with funding sponsors and requirements owners. The gal who 100% owns the problem, worldwide, says "I need X, how much it going to cost?", while X is a big, hairy ball of wax and I have 18 minutes left in the 30 minute meeting to get as many details as I can while I work up a guesstimate. Because the funding line will be decided by minute 30.
They have no idea what's going on technically. But they know where the money is and the words that have to be spoken to certain people to get and defend that money. I have been handed a problem that was estimated to cost $6M and solved it with a text message, in the meeting. Shoulda taken the money. I have also had a project poached from me, watched the new team burn $35M and come out the other end with nothing but bruised egos.
The sponsors with the budget are definitely folks who prioritize politics over everything else. They have generally have bachelor's or master's degrees, rarely doctorates. You look at their career and wonder how they got there. Their goal is not mission success. Their goal is the next job. They've been dressing for the next job their whole career. The financial folks are afraid of them, or at least very wary.
This is why I hate it when people are judged (like the article writer is doing) for doing what their job requires of them and not “taking pride in their work” - the thing is, the workers generally don’t own the work, the business does. If the business wants something a certain way, and if they act to punish you for trying to push back, why fight them? It’s not our company. We’re cogs in a machine, if they treat us like that then what do they expect?
This article has a stink of self importance that rubs me the wrong way.
Feels like beauracracy but a DACI or RFC etc. can help if the culture supports this sort of decision making.
You list the options, e.g. A combine codebases, B leave as is. Get comments and look at it logically and come to agreed decision.
You have the reason and tradeoffs documented.
The discussion may prompt other wider discussions etc. More senior people may spot patterns. E.g. lets not pay down tech debt X because Y is coming.
Culturally though if no one cares and most people are happy to manually work through the bugs and hate even discussing it then it may be a bad fit for a developer who cant stand working like that.
While I agree with the sentiment one statement jumped out that grinds my gears.
>Why does technical debt exist? Because requirements weren't properly clarified before work began.
I hate this line of thinking and the expectations that come along with this style of work. The idea that developers need to be spoon fed requirements and only then can they start working because they fundamentally lack an understanding of the desired business outcome and their work output is so valuable that it can’t evolve as their understanding of the problem evolves _is problematic_. To be clear I’m not blaming developers but the style of work that often goes by names like waterfall, agile, SAFE, agile 2.0, transformation, etc. is all hot garbage.
The author suggested that if senior leadership had a development background then tech debt would be easier to get support and resources to deal with. Between the lines I'm reading that the risks are just inherently understood by someone with a tech background.
Then the author suggests that senior leadership without a tech background will usually need to be persuaded by a value proposition - the numbers.
I'm seeing these as the same thing - the risks of specific tech debt just needs to be understood before it gets addressed. Senior leaders with a development background might be better predictors of the relationship between tech debt and its impact on company finances. Non technical leaders just require an extra translation step to understand the relationship.
Then considering that some level of risk is tolerated, and some risk is consciously taken on to achieve things, both might ultimately choose to ignore some tech debt while addressing other bits.
I'm clearly jaded by my own experience but I feel that there's less and less focus on building and retaining a solid team. People are treated like cogs on a machine and this shape their view of the system in return.
It's actually quite awful to work in such an environment.
Technical problems are generated by lack of knowledge. One type of lack of knowledge is interaction with people. You'll never know everything that another person wants to communicate to you because of several reasons.
But even in the case of magically fixing people problems - for example, if you are working on a solo project - you will still have technical debt because you will still have lack of knowledge. An abstraction that leaks. A test that doesn't cover all the edge cases. A "simple" function that was not indeed that simple.
The mistake you want to avoid at all costs is believing you don't have a knowledge gap. You will always have a knowledge gap. So plan accordingly, make sure you're ready when you will finally discover that gap.
> Most Technical Problems Are Really People Problems
The irony is that this is a classic engineer's take on the root cause of technical debt. Engineers are happy to be heads-down building. But when you get to a team size >1, you actually need to communicate - and ideally not just through a kanban board.
Im a software engineer but have been around the block enough times that I now lead large teams. It annoys me a little when people here talk about how worthless management is. I just want everyone to know that good management is very hard, way harder than anything I’ve ever faced in software development. It’s subjective, non deterministic, all the things digital logic is not. It’s very hard which is why bad management is so common.
> It annoys me a little when people here talk about how worthless management is. I just want everyone to know that good management is very hard, ...
People talk about how worthless management is, because most management is not good and most "managers" are worthless. Promotion to your level of incompetence is a real thing in tech management circles.
> It annoys me a little when people here talk about how worthless management is.
In primary function, a good manager is invisible, so it is understandable that it is seen as being worthless.
But in secondary function only a bad manager keeps themselves invisible. A good manager will stand up at stand up and tell about what they've been working on. If you are not communicating exactly what you are doing to everyone else, you've screwed up horribly.
> way harder than anything I’ve ever faced in software development.
To be fair, you can say that about every job in existence that isn't software development. There is nothing hard about software development.
> Most technical problems are really people problems. Think about it. Why does technical debt exist? Because requirements weren't properly clarified before work began. Because a salesperson promised an unrealistic deadline to a customer. Because a developer chose an outdated technology because it was comfortable.
I used to be a "stay out of politics" developer. After a few years in the industry and move to a PM role, I have had the benefit of being a bit more detached. What I noticed was that intra-developer politics are sometimes way more entrenched and stubborn than other areas of the business.
Sure, business divisions have infighting and politics but at the end of the day those are tempered by the market. It's far harder to market test Ruby Versus Java in a reasonable manner, especially when you have proponents in both camps singing the praises of their favored technology in a quasi-religious manner. And yes, I have also seen the "Why would I learn anything new, <Technology X> works for me, why would I take the effort to learn a new thing" attitudes in a large number of coworkers, even the younger Gen-Z ones.
You need to make people include some sort of objective evidence with their argument, and either have a (hopefully benevolent) dictator solve the "vim vs. emacs" problems or just let people pick their environment and sort out any issues they create themselves.
If you're trying to pick a development language by committee, something is already very wrong. That something would be a people problem I suppose (because everything is), but it's really a strategic problem of the business.
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
Reasons vary widely. Code can also get calcified because people lack the vision, tech skills, or time/budget to update it. On the opposite side of the spectrum, personality types who do like change sometimes rip out everything out and start from scratch, effectively destroying well written code, which is no better.
> Why does technical debt exist? Because requirements weren't properly clarified before work began.
Not necessarily: it can also exist because code wasn't well written to begin with, libraries weren't updated to work with OS updates, feature-creep, etc.
> In my opinion, anyone above senior engineer level needs to know how to collaborate cross-functionally, regardless of whether they choose a technical or management track.
Collaboration is a skill everyone needs, and the ability to explain things to people at other levels shouldn't be limited to senior engineers. Even junior devs would do well to be able to explain things to higher-ups.
>Because requirements weren't properly clarified before work began
Yea, software is typically way more flexible and fast moving in the real world.
At start of project: "We need software with A, B, and C"
In middle of project: "Our competitor has released with ABCD and E, and if we don't add at least E we might as well cancel the project"
There is also - Our software works 100% fine with what we expected in the field, problem is (new|old) thing showed up and now we have to work around all the bugs in it.
Then there is Chesterton's fence. That 'broken old crap' was actually doing something highly specific that calcified into how the customers systems work. People love ripping crap up and changing stuff, until they figure out it just broke their enterprise clients workflow, and that client pays their salary.
Isn't this generally the case across all sectors and industries? We have the technology today to create a post scarcity utopia, to reverse climate change, to restore the biosphere. The fact that none of that happens is a people problem, a political problem, a spiritual problem, more so than any technological barrier.
Yea this is true of virtually all problems today. It's one of the blind spots of the AI acceleration crowd. Cancer vaccine discovered by GPT-6? You still have to convince people it's safe. Fusion reactor modeled by Gemini? Convince people it's not that kind of nuclear power. Global Engineering solution for climate change? Well it might look like chemtrails but it's not. Implementation of all of these things in a society is always going to be hard.
I think this is a large factor in the turn towards more authoritarian tendencies in the Silicon Valley elites. They spent the 2000s and 2010s as a bit more utopian and laissez faire and saw it got them almost nowhere because of technology doesn't solve people problems.
I couldn't disagree more with this description of why technical debt exists and it's a dangerous line of reasoning. Sure, maybe requirements weren't clarified. But often it's impossible to clarify them and you have to build something and even if the requirements were clear to begin with who is to say they'll still be the same by the time you've finished the project let alone 5 years later. Maybe the develop chose a stable and dependable technology because it's battle worn and proven? Maybe the sales person has to manage an impossible situation between an engineering team which can't commit to the time line needed to win the sale?
There are lots of good reasons tech debt exists, and it's worrying that this person seems to think that they all boil down to "I don't know how but someone, somewhere, fucked up"
As someone else mentioned here: not all technical debt is created equal. I agree, sometimes the problem are changing requirements, etc. But it is also true that there is technical debt caused by developers who don't take the time to properly design features and will simply implement the first thing that came to their minds. I agree with the author, this kind of technical debt is caused by a mediocre attitude which often propagates to all the team if there is no one that calls it out.
The more interesting discussion to me is: how do you solve this problem once it exists in a team? I guess there are many approaches, but I tend to think that 'lead by the example' is the best you can do as an engineer, but a top-down approach might work better which is what happened at Microsoft when Satya Nadella became CEO.
The definition of technical debt is the compromises you intentionally make (generally to ship something thus not going bankrupt). Thus by definition nobody made a mistake: this was an intentional decision that was believed correct at the time. You will pay a cost later for the decision, but it is rarely a mistake to make those compromises.
It's worse, they seem to think tech debt is just a "state of mind", a "personality defect":
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
This line of thinking (we will make it with future change in mind!) is of course exactly the bullshit that is tech debt in the first place.
Ha. At my last job, I observed that we were so good at solving technical problems that we transformed social problems into hard technical problems so we could solve the original song cial problem. It's something like a problem reduction in Algorithmic Complexity Theory. There was perhaps a simpler social-centric solution, but we didn't have a method for solving those...
For every person trying to move an old code base from COBOL to Java to remove tech debt, there are an equal number of people who want rewrite a working C++ code base in Rust/Go/Zig.
Leaders who know that it's a people problem and who have read the Jerry Weinberg book know both sides of the problem.
In my opinion, people problems is just a subset of communication problems. Communication also involves people not working at the same place (remote), at the same time(remote). Even the gal working next room is a problem, that hinders questions.
This is a classic engineering take on the problem. It changes when you become a CTO. Because now technical debt is your problem and the choice whether to fix it or not is yours to make. The flip side here is that wrong choices (either way) can be expensive and even kill your company.
I've been on both sides. Having to beg a manager to get permission to fix a thing that I thought needed fixing. And now I'm on both sides where as a CTO it's my responsibility to make sure the company delivers working products to customers that are competitive enough that we actually stand a chance to make money. And I build our product too.
Two realities:
1) Broken stuff can actually slow down a lot of critical feature development. My attitude as a CTO is that making hard things easier is when things can move forward the fastest. Unblocking progress by addressing the hardest things is valuable. Not all technical debt is created equally. There's a difference between messing with whatever subjective esthetics I might have and shit getting delayed because technical problems are complicating our lives.
2) We're a small company. And the idiot that caused the technical debt is usually me. That's not because I'm bad at what I do but I simply don't get it right 100% of the time. Any product that survives long enough will have issues. And my company is nearly six years old now. The challenge is not that there are issues but prioritizing and dealing with them in a sane way.
How I deal with this is very simple. I want to work on new stuff that adds value whenever I can. I'm happy when I can do that and it has a high impact. Whenever some technical debt issue is derailing my plans, I get frustrated and annoyed. And then I sit down and analyze what the worst/hardest thing is that is causing that. And then I fix that. It's ultimately my call. But I can't be doing this all the time.
One important CTO level job is to keep the company ready for strategic goals and make sure we are ready for likely future changes. So I look at blocking issues from the point of view of the type of change that they block that I know I will need to do soon. This is hard, nobody will tell me what this is. It's my job to find out and know. But getting this right is the difference between failing or succeeding as a technology company.
Another perspective here is that barring any technical moat, a well funded VC-funded team could probably re-create whatever you do in no time at all. If your tech is blocking you from moving ahead, it can be sobering to consider how long it would take a team unburdened by technical debt to catch up with you and do it better. Because, if the answer is "it wouldn't be that hard" you should probably start thinking about abandoning whatever you are trying to fix and maybe rebuilding it better. Because eventually somebody else might do that and beat you. Sometimes deleting code is better than fixing it.
Technical debt is intentional compromises. It sounds like you are thinking of not intentional compromises, but instead accidents where someone didn't understand the requirements and so did it slightly wrong for the expected future. Cases where the system wasn't designed to handle requirements changing in the way they did so you had to "make an ugly hack" to ship are technical debt.
I understand the distinction, but at some point it's not super helpful, and I would argue even counter productive.
If you have a system that is big enough and has had enough change over time that it's structure is no longer well suited to the current or near future job-to-be-done, then it doesn't really matter how you got there, you need to explain to non-technical stakeholders that current business requests will take longer than it would intuitively take to build if you just look at the delta of the UX that exists today compared to what they want (ie. the "why can't you just..." conversation). This is a situation where the phrase "technical debt" is a useful metaphor that has crossed the chasm to non-technical business leaders, and can be useful (when used judiciously of course).
It actually undermines the usefulness of the metaphor if you try to pedantically uphold the distinction that tech debt is always intentional, because non-technical stakeholders will wonder why engineering would intentionally put us in this situation. I understand we all get to have our techie pet peeves (hacker != black hat), but this is really not a semantic battle I would fight if I'm dealing with anyone non-technical.
It’s the eternal cycle: all social problems really are tech problems in disguise; so it’s unfortunate that all tech problems are social problems in disguise. ;)
Which is why when arguing that technology XYZ succeeded, or failed, one needs to look into the larger picture of the human side regarding the related outcome in the market adoption.
Case in point - PyTorch vs Tensorflow. The Pytorch team and Soumith in particular was everywhere. You could ask about it in the forums, Twitter, freaking reddit and there would be an answer.
Well technical debt is not really a technical problem, it’s a choice.
Someone at some point said: ok we’re going to duplicate code, we’ll have a windows version and a Linux version, and yes it’ll be painful - for a while - but at this stage, it is the better option.
At some point getting shit done might be more important than getting it right.
Whether that is smart or not is a people problem.
Working on large legacy codebase is extremely annoying indeed, but sooner or later, in everyone’s career one has to make those sort of tradeoffs, and when that day comes maybe you’ll forgive those who came before you.
Edit: I want to add this:
Also those tradeoffs are often required because of business problems. It’s difficult to see, 10 years down the road, how shitty the business may have been when those decisions were made. And perhaps, it’s some of those business-driven decisions - like rushing the product out the door no matter what - that kept the company afloat and made it so that you have a job (albeit to fix the mess) today.
..and most people problems are communication problems.
Calling them 'people problem' is a convenient catch-all that lacks enough nuance to be a useful statement. What constitutes good communication? Are there cross purposes?
> Non-technical people do not intuitively understand the level of effort required or the need for tech debt cleanup; it must be communicated effectively by engineering - in both initial estimates & project updates. Unless leadership has an engineering background, the value of the technical debt work likely needs to be quantified and shown as business value.
The engineer will typically say that the communication needed is technical, but in fact the language that leadership works with is usually non-technical, so the translation into this field is essential. We do not need more engineers, we need engineer who know how to translate the details.
I realise that, here on HN, most will probably take the side of the rational technologist, but this is a self-validating cycle that can identify the issue, but cannot solve it.
IMO, we need more generalists that can speak both languages. I have worked hard to try and be that person, but it turns out that almost no-one wants to hire this cross-discipline communicator, so there's a good chance that I'm wrong about all of this.
The tech debt question from _def is interesting. In my experience quantifying it actually misses the point.
The real cost isn't the time lost - it's decision avoidance. Teams stop touching certain modules. New features get built around the problem instead of through it. You end up with architectural scar tissue that shapes every future decision.
I've seen this play out where a 2-week refactor that everyone knows needs to happen gets deferred for years because nobody can attach a dollar figure to "we're scared to change this code." Meanwhile every sprint planning becomes a creative exercise in routing around the scary parts.
The tell is when your estimates have a silent "...assuming we don't have to touch X" attached to them.
This is an excellent point. I've also seen scenarios in which the architectural scar is being defended vehemently by an engineer still at the company. In my experience it is someone respected, who is overall a highly competent engineer, and the rest of engineering ends up working around the scar.
This article resonates strongly. I am consulting right now to a group that has enormous struggles technically, but they are all self-inflicted wounds that come down to people and process.
Management claims to want to understand and fix the problem, and their "fixes" reveal the real problems. Fix 1 - schedule a lot of group meetings for twice a week. After week 1, management drops off and fails to show up anymore for most of them. The meetings go off track. The answer? More meetings!
We now have that meeting daily. And have even less attendance.
Fix 2 - we don't know what people are doing, let's create dashboards. A slapdash, highly incorrect and problematic dashboard is created. It doesn't matter, because none of the managers ever checks the dashboard. The big boss hears we are still behind, and commandeers a random product person to be his admin assistant and has her maintain several spreadsheets in semi-secret tracking everyone's progress.
This semi-secret spreadsheet becomes non-secret and people find a million and one problems with it (not surprising as the commandeered admin assistant nee product person was pulling the data from all sorts of random areas with little direction with little coordination with others). We then have the spreadsheet war of various managers having their own spreadsheets.
Fix 3 - we are going to have The Source of Truth for product intake and ongoing development, with a number of characteristics (and these are generally not terrible characteristics). These are handed off to a couple of junior people with no experience to implemented with zero feedback. The net result is we still don't have a Source of Truth, but more of an xkcd situation that now we have 4 or 5 sources of truth strung together with scripts, duct tape, bandaids and prayer.
This continues on and on over years. Ideas are put forth, some good, some bad, some indifferent, but none of them matter because the leaders lack the ability to followup or demonstrate even basic understanding of what our group actually does.
It is truly soul crushing, but in this jobs environment, what are you going to do?
I can write a similar article that: most people problems are technical problems.
This article hits on a pet peeve of mine.
Many companies and individuals can benefit from better processes, communication skills, and training.
And also people who proclaim "Most technical problems are people problems" and "It's not what you know, it's who you know" are disproportionately those who are attempting to influence others that "My skillset is more valuable than your skillset." The people who believe the opposite are heads-down building.
The truth is that nearly all problems are multifactorial and involve long chains of causality. They can be patched at multiple points.
And so while there are standard stories about "If you do the 5 Why's and trace back causality, the issue becomes a deeper human problem," you can nearly always do something else and find an alternative technical solution.
The standard story goes: "This thing failed because this this other thing crashed, because this thing was misconfigured, because the deployment script was run incorrectly, because no-one trained Bob how to use it." See, the human problem is the deepest one, right?
But you can find an alternate technical fix: why was it possible to run the deployment script incorrectly?
Or you can ping-pong it back into a technical problem: he wasn't trained because everyone is stressed with no time because things keep breaking because of bad architecture and no CI. So actually the technical problem is deepest.
But no, because that only happened because the CEO hired the wrong CTO because he didn't know anyone who could evaluate it properly....
...which only happened because they didn't use <startup that helps you evaluate engineers> (technical problem)
...which only happened because said startup didn't have good enough marketing (human problem)
...which only happened because they were too slow to build from their own tech debt and didn't have the money (technical problem...)
And so on. Ping, pong.
The article says: we had too much tech debt because humans weren't trained enough.
One can also say: we had too much tech debt because we didn't have good enough linters and clone detectors to keep out the common problems, and also we had made some poor technical choices that required hiring a much larger team to begin with.
If you have a pet problem, you can always convince yourself that it's responsible for all woes. That just keeps you from seeing the holistic view and finding the best solution.
I have been a part of a team that actually managed to significantly reduce critical tech debt in its system, to the point of background radiation. I can speculate on what I think were key contributing factors (some of which are just productivity improvements, which meant we had more bandwidth for tech debt):
* The team used a monorepo for (nearly) all its code. The upshots of this include the ability to enforce contracts between services all in one commit, the ability to make and review cross-cutting changes all in one PR, the increased flexibility in making large-scale architecture changes, and an easier time making automations and tools which work across the system.
* We used Go, which turned out to be a really excellent fit for working within a monorepo and a large-ish codebase. Also, having the Go philosophy to lean back on in a lot of code decisions, which favors a plain and clear style, worked out well (IMO). And its great for making CLI tools, especially ones which need to concurrently chew through a big data dump.
* Our team was responsible for integrations, and we took as a first principle that synchronous commands to our API would be the rare exception. Being async-first allowed us to cater for a lot of load by spreading it out over time, rather than scaling up instances (and dealing with synchronization/timing/load explosion issues).
* We converted the bulk of our microservices into a stateless monolith. Our scalability did not suffer much, because the final Go container is still just a couple MB, and we can still easily and cheaply scale instances up when we need. But being able to just make and call a function in a domain, rather than making an api and calling another service (and dealing with issues thereof), is so much easier.
* Our team was small - for most of when I was involved, it consisted of 3 developers. Its pretty easy to talk about code stuff and make decisions if you only have to discuss it with 2 other people.
* All of us developers were open to differing ideas, and generally speaking the person who cared the most about something could go and try it. If it didn't work, there would be no love lost in replacing it later.
* We had a relatively simple architecture that was enforced generally but not stringently. What I mean by that is that issues could be identified in code review, but the issue would be a suggestion and not a blocker. Either the person changes it and its fine, or they don't, in which case you could go and change it later if you still really cared about it.
* We benefited from having some early high-impact wins in terms of productivity improvements, and we used a lot of the spare sprint time to tackle ongoing tech debt, rather than accelerate feature work (but not totally, the business gets some wins too).
* Big tech debt endeavors were discussed and planned in advance with the whole team, and we made dilligent little chips at these problems for months. Once an issue was chipped away enough to not be painful anymore, then it didn't get worked on (getting microservices into the monolith, for example, died down as an issue once we refactored most of them).
* Tech debt items were prioritized by a ranked vote made by everyone, using a tool I built: https://github.com/liampulles/go-condorcet. This did well to ensure that everyone got the opportunity to have something they cared about, get tackled. Often times our votes were very similar, which means we avoided needless arguments when we actually agreed, and recognized a common understanding. I think this contributed to continued engagement from the team on the whole enterprise.
* Our tech stack was boring and reliable, which was basically Postgres, Redis, and NATS. Though NATS did present a few issues in getting the config right (and indeed, its the least boring piece). We also used Kubernetes, which is far from boring, but we benefited from having a few people who really understood it well.
* We built a release tool CLI, and built reasonably good general error alerting for our system (based on logs mostly, but with some sentry and infra alerts as well), that made releasing things become easy. This generally increased productivity, but also meant that more releases were small releases, and were easier to revert if there were issues.
* We had a fantastic PM, who really partnered with us on the enterprise and worked hard to make our project actually Agile, even though the rest of the business was not technical.
If that's not obvious to you pray you're not over of them...
But in seriousness it's management failure to build up debt like that.
Either self management, middle management or out of touch management. There's a reason that good managers are needed. And unfortunately most management is dealing with people and/or real-world, not a fixed in stone RFC or list of vendor requirements from legal.
Post hits the nail on the head. Even the best engineering solutions that closely align to organizational goals will be torpedoed by people at the end of the day, often to preserve their own political power rather than improve the organization or their own working lives.
This is why I laugh when I hear someone say tech is a meritocracy. It is if you consider manipulation, exploitation, subterfuge, sabotage, and backstabbing to be of merit; otherwise, there is no meritocracy out here in the real world, not so long as any given individual of power can destroy your career or livelihood over hurt feelings.
As much as I’d love everything to be a technical problem to solve, that’s just not reality at the moment. We gotta listen to people beyond our silos and find a way to get them to our side in things if we want to progress forward on something. I’m doing that right now in a company stuck firmly in the 1990s, and it sucks.
I mean yes, if you waste time on worked that does not bring value, people tend to get cranky. If you then take longer than you said, it's not a mood enhancer.
That's not a people problem though. That's failure to recognize that a company pays its employees money to make more money, not to have a pretty code base.
Yes, that means communicating the value, but that's not a people problem. That's a skills issue.
"anyone above senior engineer level needs to know how to collaborate cross-functionally"
If you can't collaborate xfn and deal with other people in general, you are not a senior engineer, despite the title inflation.
To me that is not a problem, it is the reality of stuffing people together who have no other bond than it is their place of work. The problem is the system, not the people.
And most people problems are communication problems. Engineers aren't engaged with the product vision or the customer base, and are allowed to silo themselves. Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop. Sales and CS fail to understand the cost of their promises to individual customers to the timelines of features they're hungry for from the product plan. Goals and metrics for success fail to align. And thus everyone rows in their own direction.
The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.
This is why I built out a Shadow Sessions program for our internal tooling teams at my BigCo.
The users are right there, go make friends. Learn what they're doing day to day. And how it fits into the larger picture.
These sessions are lightweight, and auto schedule every three weeks with no required action items and people come out of it amazed every time, lots of little bugs have been fixed, and connections are being made.
The culture of not engaging with the end users when they're so readily available is an odd one to me. And you can really get to say 80% of macro picture understanding and user experience design fundamentals with a fairly low lift.
To do this I created a sign up form and an auto scheduler that interacts with the Slack API. The scheduling and getting folk on board is the hardest part. Also finding time if you do things outside the product road map.
100% this. Go and spend time with the people using your software. Even better, use it yourself.
One of the companies I’ve worked for did food delivery, and in food delivery during Christmas week everybody works operations - either you’re out in a van with one of the regular drivers helping them carry orders that are three times larger than any other week, or you’re handling phone calls and emails to fix whatever problems arise. Either way without fail January every year would see a flurry of low effort/high value updates to the software those parts of the business used. Anything from changing the order of some interactions to fit the flow of dropping a delivery to putting our phone number in the header of every admin page.
Absolutely nothing beats going out there and doing the job to discover where the tools you’re responsible for fall over. Bonus points if you can do it at the most stressful time of year when if anything is going to fail it probably will.
Not using it themselves is why my managment at various companies wouldn't let anyone do sensible things.
Companies that sell to other companies .... don't care about the users. It's one bunch of managers sleezing up to another to make a sale. Whether the product is good to use doesn't matter to them because none of them use it.
A "good" company wouldn't allow this to happen but it happens often enough.
Another bad smell is when developers themselves never use the whole product and simply work on their little bit.
Eat ones own dog-food, or in other words, get the company cooking something great together and sharing the results.
A great company basically opens on its first day and 48 hours later there are a ton of well fed customers who come back, not incidentally, again and again for what they perceive, is great.
But apropos feeding customers, if you can't 'eat your own food' dog or otherwise, why expect the user to want to do it ..
Use it. I agree.
Yep, exactly, and amazing.
And it's such a blind spot in the industry that the people most able to build and estimate features and software are left to be the least equipped to see through the end user's eyes.
As such, when you encourage user oriented engineers, these common and often low effort issues can be avoided at the outset which improves velocity organizationally and results in better software and user experiences for projects now and in the future.
A bit more heavyweight, but we implemented a rotation program when I was managing an internal tools team at a previous company. We'd trade an engineer from our team with an engineer from a feature team for a quarter.
The amount of improvements to our collective understandings was super valuable. Feature devs got to help fix problems with their tools more directly (while also learning that it's not always as straightforward as it may seem), and we brought back much stronger insights into the experience of actually using our tools day-to-day.
This is evidence that there is a prior element to this 'problem', which is that - in order for Technology to exist, Ethics have to be aligned well enough to deliver, effectively, the result of the technology: a product.
The user, ethically, is another piece of evidence - especially in real time and at huge scale.
So you are so right about the user. The user comes first, the technology second, and when the service of the latter benefits the former, greatly, at scale, the people problems become, well, people solutions - i.e., the user.
I think it’s because companies don’t incentivize people listening to each other. Management doesn’t listen to the underlings and the underlings have to compete to get noticed.
I have only a few people with whom I can discuss something in depth without anybody pushing an agenda. With most people it’s just about pushing through what you want to do.
I am just going through a bunch of sessions where a director has engaged consultants to change our stuff to use a new platform. Nobody who works on the system thinks it makes sense but it can’t be stopped because of the director and a few yes men. Nobody listens.
Makes me think of something my dad and I both talked about with our time in the military. He was Army and I was Navy. But when the ability to promote is tied with ranking against your peers, if you really want to game the system, you essentially sabotage your peers. Which is the exact opposite you want in the military or really any organization. You want to foster a, rising tide lifts all boats with getting the work done. But it hard when your performance evaluations are the complete opposite of that, and I have seen people do it.
I got qualified on our equipment quick and was in a position where I was training my peers who I was ranked against. If I were an asshole, I would have trained them poorly and drug it out. I didn't, but someone who is goal oriented to climb through the ranks as fast a possible, it is a logical action that I could have taken.
> If I were an asshole, I would have trained them poorly and drug it out.
That's of course the obvious way this goes wrong. Bad intentions. The much more insidious version is that you could have just been a terrible teachers, maybe you suck at training your peers, and you don't know.
The end result is the same. You look like the only person who gets it amongst the riff-raff, but in this case you don't even have a choice. The system has produced a poor outcome not because anybody abused it, but because it was a bad system.
"Better people" solves a lot! But definitely not everything. But a lot!
Product doesn't see the point of engineers being engaged and feed the engineering team like an in-house outsourcing shop.
Because they want to feel superior as the ‘this was my idea and you executed on my idea’ nonsense. Their answers to most ‘why are we doing this ?’ ‘trust me bro’. I am perhaps generalizing and there are outlier product managers who have earned the ‘trust me bro’ adage, but most haven’t.
This PM behaviour will never change. Engineers have said enough is enough and are now taking over product roles, in essence eliminating the communication gap.
> Build out what that tech debt is costing the company and the risk it creates
How to do that? Genuine question.
In my experience development has become too compartmentalized. This is why this game of telephone is so inefficient and frustrating just to implement basic features.
The rise of AI actually is also raising (from my observations) the engineer's role to be more of a product owner. I would highly suggest engineers learn basic UI/UX design principles and understand gherkin behavior scenarios as a way to outline or ideate features. It's not too hard to pick up if you've been a developer for awhile, but this is where we are headed.
If it's been around for a while, look at the last year's worth of projects and estimate the total delay caused by the specific piece of tech debt. Go through old Jira tickets etc. and figure out which ones were affected.
You don't need to be anywhere close to exact, it's just helpful to know whether it costs more like 5 hours a year or 5 weeks a year. Then you can prioritize tech debt along with other projects.
It takes guts to say “this 1 month feature would be done in a couple days by a competent competitor using modern technology and techniques”, and the legendary “I reimplemented it in <framework> over the weekend” is often not well received.
But - sometimes drastic measures and hurt feeling are needed to break out of a bad attractor. Just be sure you’re OK with leaving the company/org if your play does not succeed.
And know that as the OP describes, it’s a lot about politics. If you convince management that there is a problem, you have severely undermined your technical leadership. Game out how that could unfold! In a small company maybe you can be the new TL, but probably don’t try to unseat the founder/CTO. In a big company you are unlikely to overturn many layers above you of technical leadership.
> hurt feeling
This is why I incessantly preach to my coworkers: "you are not your job". Do not attach to it emotionally, it's not your child, it's a contraption to solve a puzzle. It should be easy and relieving to scrap it in favor of a better contraption, or of not having to solve the problem at all.
More importantly, you are not your code.
This is actually harder for more senior/managerial folks, as often they'll build/buy/create something that's big for their level and now they're committed to this particular approach, which can end up being a real problem, particularly in smaller orgs.
Once upon a time, I worked for a lead who got really frustrated with our codebase and decided to re-write it (over the weekends). This person shipped a POC pretty quickly, and got management buy-in but then it turned out that it would take a lot more work to make it work with everything else.
We persevered, and moved over the code (while still hitting the product requirements) over a two year period. As we were finishing the last part, it became apparent that the problem that we now needed to solve was a different one, and all that work turned out to be pointless.
but it is their code. It's their achievement. It's their mark on the world that says they were needed and did something useful. They struggled and their passion gave them the strength to get through it.
It's how they get to be the experts that are needed.
Replacing their code IS replacing their expertise and therefore them. How would you expect words to change that?
There's very few people whose brains work like this, it requires constant maintenance and people are ready to fall into the trap easily because they are held accountable for the outcomes, and its easy to pretend your ideas would have saved you from the certain disaster your fellows brought you to.
Just like every league of legends game, it's not possibly your fault!
If there's a legit, measurable performance or data integrity problem, start with that. If most of your production bugs come from a specific module or service, document it.
If it is only technical debt that is hard to understand or maintain, but otherwise works, you're going to have a tougher time of building a case unless you build a second, better version and show the differences. But you could collect other opinions and present that.
Ultimately you have to convince them to spend the time (aka money) on it and do it without making things worse and that is easiest to do with metrics instead of opinions
That’s wishful thinking but not in the way you think. A lot of engineers just want to finish their tickets and get out of there, that’s the reality. They don’t want to be in more meetings with the end user or product. You might have 10% of folks that actually love the job and want to build products at most places.
And all communication problems involve one or more senders and one or more receiver. The issue is you only got to be in control of one side. And even flawless massaging won't save you from incapable or unwilling receivers.
As someone who has worked in IT support I have seen users habitually click away clearly formulated error dialogs that told them exactly what the cause of their problem was and how to address it. Only problem? They did not read it, as became clear when I asked them what it said.
I have had people who I repeatedly had to explain the the same thing, made sure they got it by having them do it twice and a week later they would come again with the same question like sheep, not even aware they asked that one before.
Some problems are communication problems. Others are actual people problems that could indeed be solved by getting better people. Anybody who says otherwise is invited to do first level support for a year.
100% agree. Sadly, I have realised fewer people actually give an F than you realise; for some, it's just a paycheck. I am not sure what has happened over the decades regarding actually being proud of the work you produce.
I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down, and so want to make sure you don't end up in that position again. Covers all areas of IT from Cyber, DR, not just software.
When I have moved between places, I always try to ensure we have a clear set of guidelines in my initial 90-day plan, but it all comes back to the team.
It's been 50/50: some teams are desperate for any change, and others will do everything possible to destroy what you're trying to do. Or you have a leader above who has no idea and goes with the quickest/cheapest option.
The trick is to work this out VERY quickly!
However, when it does go really wrong, I assume most have followed the UK Post Office saga in the UK around the software bug(s) that sent people to prison, suicides, etc. https://en.wikipedia.org/wiki/British_Post_Office_scandal
I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Simple:
1. People lost ownership of the things they work on. In the early 1900s, more than half of the workforce was self-employed. Today, it is 10% in the US, 13% in the EU.
What you produce is not “yours”, it’s “your employer’s”. You don’t have ownership, and very limited to no agency.
2. People lost any tangible connection to the quality and quantity of their output.
Most workers don’t get rewarded for working harder and producing more or better output. On the contrary, they are often penalized with more and/or harder work.
To quote Office Space: “That makes a man work just hard enough not to get fired.”
3. People lost their humanity. They are no longer persons. They are resources. Human resources. And they are treated like it.
They are exploited for gain and dumped when no longer needed.
One weird thing about software jobs as opposed to other crafts is the persistence of the workpiece.
A furniture maker builds a chair, ships it out, and they don’t see it again. Pride in their craft is all about joy of mastery and building a good external reputation.
In most software jobs, the thing you build today sticks around and you’ll be dealing with it next month. Pride in your craft can be self serving because building something well makes life easier for future-you
> Pride in your craft can be self serving because building something well makes life easier for future-you
Yeah I did that in my last job as a platform engineer, I particularly intented for other teams to be able to work in parallel and also not blocked on me so I have more time to refactor or generally things to make life easier for future-me.
Long story short, I got laid off.
That only applies if you expect to be at one job for a long time. Current business culture makes that a poor bet, both due to pernicious Jack Welch style layoff management and the career and salary benefits of changing jobs every few years.
I think this ignores the codebase churn in Big Tech. The code you write today probably won't be there in ten years. It will be heavily refactored, obsolete, or the product will be outright canceled. You can pour your heart in it, but in all likelihood, you're leaving no lasting mark on the world. You just do a small part to keep the number going up.
Tech workplaces are incredibly ephemeral too. Reorgs, departures, constant hiring - so if you leave today, in 5-10 years, there might be no single person left who still remembers or thinks highly of the heroic all-nighters you pulled off. In fact, your old team probably won't exist in its current shape.
If you build quality furniture for your customers, chances are, it will outlive you. If you work on some frontend piece at Amazon, it won't. I think the amount of pride in your workmanship needs to scale with that.
Well said. I’ve always also thought that writing code and craftsmanship is a forced metaphor. At most, the product is the craft, not the code. And a product is exactly as good as people’s experiences of using it and how well it solves their problems. The underlying code quality is correlated with these things, but let’s be honest a badly designed product that doesn’t meet the customers needs can have PERFECT code and zero tech debt and still be a bad product because of it.
Also you know what, some code is disposable. Sure, we all want to craft amazing sculptures of metaphorical beautiful wooden chairs that will last a lifetime, but sometimes what the customer needs is a stack of plastic chairs, cheap, and done next week. Who cares if they break after like 1 year.
So, sometimes when I accept that my boss wants something rushed through, I don’t complain about the tech debt it’ll cause, I don’t fight back about how it should’ve designed to have wonderful code… not because I have no pride in my work, but because I understand the businesses needs.
And sometimes the business just wants you to make plastic chairs.
> Pride in your craft can be self serving because building something well makes life easier for future-you
But, it doesn't. It's not as if you get to sit around doing nothing if you did a great job, you just get some new software project. The company gets to enjoy the benefit of a job well done.
Getting a new software project beats the hell out of going back and digging through the cruft of a legacy software project. At least the new software project offers the chance to learn current tech.
Can you think of two assumptions you might be making in that comment?
I feel like to some degree, things have gotten less affordable. And I have seen a big push of the idea that “a job is just making money, find your happiness somewhere else”. Which led to more and more people looking for a job that pays well with less thought about whether they enjoy it at all. Many professions had an influx of people in for the money, not the passion.
Now of course you I can’t blame people for wanting more money and better standards of living, and that’s always been a thing. But many jobs that used to afford you a middle class life don’t anymore for young people.
I saw my engineering school software engineer department going from the least sought after specialty to the most in one year. The number of people passionate about tech didn’t suddenly jump, but each year we have a report about the last promotion average starting salary and software engineering was at the top for the first time.
The stuff we don’t really need (TV etc) has become much more affordable. The stuff we can’t live without (food and shelter) has become less affordable.
This is almost certainly a nice story we tell ourselves about a mythical past that just didn't exist.
It can be annoying to say, but modern factory produced things are in an absurdly higher quality spectrum than most of what proceeded them. This is absolutely no different from when machined parts for things first got started. We still have some odd reverence for "hand crafted" things when we know that computer aided design and manufactured are flat out better. In every way.
As for ownership, I hate to break it to you, but it is very likely that a good many of the master works we ascribe to people were heavily executed by assistants. Not that this is too bad, but would be akin to thinking that Miyazaki did all of the art for the movies. We likely have no idea who did a lot of the work we ascribe to single artists throughout history.
On to the rest of the points, even the ones I somewhat resonate with are just flat out misguided. People were ALWAYS resources. Well before the modern world.
Computer and machine manufactured parts can be better, but it's a mistake to believe they always are. Take two contrasting examples.
In guitar manufacturing, CNC machines were a revolution. The quality of mid-range guitars improved massively, until there was little difference between them and the premium ones.
In furniture, modern manufacturing techniques drastically worsened the quality of everything. MDF and veneers are inherently worse than hand-crafted wood. The revolution here was making it cheaper.
CNC and other machining techniques raise the high bar for what's possible, and they have the potential to lower costs. That's it. They don't inherently improve quality, that's a factor of market forces.
I would wager that the general change in availability of wood is by far the biggest driver in difference for the markets you are describing?
Particularly, furniture benefits greatly from hard wood. At least, the furniture that is old that you are likely to see. It also benefits heavily from being preserved, not used.
> MDF and veneers are inherently worse than hand-crafted wood.
Generally incorrect, but it depends. Wear can cause mdf/veneer to have "bad optics" compared to solid wood, but mdf/veneer can have more suitable physical properties and enables more consistent visual quality and design possibilities.
I suppose it depends on your definition of worse. It is more versatile. It's also toxic and fragile, and far more likely to break in ways that are hard to repair. I can only think of one object I own where the physical properties of particle board or MDF are a positive: a subwoofer where its consistency helps with acoustics.
Comparing a cheap thing to an expensive thing is absurd.
The appropriate comparison is which is better for the same price
If the cheap thing replaces the expensive thing and there is no same-price comparison, is it absurd? My point is that many products that were handmade at high quality no longer exist because of modern manufacturing. If you want a chair or, say, a set of silverware at the same inflation-adjusted price it would have been available for seventy years ago, you can't get it because the market sector has shifted so thoroughly to cheaper, worse products (enabled by modern manufacturing) that similar quality is only available through specialty stores at a much higher price. This happens even if the specialty stores are using computer-aided techniques and not handcrafting, because of the change in economics of scale.
The catch here is that most people did not have high quality hand made furniture. Most people had low quality hand made things. Pretty much forever. And is why they aren't here for you to see them.
Modern process controls allow us to hit intended outcomes consistently at lower costs. But that doesn't mean the intended outcomes are always better that what you would aim for with less capability.
There are real customers that want cost reductions that lead to reduced lifetimes, because they have no intention of using the thing they are buying for decades. It isn't just manufacturers looking to make money through planned obsolescence.
>1. People lost ownership of the things they work on. In the early 1900s, more than half of the workforce was self-employed. Today, it is 10% in the US, 13% in the EU.
At a high level nobody works smarter and harder than people working for themselves because they see the direct results in near linear proportion. So basically half the workforce was in that situation vs a tenth. Say nothing about taxation and other things that cost more the higher up you go and serve to fractionally break or dilute the "work harder, make more, live better" feedback loop.
By "self-employed" - are you referring to subsistence farming? Everything I know about subsistence farming makes it appear much more precarious than corporate work; where hard work is especially disconnected from your rewards; governed by soil conditions, weather, etc.
> are you referring to subsistence farming?
It says early 1900s, so no. It does largely refer to farming, but farming was insanely lucrative during that time. Look at the farms that have the houses of that era standing on them and you'll soon notice that they are all mansions.
Remember, subsistence farming first had to end before people could start working off the farm. Someone has to feed them too. For 50% of the workforce to be working a job off the farm, the other 50% being subsistence farmers would be impossible.
> Look at the farms that still have the houses of that era standing on them and you'll soon notice that they are all mansions.
Those are usually large plantations, and the people who owned them weren't just farmers but vast landholders with very low paid labor working the farm (at one time usually enslaved). I doubt they were representative of the typical turn of the 20th century farm.
If we're speaking from vibes rather than statistics, I'd argue most 19th century farmhouses I've seen are pretty modest. Not shacks, but nothing gigantic or luxurious.
> Those are usually large plantations
There are no plantations around here. This was cattle and grain country in that time. Farmers got rich because all of sudden their manual labour capacity was multiplied by machines. The story is quite similar to those who used software to multiply their output in our time, and similarly many tech fortunes have built mansions just the same.
> Not shacks, but nothing gigantic or luxurious.
Well, they weren't palaces. You're absolutely right that they don't look like mansions by today's standards, but they were considered as such at the time. Many were coming from tiny, one room log cabins (stuffed to the brim with their eight children). They were gigantic, luxurious upgrades at the time. But progress marches forward, as always.
> Farmers got rich because all of sudden their manual labour capacity was multiplied by machines.
This sounds like a semantic disagreement.
I think you are using the word "farmer" to mean "large agricultural landlord". Today, those terms may have a lot of overlap, because most of us don't work in agriculture like we did then, but in the past, it wasn't so much the case.
Back then, the landlord who had the "big house" wasn't called a farmer, but often a "Lord" or "Master".
"Farmers" were mostly people who worked as tenants on their land. The confusion in US history started early as the local feudal lords of the time (the founding fathers) rebranded themselves as farmers in opposition to their British rulers, but the economic structure of the societies was scarcely different.
> Back then, the landlord who had the "big house" wasn't called a farmer, but often a "Lord" or "Master".
Feudalism in North America, in the 1900s? Your geography and timelines are way off.
In the 18th and 19th centuries, slavery and sharecropping were primary forms of agricultural labor.
Those are far closer to medieval feudal peasantry than 20th century industrial labor, regardless of the lack of an official hereditary aristocracy in the US.
Sharecropping was very common. And a hard way to earn a subsistence living.
> Look at the farms that have the houses of that era standing on them and you'll soon notice that they are all mansions.
> There are no plantations around here.
FWIW you haven't really stated where "here" is for you. It's not necessarily going to be the same for everyone, and based on the parent comments, the potential area under discussion could include the entirety of the US and Europe (although the initial comment only mentioned UK specifically, it doesn't seem clear to me that it's explicitly only talking about that). I'm not sure you can categorically state that no one in this conversation could be talking about areas that have plantations.
I think it’s pretty dependent on where you farmed. Orchards in California being vastly more profitable than like North Dakota.
Also hard to ignore the survivorship bias there. The small/bad/ugly/whatever houses are gone.
> Also hard to ignore the survivorship bias there.
It's not ignored. It is already encoded into the original comment. No need to repeat what is already said.
> It says early 1900s, so no. It does largely refer to farming, but farming was insanely lucrative during that time. Look at the farms that have the houses of that era standing on them and you'll soon notice that they are all mansions.
https://en.wikipedia.org/wiki/Survivorship_bias
Already in the original comment. Already in other replies as well. How, exactly, does one end up not ready anything in the thread before replying?
> Look at the farms that have the houses of that era standing on them and you'll soon notice that they are all mansions.
TLDR: survivorship
The typically large farms with nice houses were making reasonable money, and in a lot of places, only the house remains of the farm. My old neighborhood was a large farm, subdived into about 1000 postage stamp lots around 1900; the owner's house got a slightly larger lot and stuck around as your mansion.
The small farms that were within the means of more people tended to have shanty houses and those have not persisted. If the farm is still a farm, it's likely been subsumed into a larger plot.
> farming was insanely lucrative during that time
That is wildly inaccurate. Do you think people were flocking to cities to flee the "insanely lucrative" jobs they already had?
Farm labor paid significantly less than industrialized labor at the time. I suspect in addition to just making things up, you're looking at a few landowners who were quite wealthy due to their land holdings (and other assets) and what they have left behind while completely ignoring the lives led by the vast majority of farmers at the time.
> Do you think people were flocking to cities to flee the "insanely lucrative" jobs they already had?
The non-farmers were already accounted for. Did you, uh, forget to read the thread?
I read the thread. I don't see where that's addressed
I also see survivorship bias keep coming up. Each time it claims to be have been addressed in the original comment, and that's that. Yet I don't see how the existence of surviving mansions today proves anything about the prevalence of wealthy farmers at the time
Similarly, there's no inherent reason subsistence farming should prove or disprove work outside the farm. The existence of farms large enough to grow and sell surplus food, that doesn't mean all farms could do so
No, I absolutely read the thread. You either are just refusing to accept you're wrong, you have an exceptionally incomplete definition of farmer you refuse to share (which is really just a specific form of wrong that seems likely in this case), or you have some very exiting undiscovered data to share about life in the early 1900s in the US.
I was about to say, it's not like the early 1900s were particularly great for a lot of people... especially people whose ancestors were, uh, not in the country of their own volition.
How many people agree with the above but "disagree" with https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation
Lololol
Edit: I'm already down one - for people that don't read wikipedia here are the 4 dimensions of alienation of a worker as listed in the wiki:
1. From a worker's product
2. From a worker's productive activity
3. From a worker's Gattungswesen (species-being)
4. From other workers
Edit2: People [in America] will moan about their jobs, their bosses, their dwindling purchasing power, their loss of autonomy, etc etc etc but then come back as champions of capital. You see it all the time - "my job sucks but entrepreneurialism is what makes America great!!!!!!!". I've never seen a more rake->face take than this (and on such an enormous scale). It's absurd. It's delusional.
I don't specifically disagree with Marx's theory of alienation. However I disagree with communism. I think communism makes the problem worse, not better.
Identifying the bad stuff is not hard. Marx is far from unique in being able to do that. I find his class framing and assessment of the roles the various classes do in the status quo to be particularly good even if it ought to be deeply unflattering to the HN tax brackets.
Advising on where to go from there in an actionable way that produces good results is the hard part. Marx didn't do it. Those attempting implementation of his ideas have an exceptional record and not in a good way. And worse still, some of the worst aspects of those movements are the ones that stuck around to be peddled again and again under different brands.
I mean, there's a really simple solution between "Ayn Rand cinematic universe" and "abolishing private property" that gets you downvoted to oblivion: suggest forming a union. No communism required, just workers with bargaining power, like in other developed nations (Germany has very strong unions. Coincidentally, they also have a high quality of life and infrastructure that works). Instead, you get a bunch of people making six figures who sit around either whining or hand-wringing about losing their jobs, while continuing to support the economic system that is abusing them. After a certain point, you just have to throw your hands up and hope that people someday realize the power they have.
There is no reason to buy into the whole Marxist framework just because you share one single sentiment that various thinkers had before and after him.
> one single sentiment
Lol alienation of labor is not a single "sentiment" - it's a core principle. So like it or not you share a core principle with Marx.
The sentiment is shared with Jean-Jacques Rousseau, Adam Smith, Wilhelm von Ketteler, Louis Blanc and probably lots of other less known people. Marx's theory of alienation is far more developed and nuanced than the generic cog-in-the-machine critique that is explored by many other people of various political inclination, not only Marx.
> sentiment
...
> theory
these two words aren't interchangeable
> Jean-Jacques Rousseau, Adam Smith, Wilhelm von Ketteler, Louis Blanc
...
> generic cog-in-the-machine critique that is explored by many other people
literally only one of the names you mentioned were writing post industrial revolution - the rest had literally no notion of "cog in the machine"
you're trying so hard to disprove basically an established fact: Marx's critique of exploitation of labor post industrial revolution is certainly original and significant in his own work and those that followed.
> these two words aren't interchangeable
Exactly. That's why you can't jump from "people don't feel like they own their labor" and "people bemoan their boss" to Marx's theory of alienation.
> literally only one of the names you mentioned were writing post industrial revolution - the rest had literally no notion of "cog in the machine"
But the very framing that this is an ill that is unique to industrial society is Marxist. Slavery, corveé labor, taxes, poor laborers, marginalisation existed for thousands years in one form or another.
> you're trying so hard to disprove basically an established fact: Marx's critique of exploitation of labor post industrial revolution is certainly original and significant in his own work and those that followed.
I don't dispute that Marx's critique of exploitation of labor post industrial revolution is original or significant. I dispute your claim that people who share similar sentiment have to agree with Marx's theory of alienation.
The bad idea from Marx that lead him astray into pseudo-science territory wasn't worker alienation. It was the labor theory of value (and the other stuff he created to make it looks like it works).
Worker alienation is perfectly visible on the real world. I don't think anybody disagrees it's common.
But software development is different. There has been many decades where software developers suffered very little alienation. It only changed with the universal adoption of "corporate agile".
At age 62, I'm wondering which mythical decade did not alienate software developers?
There was a brief ray of hope in the late 90s, with the startup gold-rush idea that we would all be millionaires soon. Then the I realized the founders had 4000x my equity those companies...
Developers used to be freer to choose their tools, organize their routines, decide the result of their work, acquire transferable knowledge, and had access to their tools without any link to any organization (though that one has been steadily improving instead of post-peak).
There is more to alienation than equity.
My 40 years of alienation was not about equity, I was pointing out that the optimistic "We are all going to be rich" vibe of the 90s was wishful thinking due to the massive inequality in the tech world.
Few teams other than green-field start-ups have flexibility regarding tools or technology. My first job was COBOL, 'nuff said about that. Even at start-ups the leads / architects choose most of the technology, and many of my ideas were shot down, such as using C++ in the late 90s, and using Scala in 2010.
People seem to think agile has increased alienation, when in fact the pre-agile world was also terrible. What matters is the quality of the team, not the methodology.
One comedy that did a good job of depicting programmers with no sense of hope circa 1999 was Office Space.
> But software development is different. There has been many decades where software developers suffered very little alienation. It only changed with the universal adoption of "corporate agile"
Lol are you really gonna go with "I'm a software developer, fuck all the restaurant workers, teachers, plumbers, janitors!"
This is why Marx's ideas failed in the West - toxic individualism - and flourished in the East.
Flourished, you say?
Great retort, I actually laughed out loud.
I don't know how delusional you have to be to look at the conditions behind the Iron Curtain, where nations had to build walls to keep their citizens from leaving and a meaningful number of people were willing to risk death to get out, and say they were flourishing, but I'm glad I don't have what it takes to get there.
> where nations had to build walls
Name the Eastern nations plural that built these walls please. As far as I am aware, the G in GDPR stands for Germany, a country/nation/state which is (and always has been) firmly Western. People on here have such an infantile recollection of actual history.
Anyway, leaving aside debates of where the prime meridian of West vs East falls, it should've been manifestly obvious that in 2025 I was talking about China...
Edit: DPRK counts I guess although I'm not sure how many people would call what they have over there "communism": https://en.wikipedia.org/wiki/On_the_Juche_Idea
You mentioned one, which is North Korea, and I'm sure you're going to concoct some story to deflect the fact that China only began moving towards any semblance of prosperity after ditching Mao's fundamentally flawed economic policies, so have at it.
> you're going to concoct some story to deflect
Yes surely I'm the one concocting things (rolls eyes)
https://en.wikipedia.org/wiki/Chinese_Communist_Party
As Sartre said - it's pointless debating people like you because you're just amusing yourself and it's only my responsibility to use words responsibly.
You aren't nearly as informed or as smart as you think you are, and I'm sure I'm far from the first person to tell you this.
you're running based purely on vibes and I'm misinformed? Lol
Surely Marx would disagree with such assessment and call it idealistic and not grounded in material reality?
What happened is that most companies do not care about their employees, and their employees know it.
If anything happens, the company will lay off people without a care for what happens to them.
Even when they do care, such as in a smaller company, their own paycheck is being weighed against the employees, and they will almost always pick themselves, even if they caused the problems.
CEOs making millions while they lay off massive amounts of people is the norm now, and everyone knows it.
You can't blame the employee for not caring. They didn't start it.
There is no employer loyalty, that died in the 90s.
My dad worked as an engineer in the same firm for 30 years and retired. The company was founded before his father was born, and was publicly listed before he was born.
Substantially every company I have worked for didn't even exist 30 years before I joined, let alone before I or my father were born. Most won't be around in 30 years.
Several employers nearly went out of business, had substantial layoffs, or went thru mergers that materially impacted my department/team/job. The guys at the very top were always fine, because how could the guy in charge be responsible?
Even within the companies I stayed 5 years, I had multiple roles/bosses/teams.
>There is no employer loyalty, that died in the 90s.
As a millennial kid at the time, I remember the 90's movies and sitcoms (Office Space, Friends, the Matrix, Fight Club, etc) where the biggest problem GenX had at the time was, *checks notes*, the lack of purpose from being bored out of their minds by a safe and mundane 9-5 cubicle job that paid the bills to support a family and indulge in mindless consumerism to fill the void.
Oh boy, if only we knew that was as good as it would ever be from then on.
I remember the mass layoffs Yahoo had at the dot com bubble crash, when they had a 5-15 minute 1:1 with every worker they laid off. Now you just wake up one day to find your account locked and you put it together that you got laid off, then you read in the news about mass layoffs happening while they're now hiring the same positions in India and their stock is going up.
No wonder young people now would rather just see the whole system burn to the ground and roast marshmallows on the resulting bonfire, when you're being stack-ranked, min-maxed and farmed like cattle on the altar of shareholder returns.
The problems GenX had to deal with was watching Boomers, who enjoyed all the benefits of post-WW2 expansion of infrastructure and social services, pull the rope ladder up behind them once they got well-paying jobs.
The 80's and 90's saw the beginning of the "fuck you, got mine" mentality that pervades all but the most egalitarian societies. Reagan and Thatcher deregulated and privatized everything, and as a result a select few made a mountain of money and destroyed the middle class. "Shareholder value" and mass layoffs became the order of the day way before the dot com bubble burst. GenX knew we'd never have it as good as our parents - we just didn't know how fucked we were going to end up.
>The problems GenX had to deal with was watching Boomers, who enjoyed all the benefits of post-WW2 expansion of infrastructure and social services, pull the rope ladder up behind them once they got well-paying jobs.
No, I agree. But pulling the ladder from under them is not the biggest issue per se since every generation after them did them same if they could get on the ladder, the big problem with boomers is their immense hypocrisy.
GenX and Millennials knew that the situation was every man for himself grab everything you can while the going is still good, but crucially IMHO they didn't try to gaslight the next generations that this system of gains is somehow fair or the result of hard work and self sacrifice.
But boomers indulged in the period of sexual liberation and drug use, while then preaching about conservative family values and war on drugs when they got older, they enjoyed crazy good housing market and unionized jobs while preaching you should pull yourself by your bootstraps for a job that treats you like a disposable cog and won't buy you a house, they vocally hate socialism while depending on a generous social security system they designed for themselves and costing the taxpayer a huge amount on socialized government healthcare programs paid by the younger generations, etc the examples could go on. You can't hate boomers enough for this. Granted, not all are this hypocritical, but enough for the dots to form a line on the graph.
Boomers are dying off or dead. GenX is getting close to retirement age. What will they do with their inheritance?
To be fair, the actual lesson of Fight Club is that maybe you do need a woman in your life. :D (That and don't delude yourself into believing the fascist inside of you.)
What really killed corporate loyalty for a lot of us was the lack of jobs that have lifetime pensions, if I understand it correctly. Why would I agree to work somewhere til retirement if I would be better jumping somewhere else to make more money now?
I think too much "caring" can also be negative. I do not want employees so "loyal" to the company that they don't consider changing for another. I do not want companies so "loyal" to all employees such that they would go bankrupt rather than keep 50% of people active.
I would hope people would be more responsive to the actions of companies. Earlier in my career I looked for another company when the discrepancy between CEO bonus and employee bonus was larger than what I found reasonable.
> they will almost always pick themselves, even if they caused the problems.
And that exactly used to be different and still is in small companies.
>I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Because there's still people doing less work than you do for a bigger paycheck
Because you'd get fired or laid off for someone working for 1/2 to 1/4th of your pay
Because they make you jump through multiple rounds of interviews and technical tests while people above you have a far less barrier to being hired
Because someone stole credit for your work
Because you'd get re-hired and find a mountain of shit code from a company that off shored their dev team
Because companies stopped giving significant raises that didn't keep up with major inflation in the past few years, while your work might have gotten them many multiples more of profits
Idk it's just a mystery we'll never know
Meanwhile:
Your housing costs keep going up.
Your food costs keep going up.
Your transport costs keep going up.
Your healthcare costs keep going up.
Your education costs keep going up.
Your family costs keep going up.
And why? Not for any good reason, no. Just because they can. Your landlord isn't content when you pay $2,500 per month for an apartment, no. They need $2,600. $5 isn't enough for a dozen eggs, it needs to be $6. And what if we slapped 10-200% tariffs on random things, depending on the day? Wouldn't that be neat?
The collective delusion it requires to not see what the problem is is astounding. It's actually quite depressing, because it makes me think we're never going to meaningfully solve this problem. Maybe companies have to start executing employees or something, I don't know. Maybe then people will be bold and decide to re-organize society.
We also printed several trillion dollars because of a respiratory virus outbreak. That was never not going to inflate the cost of everything.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
My local grocery stores won’t accept pride as payment for food, and working harder doesn’t make my paycheck increase.
This is basically it. The US at this point has shown that the winning move is to just lie and scam and loot and then do it all again.
I will be held to the standards of billionaires and politicians. Not one micron more.
People have to be interested in their jobs to care about it. Corporations know that people rarely get to do whatever they want, so they assume (correctly) that most workers do not care, so they move on to care about processes, workflows, which makes even less workers care about their jobs.
For individual workers, the best thing is to work @ something you love && get good pay. Like a compiler engineer, a kernel engineer, an AI engineer, etc.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Many employers actively discourage people from doing work that they are proud of. You cannot be proud of something that is built as cheaply as possible.
You can get employees to care about customers or the product, you cannot get employees to care about profits and dividends.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Anecdotal, but I used to be proud of the work I produced, and then it got old and repetitive. However, as it was getting old, I was earning more. Now I'm in a place where if I were to quit and find something I could be proud of, I would have to accept a huge reduction in compensation. No thanks.
I'd rather have a much higher "just a paycheck" and find things to be proud of outside of work. Plus no one else cares anymore so why should I? Just pay me a lot and I'll keep showing up.
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
ignorance against wrongdoers has been a bliss for your generation, curse for ours and deadly for future
I'd really wish there was a better way to allocate compatible people together.. the distribution is often subpar.. lazies with motivated people drowning to fill in. If you change the ratio and let creative / driven / team-spirited work together you get exponentially better results.
> Or you have a leader above who has no idea and goes with the quickest/cheapest option.
This leader is not going with the quickest or cheapest option. Doing so would probably be laudable. They are going with the claims made by someone that a certain way is going to be quicker or cheaper. It doesn't matter if it actually is, or ends up being, quicker or cheaper. One plan is classified as meeting the requirements while another plan is classified as being cheaper, the cheaper one will be chosen even though it doesn't meet the requirements.
> for some, it's just a paycheck. I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Hard to be proud of the work you produce when you have no ownership over it, and companies show less and less loyalty and investment in their employees. When, at any random time, you can be subject to the next round of layoffs no matter how much value you contributed, it's hard to care.
So yeah, for most it's just a paycheck unless you are working for yourself, or drank a gallon of the koolaid and seriously believe in whatever the company's mission is/what it's doing.
I'm proud of my own work and projects I do for myself, tech or otherwise, and put great care into it. At $dayjob I do exactly what I am paid to do, nothing more nothing less, to conserve my own mental energy for my own time. Not saying I output poor work, but more so I will just do exactly what's expected of me. The company isn't going to get anything extra without paying for it.
Didn't used to be that way, but I've been burned far too many times by going "above and beyond" for someone else.
If employees had more ownership and stake in the companies they work for, I think the attitudes would change. Likewise, if companies went back to investing in training and retention, loyalty could go both ways again.
> I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down…
To the great surprise of my younger self I have never seen “it all come crashing down” and I honestly believe this is extremely rare in practice (i.e. the U.K post saga), something that senior devs like to imagine will happen but probably won’t, and is used to scare management and junior devs into doing “something” which may or may not make things better.
Almost universally I’ve seen the software slowly improved via a stream of urgent bug fixes with a sprinkle of targeted rewrites. The ease of these bug fixes and targeted rewrites essentially depends on whether there is a solid software design underneath: Poor designs tend to be unfixable and have complex layers of patches to make the system work well enough most of the time; good designs tend to require less maintenance overall. Both produce working software, just with different “pain” levels.
I've worked on two different systems which were built in weakly-typed languages that just got too difficult to reason about and fix bugs, so we ended up porting to Java. Customer-facing bugs that the guy who built the framework couldn't figure out.
Sometimes people make such a big mess you have to burn it down and start over.
> Sadly, I have realised fewer people actually give an F than you realise; for some, it's just a paycheck.
I found that most of the "people problems disguised as technical problems" are actually generated by people who get far too invested in their work and let it define them. They get territorial, treat any lost argument as an attack on their whole self, etc. They also lose perspective, getting into flame wars over indentation styles or minor API syntax quibbles.
People who show up for the paycheck are usually far more reasonable in that regard.
Yep. I’m just like “pick a technology. I don’t care what, just stick with it long enough to get something done with it”
> for some, it's just a paycheck.
What is wrong with just wanting to work for money?
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Maybe if wages kept up with inflation people would still care. You know, when I was young, I was able to rent an apartment while being a cashier in a grocery store.
>> for some, it's just a paycheck.
> What is wrong with just wanting to work for money?
Imagine a society where your work was an opportunity for you to provide products/services for your community, where you could earn a reputation for craftsmanship and caring, and where the real value was in the social ties and sense of social worth-- your community cares for you just as you care for it, and selfish assholery has high costs leading to poverty.
Now imagine a society where the only measure of social worth is a fiat currency, and it doesn't matter how you get it, only matters how much you have. Selfish assholery is rewarded and actually caring leads to poverty.
Which society would you rather live in? Which society is more emotionally healthy?
So the question is, is our current society the one we want to live in? If not, how do we move it closer to what we want?
Our current society can and does have room for both, which is great since some people want to live to work, and some just want to work to live. I don't see a problem with either, as long as it makes one happy.
And there's another group, grifters, who are neither living to work nor working to live. They are the parasites, and our current society rewards grifters by not putting them in check. Probably because so many want a piece of the grifting pie, in the same way many people see themselves as temporarily embarrassed millionaires.
Don’t forget another group, permanently disenfranchised, who are working to barely live. They are the unsung heroes of our society, who for a brief year or two recently got celebrated as key workers, got claps and applause, and then forgotten again once normality resumed.
"Show HN: I drive a garbage truck" wouldn't make the front page, but the world would grind to a halt tomorrow if those people stopped showing up for work.
The NYC garbage truck people are more than content to be paid handsomely in dollars instead of claps and cheers. Their union has the city by the balls and they know it, and they abuse that power to block modern trash containerization improvements. I wouldn’t have any qualms about personally automating their job
> If not, how do we move it closer to what we want?
By going all Ted Kaczynski on the elite and abandon sensationism and most of technology.
Ethically? Nothing.
Socially and emotionally? It's brutal. For both the employee and society in general.
Spending almost half their waking hours not caring is not good for people.
Frankly, people for whom the work is "just a paycheck" I know in real life are simultaneously happy and simultaneously frequently produce actually good reliable work.
Work being "just a paycheck" does not mean you hate it or half ass it. But, it means you do go home to get rest, you do socialize outside of work instead of irrationally pushing it and then using meetings for socialization. It means you do not have ego tied to it so much you throw temper tantrum when things are imperfect (which is not the same as being able to change things for the better).
So is it not good for people to care and yet be blocked from being able to do good work.
Then pay people so they have a reason to care their work. This is like a wife beating husband wondering why his wife to care more about him.
every company in the united states could become a co-op and nothing would change for the business and everything would change for the workers. And everyone would be much happier at work and you would have the caring people you want.
It is the system that is the problem, not the people.
There's a difference between caring about your personal work product (and reputation), your colleagues on a personal and professional level, and your employer as an entity.
I expect my employees to show up to work and put forth a solid effort on a regular basis. Note that this doesn't mean a constant death march towards some unreasonable objective, or anything even close to it. Just apply yourself using the skills we agree you have for the pay we also agreed upon for 8 hours a day on average. In my field, this means you have pay that is well above the norm for an average software developer, and the working conditions are good or better.
A shocking number of people are incapable of this, and generally are also the same people who would claim that "they didn't start this".
I don't know how to explain any better that, if given the choice, I would simply not do what I do for the company for which I do it. Full stop. Somehow, when we talk about companies laying off thousands, that's "business as usual" and "nothing personal". But when an employee acts like the robot the company sees them as, suddenly people get upset! Why is it so hard to understand that people work because they have to, and not because they want to? Why is that so threatening to your worldview? Is it because, deep down, you know it's true?
I used to cope like that. I told myself that I could throw myself into my work, maybe stand out and make a difference. Guess what? I was overworked, burned out, and laid off right as I worked a few weekends and pushed through a crazy (and arbitrary) deadline. I still haven't recovered emotionally. I was sort of believing the lie, for a bit, but this severed the last thread.
My story isn't unique or special, but then I come on HN and I get told that I just have to "take pride in my work", like I'm not checking my e-mail every day to see if I even still have a job, during the worst cost of living crisis since 2008. I'm sorry, that's a fucking joke.
There are a million other things I'd rather be doing all day than this. And a lot of them involve programming a computer! But not things that allow some suit to send me a smarmy e-mail about "making 2026 our best year ever", no. Things that help me, my friends, my family, my community. Those are the only things that matter. Work exists because my landlord wants to retire comfortably in Florida. Bully for him. The rest of us, well. We have to grind it out and hope we make it to the finish line.
Give us a reason to care. It's that simple.
I believe that seeking external validation, inspiration and/or reason is not robust and a path to unhappiness. IMO, it's better if the reasons for you to care come from within.
I dont pay my bills from reasons within.
The reasons to care are personal pride in the quality of your work, understanding that your lack of effort has a negative impact on your colleagues, and your continued employment.
And if you hate your job, but are completely unable to find alternative employment (which is what you should do if you hate your job), you probably should reconsider how much you hate your job.
Got any recipes for delicious meals I can make with my pride?
I take pride in the stuff I enjoy doing. A job is just a paycheck because I need it.
He wasn't asking you to work for free.
I know. But people will worry about dollars first before they even think about pride.
I find it hard to believe you actually read my comment before demonstrating you are probably one of the people I'm talking about at the end of it.
At no point did I state or imply that workers should be working solely or even primarily for anything other than money.
But if you can't be bothered to take pride in the work you're being paid to do, you shouldn't be paid to do it for long.
I will do my job as well as necessary to keep it in order to keep receiving money. If I could find a job that pays well and made me happier I would.
If you can't find a better job, you should probably appreciate the one you have and not try to skate by with the bare minimum, if for no other reason than you're likely to miscalculate at some point.
That’s just another way of saying work harder for same pay because the company knows they have you by the balls.
No, it's recognizing you have no better alternative so you shouldn't take what you do have for granted, because it's not guaranteed to continue.
"Beatings will continue until morale improves."
People have a working contract and all you have to do is work according to the contract.
Ah, noble poverty! Be grateful to tha masta' for providing you the scraps he can provide! Your paycheck is the beautiful work you produce for tha masta'!
Seriously, pay people what they are worth and they will care. It is not that hard.
The vast majority of people significantly overestimate their worth, yet people with your attitude seem to believe it only exists with respect to highly compensated employees.
I agree with your second sentence, but it's harder than it should be due to what I said above.
Pride in the quality of my work is a phrase to make one feel bad about themselves. I take pride in my hobbies and in my hobby projects. I take pride in my family and friends. I do not take pride in being exploited for my work so some higher up can buy a new car every year.
And again, someone comes and makes a comment that proves my point. Unless you are working in very unusual (and illegal in the developed world) circumstances, you are not being exploited in any real sense.
In the end this depends on your definition of "fair". What percentage of your generated production do you think is fair for the company to take? 95%? 50%? 10%?
That depends on the value of your generated production, among many other things, and ultimately isn't the right question to ask.
Can an employee obtain better employment terms elsewhere (which is a complex concept to define in itself)? If so, they are underpaid, if not, they aren't.
You were talking about exploitation. Using the fact that the employee cannot obtain a better employment elsewhere to extract as much of the production or value from the employee smells a lot like exploitation to me.
If an employer offers an employee $100 per hour, and the next best offer that employee can obtain elsewhere is $90 for an otherwise equivalent job, should the employee take that job for granted? Is the employer exploiting them with their pay rate?
In my humble exploited worker opinion, you resemble Samuel L Jackson in Django Unchained. You dont even realize in what position you are in. Get back to the ground bootlicker.
And in my humble opinion, you will continue to be dissatisfied and somehow it's everyone's fault but your own.
> You know, when I was young, I was able to rent an apartment while being a cashier in a grocery store.
You still can almost everywhere outside of places like SF? I just spot-checked some data, and in Minneapolis for example currently available apartments are comparable to what they were when I was looking 10 years ago, cashier wages have gone up 45%, and that often comes with healthcare benefits now. It's not an especially wealthy life, but a single person should be very comfortable (that's a comparable hourly wage and apartment cost to what I had delivering pizza at some other part of my life, and I lived comfortably and was able to save up to splurge on a nicer used Miata and the down payment for a small house).
So I believe it actually worse that the article makes it out to be.
Currently AI "solutions" being implemented in places like call centers are often technical solutions attempting to pave over organizational problems. Many IT solutions are like that. We refuse to fix the underlying problems, so we layer software on top, so we won't notice the stupidity below.
IT companies will happily take the money and write the code, broken as it might be, because the real problems aren't actually resolved. That to me is a problem. Companies needs to be way better at saying no, and offer help address the underlying issues instead, even if they aren't technical in nature.
> What is wrong with just wanting to work for money?
Nothing. In fact, I envy people who can and wish I could. Consider it one of my largest flaws.
> I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect
I recall there was a whistleblower Richard Roll who said that engineering did know of the bugs and flaws
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Millions of boocampers and juniors trying to make a quick buck; any tech work that is not “make it, and make it quick” is punished; tech debt swept under the rug; any initiative is being shut down because status quo is more important; “we’ll optimize when it becomes a problem” on 15 seconds page reload; dozen of layers of parasites and grifters making your life hell, because their paycheck depends on it; salary bumps that don’t even cover inflation – the only way to actually move in life is to join, raise as much hell as possible in 2 years and jump ship leaving the fallout for the next SOB in the line.
And that’s just what I bothered enough to type on bad iOS keyboard.
People need visas and that’s all they care about
You started an excellent discussion with this comment
Work is just a paycheck because I am just a number for my employer. Why would I be proud of my work when apparently according to management I should be replaced by AI at some point because im just a cost factor. Why would I care about the business at that point? Fuck the higher ups, I'll be proud of my work and actually put in effort if I can afford a house.
Frankly, something that I don't see discussed enough is the truth that many people are plain stupid. If my position in the company depends on stupid people, then this completely changes the game, because then good engineering isn't the best way to maximize my status anymore. That's how you get smart people spend their time coming up with elaborate tactics to appear productive while in reality they aren't and play office politics. All successful corporations understand this and build processes around the assumption that their workers are idiots, which has the side effect of suffocating smart workers, but the truth is, ten thousand morons is a bigger force than a hundred geniuses.
Say this in an interview and its a perfect way to fail, even though its true. Its sad how interviewers often take pleasure in pointing out that anything said outside their packets is a signal for lack of technical knowledge. I've been in and passed several tech interviews. I've also interviewed plenty of people, if someone points out the human aspect of a problem, I actually award points. Sad how often I have to fight with my colleagues.
"But what about using a message queue.."
"Candidate did not use microservices.."
"Lacks knowledge of graph databases.." (you know, because I took a training last week ergo it must be the solution).
Thankfully, we do not have to judge a blog post by its ability to pass muster in technical interviews. :)
In my most recent role, everyone interviewing me gave me a thumbs up. Except one engineer.
I remembered our conversation well, because it left me a little confused. We were talking about handling large volumes of messages. And when I said "well it really depends on the volume, you could be fine with batch processing in many cases" he jumped on it like I had never heard of a queue.
Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues. He flat out rejected the claim (because that didn't fit the current system design).
Guess what we're discussing now and have spun up a whole team to complete? Forcing every micro service to use a single API rather than elasticsearch directly, because of scale.
> Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues.
There's a small but substantial number of engineers out there who haven't operated at the kinds of scales where hyperscalers' limits become normal architectural problems and don't have the humility to imagine that it could be the case. (e.g. blob stores do in fact have limits you can hit, and when you operate at petabyte scales you have to anticipate in the architecture that you can hit them for even trivial operations.) I also work on petabyte datastores and have encountered a bunch of those engineers over time.
To be fair though, that's the small minority of engineers I've encountered, and if it wasn't arguing about the types of scale problems unique to petabyte scales, it'd be about some other nuanced subject matter. It's a humility problem.
Its also a math problem. The kind I've encountered that make bad decisions are also the ones shockingly bad at doing back of the envelope calculations.
Honestly failing candidates in an interview put of a sense of superiority is just about saddest thing I've heard. I mean how lonely do you have to be ?
/endrant.
Oh, wow, strangely I went exactly through the same thing.
I once had an interviewer expected me to answer "message queue", despite all of his answers to my questions pointing to an MQ not solving the issue.
He was getting really frustrated with the "it depends" and the questions, until I answered "Message Queue" and he sighed in relief.
I passed the interview but rejected the job offer.
What sort of batch are you referring to? Is batch processing why some websites take 5 minutes to send an OTP?
Aso, it's crazy that an employer would yell you which individual employees voted for/against your hire.
I've found presenting arguments from both sides, i.e. presenting the tradeoff, to be effective in interviews. Especially because if the team I'm considering doesn't recognize the tradeoffs, then I can avoid joining up with them.
I know this is a tangent, but graph DB gets overused a lot because it's so often a neat-looking idea.
As a data engineer in big tech, the two hardest problems I deal with are:
* Conway's law causing multiple different data science toolchains, different philosophies on model training, data handling, schema and protocol, data retention policies, etc.
* Coming up with tech solutions to try to mitigate the impact of multiple silos insisting on doing things their own way while also insisting that other silos do it their way because they need to access other silos' data.
And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs. As someone who gets to see all of those approaches - most of their approaches are both valid and flawed and often not in the way their leaders think. A few are "it's not going to work" levels of flawed as a result of an architect or leadership lacking operating experience.
So yeah, it might look like technical problems on the surface, but it's really people problems.
I can add so many:
- Requirements are rarely clear from the beginning;
- We (DE) are not enabling self-service and automation so we are drowned in small requests (add this column for example;
- Upstream rarely notify us about the changes so we only know when downstream alerts us. We end up building expensive pipelines to scan and send alerts. Sometimes the cost of alerts > cost of pipeline itself;
- We have so many ad-hoc requests that sprint is meaningless. If I were the manager I'd abolish sprint completely;
- Shadow knowledge that no one bothered to write down. I tried to write down as much as possible, but there are always more unknowns than knowns;
Working in DE definitely gives me enough motivation to teach myself about lower level CS.
What does DE mean in this context?
Presumably Data Engineer.
data engineering
data engineering
Divest and exclude? …
Wrong answers only please.
That's the mother of all people-space problems in IT, right there.
To solve this, one can be an instrument for change. Network, band people together, evangelize better ways forward, all while not angering management by operating transparently.
Sometimes, that can work... up to a point. To broadcast real change, quickly, you really need anyone managing all the stakeholders to lead the charge and/or delegate a person or people to get it done. So the behavior of directors and VPs counts a lot for both the problem and the solution. It's not impossible to manage up into that state with a lot of talking and lobbying, but it's also not easy.
I'll add that technological transformation of the workplace is so hard to do, Amazon published a guide on how to do this for AWS. As a blueprint for doing this insanely hard task, I think it holds up as a way to implement just about any level of tech change. It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow. https://docs.aws.amazon.com/prescriptive-guidance/latest/clo...
> It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow.
Yup, this is the key issue and what makes it primarily a people problem. Technical solutions don't work if the main problem is getting buy-in to spec/build/adopt one, unless you're willing to build a lot of things you end up throwing out. So instead the bulk of the high risk work is actually negotiation between people.
> And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs
I work in implementation of large enterprise wide systems. When I do projects that span departments/divisions/agencies what you’re describing is the biggest hurdle. The project always starts with “we’re bringing everyone together into one solution” but as time goes on it starts to diverge. It’s so easy to end up with a project per department vs one project for all. You have to have someone with the authority to force/threaten/manipulate all the players onto the same page. It’s so easy to give in to one groups specific requirements and then you’ve opened Pandora’s box as word spreads. It’s very hard to pull off.
I think public sector (governments) is the hardest because the agencies seem to sincerely hate each other. I’ve been in requirements gathering meetings where people refused to join because someone they didn’t like was on the invite. At least in a for profit company the common denominator for everyone is keeping their job.
Jerry Weinberg, Secrets of Consulting (1985) - "No matter how it looks at first, it's always a people problem." - no matter how technical a problem seems, its root cause always involves people—their choices, communication, management, or skills—making human factors central to any solution, from software development to complex systems
Came here to say this. Amazing how timeless his wisdom is.
I worked as an analyst on a team doing a system replacement.
The old system assigned work cases out in a plain round robin system - Person 1 got Case 1, Person 2 got Case 2, etc, regardless of what people already had on their plate.
The new system looked at a number of factors and assigned a new case to people who had the least amount of overall work in their queue. So if Person 1 had 2 cases and Person 2 had 10, then Person 1 was getting the next case.
Management in one division came to us after a while and said the method of assigning cases was broken, and cases were not being assigned out "fairly." They wanted us to implement the old system's round-robin assignment method in the new system.
After some investigation I determined that workers had figured out ways to game the system in order to seem more busy than they actually were and therefore receive less new cases. As a result efficient workers who were actually doing their jobs were getting punished with new cases while inefficient workers were getting rewarded.
I, another analyst from that division, and my management laid out a very clear case that if employees were not properly handling their cases, and not being monitored on their progress (by all the new monitoring tools the new system provided) then changing the method of distributing cases wouldn't fix the underlying problem.
We were overruled and forced to implement the technical solution to the human problem.
seems like this was a decision between two technical solutions, not a people problem. one solution had a kind of perverse incentive
even without perverse incentive, it seems to be human nature that work expands to fill available time (this is another kind of perverse incentive)
maybe best to frame problems of human nature as technical problems. ex, the preferred path should be the easiest path
sadly, people do not behave like the utopian ideal
Jerry Weinberg wrote a number of books to this point, starting with 1971's 'The Psychology of Computer Programming.' Here's what he had to say a decade or so later...
"The First Law of Consulting: In spite of what your client may tell you, there’s always a problem.
The Second Law of Consulting: No matter how it looks at first, it’s always a people problem." [0]
Everything he wrote is worth the time to read.
[0] Weinberg, Gerald. "The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully", 1986
Saw this post title and immediately thought of Jerry.
There are other ways to look at it. Back in the old days when computers required lots of planning to program, the technical problem of having a buggy program was also a people problem of not planning carefully enough. But now we have fast computers and cheap storage and version control and autosave and so many other things, such that perfectly conscientious human planning of the activity of programming is no longer necessary. In many cases you can just bang stuff out by trial and error.
My point is, we have often discovered technical solutions for things that used to be regarded as people problems.
So maybe a lot of things are just problems, which may be solvable through either technical or people means.
I think I'm mostly of the opinion these days that there is no such thing as an "outdated technology". There are technologies that are no longer fit for purpose but that is almost never because of their age. It nearly always because of one of as examples: Needing to run in an environment it can't support, Having bugs that are not getting fixed/no longer maintained, Missing features necessary to solve new problems or add new features, Hitting scale limits.
Outdated may sometimes be a euphemism for one of the above but usually when I see it in a discussion it just means "old" or "out of fashion" instead.
I'd also add "there are almost no developers using it on the job market" to the list why some technologies are no longer fit for purpose. It's a major one. Sort of tied to the ecosystem (no devs - not many things get mantained/created).
I do think that holds more water than just "It's old".
However for pretty much any dev I would hire for a job they can get to grips with a technology that's older pretty quickly. Where it does get dicey is when good dev just refuses to work with it. For those devs, I think, when they hold that opinion it typically means one of those other reasons is behind their refusal.
>one of those other reasons is behind their refusal.
I mean, one of those reasons is "When I leave this job will I be able to get another job" is a huge deeply life affecting one.
If you want me to work on COBOL from 1988 then you've limited my work prospects to one of a very few employers in the country at a very specific pay range. If I instead tell you to eat a fat one and go with $language_de_jour the number of employers and potential salary range is much, much larger.
Why does working in one technology prevent you from getting a job in another one?
Haven't you seen job offers where X years of experience in XYZ is a must? It's like most of them. Never got one without this actually. Gotta have this experience from somewhere.
I know devs like to say they would hire anyone, but they're not the ones hiring. At best you get to interview people already prefiltered by HR which... looks for keywords in CV.
My personal anecdotal experience is considerably different. I've worked multiple places where I had to learn the stack on the job. Up to and including the language at least once.
I've never found it too difficult to get hired even when the requirements don't list something I've done already.
At least in the current market there is a lot less leeway for this
At this point I'm fairly senior and work directly with funding sponsors and requirements owners. The gal who 100% owns the problem, worldwide, says "I need X, how much it going to cost?", while X is a big, hairy ball of wax and I have 18 minutes left in the 30 minute meeting to get as many details as I can while I work up a guesstimate. Because the funding line will be decided by minute 30.
They have no idea what's going on technically. But they know where the money is and the words that have to be spoken to certain people to get and defend that money. I have been handed a problem that was estimated to cost $6M and solved it with a text message, in the meeting. Shoulda taken the money. I have also had a project poached from me, watched the new team burn $35M and come out the other end with nothing but bruised egos.
The sponsors with the budget are definitely folks who prioritize politics over everything else. They have generally have bachelor's or master's degrees, rarely doctorates. You look at their career and wonder how they got there. Their goal is not mission success. Their goal is the next job. They've been dressing for the next job their whole career. The financial folks are afraid of them, or at least very wary.
This is why I hate it when people are judged (like the article writer is doing) for doing what their job requires of them and not “taking pride in their work” - the thing is, the workers generally don’t own the work, the business does. If the business wants something a certain way, and if they act to punish you for trying to push back, why fight them? It’s not our company. We’re cogs in a machine, if they treat us like that then what do they expect?
This article has a stink of self importance that rubs me the wrong way.
This is painfully clear once you’ve worked in a non-first-world country. Everybody is just working a job.
I love the header pic.
That describes so many projects that I've seen, over the years.
One of my first programming projects, was maintaining a 100KLoC+ FORTRAN IV email program, circa 1975.
No comments, no subroutines, short, inscrutable, variables, stepped on by dozens of junior programmers, and the big breadwinner for the company.
Joy.
It was probably the single biggest motivation for my uptight coding style, since. I never want to do to others, what was done to me[0].
[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/
"was maintaining a 100KLoC+ FORTRAN IV email program, circa 1975"
That sounds challenging, and very early for email. Would I find it in the timeline or was it internal only?
https://archive.computerhistory.org/resources/access/text/20...
It was basically before Internet email.
Proprietary store-and-forward system, run by a BT subsidiary, named Dialcom. Ran on Prime minicomputers.
I worked there in 1987.
[UPDATED TO ADD] And to add insult to injury, it was all on sub-VGA 300-Baud VT-100 terminals and line printers.
I spent a lot of time, staring at blue-striped paper.
Telecom Gold! Good for you.
https://en.wikipedia.org/wiki/Telecom_Gold
I still wake up screaming...
One of the issues with the system, was it couldn’t generate reliable billing.
One customer had been running the system for free, for years, because we couldn’t send them an accurate bill.
One look at that bowl of spaghetti, and it’s easy to see why.
Feels like beauracracy but a DACI or RFC etc. can help if the culture supports this sort of decision making.
You list the options, e.g. A combine codebases, B leave as is. Get comments and look at it logically and come to agreed decision.
You have the reason and tradeoffs documented.
The discussion may prompt other wider discussions etc. More senior people may spot patterns. E.g. lets not pay down tech debt X because Y is coming.
Culturally though if no one cares and most people are happy to manually work through the bugs and hate even discussing it then it may be a bad fit for a developer who cant stand working like that.
While I agree with the sentiment one statement jumped out that grinds my gears.
>Why does technical debt exist? Because requirements weren't properly clarified before work began.
I hate this line of thinking and the expectations that come along with this style of work. The idea that developers need to be spoon fed requirements and only then can they start working because they fundamentally lack an understanding of the desired business outcome and their work output is so valuable that it can’t evolve as their understanding of the problem evolves _is problematic_. To be clear I’m not blaming developers but the style of work that often goes by names like waterfall, agile, SAFE, agile 2.0, transformation, etc. is all hot garbage.
The author suggested that if senior leadership had a development background then tech debt would be easier to get support and resources to deal with. Between the lines I'm reading that the risks are just inherently understood by someone with a tech background.
Then the author suggests that senior leadership without a tech background will usually need to be persuaded by a value proposition - the numbers.
I'm seeing these as the same thing - the risks of specific tech debt just needs to be understood before it gets addressed. Senior leaders with a development background might be better predictors of the relationship between tech debt and its impact on company finances. Non technical leaders just require an extra translation step to understand the relationship.
Then considering that some level of risk is tolerated, and some risk is consciously taken on to achieve things, both might ultimately choose to ignore some tech debt while addressing other bits.
The risk of tech debt is marginal cost of adding features goes up as tech debt goes unpaid.
I'm clearly jaded by my own experience but I feel that there's less and less focus on building and retaining a solid team. People are treated like cogs on a machine and this shape their view of the system in return.
It's actually quite awful to work in such an environment.
Technical problems are generated by lack of knowledge. One type of lack of knowledge is interaction with people. You'll never know everything that another person wants to communicate to you because of several reasons.
But even in the case of magically fixing people problems - for example, if you are working on a solo project - you will still have technical debt because you will still have lack of knowledge. An abstraction that leaks. A test that doesn't cover all the edge cases. A "simple" function that was not indeed that simple.
The mistake you want to avoid at all costs is believing you don't have a knowledge gap. You will always have a knowledge gap. So plan accordingly, make sure you're ready when you will finally discover that gap.
> Technical problems are generated by lack of knowledge.
Or a lack of action. Tech breaks and you need to take the action of preparing for that.
> Most Technical Problems Are Really People Problems
The irony is that this is a classic engineer's take on the root cause of technical debt. Engineers are happy to be heads-down building. But when you get to a team size >1, you actually need to communicate - and ideally not just through a kanban board.
Im a software engineer but have been around the block enough times that I now lead large teams. It annoys me a little when people here talk about how worthless management is. I just want everyone to know that good management is very hard, way harder than anything I’ve ever faced in software development. It’s subjective, non deterministic, all the things digital logic is not. It’s very hard which is why bad management is so common.
> It annoys me a little when people here talk about how worthless management is. I just want everyone to know that good management is very hard, ...
People talk about how worthless management is, because most management is not good and most "managers" are worthless. Promotion to your level of incompetence is a real thing in tech management circles.
> It annoys me a little when people here talk about how worthless management is.
In primary function, a good manager is invisible, so it is understandable that it is seen as being worthless.
But in secondary function only a bad manager keeps themselves invisible. A good manager will stand up at stand up and tell about what they've been working on. If you are not communicating exactly what you are doing to everyone else, you've screwed up horribly.
> way harder than anything I’ve ever faced in software development.
To be fair, you can say that about every job in existence that isn't software development. There is nothing hard about software development.
Yes, you are describing a "people problem"...
> Most technical problems are really people problems. Think about it. Why does technical debt exist? Because requirements weren't properly clarified before work began. Because a salesperson promised an unrealistic deadline to a customer. Because a developer chose an outdated technology because it was comfortable.
I used to be a "stay out of politics" developer. After a few years in the industry and move to a PM role, I have had the benefit of being a bit more detached. What I noticed was that intra-developer politics are sometimes way more entrenched and stubborn than other areas of the business.
Sure, business divisions have infighting and politics but at the end of the day those are tempered by the market. It's far harder to market test Ruby Versus Java in a reasonable manner, especially when you have proponents in both camps singing the praises of their favored technology in a quasi-religious manner. And yes, I have also seen the "Why would I learn anything new, <Technology X> works for me, why would I take the effort to learn a new thing" attitudes in a large number of coworkers, even the younger Gen-Z ones.
You need to make people include some sort of objective evidence with their argument, and either have a (hopefully benevolent) dictator solve the "vim vs. emacs" problems or just let people pick their environment and sort out any issues they create themselves.
If you're trying to pick a development language by committee, something is already very wrong. That something would be a people problem I suppose (because everything is), but it's really a strategic problem of the business.
Some questionable assumptions here:
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
Reasons vary widely. Code can also get calcified because people lack the vision, tech skills, or time/budget to update it. On the opposite side of the spectrum, personality types who do like change sometimes rip out everything out and start from scratch, effectively destroying well written code, which is no better.
> Why does technical debt exist? Because requirements weren't properly clarified before work began.
Not necessarily: it can also exist because code wasn't well written to begin with, libraries weren't updated to work with OS updates, feature-creep, etc.
> In my opinion, anyone above senior engineer level needs to know how to collaborate cross-functionally, regardless of whether they choose a technical or management track.
Collaboration is a skill everyone needs, and the ability to explain things to people at other levels shouldn't be limited to senior engineers. Even junior devs would do well to be able to explain things to higher-ups.
>Because requirements weren't properly clarified before work began
Yea, software is typically way more flexible and fast moving in the real world.
At start of project: "We need software with A, B, and C"
In middle of project: "Our competitor has released with ABCD and E, and if we don't add at least E we might as well cancel the project"
There is also - Our software works 100% fine with what we expected in the field, problem is (new|old) thing showed up and now we have to work around all the bugs in it.
Then there is Chesterton's fence. That 'broken old crap' was actually doing something highly specific that calcified into how the customers systems work. People love ripping crap up and changing stuff, until they figure out it just broke their enterprise clients workflow, and that client pays their salary.
There is a big and vocal group one who does not believe in the idea of solving the tech debt for couple reasons
1. Solving tech debt is not going to get you promotions and visibility as the article right said there is no visible difference
2. Its going to accrue continuously
3. There is no dedicated role that owns the tech debt so its not really anyones explicit responsibility as a part of job
100% agree. The coding is straightforward - it's the human factors, context, and data complexities that make things difficult
Isn't this generally the case across all sectors and industries? We have the technology today to create a post scarcity utopia, to reverse climate change, to restore the biosphere. The fact that none of that happens is a people problem, a political problem, a spiritual problem, more so than any technological barrier.
Yea this is true of virtually all problems today. It's one of the blind spots of the AI acceleration crowd. Cancer vaccine discovered by GPT-6? You still have to convince people it's safe. Fusion reactor modeled by Gemini? Convince people it's not that kind of nuclear power. Global Engineering solution for climate change? Well it might look like chemtrails but it's not. Implementation of all of these things in a society is always going to be hard.
I think this is a large factor in the turn towards more authoritarian tendencies in the Silicon Valley elites. They spent the 2000s and 2010s as a bit more utopian and laissez faire and saw it got them almost nowhere because of technology doesn't solve people problems.
I couldn't disagree more with this description of why technical debt exists and it's a dangerous line of reasoning. Sure, maybe requirements weren't clarified. But often it's impossible to clarify them and you have to build something and even if the requirements were clear to begin with who is to say they'll still be the same by the time you've finished the project let alone 5 years later. Maybe the develop chose a stable and dependable technology because it's battle worn and proven? Maybe the sales person has to manage an impossible situation between an engineering team which can't commit to the time line needed to win the sale?
There are lots of good reasons tech debt exists, and it's worrying that this person seems to think that they all boil down to "I don't know how but someone, somewhere, fucked up"
As someone else mentioned here: not all technical debt is created equal. I agree, sometimes the problem are changing requirements, etc. But it is also true that there is technical debt caused by developers who don't take the time to properly design features and will simply implement the first thing that came to their minds. I agree with the author, this kind of technical debt is caused by a mediocre attitude which often propagates to all the team if there is no one that calls it out.
The more interesting discussion to me is: how do you solve this problem once it exists in a team? I guess there are many approaches, but I tend to think that 'lead by the example' is the best you can do as an engineer, but a top-down approach might work better which is what happened at Microsoft when Satya Nadella became CEO.
The definition of technical debt is the compromises you intentionally make (generally to ship something thus not going bankrupt). Thus by definition nobody made a mistake: this was an intentional decision that was believed correct at the time. You will pay a cost later for the decision, but it is rarely a mistake to make those compromises.
Technical debt also includes descriptions of unintentional debt. For example you can 'withdrawal' technical debt from ignorance.
It's worse, they seem to think tech debt is just a "state of mind", a "personality defect":
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
This line of thinking (we will make it with future change in mind!) is of course exactly the bullshit that is tech debt in the first place.
Oh wow, nice catch in the article, jesus.
Peopleware is an excellent book built on this premise.
https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...
Ha. At my last job, I observed that we were so good at solving technical problems that we transformed social problems into hard technical problems so we could solve the original song cial problem. It's something like a problem reduction in Algorithmic Complexity Theory. There was perhaps a simpler social-centric solution, but we didn't have a method for solving those...
All problems that concern people are people problems. That's why we don't talk about it. It's like saying all rain is wet.
Just assume the other person knows, and avoid one extra people problem.
At least the headline makes sense to me.
> Most technical problems are people problems
Certainly explains Microsoft Teams and Windows 11.
[note there is no /s -- it's 100% a people problem, because the wrong people are steering the ship]
All product problems are organization problems.
There are plenty of actual "technical problems" that have nothing whatsoever to do with "technical debt".
The title could maybe be more accurate if it read "Most Technical Problems IN BUSINESS Are Really People Problems", though I guess its less punchy.
Or, perhaps "Technical Debt Is Really a People Problem".
For every person trying to move an old code base from COBOL to Java to remove tech debt, there are an equal number of people who want rewrite a working C++ code base in Rust/Go/Zig.
Leaders who know that it's a people problem and who have read the Jerry Weinberg book know both sides of the problem.
In my opinion, people problems is just a subset of communication problems. Communication also involves people not working at the same place (remote), at the same time(remote). Even the gal working next room is a problem, that hinders questions.
This is why communication skill is the most important differentiator between a senior dev and a junior dev.
This is a classic engineering take on the problem. It changes when you become a CTO. Because now technical debt is your problem and the choice whether to fix it or not is yours to make. The flip side here is that wrong choices (either way) can be expensive and even kill your company.
I've been on both sides. Having to beg a manager to get permission to fix a thing that I thought needed fixing. And now I'm on both sides where as a CTO it's my responsibility to make sure the company delivers working products to customers that are competitive enough that we actually stand a chance to make money. And I build our product too.
Two realities:
1) Broken stuff can actually slow down a lot of critical feature development. My attitude as a CTO is that making hard things easier is when things can move forward the fastest. Unblocking progress by addressing the hardest things is valuable. Not all technical debt is created equally. There's a difference between messing with whatever subjective esthetics I might have and shit getting delayed because technical problems are complicating our lives.
2) We're a small company. And the idiot that caused the technical debt is usually me. That's not because I'm bad at what I do but I simply don't get it right 100% of the time. Any product that survives long enough will have issues. And my company is nearly six years old now. The challenge is not that there are issues but prioritizing and dealing with them in a sane way.
How I deal with this is very simple. I want to work on new stuff that adds value whenever I can. I'm happy when I can do that and it has a high impact. Whenever some technical debt issue is derailing my plans, I get frustrated and annoyed. And then I sit down and analyze what the worst/hardest thing is that is causing that. And then I fix that. It's ultimately my call. But I can't be doing this all the time.
One important CTO level job is to keep the company ready for strategic goals and make sure we are ready for likely future changes. So I look at blocking issues from the point of view of the type of change that they block that I know I will need to do soon. This is hard, nobody will tell me what this is. It's my job to find out and know. But getting this right is the difference between failing or succeeding as a technology company.
Another perspective here is that barring any technical moat, a well funded VC-funded team could probably re-create whatever you do in no time at all. If your tech is blocking you from moving ahead, it can be sobering to consider how long it would take a team unburdened by technical debt to catch up with you and do it better. Because, if the answer is "it wouldn't be that hard" you should probably start thinking about abandoning whatever you are trying to fix and maybe rebuilding it better. Because eventually somebody else might do that and beat you. Sometimes deleting code is better than fixing it.
Technical debt is intentional compromises. It sounds like you are thinking of not intentional compromises, but instead accidents where someone didn't understand the requirements and so did it slightly wrong for the expected future. Cases where the system wasn't designed to handle requirements changing in the way they did so you had to "make an ugly hack" to ship are technical debt.
I understand the distinction, but at some point it's not super helpful, and I would argue even counter productive.
If you have a system that is big enough and has had enough change over time that it's structure is no longer well suited to the current or near future job-to-be-done, then it doesn't really matter how you got there, you need to explain to non-technical stakeholders that current business requests will take longer than it would intuitively take to build if you just look at the delta of the UX that exists today compared to what they want (ie. the "why can't you just..." conversation). This is a situation where the phrase "technical debt" is a useful metaphor that has crossed the chasm to non-technical business leaders, and can be useful (when used judiciously of course).
It actually undermines the usefulness of the metaphor if you try to pedantically uphold the distinction that tech debt is always intentional, because non-technical stakeholders will wonder why engineering would intentionally put us in this situation. I understand we all get to have our techie pet peeves (hacker != black hat), but this is really not a semantic battle I would fight if I'm dealing with anyone non-technical.
Calling it intentional makes it sound reasonable, but the thinking could be "I ain't gonna be around when it breaks".
Yes, we evolved to have people problems.
If however, we were more technical about things during the entirety of evolution, we would exclusively have technical problems now.
So maybe it is good to start taking the technical angle.
Reading the article, I'll note the author has chosen to format hyperlinks with dark grey font on a black background.
It comes as no surprise that a worker unit who makes this conscious decision might have problems interfacing with a Homo sapiens unit.
It’s the eternal cycle: all social problems really are tech problems in disguise; so it’s unfortunate that all tech problems are social problems in disguise. ;)
Which is why when arguing that technology XYZ succeeded, or failed, one needs to look into the larger picture of the human side regarding the related outcome in the market adoption.
Case in point - PyTorch vs Tensorflow. The Pytorch team and Soumith in particular was everywhere. You could ask about it in the forums, Twitter, freaking reddit and there would be an answer.
Well technical debt is not really a technical problem, it’s a choice.
Someone at some point said: ok we’re going to duplicate code, we’ll have a windows version and a Linux version, and yes it’ll be painful - for a while - but at this stage, it is the better option.
At some point getting shit done might be more important than getting it right.
Whether that is smart or not is a people problem.
Working on large legacy codebase is extremely annoying indeed, but sooner or later, in everyone’s career one has to make those sort of tradeoffs, and when that day comes maybe you’ll forgive those who came before you.
Edit: I want to add this:
Also those tradeoffs are often required because of business problems. It’s difficult to see, 10 years down the road, how shitty the business may have been when those decisions were made. And perhaps, it’s some of those business-driven decisions - like rushing the product out the door no matter what - that kept the company afloat and made it so that you have a job (albeit to fix the mess) today.
And people problems are almost invariably managent failures
I learn this more and more as my inferiority complex when it comes to code crumbles through the help of AI.
..and most people problems are communication problems.
Calling them 'people problem' is a convenient catch-all that lacks enough nuance to be a useful statement. What constitutes good communication? Are there cross purposes?
> Non-technical people do not intuitively understand the level of effort required or the need for tech debt cleanup; it must be communicated effectively by engineering - in both initial estimates & project updates. Unless leadership has an engineering background, the value of the technical debt work likely needs to be quantified and shown as business value.
The engineer will typically say that the communication needed is technical, but in fact the language that leadership works with is usually non-technical, so the translation into this field is essential. We do not need more engineers, we need engineer who know how to translate the details.
I realise that, here on HN, most will probably take the side of the rational technologist, but this is a self-validating cycle that can identify the issue, but cannot solve it.
IMO, we need more generalists that can speak both languages. I have worked hard to try and be that person, but it turns out that almost no-one wants to hire this cross-discipline communicator, so there's a good chance that I'm wrong about all of this.
Incidentally, in Adlerian psychology; all problems are considered people problems.
The tech debt question from _def is interesting. In my experience quantifying it actually misses the point.
The real cost isn't the time lost - it's decision avoidance. Teams stop touching certain modules. New features get built around the problem instead of through it. You end up with architectural scar tissue that shapes every future decision.
I've seen this play out where a 2-week refactor that everyone knows needs to happen gets deferred for years because nobody can attach a dollar figure to "we're scared to change this code." Meanwhile every sprint planning becomes a creative exercise in routing around the scary parts.
The tell is when your estimates have a silent "...assuming we don't have to touch X" attached to them.
This is an excellent point. I've also seen scenarios in which the architectural scar is being defended vehemently by an engineer still at the company. In my experience it is someone respected, who is overall a highly competent engineer, and the rest of engineering ends up working around the scar.
Thanks for reading!
This article resonates strongly. I am consulting right now to a group that has enormous struggles technically, but they are all self-inflicted wounds that come down to people and process.
Management claims to want to understand and fix the problem, and their "fixes" reveal the real problems. Fix 1 - schedule a lot of group meetings for twice a week. After week 1, management drops off and fails to show up anymore for most of them. The meetings go off track. The answer? More meetings!
We now have that meeting daily. And have even less attendance.
Fix 2 - we don't know what people are doing, let's create dashboards. A slapdash, highly incorrect and problematic dashboard is created. It doesn't matter, because none of the managers ever checks the dashboard. The big boss hears we are still behind, and commandeers a random product person to be his admin assistant and has her maintain several spreadsheets in semi-secret tracking everyone's progress.
This semi-secret spreadsheet becomes non-secret and people find a million and one problems with it (not surprising as the commandeered admin assistant nee product person was pulling the data from all sorts of random areas with little direction with little coordination with others). We then have the spreadsheet war of various managers having their own spreadsheets.
Fix 3 - we are going to have The Source of Truth for product intake and ongoing development, with a number of characteristics (and these are generally not terrible characteristics). These are handed off to a couple of junior people with no experience to implemented with zero feedback. The net result is we still don't have a Source of Truth, but more of an xkcd situation that now we have 4 or 5 sources of truth strung together with scripts, duct tape, bandaids and prayer.
This continues on and on over years. Ideas are put forth, some good, some bad, some indifferent, but none of them matter because the leaders lack the ability to followup or demonstrate even basic understanding of what our group actually does.
It is truly soul crushing, but in this jobs environment, what are you going to do?
I can write a similar article that: most people problems are technical problems.
This article hits on a pet peeve of mine.
Many companies and individuals can benefit from better processes, communication skills, and training.
And also people who proclaim "Most technical problems are people problems" and "It's not what you know, it's who you know" are disproportionately those who are attempting to influence others that "My skillset is more valuable than your skillset." The people who believe the opposite are heads-down building.
The truth is that nearly all problems are multifactorial and involve long chains of causality. They can be patched at multiple points.
And so while there are standard stories about "If you do the 5 Why's and trace back causality, the issue becomes a deeper human problem," you can nearly always do something else and find an alternative technical solution.
The standard story goes: "This thing failed because this this other thing crashed, because this thing was misconfigured, because the deployment script was run incorrectly, because no-one trained Bob how to use it." See, the human problem is the deepest one, right?
But you can find an alternate technical fix: why was it possible to run the deployment script incorrectly?
Or you can ping-pong it back into a technical problem: he wasn't trained because everyone is stressed with no time because things keep breaking because of bad architecture and no CI. So actually the technical problem is deepest.
But no, because that only happened because the CEO hired the wrong CTO because he didn't know anyone who could evaluate it properly....
...which only happened because they didn't use <startup that helps you evaluate engineers> (technical problem)
...which only happened because said startup didn't have good enough marketing (human problem)
...which only happened because they were too slow to build from their own tech debt and didn't have the money (technical problem...)
And so on. Ping, pong.
The article says: we had too much tech debt because humans weren't trained enough.
One can also say: we had too much tech debt because we didn't have good enough linters and clone detectors to keep out the common problems, and also we had made some poor technical choices that required hiring a much larger team to begin with.
If you have a pet problem, you can always convince yourself that it's responsible for all woes. That just keeps you from seeing the holistic view and finding the best solution.
No doubt the author was richly rewarded for such monumental effort and sleepless nights.
I have been a part of a team that actually managed to significantly reduce critical tech debt in its system, to the point of background radiation. I can speculate on what I think were key contributing factors (some of which are just productivity improvements, which meant we had more bandwidth for tech debt):
* The team used a monorepo for (nearly) all its code. The upshots of this include the ability to enforce contracts between services all in one commit, the ability to make and review cross-cutting changes all in one PR, the increased flexibility in making large-scale architecture changes, and an easier time making automations and tools which work across the system.
* We used Go, which turned out to be a really excellent fit for working within a monorepo and a large-ish codebase. Also, having the Go philosophy to lean back on in a lot of code decisions, which favors a plain and clear style, worked out well (IMO). And its great for making CLI tools, especially ones which need to concurrently chew through a big data dump.
* Our team was responsible for integrations, and we took as a first principle that synchronous commands to our API would be the rare exception. Being async-first allowed us to cater for a lot of load by spreading it out over time, rather than scaling up instances (and dealing with synchronization/timing/load explosion issues).
* We converted the bulk of our microservices into a stateless monolith. Our scalability did not suffer much, because the final Go container is still just a couple MB, and we can still easily and cheaply scale instances up when we need. But being able to just make and call a function in a domain, rather than making an api and calling another service (and dealing with issues thereof), is so much easier.
* Our team was small - for most of when I was involved, it consisted of 3 developers. Its pretty easy to talk about code stuff and make decisions if you only have to discuss it with 2 other people.
* All of us developers were open to differing ideas, and generally speaking the person who cared the most about something could go and try it. If it didn't work, there would be no love lost in replacing it later.
* We had a relatively simple architecture that was enforced generally but not stringently. What I mean by that is that issues could be identified in code review, but the issue would be a suggestion and not a blocker. Either the person changes it and its fine, or they don't, in which case you could go and change it later if you still really cared about it.
* We benefited from having some early high-impact wins in terms of productivity improvements, and we used a lot of the spare sprint time to tackle ongoing tech debt, rather than accelerate feature work (but not totally, the business gets some wins too).
* Big tech debt endeavors were discussed and planned in advance with the whole team, and we made dilligent little chips at these problems for months. Once an issue was chipped away enough to not be painful anymore, then it didn't get worked on (getting microservices into the monolith, for example, died down as an issue once we refactored most of them).
* Tech debt items were prioritized by a ranked vote made by everyone, using a tool I built: https://github.com/liampulles/go-condorcet. This did well to ensure that everyone got the opportunity to have something they cared about, get tackled. Often times our votes were very similar, which means we avoided needless arguments when we actually agreed, and recognized a common understanding. I think this contributed to continued engagement from the team on the whole enterprise.
* Our tech stack was boring and reliable, which was basically Postgres, Redis, and NATS. Though NATS did present a few issues in getting the config right (and indeed, its the least boring piece). We also used Kubernetes, which is far from boring, but we benefited from having a few people who really understood it well.
* We built a release tool CLI, and built reasonably good general error alerting for our system (based on logs mostly, but with some sentry and infra alerts as well), that made releasing things become easy. This generally increased productivity, but also meant that more releases were small releases, and were easier to revert if there were issues.
* We had a fantastic PM, who really partnered with us on the enterprise and worked hard to make our project actually Agile, even though the rest of the business was not technical.
If that's not obvious to you pray you're not over of them...
But in seriousness it's management failure to build up debt like that. Either self management, middle management or out of touch management. There's a reason that good managers are needed. And unfortunately most management is dealing with people and/or real-world, not a fixed in stone RFC or list of vendor requirements from legal.
CodingHorror did it 18 years ago. https://blog.codinghorror.com/no-matter-what-they-tell-you-i...
And, following the links... apparently Gerald Weinberg in 1985. There is nothing new under the sun, only endless repackagings. :)
> the perception that your team is getting a lot done is just as important as getting a lot done.
This might be true. But I hate it. I think I should quit software engineering.
PEBCAK
Post hits the nail on the head. Even the best engineering solutions that closely align to organizational goals will be torpedoed by people at the end of the day, often to preserve their own political power rather than improve the organization or their own working lives.
This is why I laugh when I hear someone say tech is a meritocracy. It is if you consider manipulation, exploitation, subterfuge, sabotage, and backstabbing to be of merit; otherwise, there is no meritocracy out here in the real world, not so long as any given individual of power can destroy your career or livelihood over hurt feelings.
As much as I’d love everything to be a technical problem to solve, that’s just not reality at the moment. We gotta listen to people beyond our silos and find a way to get them to our side in things if we want to progress forward on something. I’m doing that right now in a company stuck firmly in the 1990s, and it sucks.
Reminds me of the quote attributed to Stalin:
"Death solves all problems, no man, no problem."
"Most problems resulting from things people do are people problems."
I mean yes, if you waste time on worked that does not bring value, people tend to get cranky. If you then take longer than you said, it's not a mood enhancer.
That's not a people problem though. That's failure to recognize that a company pays its employees money to make more money, not to have a pretty code base.
Yes, that means communicating the value, but that's not a people problem. That's a skills issue.
"anyone above senior engineer level needs to know how to collaborate cross-functionally"
If you can't collaborate xfn and deal with other people in general, you are not a senior engineer, despite the title inflation.
Conway’s Law yet again!
People are not problems. This is sociopath talk. This is why they want to replace you with AI, they see you as the problem.
That's not what the article was about. It's about people failing to communicate.
To me that is not a problem, it is the reality of stuffing people together who have no other bond than it is their place of work. The problem is the system, not the people.
If you think your only bond to others you work with is your place of employment, you're right.