Comment by sublinear | Hacker News Reader

Comment by sublinear | Hacker News Reader

Parent Full thread

> There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.

I'm not going to bang this drum too much, because it's been done to death for well over a decade, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective. Much of that engineering is in the decisions made outside the codebase, or spread across multiple codebases. If you're looking for the one obviously brilliant line of code to tip your fedora to while sipping your snifter of wine, you're not gonna find it. In fact, "clever" code like that is rightfully and instantly rejected as cowboy code.

By your reasoning, civil engineering isn't "real" engineering like aerospace cuz they don't build things that go really really fast and shoot out fire and stuff. Also, there's like too many responsibilities delegated out. Like, man, I only wanna talk to the guys who put the rockets on the thing. Everyone else are just overpaid slackers that smooth talked their way! They're gonna get replaced by AI! Mark my words!

>, but lines-of-business supported by CRUD apps are rarely simple from an engineering perspective.

You misread my comment as some dig at CRUD LOB enterprise coders. I used to work on enterprise ERP code with 20000+ tables. Yes, I agree it definitely wasn't simple.

Instead, I was responding to a very specific observation the gp made: he saw that both senior and junior devs were interchangeable when randomly assigning the next JIRA ticket.

That can only happen in a situation where the JIRA tickets are similar enough in complexity that the difference in skills between your senior and junior devs are irrelevant when the work is assigned.

Maybe some enterprise software teams can work like that. However, none of the engineering-heavy type of codebases can treat seniors and juniors interchangeably.

All engineers should be spending more time "planning" than "doing".

Even before LLMs, the coding tasks were less than 50% of the time spent on all my Jira boards in the past 15 years. It makes perfect sense that they are assigned based on available capacity. By the time the coding begins, it's already too late to worry about implementation.

You're right that small tasks are trivial enough to be assigned to anyone. That's the point. That's how it feels to work on the "good" projects regardless of complexity. Planning a complex project should result in more tasks, not harder tasks. Your epics and stories can sometimes vary in points, but your tasks should not. A primary goal of the planning phase is figuring out how to keep them as low as you can. The points stop being meaningless when you think this way. They tell you where things are too lumpy. You throw more planning time at those lumps.

If assigning to a senior produces better code, you're not spending enough time planning ahead.

> Instead, I was responding to a very specific observation the gp made: he saw that both senior and junior devs were interchangeable when randomly assigning the next JIRA ticket. That can only happen in a situation where the JIRA tickets are similar enough in complexity that the difference in skills between your senior and junior devs are irrelevant when the work is assigned.

That’s not what I was saying.

I was saying that the perception of management is that the tickets are interchangeable. Not that the tickets are actually interchangeable.

Notice what I said after that. That this usually results in seniors coming in at the end to rescue the project.

Reply on news.ycombinator.com