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

If you thought code writing speed was your problem you have bigger problems

andrewmurphy.io

Post reply on HN
Print view View original

41–50 of 231 posts

Re: If you thought code writing speed was your problem you have bigger problems

#41

Post by Terr_ »

doix wrote: post #31
furyofantares wrote: post #6

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

Pretty much, the article assumes people didn't build the wrong thing before AI. Except that did happen all the time and it just happened slower, took longer to realize that it was the wrong thing and then building the right thing took longer. It's funny, because you could actually take that story and use it to market AI. > I once watched a team spend six weeks building a feature based on a Slack message from a sales…

Sometimes being involved in the construction process allows you to discover all the (many, overlapping) ways it's the "wrong thing" sooner.

In the long term, some of the most expensive wrong-things are the ones where the prototype gets a "looks good to me" from users, and it turns out what they were asking for was not what they needed or what could work, for reasons that aren't visually apparent.

In other words, it's important to have many people look at it from many perspectives, and optimizing for the end-user/tester perspective at the expense of the inner-working/developer perspective might backfire. Especially when the first group knows something is wrong, but the second group doesn't have a clue why it's happening or how to fix it. Worse still if every day feels like learning a new external codebase (re-)written by (LLM) strangers.

Re: If you thought code writing speed was your problem you have bigger problems

#42

Post by tovej »

petcat wrote: post #20

As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution. For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and…

Is this a copypasted response? I've seen the exact same bs in other AI threads on this site.

Re: If you thought code writing speed was your problem you have bigger problems

#43

Post by zer00eyz »

gammalost wrote: post #3

Seems easy to address with a simple rule. Push one PR; review one PR

The problem is most of the people we have spent the last 20 years hiring are bad at code review.

Do you think the leet code, brain teaser show me how smart you are and how much you can memorize is optimized to hire the people who can read code at speed and hold architecture (not code but systems) in their head? How many of your co-workers are set up and use a debugger to step through a change when looking at it?

Most code review was bike shedding before we upped the volume. And from what I have seen it hasn't gotten better.

Re: If you thought code writing speed was your problem you have bigger problems

#44

Post by bdcravens »

felipellrocha wrote: post #22
petcat wrote: post #20

As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution. For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and…

If you truly believe that, why don’t you just transform code directly to assembly? Skip the middleman, and get a ton of performance!

I assume you're being cynical, but there's a lot of truth in what you say: LLMs allow me to build software to fit my architecture and business needs, even if it's not a language I'm familiar with.

Re: If you thought code writing speed was your problem you have bigger problems

#45

Post by jrop »

krackers wrote: post #27
petcat wrote: post #20

As human developers, I think we're struggling with "letting go" of the code. The code we write (or agents write) is really just an intermediate representation (IR) of the solution. For instance, GCC will inline functions, unroll loops, and myriad other optimizations that we don't care about. But when we review the ASM that GCC generates (we don't) we are not concerned with the "spaghetti" and the "high coupling" and…

>Source code in a higher-level language is not really different anymore Source code is a formal language, in a way that natural language isn't.

Right? That's the only reason that "coding with LLMs" works at all (believe me, all at the same time, I am wowed by LLMs, and carry a healthy level of skepticism with respect to their ability as well). You can prompt all you want, let an Agent spin in a Ralph loop, or whatever, but at the end of the day, what you're checking into Git is not the prompts, but the formalized, codified artifact that is the bi-product of all of that process.

Re: If you thought code writing speed was your problem you have bigger problems

#46

Post by [deleted] »

furyofantares wrote: post #6

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

[deleted]

Re: If you thought code writing speed was your problem you have bigger problems

#47

Post by teaearlgraycold »

> I once watched a team spend six weeks building a feature based on a Slack message from a sales rep who paraphrased what a prospect maybe said on a call. Six weeks. The prospect didn't even end up buying. The feature got used by eleven people, and nine of them were internal QA. That's not a delivery problem. That's an "oh fuck, what are we even doing" problem.

I have very much upset a CEO before by bursting his bubble with the fact that how fast you work is so much less important than what you are working on.

Doing the wrong thing quickly has no value. Doing the right thing slowly makes you a 99th percentile contributor.

Re: If you thought code writing speed was your problem you have bigger problems

#48

Post by p-o »

furyofantares wrote: post #6

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

Re: If you thought code writing speed was your problem you have bigger problems

#49

Post by lgessler »

john_strinlai wrote: post #30
furyofantares wrote: post #6

> 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? do you have a example (even a toy one) where typing faster would help you understand a problem faster?

Has everyone always nailed their implementation of every program on the first try? Of course not. Probably what happens most times is you first complete something that sorta works and then iterate from there by modifying code, executing, observing, and looping back to the beginning. You can wonder about ultimately how much of your time/energy is consumed by the "typing code" part, and there's surely a wide range of variation there by individual and situation, but it's undeniable that it is a part of the core iteration loop for building software.

I don't understand why GP's comment is so controversial. GP is not denying that you should maybe think a little before a key hits the keyboard as many commenters seem to suppose. Both can be true.

Re: If you thought code writing speed was your problem you have bigger problems

#50

Post by mooreds »

furyofantares wrote: post #6

> 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 write a better description of the problem and assure the person working on it that the integration would work. This was valuable.

I immediately threw away that prototype code, though. See above aspects I just didn't need to think about.

Post reply on HN