Hacker News Reader

Comment by vjvjvjvjghv | Hacker News Reader

With all the changes coming up, I am happy that I am retiring soon. Since I started in the 90s, SW dev has become more and more tightly controlled and feels more like an assembly line. When I started, you could work for weeks and months without much interruption. You had plenty of time for experimentation and creativity. Now everything is ticked based and you constantly have to report status and justify what you are doing. I am sure there will always be devs who are doing interesting work but I feel these opportunities will be less and less.

In a way it's only fair. Automation has made a lot of jobs obsolete or miserable. Software devs are a big contributor to automation so we shouldn't be surprised that we are finally managing to automate our own jobs away,

View on HN

> Since I started in the 90s, SW dev has become more and more tightly controlled and feels more like an assembly line. When I started, you could work for weeks and months without much interruption. You had plenty of time for experimentation and creativity. Now everything is ticked based and you constantly have to report status and justify what you are doing

Yeah the consistent "reporting" of "status" on "stand-ups" where you say some filler to get someone incapable of understanding what it is that you're doing off your back for 24 more hours has consistently been one of the most useless and unpleasant parts of the job.

I tried, but I couldn't get a job as a web dev in the 90s because nobody in my area knew what the web was, I'm not sure anyone in my country did.

> you say some filler to get someone incapable of understanding what it is that you're doing off your back for 24 more hours has consistently been one of the most useless and unpleasant parts of the job

This sucks for the 50% or so who are like you, but there's another 50% who won't really get much done otherwise, either because they don't know what to do and aren't self-motivated or capable enough to figure it out (common) or because they're actively cheating you and barely working (less common)

Just if there were a way to filter people at hiring and perhaps some way to choose to not employ them after doing so...

> there's another 50% who won't really get much done otherwise, either because they don't know what to do and aren't self-motivated or capable enough to figure it out (common) or because they're actively cheating you and barely working (less common)

Idk I barely ever work with people who are like this, and if people become like this, it's usually obvious to everyone that it's happened and they get a talking to in the office then get shown the door

I assume you are in a country with fire-at-will policies. In Germany you have a job security, you can't just fire people without a reason. The difficulty is actually proving their incompetence or unwillingness to work. Thus in my experience (working a self-employed contractor in Germany) this group is far larger than 50%. Also one of my reasons why no good software comes out of germany (and this includes SAP, as long as you show me a single end-user that is happy with working with SAP software).

The ability to deliver a 30 second summary in a daily standup has very little to do with real productivity.

Why is incapability to make progress at work tasks not a valid reason for job dismissal in Germany? Unless I am misunderstanding something

You have to prove it is the employees fault by intentionally not completing the task. Incompetence or incapability is not the employees fault, because well, you hired them and judged their ability - probably due to their education (it is a little more complex than that of course). As a concrete example, if you have a CS degree from the 80s and job as a COBOL programer and your employer decides to assign you to a new team doing react+js, the employee is still formally qualified. You couldn't fire him for incompetence, just because a 22 year old bootcamp graduate delivers 10x the results.

Yes I work in the US but my company has extreme time wasting practices designed to have engineers explain every thing they do and why it's worth it. I never found this helpful and find it causes more problems than it solves.

Incompetent workers migrating to the US is a big issue.

Those people should not have been hired, or should have been let go at 6 months when that became obvious. The real solution to this problem doesn't fit with most management methodology though.

It only makes sense to fire someone who needs to be nudged into getting their job done if you can find a replacement at a similar cost who doesn’t.

1+1 is often less than 1.

The mediocre unmotivated person is dragging down the other, killing their motivation. You'd be better off without them even if you couldn't replace them.

>> Yeah the consistent "reporting" of "status" on "stand-ups" where you say some filler to get someone incapable of understanding what it is that you're doing off your back

In my experience it is human nature to think you are doing something that people around you can't or don't understand. The graveyard is full of irreplaceable people is an old saying. Sometimes the people you report to are morons, but if you consistently report to a moron its time for introspection. There's more that you can do than just suffer that. One place to start is to have some charity for the people you work with.

> graveyard is full of irreplaceable people

I am not special and make no claims of it; I am entirely replaceable and I'd make no claims to the contrary.

This has nothing to do with me or anyone like me, and everything to do with the "adult daycare" style of project managers.

I'm tired of re-iterating to non-technical project managers that status of tickets, why things are "blocked" or why the ask isn't feasible given constraints, over and over again. Time is a flat-circle.

If they understood the problem scope better, such questions would not arise. I know this from experience.

The majority of them are completely stateless and I'll repeat things daily for weeks on end, explaining the same things over and over again, while they make 0 effort to "unblock" issues.

I've had one good project manager in my career that advocated for his technical staff and understood the both the project and business deeply; he was invaluable and a pleasure to work with.

I've had many many others that served no tangible purpose whatsoever.

My frustration is ostensibly there is a purpose for these jobs beyond employing people with the role of "attending meetings"; I've rarely seen it.

