4 ms·

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

by fuzzy2 2y ago

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.

wryl 2y ago
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.
stackskipton 2y ago
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.
- fuzzy2 2y ago
  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.
  - stackskipton 2y ago
    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/ https://www.productplan.com/glossary/feature-factory/
TeMPOraL 2y ago
> 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.
- fuzzy2 2y ago
  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.

by fuzzy2 2y ago

wryl 2y ago

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.

stackskipton 2y ago

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.

fuzzy2 2y ago
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.
- stackskipton 2y ago
  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/ https://www.productplan.com/glossary/feature-factory/

TeMPOraL 2y ago

> 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.

fuzzy2 2y ago
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.