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

51–60 of 231 posts

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

#51

Post by intrasight »

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?

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".

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

#52

Post by petcat »

exceptione wrote: post #40
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…

None of the comparisons make any sense. In short, these concepts are essential to understand: - determinism vs non-determinism - conceptual integrity vs "it works somewhat, don't touch it"

> determinism vs non-determinism

Here are the reported miscompilation bugs in GCC so far in 2026. The ones labeled "wrong-code".

https://gcc.gnu.org/bugzilla/buglist.cgi?chfield=%5BBug%20cr...

I count 121 of them. It appears that code-generation is not as deterministic as you seem to think it is.

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

#54

Post by yummypaint »

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…

Just because an LLM can turn high level instructions into low level instructions does not make it a compiler

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

#55

Post by ErroneousBosh »

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 do you need to type at all to understand the problem?

I write my best code when I'm driving my car. When I stop and park up, it's just a case of typing it all in at my leisure.

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

#56

Post by onlyrealcuzzo »

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…

AI is really good when:

1. you want something that's literally been done tons of times before, and it can literally just find it inside its compressed dataset

2. you want something and as long as it roughly is what you wanted, it's fine

It turns out, this is not the majority of software people are paying engineers to write.

And it turns out that actually writing the code is only part of what you're paying for - much smaller than most people think.

You are not paying your surgeon only to cut things.

You are not paying your engineer only to write code.

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

#58

Post by ruszki »

petcat wrote: post #38
inamberclad wrote: post #34

Earlier quoted context omitted.

When you get to the really tightly controlled industries, your "formal" language becomes carefully structured English.

Legalese exists precisely because it is an attempt to remove doubt when it comes to matters of law. Maybe a dialect of legalese will emerge for software engineering?

Legalese is nowhere near precise, and we have a whole very expensive system because it’s not precise.

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

#59

Post by mooreds »

cdrnsf wrote: post #15
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…

Because you're working on the implementation before you understand the problem?

Ding ding ding!

The article talks about process flows and finding the bottleneck. That might be coding, but probably is not.

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

#60

Post by podgorniy »

Yeah, we again have a solution (LLMs) in search of problems.

Proper approach to speeding things up would be to ask "What are the limiting factors which stops us from X, Y, Z".

--

This situation of management expecting things to become fast because of AI is "vibe management". Why to think, why to understand, why to talk to your people if you saw an excited presentation of the magic tool and the only thing you need to do is to adopt it?..

Post reply on HN