Hacker News Reader

Comment by bborud | Hacker News Reader

Are you, perchance, assuming that since you spend most of your time struggling with actual code, this is so for everyone else?

Or are you saying that I'm lying. That I am secretly hammering away at my keyboard while pretending not to?

No, writing code hasn't been how I spend most of my time for many decades now.

View on HN

Are you a staff level engineer that has dozens of other engineers banging away at code projects you help define?

Try to write a design doc before you implement something (which people find they need to do for LLMs to work at all anyway). You’ll find that you spend much less time actually writing code.

Write proper API documentation laying out the assumptions and intent, generate some good API docs, write a design and architecture document (which people find they need for LLMs to work at all anyway). You’ll find that you spend a lot less time reading code.

> which people find they need to do for LLMs to work at all anyway

Everything we have to do for AI to function well, would help humans to function better too.

If you take the things for AI, but do them for humans instead, that human will easily 2x or more, and someone will actually understand the code that gets written.

> If you take the things for AI, but do then for humans instead, that human will easily 2x or more, and someone will actually understand the code that gets written

This only works on high-trust teams and organizations. A lot of AI productivity gains are from SWE putting the extra effort because the results will be attributed to them. Being a force-multiplier for others isn't always recognized, instead, your perfomance will likely judged solely on the metrics directly attributed to you. I learned this lesson the hard way by being idealistic, and overestimating the level of trust that had been built after joining a new team. Companies pay lip service to software quality, no one gives a shit if your code has the lowest SEV rates.

Ah… that’s a reasonable point. Yes, the difference between a high-trust team and what you described is night and day. I suppose for those situations there’s a much bigger incentive to just throw AI at it, which explains why the big corporates love AI.

It has varied over the years but it isn't actually relevant since I am talking about when I write software.

Writing code just isn't what takes time.

Getting the code into a state where it actually does what you want takes time - but a lot of that is research, testing, experimentation, documentation, etc. Those can be faster with AI assistance but you still need to bang on it enough to make sure it works right.

I am not, yet actual coding is miniscule part of workflow. The rest is cca un-automable by any llm - politics, meetings, discussions, brainstorming, organizing testing teams, stakeholders and so on.

This is how big corporations look like, not some SV startups.

I agree. And that stuff is soul destroying. I have done it, and right now I work in a place a little smaller, but we get so much done without all the cruft. And we get it done better. I spend much more time writing code now (*) than at the big corps, and we do a much better job because we can iterate.

(*) Well, now claude spends a lot of time writing code, I spend a lot of time designing and steering it. Claude can write remarkably sophisticated code with the correct steering.*

No, no actually capable engineer should be just banging away at code. This is one way to know the level of an engineer.

Less capable engineers think in terms of implementing runtime execution and solving runtime errors.

More capable engineers think in terms of designing the most effective architecture and abstractions for maintainability, performance, and robustness.

I have a project I am working on, It has not compiled in months, but that's ok, since the real work, for me, is in the architectural design.

Yes, getting it to actually run takes some time and effort, but for me that is almost mechanical now.

Reply on news.ycombinator.com