HN Reader

Who divides a pizza into 4 slices? A regular pizza is 8 slices, 6 if its actually a smaller pizza. 4 slices is mental.

> In most teams, coding - reading, writing, and debugging code - used to be the part that took engineers the most time, but that is no longer the bottleneck.

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.

100% agree with the org shift, but I think of things differently. Specialists are important for architectural insight and domain expertise, but are also the byproduct of codebases growing past a certain size.

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 think a corollary to this is that any pizza is a personal pizza if you believe hard enough.

> Product and design are the new bottleneck

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.

> The ideal team size now appears to be 2-3 engineers per project

That's pretty much always been true for greenfield that doesn't require large swaths of boilerplate (e.g. integrations)

> Okay, so what are product engineers? They are software engineers empowered to handle some responsibilities of PMs and Designers, balancing the roles.

> Product engineers assume traditional PM roles, including owning the roadmap, engaging with users, analyzing data, framing opportunities, and determining what to build. However, they do not replace a PM. The PM still provides context but is no longer the main driver of implementation.

How is this different from a "lead"?

If I'm working late and the "compensation" is free pizza, then I better be getting a whole pizza to myself.

The prediction that there will be greater demand for specialist frontend and backend engineers is the one that surprises me. How do folks think about it? I've been assuming the opposite - that demand for specialists will decline because expectations around what a single person should be able to do will grow.

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.

I see the argument for saying in the future we will be at this place, but this is stated as though it's something that has already happened. It is stated as a simple fact that the time to produce a feature has gone down by orders of magnitude. I have not found this to be true, even if I do give honest tries to the process of coding with AI tools. I'm not a skeptic of AI coding tools, I'm actually one of the persons at my workplace that has best adopted it into their workflows. But this is not realistic.

>The Theory of Constraints states that every system has a bottleneck, since without one, it would operate infinitely fast, which is impossible.

If we believe the AI-influenced system will be faster, more prolific and more experimental (cheaper experiments), then it seems human attention and the rate at which humans can change (individually, processes, tools, teams, etc) becomes the bottleneck.

In that system, the designer and PM functions become more important in addressing that bottleneck - in producing solutions to best overcome those bottlenecks?

I know one team, consists of me only :)

From my team's PoV, I reject the premise. The non-eng people can scale their ambitions and asks even faster than AI has accelerated the engineers' work. In fact, they always have a bunch of stuff that ends up below the line, they always would have wanted to go bigger and faster.

Nothing worse than being famished and getting one measly slice of pizza.

Old idea: 1-2 pizza teams (Bezos, 2002)

New idea: 1-2 pizza companies

i'm betting on the "personal pan pizza team" -> won't be long until we have a 1-person $1B company

I'd be a lot more hesitant now if brin, gates or bezos invited me to a pizza party.

I can eat half a pizza pretty easily.

When was product and design never the bottleneck?

I read the whole thing somewhat critically, but at the end it became clear that the core issue I had with this post were explained in a caveat at the end: the author assumes that AI capabilities won’t improve much beyond the current state of the art.

If you replace this assumption with “we’re going to see the same magnitude improvement in the next six months that we saw in the last six months” then the post is already outdated. You can’t hire new people fast enough to effectuate this strategy before you’ll have to change course.

Instead, I’d propose allowing a bit more anarchy in your teams, letting people know that it’s OK to take the initiative, even if it means stepping on each others toes. Management should be clear that critical risks need to be mitigated (eg no security vulns, no prod outages) and be strict about those (to the point where you can say ‘yolo pushing a prod outage will affect your bonus and be added to your HR record’), but otherwise let people—anyone—code.

So one person? Or am I just fat?

>We will probably see fewer full-stack engineer openings and more roles for back-end and front-end engineers. This doesn't mean they will do only one or the other, but they will be expected to be an expert in one area.

Good. Fullstack roles are like giving away free options contracts away to businesses when they were only buying some stock. Sure, you don't work twice as much as fullstack and shouldn't get twice the pay, but the flexibility should have a price.

When fullstack engineers are making just as much as front-end/backend only engineers, they are giving the options away for free. Engineers simply didn't stand up for themselves to assert their worth in these positions, which led companies to prioritize hiring them over specialists. Any decrease in fullstack positions will help our compensation.

“My post assumes that AI won't improve much beyond its current state, which seems like a safe prediction.”

Say what?

"Product and design are the new bottlenecks"

Yup, so far the LLMs just haven't been as great at product and design as us. But they'll get there.

> In most teams, coding - reading, writing, and debugging code - used to be the part that took engineers the most time, but that is no longer the bottleneck.

This is just a blatant lie lmao, this is the core tenant that all these AI takes rely on and it is just flat out not true.

even this is an intermediary stage

as elon musk said, the next phase is 100% AI run companies, any sort of a human in a loop, even if in a minimal role, will collapse the productivity