Most active commenters
  • crazygringo(6)
  • nitwit005(3)

←back to thread

120 points cl42 | 18 comments | | HN request time: 0.523s | source | bottom
Show context
xenotux ◴[] No.45075415[source]
Coding as such is seldom a bottleneck to begin with. How many times have you been in a conversation along the lines of "we have every detail of the product figured out, but we need another month for the coders to finish writing the code"?

The bottlenecks are almost always elsewhere. Design, quality assurance and debugging, art assets, localizations, hiring, performance management, you name it. And to be fair, AI can streamline some of that.

replies(4): >>45075460 #>>45075490 #>>45075564 #>>45075643 #
1. crazygringo ◴[] No.45075490[source]
> How many times...

Literally all the time? Every single month?

I am struggling to understand your perspective. In my existence, the bottleneck is always the coding.

The development team has a backlog that could keep them busy for years. Meanwhile, everyone else -- QA, localization, whatever -- operates at whatever pace the code gets delivered.

Never in my entire life have I been in the situation where the engineering manager said, "well folks, localization is backed up so we've got no more code we need to write. Go home and check in next week to see if we have any work?"

The only exception I can think of might be videogames where the bottleneck is the art and then maybe the testing loop. But gaming isn't representative of software development generally at all.

replies(7): >>45075516 #>>45075531 #>>45075599 #>>45075617 #>>45076502 #>>45081051 #>>45086644 #
2. dietr1ch ◴[] No.45075516[source]
Your "coding team" there isn't actually coding most of the time. Sitting down to type isn't the bottleneck, but the work that needs to happen so you can sit down and type what needs to be typed.
replies(1): >>45075577 #
3. mrbombastic ◴[] No.45075531[source]
I find it is either coding or design but yeah not sure where the perspective of the GP come from, that has not been my experience. I have actually vented with other devs about too many brainstorming meetings, ideas of what to do we are never short on. Maybe where I agree slightly is the devil is in the maintenance, ai can maybe? help with that but i think you will quickly reach a saturation point where you have more than you can manage.
4. crazygringo ◴[] No.45075577[source]
The comparison is with other departments, like QA or localization.

Figuring out libraries, deciding on architectures, researching documentation, that's an integral part of coding.

The topic here is not keystrokes.

5. boredtofears ◴[] No.45075599[source]
A fully curated backlog with complete specifications that is kept up to date with current changes in the product/industry? I've never had the privilege of working in an environment like that.
replies(1): >>45075883 #
6. Syntaf ◴[] No.45075617[source]
I had a period of time at my last job where the product org was so dysfunctional engineers did in fact run out of work.

Initially I didn’t mind it because my team focused on technical debt, but it pretty quickly turned sour. Having to scrape up “work” for the team of 6 engineers each morning to appear productive to management was dreadful

7. crazygringo ◴[] No.45075883[source]
Obviously not every item in the backlog has a full design, for work that might be years out.

But yes, the next few items for the team to work on should always have the necessary specifications to start work. Whether it's UX mocks or a requirements document or whatever. Having that stuff ready to go is a primary job of the PM who manages the backlog.

Obviously the engineering team then has to break it down further into tasks to complete, but that's what engineering is. And you will run into areas that turned out to be underspecified and the PM needs to liaison with other folks to figure out answers, but again that's part and parcel. That's not generally stopping the whole team from work, and teams often work on multiple features at once so even being temporarily blocked on one doesn't keep you from progress on another.

replies(1): >>45076929 #
8. ◴[] No.45076502[source]
9. boredtofears ◴[] No.45076929{3}[source]
I’ve been bottlenecked by that middle part quite often. A design isn’t finished, we’re awaiting user feedback or testing, specs are done but waiting for sign off from required parties, etc..

I’ve never had a shortage of work as an engineer, but that doesn’t mean that work has always been perfectly optimized to business priorities - there’s plenty of other bottlenecks in the process that are not coding.

10. moi2388 ◴[] No.45081051[source]
You have a full backlog with all requirements clear? The edge cases are known? I’m calling bullshit.
11. nitwit005 ◴[] No.45086644[source]
This story feels inconsistent. Where did the backlog come from?

The developers would have to help with the requirements and planning all the code changes. That implies a huge amount of non-coding work was done by the developers.

replies(1): >>45088123 #
12. crazygringo ◴[] No.45088123[source]
Inconsistent? It's just my experience at different companies.

The backlog comes from the PM, as user needs are established.

The requirements come from a mix of PM and UX.

Obviously developers plan how to write the code. That's part of coding. Not part of product requirements.

replies(2): >>45088728 #>>45089430 #
13. nitwit005 ◴[] No.45088728{3}[source]
Exactly as I suggested, you've tossed non-coding activities into the coding category. Planning is not writing code.

Imagine an architect who never writes a line of code. Under your accounting, they're doing coding, because it's the planning for code.

replies(1): >>45095868 #
14. kj4211cash ◴[] No.45089430{3}[source]
I'd hate to work at a place where the backlog comes from the PM and the requirements come from a mix of PM and UX. Do you really think your PMs know that much more than your Engineers, Data Scientists, Ops/Business, etc.? This just sounds like something the type of PMs most of us hate, the type who insist on being the main character, would say.
replies(1): >>45095937 #
15. crazygringo ◴[] No.45095868{4}[source]
You seem to be having a different conversation.

The root comment was about coding vs "design, quality assurance and debugging, art assets, localizations", etc.

Not coding vs planning coding. It's the same way the art department both plans the art and draws it.

replies(2): >>45110134 #>>45110239 #
16. crazygringo ◴[] No.45095937{4}[source]
I'm genuinely confused by your comment.

Yes, PM's are absolutely supposed to know that much more about what the customers need. That's their job. They're constantly talking to customers; engineers are generally doing that only occasionally, if ever. They're not trying to be the "main character", but their entire job is to be the point person for integrating all the stakeholders' needs and making prioritization decisions. It's organizational needs, not ego-driven.

Sometimes products are simple and straightforward enough where you don't really need a dedicated PM, but then the lead engineer often just winds up informally taking on the same responsibility, and at some point there's enough success and complexity that it needs to become a full-time dedicated position.

I'm really curious how you've arrived at the perspective that engineers and data scientists know as much about customer needs as a PM, that they learned via channels outside of the PM? I've certainly never worked anywhere where that was the case.

17. ◴[] No.45110134{5}[source]
18. nitwit005 ◴[] No.45110239{5}[source]
The root conversation began with:

> Coding as such is seldom a bottleneck to begin with. How many times have you been in a conversation along the lines of "we have every detail of the product figured out, but we need another month for the coders to finish writing the code"?

And you quoted "how many times" contradicting it.

Yes, the art department plans the art and draws it, but an AI tool for generating art could only help with the actual drawing. The possible productivity improvement directly relates to the portion spend actually making art.

Your department or job-role style view of things doesn't make sense for this conversation.