Your username is apt, because working with you sounds like encountering the Crawling Chaos Himself, an eldritch being of pure condescension and disdain who unknowingly makes everybody else's lives miserable because they fundamentally do not respect anybody else except themself. Best of luck to you.

Project Manager here. I wish software were an industry where my job was not needed! Where the software team could just directly tell the boss: "It will be done in 3 months. Trust us, bro!" and they go off to do work without a single status report or a single meeting, and come back exactly 3 months later with a finished, tested and working product, ready for distribution! God that would be so great. I could just chill out, tell my boss and boss's boss to chill out, that the software team's got this, with 100% confidence that it was true. Or, I could go find some more useful career!

But it's never true. Team A depends on Team B, who is busy with work for Team C, and none of these teams are talking to each other because they're too busy writing code. Team D just lost two people and can't make the date that they promised, which sets Teams E and F back a few months unless we can figure it out. Or they're behind because they up and decided to do a big refactoring in the middle of the project without telling anyone. Or people just estimated poorly, like orders-of-magnitude poorly, and while the marketing team is ready, and the trade shows are scheduled, and the factory is ramping the device that the software should be flashed on, but the software won't be ready for another three months.

I empathize with engineers since I was once one, and can understand why some of them see us as adversarial. We tend to interact with them in places that Software Engineers hate, like in meetings and standups and via "update" E-mail blasts. Or we're sending them JIRA tickets which they also hate. I do my best to shield my teams from these things that I know they don't like, but sometimes they have to happen.

I also started in the 1990’s and agree the evolution has been as you describe it. It does highly depend on where you work, but the tightly managed JIRA-driven development seems awfully popular.

But I fall short of declaring the 1990s or 2000s or 2010s were the glory days and now things suck. I think part of it is nostalgia bias. I can think of a job I spent 4 years and list all the good parts of the experience. But I suspect I’m forgetting over a lot of mediocre or negative stuff.

At any rate I still like the work today. There are still generally hard challenges that you can overcome, people that depend on you, new technologies to learn about. Generically good stuff.

Another datapoint is working earlier eras sound bad to me: punchcards, assembly, COBOL, FORTRAN. Yes I suspect those people had a blast.

Ex-cobol guy here, the work was a blast! I was working on the Lawson erp for a non-profit, mostly customizing the software for their specific use case. I loved it because the tools were crazy, the language limited, and the system itself was high value to the org. Debugging took forever but the fixes were often really small changes. I often had to go into the database (oracle) and clean up the data by hand. Such fun!

I crave novelty and have a love for bad technology. I was an early nodejs adopter and loved es4 but newer versions of the language is too easy to use lol!

Thanks for pointing out JIRA. I think the problem comes from needing to keep the codebase running next month while trying to up scalars / numbers, not thinking years ahead or how to improve both inside culture and outside image of a company which are more complex structures with lots of little metrics and interdependent components than a win/loss output or an issue tracker that ignores the fact issues solved != issues prevented.

I guess these strategies boil down to having some MBA on top or an engineer that has no board of MBAs to bow down to. I strive to stay with private owned companies for this reason but ofc these are less loud on the internet, so you can easily miss them while jobhunting.

Now everything is ticked based and you constantly have to report status and justify what you are doing.

The weird thing about this is, many developers wanted this. They wanted the theater of Agile, JIRA tickets, points etc.

I'm in the same boat yet still need to squeeze out another 10 years or so but personally working om multiple-side projects so I can get out of this boring, mundane shit.

I think what you are describing is the difference between being among the people to engineer the first car to being in the factory trying to make the 100 millionth car as cheaply as possible. Forty years ago people mostly learned to program because they were interested in it. People starting software / tech companies were taking a chance on something most didn't understand. That self selected for a type. Now its the most common major in school. I am sure its possible to recreate what you felt in the '90s but probably in a different field or a subset of this one.

It’s less automating the job of the engineer away, and replacing management with a panopticon AI

Knowing Amazons backends this is just their technical debt creeping up. Coders do repetetive work there because extending from their architecture means lots of code simply to keep the machine running. I would be surprised if they did not assign ASIN (which come from the need to keep ISBN compatibility everywhere) to not only Apps but other virtual goods lol.

From my integrations pov Ebay was ahead of their time with their data structure and pushed for deprecation fast to not keep the debt. Amazon ooth only looks more modern through acquiring new market fields instantly followed by throwing a lot of money to facade up the mess. Every contact like key account managers there were usually pushed for numbers, this has nothing to do with coders being coders.

Bosses always look for ways to instantly measure coders output which is just short-sighted way of thinking. My coworkers were measured by lines of code obviously. I wonder how you measure great engineering.

So no, this has not changed, you can still work uninterrupted on stuff for months or years if you want and skip these places, maybe even proved over your career that previous designs are stable for years to come.

From what I've seen, devs though that COVID = full remote forever. It's no wonder there's more control now. So it started before AI IMO.

The plague of the two-week sprint.

Reply on news.ycombinator.com