[flagged]
For me it's also in generating output that I know is right when I see it, but don't necessarily know every intricate detail of up front.
If you thought code writing speed was your problem you have bigger problems
81–90 of 231 posts
Re: If you thought code writing speed was your problem you have bigger problems
#82The word typing is wrong.
It is not about the speed of typing code.
Its about the speed of "creating" code: the boilerplate code, the code patterns, the framework version specific code, etc.
Re: If you thought code writing speed was your problem you have bigger problems
#83I can really relate to this. At the same time I’m not convinced cycle time always trumps throughput. Context switching is bad, and one solution to it is time boxing, which basically means there will be some wait time until the next box of time where the work is picked up. Doing time boxing properly lowers context switching, increases throughput but also increases latency (cycle time). It’s a trade-off. But of course maybe time boxing isn’t the best solution to the problem of context switching, maybe it’s possible to figure out a way to have the cookie and eat it. And maybe different circumstances require a different balance between latency and throughput.
Re: If you thought code writing speed was your problem you have bigger problems
#84Re: If you thought code writing speed was your problem you have bigger problems
#85Earlier quoted context omitted.
That's fair. I'm usually my own customer.
I think a lot of the discourse around LLMs fails because of organizational differences. I work in science, and I’ve recently worked with a couple projects where they generated >20,000 LOC before even understanding what the project was supposed to be doing. All the scientists hated it and it didn’t do anything that it was supposed to. But I still felt like I was being “anti-ai” when criticizing it. I understand that i…
I'm starting to see this. It starting to seem like a lot of the people making the most specious, yet wild AI SLDC claims are:
* Hobbyist or people engaged in hobby and personal projects
* Startup bros; often pre-funding and pre-team
* Consultancies selling an AI SDLC as that wasn't even possible 6 months ago as "the way; proven, facts!"
It's getting to the point I'd like people to disclose the size of the team and org they are applying these processes at LOL.
Re: If you thought code writing speed was your problem you have bigger problems
#86Earlier quoted context omitted.
> Why not? Why can't faster typing help us understand the problem faster? do you have a example (even a toy one) where typing faster would help you understand a problem faster?
Here's a literal toy one. Build a toy car with square wheels and one with triangular wheels and one with round wheels and see which one rolls better. The issue isn't "typing faster" it's "building faster".
No need to build three, you just have to quickly write a proof for which shapes can roll. You'll then spend x+y units of time, where y<<x, instead of 3*x units. We have stories that highlight the importance of thinking instead of blindly doing (sharpening the axe, $1 for pressing a button and $9999 for knowing which button to press).
Re: If you thought code writing speed was your problem you have bigger problems
#87> The bottleneck is understanding the problem. No amount of faster typing fixes that. Why not? Why can't faster typing help us understand the problem faster? > When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. Why can't we figure out the right thing faster by building the wrong thing faster? Presumably we were gonna build the wrong thing either way in…
> Why not? Why can't faster typing help us understand the problem faster? I think we can, in some cases. For instance, I prototyped a feature recently and tested an integration it enabled. It took me a few hours. There's no way I would have tried this, let alone succeeded, without opencode. Because I was testing functionality, I didn't care about other aspects: performance, maintainability, simplicity. I was able to…
>There's no way I would have tried this, let alone succeeded, without opencode
Sure there is.
You could have used Claude or Codex directly :)
Re: If you thought code writing speed was your problem you have bigger problems
#88> The bottleneck is understanding the problem. No amount of faster typing fixes that. Why not? Why can't faster typing help us understand the problem faster? > When you speed up code output in this environment, you are speeding up the rate at which you build the wrong thing. Why can't we figure out the right thing faster by building the wrong thing faster? Presumably we were gonna build the wrong thing either way in…
> Why not? Why can't faster typing help us understand the problem faster? Why can't you understand the problem faster by talking faster?
Sometimes you can.
Re: If you thought code writing speed was your problem you have bigger problems
#89he’s treating “systems thinking” and architecting software like it’s some sacred, hard to automate layer that AI apparntly sucks at ..
Re: If you thought code writing speed was your problem you have bigger problems
#90Earlier quoted context omitted.
> Why can't we figure out the right thing faster by building the wrong thing faster? Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time. This is easily the biggest bottleneck in B2B/SaaS stuff for banking. You can iterate maybe once a week if you have a really, really good client.
> Why can't we figure out the right thing faster by building the wrong thing faster? > Because usually the customer can only tolerate so many failed attempts per unit of time. Running your fitness function is often very expensive in terms of other people's time. Heh, depends on what you do. Many times the stakeholders can't explain what they want but can clearly articulate what they don't want when they see it. Gener…
That's done by arranging a demo (the very old way) or (better) by deploying to a staging server. The customer meets with you for a demo not very often, maybe once per month, or checks what's on the staging server maybe a couple of times per week. They have other things to do, so you cannot make them check your proposal multiple times per day. However I concede that if you are fast you can work for multiple customers at the same time and juggle their demos on the staging servers.