Earlier quoted context omitted.
A Luddite farm worker can assist in all those things, the question is, can it assist in a useful manner?
Not only it can but it does. Just as I was reading this claude implemented a drag&drop of images out of SumatraPDF. I asked: > implement dragging out images; if we initiate drag action and the element under cursor is an image, allow dragging out the image and dropping on other applications then it didn't quite work: I'm testing it by trying to drop on a web application that accepts dropped images from file system but…
Write less code, be more responsible
111–120 of 135 posts
Re: Write less code, be more responsible
#112Earlier quoted context omitted.
> using an aphorism to make a point. But your “aphorism” is not true. You made a claim that more developers make a project slower. And you pointed to TMMM in support of that claim. Now you seem to be saying “I know this isn’t really true, but my point hinges on us pretending it is.” > Let’s imagine we’re going to make a new operating system to compete with Linux. This is a nonsensical question. “Would you rather be s…
You’re right, I’m not making my point well. You do need enough people to make complex systems. We can do more together than we can on our own. Linux started out with a small team but it is large today. It runs against my experience though and I can’t seem to explain why. My observation in my original post is that I don’t see why writing code is the bottleneck. It can be when you have too much of it but I find all the…
Your experiences are probably correct, but incomplete. More engineers on a project do come with more cost. Spinning up a new engineer is a net loss for some time (making the late project later) and output per engineer added (even after ramp up) is not linear. 5000 engineers working on Linux do not produce 5000x as much as Torvalds by himself. But they probably do produce more than 2500 engineers.
> Thanks for the discussion!
You too
Re: Write less code, be more responsible
#113Earlier quoted context omitted.
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.…
Re: Write less code, be more responsible
#114Earlier 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. He didn’t say that. He said adding developers to a late project makes it slower , explained why, and even added some charts to illustrate it. The distinction matters. By your interpretation, no company should have more than a few developers, which is obvious…
> He didn’t say that. Actually he did, or something very close to it. Obviously SOMETIMES you can add more developers to a project to successfully speed it up, but Brooks point was that it can easily also have the opposite effect and slow the project down. The main reason Brooks gives for this is the extra overhead you've just added to the project in terms of communications, management, etc. In fact increasing team s…
Yeah, the "something very close to it" is what I quoted. And I'll repeat: distinction matters.
> don't think you are going to get linear speedup by adding more people.
I didn't either say, nor imply, this. Of course communication and coordination is overhead. Let's quote Brooks from the same article some more: The maximum number of men depends upon the number of independent subtasks.
Which is why in modern times you have a bunch of theoretical and practical research around team topologies, DORA, Reverse Conway Manoeuvre, the push to microservices, etc, etc. You can boil all that down to "maximize team independence while making each team as productive as possible."
This is a wonderful tangent (and if this interests you, I heartily recommend the Team Topologies book), but can we just keep in mind the gp never actually said he was overhiring for a single project? Parent latched onto a wrong idea and ran with it.
Re: Write less code, be more responsible
#115Earlier quoted context omitted.
> What if that process changes and the language you’re reading is a natural one instead of code? Natural language is not a good way to specify computer systems. This is a lesson we seem doomed to forget again and again. It's the curse of our profession: nobody wants to learn anything if it gets in the way of the latest fad. There's already a historical problem in software engineering: the people asking for stuff use…
> 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…
Re: Write less code, be more responsible
#116Earlier quoted context omitted.
>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…
> 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. This is a very superficial and simplistic analysis of the whole domain. Programmers don't "type". They apply changes to the code. Pressing buttons in a keyboard is not the bottleneck. If that was the case, code completion and templating would ha…
And yet this is "AI is world changing, look at how fast it can change code!"
> So while you still try to navigate through files, others already have features out.
Your argument is "it can also read code faster too" - but it doesn't have the same tacit knowledge within the codebase. Documentation and comments can be wrong sometimes. Names are poorly chosen
That's the thing about reviews: the implementor doesn't know what's needed for the feature, but the reviewer now needs to. The latter can't trust the former anymore.
/Explain is constantly wrong. /Plan is constantly over engineered. /Tests are constantly fragile
The only benefit AI has produced to existing codebase is now people care a lot more about getting documentation right and adding little snippet/how-tos called "skills" or whatever.
Re: Write less code, be more responsible
#117I’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 al…
I haven't needed to change jobs but I'm worried that one day I'll have to
Re: Write less code, be more responsible
#118I’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…
> Writing the code hasn’t been the bottle neck to developing software for a long time. For who? There's no lack of professional programmers who couldn't clear FizzBuzz now coding up company-sized systems using Agents. This is all good as long as agents can stick to the spec/req & code it all up with decent enough abstractions... as the professional approving it is in no position to clue it on code organization or bug…
The one-shot vibe-coded C compiler is a good example. Sure it created a compiler that could pass the basic tests. But it was no where near a plausible or useful compiler you’d use in a production system.
Someone who knows compilers reviewed it and was able to prompt Claude or Gemini to fix the issues. But still… you’re not going to be able to do that unless you know what to look for.
On an enterprise development team doing boring, Line of Business software? Might have a chance at rolling the dice and trusting the agents and tests and processes to catch stuff for you but I’d still be worried about people who don’t know what questions to ask or have deep expertise to know what is “good,” etc.
Re: Write less code, be more responsible
#119And I can tell all of the nay-sayers in this thread, from first-hand experience, that the AI tools can be useful. When you use them well, they can save time. If you're writing just a dinky webapp for your "radio on the internet" startup, it can do a lot of grunt work. It's better auto completion, at a minimum.
Last week I was struggling with an annoying, interlocking-race-condition/-stale-state bug. Fixing one issue kept reintroducing others that I'd just fixed. Skill issue, right? Right. And Clause 4.6 Opus diagnosed the problem and fixed it with just a little bit of coaxing.
Then I asked it to fix another issue and it wound up chasing its tail, as it tried to apply the same principle to unrelated code with unrelated problems.
Call these tools stochastic parrots. Call them autocorrect on steroids. Call them whatever you want. If you think they're worthless or have no use, you're living either in a fantasy land or in 2022 just after openai released its first, hilariously stupid chatbot.
Re: Write less code, be more responsible
#120I’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…
Code may not be the bottleneck, but writing it absolutely does consume time.
Especially with solo game dev, I can prototype ideas, try them out, and then refine or scrap them at a rate I could never do without AI. This type of experimentation is a perfect use-case for AI. It’s actually super fun, and if I pay attention and give the AI decent instructions, I don’t really lose out on code quality.