Hacker News Reader

> I partly blame Hollywood and their incessant humiliation of software/IT people, while creating endless leading roles for doctors and lawyers, effortlessly weaving their complicated terminologies into fascinating storylines, which is aparently not possible to do for us?

Doctors and lawyers deal with people and everyday problems that are easy to turn into a interesting story. I don't see many contract lawyers or radiologists as protagonists - it's ER docs and criminal law.

Software development is about rigorously talking to a computer all day, either solving mundane solved tasks in a new application, or problems that you can't even grasp without a technical background. I'm a developer who started programming as a teen over 20 years ago for fun - and I'm bored out of my mind with most of the work - I don't even try to talk about it to non-developers because I know it's about as interesting as accounting, more people would get useful info out of their stories.

Bugs can make great stories. But only for a niche audience. Not Hollywood.

accounting, expecially tax optimization is really interesting/fun, but maybe its just in my bubble in a high tax country where most of the middle class needs tax optmization to live above the poverty line

I could buy this argument. Had I been a junior during the agile era, I'm not sure I would have developed as fast or as far as I have.

The most agile pilled company I worked for just treated juniors & seniors as interchangeable cogs, except seniors should be able to clear more points per sprint. Active discouragement from thinking outside the scope of your ticket, keep your head down and mouth shut.

When I was starting out a bit more than a decade ago, I was on an agile/scrum software team in a hardware company. The team was fine but I found the process painful. I ejected as soon as a new director realized he could do algebra with the story points and began plotting stories quarters out. I've never been on a scrum team since and am happier for it. As a manager now, I would push back on scrum in almost every situation (and have).

The problem with "agile" is that everybody claims to do it. Companies with a healthy environment cram their procedures into agile-derived names, and keep the healthy environment, while unhealthy ones also cram their procedures into agile-derived names, and use their universality as an excuse to never improve.

I think scrum is irremediable, but even then, some places only practice it pro-forma: divide the work into tickets at the beginning of the sprint, rewrite the tickets into what they did at the end, and go home happy.

> juniors & seniors as interchangeable cogs

welcome to the car factory

This doesn’t mirror my experience at all. Where I worked agile meant removing unnecessary processes as well as trusting people over tools. As a junior I was given a lot of flexibility and probably too little oversight. I was mostly given a high level task, no deadline, and had to together with others find ways to make the tasks smaller.

In big tech lots of managers are highly technical all the way up.

But there's two problems: they can't get into the weeds, and they also are subject to the perverse incentive of being rewarded for generating complexity.

Some people fight it, sure, but those who fight it are less likely to be promoted. You don't get rewarded for having less staff under you or eliminating your own role.

The perceived misery you describe I feel is self-inflicted. Many devs "below" me have become entirely disconnected from customer needs, instead only focusing on "interesting" dev problems.

Why do developers only work on ticket-sized portions of the actual requirements? To put it succinctly: because they are simply too dumb. They cannot wrap their heads around it. They cannot grasp it.

Do I sound frustrated? I am. It is inscrutable.

Sorry.

Problems surrounding computing education do compound these frustrations, and I sympathize.

Having worked for larger organizations (whatever FAANG calls itself these days, I can't keep track), as well as academia and independent education, I've seen both halves of the "production line" for newcomers to computing.

Something has to change in how we bring individuals into our field. I have some ideas based on my experiences, but you're not in the wrong for feeling frustrated about this. It is the state of things, and many companies are not equipped to handle it, because it's unexplored territory.

I think categorizing it as "Too dumb" is also doing disservice to many developers who are stuck in feature factories. After a while you realize business is happy with status quo so do your Jira tickets, take your paycheck and go home. My puny stock options are extremely unlikely to be impacted by my work output.

My boss doesn't care about Tech Debt. Get this ticket done, get it done quick and move on. He figures he will be long gone before tech debt racks up to point he would get in trouble for it. Hell, I'm not sure his higher ups even realize the tech debt problem so fact if he is here for 4 years, they wouldn't realize what was cause of the tech debt.

Though my employer certainly could be categorized as a feature factory (individual software development), we kind of sell the opposite: Sustainable development producing software which can be changed easily. There's only direct monetary compensation. Hierarchies are flat. Like, too flat.

I understand many do not have the energy to fight the status quo and some may not have the… eloquence to do so. I have worked very hard for many years to end up where I am. If others don't, I expect them to at least accept where they remain. Because they don't do "don't care". They are effectively sabotaging projects.

They certainly aren't unintelligent. They still act pretty dumb. Again, I must apologize for my polemics.

Problem is, generally only places not doing this are FAANG and we all can't work there. I've interviewed at two FAANG companies in my field (Ops Type) and went ok but didn't get hired. So apparently, I'm not good enough for FAANG so far. Also, they are losing their luster as well.

Now, whatever. It's a job that pays well. I'm making rich people richer but I'm not sure what I'm supposed to do differently. MBAs continue to strip mine everything and my country upcoming elections are between two people we should be saying "Sure grandpa" while they tell us stories in their nursing home.

If that makes me dumb, I'll take the label I guess. I try not to be but when I'm having to explain to Dev for 5th time to stop doing appsettings.json, I realize that my tilting at windmills isn't going to fix anything.

Also, this is a feature factory: https://www.productplan.com/glossary/feature-factory/

> Why do developers only work on ticket-sized portions of the actual requirements? To put it succinctly: because they are simply too dumb. They cannot wrap their heads around it. They cannot grasp it.

I think the reason is entirely different: ticket-sized portions of requirements are the only thing that one can hope to estimate in any useful fashion. Business side needs estimates, so they create pressure to split work into pieces they know how to handle.

Put another way, it's not that developers are "too dumb" to wrap their head around actual requirements. They're not allowed to. The business prefers devs to consistently crank out small improvements, keep "velocity", even though it leads to "organically" designed systems - i.e. complex, full of weird edge cases, and smelling of decay. The alternative would be to let the dev talk, design, experiment, take the project holistically - but that also means the work becomes impossible to estimate more precisely than "sometimes next year, maybe", which modern businesses can't stand.

I very much dispute the claim that devs are not allowed to think big. It’s just that they take the easy way out. After all, others are taking care of the visual design, requirements engineering, reporting, controlling and whatnot, right?

It’s fine, really. But then please don’t try to overstep the role you assumed.

In my opinion, it is critical you do both: Know the big picture, the vision, build a technological vision based on that. And then you must work on this, in bite-sized pieces. From my experience, in all but the smallest projects, not working iteratively (“experiment”, as you call it) is pretty much a guarantee to build the wrong thing from a user/customer requirement standpoint. Not having the technological vision is also guaranteed to result in a steaming pile of tech debt.

I don’t see a problem with providing reasonably accurate long-time estimates either. Build your technological vision and you’ll know. Everybody knows and will understand that substantial requirement changes or newly discovered requirements will change the timeline.

Counterpoint: Boeing.