Hacker News Reader

Comment by sefrost | Hacker News Reader

Only 5% of your time is spent writing code? That sounds like a low estimate for most software engineers I work with.

May I ask if you could estimate how you spend the other 95% of the time?

In no particular order

    - Meetings
    - Reading papers
    - Understanding legacy code
    - Reading internal news
    - Ad hoc chats with coworkers
    - Writing docs
    - Editing configs
    - Thinking about solutions
    - Slacking off
    - Analyzing results
    - Testing code
    - Reviewing PRs
    - Understanding others' ongoing projects

AI can do everything you listed except chats with coworkers and slacking off.

I just don't think you've utilized the most recent versions of codex or claude.

It's definitely theoretically possible, but not there yet. I use cursor, claude (opus 4.7), and several proprietary LLMs/LLM frameworks at my job. The institutional knowledge I have wouldn't fit in the context window, and AIs lack my mental index/intuition of where to look for answers. When my AI makes a PR, I generally have to make some important changes, without which it's solution would be fundamentally broken. AI also cannot be trusted to make the right business tradeoff decisions.

Many things at my software engineering job are like this, which require constantly changing human institutional knowledge that is almost always undocumented, or changing so quickly that it isn't relevant anymore. By the time you decide to automate it, the process changes. Tribal knowledge used to be something I hated seeing senior engineers keeping to themselves, but now it seems like an asset.

    > Slacking off

I laughed when I read this, but there is something to it. I like to say "intellectual relaxation" or take a break. Sometimes getting up from your desk to do some mindless admin task like photocopy a document for HR can free up your mind. If we were line workers at a factory, this would be mandated breaks. Business/Financial newspapers and factory executives love the old quote: "With robots, they never need a break, never need holiday, and can work 24x7." With the advent of agentic LLMs, a tiny fraction of that reality is leaking into the white collar world.

It sounds plausible to me since this is pretty en par with most other engineering disciplines. I’m a civil engineer. My responsibility is ultimately mostly to produce a constructable plan set. I spend far less than 5% of my time drafting or modeling.

The least experienced developer writes the most code. Juniors would be spending whole day in the IDE, typing, testing, typing etc. Senior developers will go to a park for a few hours, think, then come back spent an hour or less typing code that just works or write nothing at all, maybe even delete code. Instead they might update documents, ask clarifications about found edge cases or errors in planning that were not considered.

Since software is in every industry of man, I think you'll need to mention which industry this perspective is coming from. This is definitely NOT the case in certain industries.

Finance, web services, service integration

I don’t know if that’s true for most of us, who simply work in CRUD apps. Maybe I’m in a bubble though.

Commenting on Hacker News?

In all seriousness, communications consumes a lot of time. Meetings, emails, Slack messages, pestering stake holders and other developers...

If you spend 95% of your time on that stuff, you better be working on like critical infrastructure where nothing can go wrong, otherwise you are in an incredibly dysfunctional company.

I agree it would be absurd for it to take 95% of your time. I have, however, seen that it takes a lot more time than one would think.

I did some contracting work for a severely dysfunctional meeting heavy organization and it was about 2 hours of meetings for every hour of real technical work!

Even when it’s not dysfunctional, you spend a lot of time on communication and reading stuff other people wrote (including code). It’s very rare to work in isolation.

I guess it depends on what you feel coding is. To me it's the architecture planning and reading other people code, not just writing code. If we say it's just typing, then 95% is not absurd no

> it depends on what you feel coding is. To me it's the architecture planning and reading other people code, not just writing code

And that would be where we disagree. I don’t read code to look at code. When I’m reading code, I’m looking for the contracts to follow when interacting with a system. It would be nice if it were documented, but more often than not you have to rely on code.

It’s very rare that I plan with a technical mindset. Yes I use the jargon, but it’s all about the business needs. Which again create contracts.

Same with writing code. Code is like English for me. If I don’t have a clear idea on what to write, I stop and do research (or ask someone). But when I do, it’s as straightforward as writing a sentence.

Huh? So you you don't research if something is technically feasible before you promise your stakeholders a delivery time/ price estimate?

We all do the same stuff, the disagreement would just be what you feel coding is and if you think technical work is the same thing or a superset. If you as software dev aren't hands on with planning or working more than 5% of your time, you are basically a PO with a programing hobby

> So you you don't research if something is technically feasible before you promise your stakeholders a delivery time/ price estimate

I believe 99% of requests are not about what’s technically feasible. And the rare time I encountered one of those, my answer has mostly been “you don’t have enough resources to try solving that problem”.

If you know your fundamentals well, very often you will find the same common blocks everywhere. People much more smarter than me has solved a lot of fundamental issues and it’s rare that I see a business request that doesn’t reuse the same familiar stuff.

That’s why coding is mostly boring. You follow the same pattern again and again. But what dictates the flows are the business parameters. And that’s why most senior spend so much time gathering good requirements. Because the code is straightforward after that.

So about 26 hours of meetings to 13 hours of "real technical work" per week, but that's is 33%, not 5%.

Ah yes agreed, if it's more than 90% it just signals to me that a developers skills are probably being wasted too much on business/coordination stuff.

But i guess if we mean actual time tapping your keyboard making code, then it's true some days for senior+ devs, but definitely not technical work overall.

For those who claim to be developers who code no more than 5% of their time and resort to arguments like "we're already not writing machine code by hand for 50 years, how is AI different from a higher level language?", it's not commenting, it's shilling for the AI corpocracy on HN.

>> "we're already not writing machine code by hand for 50 years, how is AI different from a higher level language?"

I never got that argument. Compilers are formally proven, deterministic algorithms . If you understand what compiler does, you can have pretty good idea what it will produce. If it doesn't do that, its a bug. Definition of correctness is well defined by semantic equivalence.

LLMs are none of that. Its a fuzzy system that approximates your intent and does its best. I can make my intent more and more specific to get closer to what I want, but given all that is just regular spoken language its still open to interpretation. And all that is still quite useful, but I don't get the assembly language comparison here.

Because compilers are only deterministic when using ahead of time compilation, without profiling data, and always the same set of compiler flags.

Introduce dynamic compilation, profiling data, optimization passes, multiple implementations, ML driven heuristics, and getting deterministic Assembly output from a compiler starts to get harder to achieve.

You are right about that but that's talking about what you generate but not what the output does. My point is that the compilers still designed to preserve semantic equivalence. semantic equivalence makes sense here because there are semantics well defined for both input and output. That bit is supposed to be deterministic. If something breaks that that is a bug.

I just don't think comparing with compilers is a good argument.

Semantic equivalence breaks down with UB optimizations.

and hence reading code is unnecessary because how well LLMs understand and converts my prompts is almost equivalent to how well compilers can understand programs and turn into assembly. The prompts carry equal amount of ambiguity as the prompts I would write to define the behavior and want.

By extension, does this imply that all the HLL advocates from decades past were shilling for compiler companies?

Sneering at "kids these days"

Reply on news.ycombinator.com