Live data from Hacker News

Write less code, be more responsible

blog.orhun.dev

11–20 of 135 posts

Re: Write less code, be more responsible

#11

I’m working as a single solo developer of a tiny video game. I’m writing it in C with raylib. No coding assistants, no agents, not even a language server. I only work on it for a few hours during the week. And it’s progressing at a reasonable pace that I’m happy with. I got cross-compilation from Linux to Windows going early on in a couple of hours. Wasn’t that hard. I’ve had to rework parts of the code as I’ve progr…

>I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less.

This is what I've always found confusing as well about this push for AI. The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster

Re: Write less code, be more responsible

#12

Earlier quoted context omitted.

> Writing the code hasn’t been the bottle neck to developing software for a long time. I see this on HN just so much and I am not sure what this is, almost seems like a political slogan that followers keep repeating. I had to do some rough math in my head but in the last 5 years I have been involved with hiring roughly 40 SWEs. Every single one of them was hired because writing the code was THE bottleneck (the only o…

If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down. I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specializ…

> they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours

Haha, this is exactly my experience.

I'll never forget the best candidate I ever interviewed - my feedback was to absolutely hire him and put him on the most interesting and challenging problems. They put him in a marketing team tweaking upsell popups. He left after 2 months.

Re: Write less code, be more responsible

#13
post #4

Earlier quoted context omitted.

> Writing the code hasn’t been the bottle neck to developing software for a long time. I see this on HN just so much and I am not sure what this is, almost seems like a political slogan that followers keep repeating. I had to do some rough math in my head but in the last 5 years I have been involved with hiring roughly 40 SWEs. Every single one of them was hired because writing the code was THE bottleneck (the only o…

But how much time per week does an SWE actually spend writing code?

another one, this is 2nd most frequent thing people write here, not sure how to even approach answering :)

so I’ll do what I was thought in first grade to never do and answer a question with a question - how much time per week does a brick layer spend laying bricks? they are looking at these new “robots” laying bricks automatically and talking on BrickLayerNews “man, the brick laying has not been a bottleneck for a long time.”

But to answer your question directly, a lot of time if other people do their job well. Last week I had about 7 hours of meetings, the rest of the time I was coding (so say 35 hours) minus breaks I had to take to stretch and rest my eyes

Re: Write less code, be more responsible

#14

Earlier quoted context omitted.

> Writing the code hasn’t been the bottle neck to developing software for a long time. I see this on HN just so much and I am not sure what this is, almost seems like a political slogan that followers keep repeating. I had to do some rough math in my head but in the last 5 years I have been involved with hiring roughly 40 SWEs. Every single one of them was hired because writing the code was THE bottleneck (the only o…

If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down. I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specializ…

> The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down.

I've been doing this for 30-years and this is another political slogan of sorts. this is true in every single imaginable job - new people slow you down, until they do not and become part of the well-oiled machine that is hopefully your team. not sure why people insist on saying this, it is like saying "read this book, says that that Sun will rise tomorrow morning"

> I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people.

I wasn't talking about startups or developers making boxes more blue, I was talking about personal experience. The bottleneck, if you are doing amazing shit and not burning some billionaries money on some silly "startup" is always the code which is why we hire developers to write the code. Everything else is just coming up with some silly unrelated examples - of course there are people (at every job again) doing nothing or menial tasks - this isn't what I was talking about.

> You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday.

I do have customers that want features that would make their lives easier and are willing to handsomely pay for it, that good enough?

> This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead.

This is only on super shitty teams with super shitty co-workers (especially senior ones) and super shitty managers. I feel for the careers in this industry where this is/was the case. A whole lot of people are terrible at their jobs in places like this - a whole lot of people...

> A well-sized team that has worked together a long time can outperform a massive team any day in my experience.

a well-sized team was at one point (well-sized team - 1) and (well-sized team - 2) and (well-sized team - 3) and in the future if it is right team will be even more amazing as well (well-sized team + 1), (well-sized team + 2)

Re: Write less code, be more responsible

#15
post #4

Earlier quoted context omitted.

But how much time per week does an SWE actually spend writing code?

another one, this is 2nd most frequent thing people write here, not sure how to even approach answering :) so I’ll do what I was thought in first grade to never do and answer a question with a question - how much time per week does a brick layer spend laying bricks? they are looking at these new “robots” laying bricks automatically and talking on BrickLayerNews “man, the brick laying has not been a bottleneck for a l…

Interesting! I guess it really varies between jobs, roles, and companies.

Thats never been my experience but I have an odd skill set that mixes design and dev.

I’ve always spent a lot of time planning, designing, thinking, etc.

How detailed are the tickets if you spend all your time coding? You never have to think through architecture, follow up on edge cases the ticket writers didn’t anticipate, help coworkers with their tasks, review code, etc.?

Re: Write less code, be more responsible

#16
It was always possible to write large amounts of crappy code if you were motivated or clueless enough (see https://github.com/radian-software/TerrariaClone). It's now just easier, and the consequences less severe, as the agent has code comprehension superpowers and will happily extend your mud ball of a codebase.

There are still consequences, however. Even with an agent, development slows, cost increases, bugs emerge at a higher rate, etc. It's still beneficial to focus on code quality instead of raw output. I don't think this is limited writing it yourself, mind - but you need to actually have an understanding of what's being generated so you can critique and improve it.

Personally, I've found the accessibility aspect to be the most beneficial. I'm not always writing more code, but I can do much more of it on my phone, just prompting the agent, which has been so freeing. I don't feel this is talked about enough!

Re: Write less code, be more responsible

#17
post #11

I’m working as a single solo developer of a tiny video game. I’m writing it in C with raylib. No coding assistants, no agents, not even a language server. I only work on it for a few hours during the week. And it’s progressing at a reasonable pace that I’m happy with. I got cross-compilation from Linux to Windows going early on in a couple of hours. Wasn’t that hard. I’ve had to rework parts of the code as I’ve progr…

>I don’t really understand the, “more, better, faster,” cachet to be honest. Writing the code hasn’t been the bottle neck to developing software for a long time. It’s usually the thinking that takes most of the time and if that goes away well… I dunno, that’s weird. I will understand it even less. This is what I've always found confusing as well about this push for AI. The act of typing isn't the hard part - its unde…

> The act of typing isn't the hard part - its understanding what's going on, and why you're doing it. Using AI to generate code is only faster if you try and skip that step - which leads to an inevitable disaster

It’s more than just typing though. A simple example remembering the exact incantation of CSS classes to style something that you can easily describe in plain English.

Yes, you could look them up or maybe even memorize them. But there’s no way you can make wholesale changes to a layout faster than a machine.

It lowers the cost for experimentation. A whole series of “what if this was…” can be answered with an implementation in minutes. Not a whole afternoon on one idea that you feel a sunk cost to keep.

Re: Write less code, be more responsible

#20

Earlier quoted context omitted.

If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down. I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specializ…

> The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down. I've been doing this for 30-years and this is another political slogan of sorts. this is true in every single imaginable job - new people slow you down, until they do not and become part of the well-oiled machine that is hopefully your team. not sure why people insist on saying th…

If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you.

I’m talking from personal experience of well over twenty years as both a developer, and for a while, a manager.

The slow part isn’t writing code.

It’s shipping it. You can have every one vibe coding until their eyes bleed and you’ve drained their will to live. The slowest part will still be testing, verifying, releasing, and maintaining the ball of technical debt that’s been accumulating. You will still have to figure out what to ship, what to fix, what to rush out and what to hold out until it’s right, etc. The more people you have to slower that goes in my experience. AI tools don’t make that part faster.

Post reply on HN