Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write less code, be more responsible

blog.orhun.dev

Post reply on HN
Print view View original

91–100 of 135 posts

Re: Write less code, be more responsible

#91

Post by agentultra »

bdangubic wrote: post #63
agentultra wrote: post #20

Earlier quoted context omitted.

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, verifyi…

> 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…

Maybe it's just my luck but most engineering teams I've worked with that were building some kind of network-facing service in the last 16-some-odd-years have tried to implementing continuous delivery of one kind or another. It usually started off well but it ends up being just as slow as the versioned-release system they used before.

It sounds like your team is the exception? Many folks I talk to have similar stories.

I've worked with teams to build out a well-oiled continuous delivery system. With code reviews, integration gating, feature flags, a blue-green deployment process, and all of the fancy o11y tools... we shipped several times a day. And people were still afraid to ship a critical feature on a Friday in case there had to be a roll-back... still a pain.

And all of that took way more time and effort than writing the code in the first place. You could get a feature done in an afternoon and it would take days to get through the merge queue, get through reviews, make it through the integration pipeline and see the light of production. All GenAI had done there was increase the input volume to the slowest part of the system.

People were still figuring out the best way to use LLM tools at that time though. Maybe there are teams who have figured it out. Or else they just stop caring and don't mind sloppy, slow, bloated software that struggles to keep one nine of availability.

Re: Write less code, be more responsible

#92

Post by [deleted] »

osm3000 wrote: post #37

I am a machine learning engineer. I've been in the domain almost 12 years now (different titles and roles). In my current role (and by no means that is unique), I don't know how to write less code. Here are problems I am facing: - DS generating a lot of code - Managers who have therapy sessions with Gemini, and in which their ideas have been validated - No governance on DS (you want this package? import it) - No gove…

[deleted]

Re: Write less code, be more responsible

#93

Post by [deleted] »

agentultra wrote: post #6
bdangubic wrote: post #3

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…

[deleted]

Re: Write less code, be more responsible

#94

Post by hnthrowaway0315 »

agentultra wrote: post #2

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…

“more, better, faster,”

