Posted by jampa 4 days ago
Do most engineers find this to be true? For me the balance switched within a few years of being a senior (nearly a decade ago). Writing code is easy, negotiating over what code to write takes time.
But I have worked in some areas that its not like that. What we are building is decided pretty quick, but the implementation takes a month of two.
my days are spent in meetings discussion how to implement things or why do it certain ways - when most of that time spend asking inevitably turns into "when can this be ready?"....well if you didnt have me stuck discussing it for the last 6 months it would've been ready yesterday like you wanted.
And by the way, one thing is missing from the OP graph: i now spend maybe 50% less time writing my own code, and 100% more time fixing my juniors PRs and fixing production issues after my reviews miss issues...
Product and design were always the bottleneck. Engineering speed was never the issue, it was the politics and indecision in product that always slowed engineering teams down. I can't count how many prep meetings product had before they presented to their boss what the new font and color looks like. They basically had a team of PMs just running around creating busy work and making decision based on pure whim and personal feeling, without actually looking at any data. And God forbid they ever talk to customers. Ew, who cares about what they have to say.
Engineers like to claim everyone else is their problem, when in fact, it's often the case that engineers are their own problem.
Bottlenecks happen everywhere.
Sometimes there’s valid reasons for addressing technical debt and reworking things to be better in the future… and other times people are just rewriting working code because reasons™.
Encountering the latter can be quite demotivating, especially when it turns to nitpicking over small stuff or keeping releases back for no good reason. Personally, I try to lean away from that and more into the “if it works, it works” camp (as long as you don’t ignore referential integrity and don’t mess up foundational logic).
Depends. It definitely can be. When you get those people who want to spend weeks going back and forth over whether the button should be red or slightly darker red, as if they can somehow figure out the right answer from gut feeling alone, not realizing that in that time they could have tried both and learned from it, all while delivering other things of value on top, engineering has no hope of becoming the bottleneck.
That being said, I've recently made a few light weight apps for myself with Claude and I've easily spent 4x the time hand tuning the UI compared to implementing business logic / core features. Super fun tbh
That's pretty much always been true for greenfield that doesn't require large swaths of boilerplate (e.g. integrations)
One 16" pizza can be a lunch for 2, maybe 3 people. Which, by the way, is a very good size for a team.
It starts with "I know/can handle issues from infra to design" to regroupings of focus, often DevOps / code / design. But companies also might split focus by user concerns, like the "Admin console team" vs. "End user team". That depends on the product and the complexity of the specialist concerns.
I think across the board there is going to be a blurring of management and engineering. We see the value of "product engineers" now but they are starting to eat some of PM's lunch. On the other side, "technical PMs" are more valuable, as they come at things from the other side. The driver for this change is that both are using a shared context to bridge the gap from "business concerns + product requirements" to code.
I'm a frontend specialist developer currently taking some time off to reskill - and trying to decide exactly which direction to go. My thinking was that I would need to lean into design and product - leverage my technical knowledge in building interfaces to be able to inform the product side. Knowing what is easy or hard to build hopefully would speed up the product side.