[throwawayb299]

20 years and counting. Maybe you're the person at the middle point of that bell curve meme, while I'm the one to the right?

I used to drink the kool aid too: writing code is the last step, the shortest and the easiest one...

Over time I came to believe, this is what people in dysfunctional organizations say to justify endless political back and forth over painfully trivial matters and constant turf wars.

Anyone speaking up about it is of course getting shamed as inexperienced or incompetent. It's no surprise, people who are holding these bullshit jobs have their livelihood on the line if the bullshit gets called out.

By the way, I'm not saying there's no need to plan things out at least just a little bit or that communication does not come with a certain overhead. Not 95% though, not even anything close to that. Especially if you aren't breaking any new grounds, which the overwhelming majority of devs aren't. No, a LOB reporting app on microservices is not it. No, another AI-enabled social network on blockchain is not it either.

Coding isn't the shortest step either, go ahead have a look into a serious codebase such as Chromium then come back and tell me with a straight face developing that codebase was the shortest step.

[gigel82]

I have to disagree. I have 25+ years of full time software engineer positions (after a short stint in management I've been back to IC for 15+ years) and it's extremely rare to spend more than 10% of my time coding in any given week.

Things were different when I was doing contract work, and every month brought on a new project that we'd have to quickly spin up. Nowadays I work in mature (legacy) codebases where introducing a new feature requires interacting with undocumented libraries last touched decades ago. I spend 1/2 of my time debugging code, 1/3 in meetings, emails and code reviews/coaching, and the rest in planning and coding.

There's definitely some degree of dysfunctionality in the orgs I worked in, but this has been consistent across 3 employers (bigger companies / FAANGs, not startups though).

[throwawayb299]

Clearly you know what you're talking about and when you break your time down like this it makes way more sense.

A minor point I'd make is you seem to define coding as strictly typing out... well, code. My perspective is that interacting with undocumented libs definitely counts towards coding and debugging might, depending on the context.

Now, if you scroll way up to the comment that kicked off this thread you'll see it lists three kind of activities a software dev's job is made up of and claims that that the first two are supposed to take the overwhelming majority of time and effort.

Let me quote:

> Why am I doing this? Understanding the business problem and value

> What do I need to do? Designing the solution conceptually

> How am I going to do it? Actually writing the code[, debugging, and refining]

>

> That last part is actually the easiest, and if you're spending inordinate amount of time there...

Let's go along with this notion for a moment, if a dev spends 95% of their time on the first and second parts then for every 16 hours they dedicate 51 minutes to actual coding (as in legacy libs spelunking, debugging, and typing out code)

And that's what I call utter bs on.

[bluefirebrand]

> Over time I came to believe, this is what people in dysfunctional organizations say to justify endless political back and forth over painfully trivial matters and constant turf wars

Maybe yes

But I'm really referring to the idea that at some point you should more or less create a solution in a spec, and then code should just be an implementation of the spec

If you are still spending 95% of your time writing code after 20 years as a programmer, then either you are incredible at creating specs in a short period of time, or you are still just doing "I'll start coding and figure it out as I go"

Or worse: "I'll just hack something together without thinking about how it fits overall into the whole"

Writing the code is translating a solution into computer language. Creating the solution is the part that should take majority of your time

[throwawayb299]

> But I'm really referring to the idea that at some point you should more or less create a solution in a spec, and then code should just be an implementation of the spec

This sentence is a little ambiguous, so I might be reading it wrong. But if you're literally referring to the idea of a spec so detailed it's virtually coded in a natural language, then I find this idea baffling. We have a specialized tool for this job - programming languages, which I enjoy quite a bit, btw. Are these somehow beneath a true software engineer, who's supposed to program in English?

Anyway, let's do a bit of napkin math here.

- So, a real Senior Software Engineer spends 95% of their time producing specs.

- Say, coming up with this particular spec took 16 hours, then the time dedicated to implementation works out to approx. 51 minute.

- Assuming their typing speed is 350 characters per minute (nothing to scoff at, especially considering typing is such a minor part of their job.)

- Now, their style guide sets the cutoff for a line of code at 120 chars (they aren't some 80-char cavemen, are they?)

Putting it all together, banging out code non-stop for 51 minutes, they'd end up with O(150) lines of code to show for 16 hours of planning and speccing... I say someone is coasting as if it were the last day of their life. Curious to hear your take!