I have heard these words, almost verbatim, from manager-yes-men coming from a FAANG background, and surprisingly concentrated in a certain demography (if someone find this offensive, I'll remove this part).

My CTO wants us to "deliver as fast as possible", and my VP wants us to "go much faster, and more ownership". "Better" or anything related with quality was definitely mentioned, too, but always at a second place.

To this day, I consider these yes-men to be a major red flag, so I always tried to probe for such information during interviews.

Re: Write less code, be more responsible

#95

Post by locknitpicker »

the_af wrote: post #90
locknitpicker wrote: post #88

Earlier quoted context omitted.

> But it seems we are introducing a whole new layer of lossy interpretation to the whole mess (...) I recommend you get acquainted with LLMs and code assistants, because a few of your assertions are outright wrong. Take for example any of the mainstream spec-driven development frameworks. All they do is walk you through the SRS process using a set of system prompts to generate a set of documents featuring usecases, f…

> I recommend you get acquainted with LLMs and code assistants I use them daily, thanks for your condescension. > I could see LLMs being used to check/analyze natural language requirements and help turn them into formal requirements though. Did you read this part of my comment? > Take for example any of the mainstream spec-driven development frameworks. All they do is walk you through the SRS process using a set of s…

> Did you read this part of my comment?

Yes, and your comment contrasts heavily with the reality of using LLMs as code assistants, as conveyed in comments such as "a whole new layer of lossy interpretation. This is profoundly wrong, even if you use LLMs naively.

I repeat: LLM assistants have been used to walk users through software requirements specification processes that not only document exactly what usecases and functional requirements your project must adhere to, but also create tasks and implement them.

The deliverable is both a thorough documentation of all requirements considered up until that point and the actual features being delivered.

To drive the point home, even Microsoft of all companies provides this sort of framework. This isn't an arcane, obscure tool. This is as mainstream as it can be.

> I'm not criticizing spec-driven development frameworks, but how battle-tested are they?

I really recommend you get acquainted with this class of tools, because your question is in the "not even wrong" territory. Again, the purpose of these tools is to walk developers through a software requirements specification process. All these frameworks do is put together system prompts to help you write down exactly what you want to do, break it down into tasks, and then resume the regular plan+agent execution flow.

What do you think "battle tested" means in this topic? Check if writing requirements specifications is something worth pursuing?

I repeat: LLM assistants lower formal approaches to the software development lifecycle by orders of magnitude, to the point you can drive each and every single task with a formal SRS doc. This isn't theoretical, it's month's old stuff. The focus right now is to remove human intervention from the SRS process as well with the help of agents.

Re: Write less code, be more responsible

#96

Post by kjksf »

16bitvoid wrote: post #84
svieira wrote: post #80

Earlier quoted context omitted.

Why is it using a temp file? Is there really no more elegant way to pass around pointers to images than spilling to disk?

Of course there is, but slop generators be slopping

What is it, o wise person stingy with the information.

Re: Write less code, be more responsible

#97

Post by the_af »

locknitpicker wrote: post #95
the_af wrote: post #90

Earlier quoted context omitted.

> I recommend you get acquainted with LLMs and code assistants I use them daily, thanks for your condescension. > I could see LLMs being used to check/analyze natural language requirements and help turn them into formal requirements though. Did you read this part of my comment? > Take for example any of the mainstream spec-driven development frameworks. All they do is walk you through the SRS process using a set of s…

> Did you read this part of my comment? Yes, and your comment contrasts heavily with the reality of using LLMs as code assistants, as conveyed in comments such as "a whole new layer of lossy interpretation. This is profoundly wrong, even if you use LLMs naively. I repeat: LLM assistants have been used to walk users through software requirements specification processes that not only document exactly what usecases and…

> Yes, and your comment contrasts heavily with the reality of using LLMs as code assistants, as conveyed in comments such as "a whole new layer of lossy interpretation. This is profoundly wrong, even if you use LLMs naively.

Most people, when told they sound condescending, try to reframe their argument in order to remove this and become more convincing.

Sadly, you chose to double down instead. Not worth pursuing.

> This isn't theoretical, it's month's old stuf

Hahaha! "Months old stuff"!

Disengaging from this conversation. Over and out.

Re: Write less code, be more responsible

#98

Post by agentultra »

dpark wrote: post #31
agentultra wrote: post #20

Earlier quoted context omitted.

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, verifyi…

> If you’ve heard it a number of times and refuse to consider what people are saying then maybe I can’t help you. What someone says “I’ve heard this a thousand times, but…”, it could be that the person is just stupidly obstinate but it could also mean that they have a considered opinion that it might benefit you to learn. “More people slow down projects” is an oversimplified version of the premise in The Mythical Man…

Sure, I’m not writing a whole critical analysis of TMMM here and am using an aphorism to make a point.

Let’s imagine we’re going to make a new operating system to compete with Linux.

If we have a team of 10 developers we’re probably not going to finish that project in a month.

If we’re going to add 100 developers we’re not going to finish that project in a month.

If we add a thousand developers we’re still not going to finish that project in a month.

But which team should ship first? And keep shipping and release fastest?

My bet would be on the smaller team. The exact number of developers might vary but I know that if you go over a certain threshold it will slow down.

People trying to understand management of software projects like to use analogies to factory lines or building construction to understand the systems and processes that produce software.

Yet it’s not like adding more code per unit of time is adding anything to the process.

Even adding more people to a factory line had diminishing returns in efficiency.

There’s a sweet spot, I find.

As for Google… it’s not a panacea of efficiency from what I hear. Though I don’t work there. I’ve heard stories that it takes a long time to get small changes to production. Maybe someone who does work there could step in and tell us what it’s like.

As a rule though, I find that smaller teams with the right support, can ship faster and deliver higher quality results in the long run.

My sample size isn’t large though. Maybe Windows is like the ultimate operating system that is fast, efficient, and of such high quality because they have so many engineers working on it.

Re: Write less code, be more responsible

#99

Post by slopinthebag »

bdangubic wrote: post #65
slopinthebag wrote: post #35

Earlier quoted context omitted.

I think you comparing software development to brick laying says all anyone needs to hear about your approach to software development. It's like saying the bottleneck in mathematics is arithmetic.

writing software, if you know what you are doing, is very similar to laying bricks. write smallest possible functions that do one thing and do it well and then compose them, like bricks, to make a house (which is what brick layers do). comments like this come from places where it is more like bunch of chefs in a italian restaurant making spaghetti pasta (code) :)

No, thats a common mechanistic view of building software but it's not really accurate. Unlike with bricks, the way you arrange your components and subcomponents has an effect on the entire system. It's a complex phenomenon.

Of course your view is quite common especially in the managerial class, and often leads to broken software development practices and the idea that you can just increase output by increasing input. One step away from hiring 9 pregnant women to make a baby in a month.

Re: Write less code, be more responsible

#100

Post by slopinthebag »

bdangubic wrote: post #66
slopinthebag wrote: post #34

Earlier quoted context omitted.

It sounds like you just aren't very good at managing teams of programmers tbh. If your bottleneck is producing code, very rarely does hiring more programmers actually help.

this makes just so much sense, I'll manage my programmers to work 37 hours per day, imma try this next week and will let you know how it goes

Try having your programmers work 30 hours a week instead of 40 and measure their output. You might be surprised.
Post reply on HN