[HN Gopher] Most technical problems are people problems
___________________________________________________________________
Most technical problems are people problems
Author : mooreds
Score : 282 points
Date : 2025-12-05 13:07 UTC (9 hours ago)
(HTM) web link (blog.joeschrag.com)
(TXT) w3m dump (blog.joeschrag.com)
| zaphar wrote:
| 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.
| amonith wrote:
| 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).
| zaphar wrote:
| 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.
| pixl97 wrote:
| >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.
| zaphar wrote:
| Why does working in one technology prevent you from
| getting a job in another one?
| amonith wrote:
| 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.
| anonu wrote:
| > 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.
| chasd00 wrote:
| 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.
| bsoles wrote:
| > 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.
| 9rx wrote:
| _> 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.
| fogleman wrote:
| Yes, you are describing a "people problem"...
| IAmBroom wrote:
| 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.
| N_Lens wrote:
| 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.
| roxolotl wrote:
| 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.
| quadrifoliate wrote:
| > 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.
| bpt3 wrote:
| 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.
| woodylondon wrote:
| 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.
| Noaidi wrote:
| > 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.
| wccrawford wrote:
| 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.
| zwnow wrote:
| Give us a reason to care. It's that simple.
| bpt3 wrote:
| 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.
| Noaidi wrote:
| 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.
| zwnow wrote:
| 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.
| bpt3 wrote:
| 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.
| youoy wrote:
| 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%?
| bpt3 wrote:
| 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.
| youoy wrote:
| 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.
| nkrisc wrote:
| 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.
| bpt3 wrote:
| 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.
| nkrisc wrote:
| 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.
| bpt3 wrote:
| 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.
| nkrisc wrote:
| That's just another way of saying work harder for same
| pay because the company knows they have you by the balls.
| venturecruelty wrote:
| "Beatings will continue until morale improves."
| zwnow wrote:
| People have a working contract and all you have to do is
| work according to the contract.
| GaryBluto wrote:
| He wasn't asking you to work for free.
| nkrisc wrote:
| I know. But people will worry about dollars first before
| they even think about pride.
| rmah wrote:
| 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.
| zwnow wrote:
| I dont pay my bills from reasons within.
| watwut wrote:
| 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).
| bpt3 wrote:
| 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".
| venturecruelty wrote:
| 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.
| Noaidi wrote:
| 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.
| AnimalMuppet wrote:
| So is it not good for people to care and yet be blocked
| from being able to do good work.
| mrweasel wrote:
| 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.
| hansvm wrote:
| > 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).
| mylifeandtimes wrote:
| >> 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?
| zwnow wrote:
| > 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.
| stronglikedan wrote:
| 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.
| thwarted wrote:
| 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.
| oarsinsync wrote:
| 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.
| venturecruelty wrote:
| "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.
| AbstractH24 wrote:
| > 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.
| wccrawford wrote:
| 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.
| 1718627440 wrote:
| > 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.
| steveBK123 wrote:
| 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.
| jack_tripper wrote:
| _> 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.
| taeric wrote:
| 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?
| FatherOfCurses wrote:
| 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.
| jack_tripper wrote:
| _> 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.
| vladms wrote:
| 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.
| zwnow wrote:
| 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.
| hnthrow0287345 wrote:
| >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
| venturecruelty wrote:
| 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.
| Hendrikto wrote:
| > 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.
| almostgotcaught wrote:
| 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.
| Thorrez wrote:
| 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.
| marcosdumay wrote:
| 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".
| almostgotcaught wrote:
| > 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.
| taeric wrote:
| Flourished, you say?
| bpt3 wrote:
| 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.
| almostgotcaught wrote:
| > 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
| LudwigNagasena wrote:
| Surely Marx would disagree with such assessment and call
| it idealistic and not grounded in material reality?
| kagakuninja wrote:
| 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...
| marcosdumay wrote:
| 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.
| kagakuninja wrote:
| 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.
| markjenkinswpg wrote:
| One comedy that did a good job of depicting programmers
| with no sense of hope circa 1999 was Office Space.
| potato3732842 wrote:
| 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.
| venturecruelty wrote:
| 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.
| LudwigNagasena wrote:
| 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.
| almostgotcaught wrote:
| > 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.
| LudwigNagasena wrote:
| 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.
| almostgotcaught wrote:
| > 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.
| LudwigNagasena wrote:
| > 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, corvee 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.
| JambalayaJimbo wrote:
| 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.
| 9rx wrote:
| _> 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.
| danans wrote:
| > 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.
| 9rx wrote:
| _> 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.
| saghm wrote:
| > 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.
| danans wrote:
| > 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.
| 9rx wrote:
| _> 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.
| NegativeLatency wrote:
| 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.
| 9rx wrote:
| _> 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.
| psunavy03 wrote:
| > 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
| 9rx wrote:
| 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?
| bpt3 wrote:
| > 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.
| 9rx wrote:
| _> 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?
| anonymars wrote:
| 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
| toast0 wrote:
| > 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.
| venturecruelty wrote:
| 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.
| potato3732842 wrote:
| >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.
| taeric wrote:
| 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.
| Miraste wrote:
| 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.
| lupire wrote:
| Comparing a cheap thing to an expensive thing is absurd.
|
| The appropriate comparison is which is better _for the
| same price_
| Miraste wrote:
| 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.
| taeric wrote:
| 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.
| taeric wrote:
| 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.
| yobbo wrote:
| > 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.
| Miraste wrote:
| 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.
| parpfish wrote:
| 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
| Miraste wrote:
| 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.
| chemotaxis wrote:
| 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.
| jama211 wrote:
| 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.
| nitwit005 wrote:
| > 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.
| ThrowawayR2 wrote:
| 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.
| AStrangeMorrow wrote:
| 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.
| insane_dreamer wrote:
| 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.
| graemep wrote:
| > 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.
| willvarfar wrote:
| > 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
| nkrisc wrote:
| > 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.
| throwawaysleep wrote:
| 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.
| ferguess_k wrote:
| 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.
| merrvk wrote:
| People need visas and that's all they care about
| stardude900 wrote:
| You started an excellent discussion with this comment
| jt2190 wrote:
| > 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.
| QuercusMax wrote:
| 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.
| thwarted wrote:
| > _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.
| stronglikedan wrote:
| > 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.
| wiseowise wrote:
| > 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.
| chemotaxis wrote:
| > 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.
| anal_reactor wrote:
| 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.
| thewebguyd wrote:
| > 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.
| agumonkey wrote:
| 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.
| jl6 wrote:
| This is why communication skill is the most important
| differentiator between a senior dev and a junior dev.
| Noaidi wrote:
| People are not problems. This is sociopath talk. This is why they
| want to replace you with AI, they see you as the problem.
| magicmicah85 wrote:
| That's not what the article was about. It's about people
| failing to communicate.
| Noaidi wrote:
| 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.
| magicmicah85 wrote:
| If you think your only bond to others you work with is your
| place of employment, you're right.
| woadwarrior01 wrote:
| Incidentally, in Adlerian psychology; all problems are considered
| people problems.
| jillesvangurp wrote:
| 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.
| bluGill wrote:
| 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.
| dasil003 wrote:
| 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.
| esafak wrote:
| Calling it intentional makes it sound reasonable, but the
| thinking could be "I ain't gonna be around when it breaks".
| SilverBirch wrote:
| 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"
| bluGill wrote:
| 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.
| pixl97 wrote:
| Technical debt also includes descriptions of unintentional
| debt. For example you can 'withdrawal' technical debt from
| ignorance.
| uriegas wrote:
| 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.
| stefan_ wrote:
| 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.
| sigbottle wrote:
| Oh wow, nice catch in the article, jesus.
| philk10 wrote:
| 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
| mooreds wrote:
| Came here to say this. Amazing how timeless his wisdom is.
| jvanderbot wrote:
| Peopleware is an excellent book built on this premise.
|
| https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...
| munchbunny wrote:
| 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.
| ferguess_k wrote:
| 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.
| j_w wrote:
| What does DE mean in this context?
| esafak wrote:
| data engineering
| AgentMatt wrote:
| Presumably Data Engineer.
| ferguess_k wrote:
| data engineering
| chasd00 wrote:
| > 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.
| pragma_x wrote:
| 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...
| munchbunny wrote:
| > 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.
| brador wrote:
| No doubt the author was richly rewarded for such monumental
| effort and sleepless nights.
| AbstractH24 wrote:
| I learn this more and more as my inferiority complex when it
| comes to code crumbles through the help of AI.
| pjmlp wrote:
| 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.
| another_twist wrote:
| 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.
| dvrp wrote:
| Conway's Law yet again!
| deelayman wrote:
| 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.
| another_twist wrote:
| The risk of tech debt is marginal cost of adding features goes
| up as tech debt goes unpaid.
| Scubabear68 wrote:
| 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?
| another_twist wrote:
| 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).
| iterance wrote:
| Thankfully, we do not have to judge a blog post by its ability
| to pass muster in technical interviews. :)
| btreecat wrote:
| 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.
| munchbunny wrote:
| > 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.
| another_twist wrote:
| 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.
| lupire wrote:
| 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.
| whstl wrote:
| 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.
| liampulles wrote:
| 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.
| morshu9001 wrote:
| I know this is a tangent, but graph DB gets overused a lot
| because it's so often a neat-looking idea.
| com wrote:
| And people problems are almost invariably managent failures
| StanislavPetrov wrote:
| PEBCAK
| willguest wrote:
| ..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.
| jeffheard wrote:
| 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.
| _def wrote:
| > Build out what that tech debt is costing the company and the
| risk it creates
|
| How to do that? Genuine question.
| orangebread wrote:
| 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.
| SatvikBeri wrote:
| 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.
| theptip wrote:
| 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.
| nine_k wrote:
| > _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.
| hobs wrote:
| 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!
| disgruntledphd2 wrote:
| 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.
| hnthrow0287345 wrote:
| 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
| atoav wrote:
| 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.
| codyb wrote:
| 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.
| strifey wrote:
| 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.
| jon-wood wrote:
| 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.
| codyb wrote:
| 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.
| arcbyte wrote:
| "Better people" solves a lot! But definitely not everything.
| But a lot!
| vjvjvjvjghv wrote:
| 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.
| tcmart14 wrote:
| 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.
| delusional wrote:
| > 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.
| staplers wrote:
| 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.
| _def wrote:
| > 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.
| pjmorris wrote:
| 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
| veryfancy wrote:
| Saw this post title and immediately thought of Jerry.
| lupire wrote:
| CodingHorror did it 18 years ago.
| https://blog.codinghorror.com/no-matter-what-they-tell-you-i...
| rob_c wrote:
| 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.
| etamponi wrote:
| 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.
| intrasight wrote:
| > 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.
| ChrisMarshallNY wrote:
| 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/
| 2b3a51 wrote:
| _" 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...
| ChrisMarshallNY wrote:
| 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._
| 2b3a51 wrote:
| Telecom Gold! Good for you.
|
| https://en.wikipedia.org/wiki/Telecom_Gold
| ChrisMarshallNY wrote:
| 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.
| FatherOfCurses wrote:
| 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.
| spongebobstoes wrote:
| 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
| kmoser wrote:
| 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.
| pixl97 wrote:
| >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.
| gaigalas wrote:
| 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.
| amelius wrote:
| 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.
| 0xWTF wrote:
| 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.
| stego-tech wrote:
| 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_.
| adsharma wrote:
| 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.
| hermitcrab wrote:
| Reminds me of the quote attributed to Stalin:
|
| "Death solves all problems, no man, no problem."
| sandeepkd wrote:
| 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
| dbacar wrote:
| 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.
| leoc wrote:
| 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. ;)
| jackfranklyn wrote:
| 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.
| liampulles wrote:
| 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.
| danjl wrote:
| There are plenty of actual "technical problems" that have nothing
| whatsoever to do with "technical debt".
| liampulles wrote:
| 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.
| danjl wrote:
| Or, perhaps "Technical Debt Is Really a People Problem".
| jibal wrote:
| "Most problems resulting from things people do are people
| problems."
| jama211 wrote:
| 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.
| xorvoid wrote:
| 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...
| jerhewet wrote:
| 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]
___________________________________________________________________
(page generated 2025-12-05 23:00 UTC)