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

Writing Code Was Never the Bottleneck

ordep.dev

Post reply on HN
Print view View original

211–220 of 400 posts

Re: Writing Code Was Never the Bottleneck

#211

Post by NiloCK »

Writing code was never the only bottleneck, and I'm sure there is personal variation, but for me personally it has always been the dominant bottleneck.

My backspace and delete keys loom larger than the rest of my keyboard combined. Plodding through with meager fingers, I could always find fault faster than I could produce functionality. It was a constant, ego-depleting struggle to set aside encountered misgivings for the sake of maintaining forward progress on some feature or ticket.

Now, given defined goals and architectural vision, which I've never been short of, the activation energy for producing large chunks of 'good enough' code to move projects forward is almost zero. Even my own oversized backspace is no match for the torrent.

Again - personal variation - but I expect that I am easily 10x in both in ambition and in execution compared to a year ago.

Re: Writing Code Was Never the Bottleneck

#212

Post by whatevsmate »

m_mueller wrote: post #196
raincole wrote: post #169

Earlier quoted context omitted.

People think juniors submitting LLM-generated code to seniors to review is a sign of how bad LLM is. I see it as a sign of how bad juniors are, and the need of seniors interacting with LLM directly without the middlemen.

The main problem in this environment is IMO: how does a junior become a senior, or even a bad junior become a good junior. People aren't learning fundamentals anymore beyond what's taught, and all the rest of 'trade knowledge' is now never experienced, people just trust that the LLM has absorbed it sufficiently. Engineering is all about trade-offs. Failing to understand why from 10 possible ways of achieving somethin…

The LLM is the coding tool, not the arbiter of outcome.

A human’s ability to assess, interrogate, compare, research, and develop intuition are all skills that are entirely independent of the coding tool. Those skills are developed through project work, delivering meaningful stuff to someone who cares enough to use it and give feedback (eg customers), making things go whoosh in production, etc etc.

This is a XY problem and the real Y are galaxy brains submitting unvalidated and shoddy work that make good outcomes harder rather than easier to reach.

Re: Writing Code Was Never the Bottleneck

#213

Post by conartist6 »

lsaferite wrote: post #201
conartist6 wrote: post #184

Earlier quoted context omitted.

https://github.com/bablr-lang/ I'm building a universal DOM for code so that we should see an explosion in code whose purpose is to help clean up other code. If you want to write code that makes changes to a tree of HTML nodes, you can pretty much write that code once and it will run in any web browser. If you want to write code that makes a new program by changing a tree of syntax nodes, there are an incredible numb…

Where does this "universal DOM for code" sit in relation to CSTs and ASTs?

It's an immutable btree-based format for syntax trees which contain information both abstract and concrete. Our markup language for serializing the trees is Concrete Syntax Tree Markup Language, or CSTML.

Re: Writing Code Was Never the Bottleneck

#214

Post by marcosdumay »

gdiamos wrote: post #18

I used to think I needed to type faster. As I get older I spend more of my coding time on walks, at the whiteboard, reading research, and running experiments

Programmers don't have to type fast, but we have to type unconsciously. Training for one of those usually also trains for the other.

Re: Writing Code Was Never the Bottleneck

#215

Post by intelVISA »

konovalov-nk wrote: post #177

Nobody mentioned Joel Spolsky's October 2nd, 2000 article, so I'll start: https://www.joelonsoftware.com/2000/10/02/painless-functiona... Code is not a bottleneck. Specs are. How the software is supposed to work, down to minuscule detail. Not code, not unit tests, not integration tests. Just plain English, diagrams, user stories. Bottleneck is designing those specs and then iterating them with end users, listening to…

> How the software is supposed to work, down to minuscule detail.

So... coding. :P

Re: Writing Code Was Never the Bottleneck

#216

Post by mdaniel »

conartist6 wrote: post #184
distalx wrote: post #175

Earlier quoted context omitted.

Any hints on what kind of tools you're creating for the inevitable mess?

https://github.com/bablr-lang/ I'm building a universal DOM for code so that we should see an explosion in code whose purpose is to help clean up other code. If you want to write code that makes changes to a tree of HTML nodes, you can pretty much write that code once and it will run in any web browser. If you want to write code that makes a new program by changing a tree of syntax nodes, there are an incredible numb…

Who is the consumer for the JSX noise that is happening here? https://github.com/bablr-lang/language-en-ruby/blob/550ad6fd...

As two nits, https://docs.bablr.org/reference/cstml and https://bablr.org/languages/universe/ruby are both 404, but I suspect that latter one is just falling into the same trap as many namespaces make of using a URL when they meant it as a URN

Re: Writing Code Was Never the Bottleneck

#217

Post by ericyd »

andrelaszlo wrote: post #22

My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…

> always require a lot of (passing) tests

My favorite LLM-generated code I've seen in PRs lately is

    expect(true).toBe(true)
Look ma! Tests aren't flaky anymore!

Re: Writing Code Was Never the Bottleneck

#218

Post by andrelaszlo »

akkad33 wrote: post #182
andrelaszlo wrote: post #22

My most recent example of this is mentoring young, ambitious, but inexperienced interns. Not only did they produce about the same amount of code in a day that they used to produce in a week (or two), several other things made my work harder than before: - During review, they hadn't thought as deeply about their code so my comments seemed to often go over their heads. Instead of a discussion I'd get something like "go…

Could you tell which language they were coding in?

A mix, but a majority Ruby, with some shell scripts and Terraform.

My gut feeling is that it would generalize to typed languages, Go, Erlang, even Haskell etc, but maybe some of them make life easier for the reviewer in some ways? What are your thoughts on that?

Re: Writing Code Was Never the Bottleneck

#219

Post by conartist6 »

mdaniel wrote: post #216
conartist6 wrote: post #184

Earlier quoted context omitted.

https://github.com/bablr-lang/ I'm building a universal DOM for code so that we should see an explosion in code whose purpose is to help clean up other code. If you want to write code that makes changes to a tree of HTML nodes, you can pretty much write that code once and it will run in any web browser. If you want to write code that makes a new program by changing a tree of syntax nodes, there are an incredible numb…

Who is the consumer for the JSX noise that is happening here? https://github.com/bablr-lang/language-en-ruby/blob/550ad6fd... As two nits, https://docs.bablr.org/reference/cstml and https://bablr.org/languages/universe/ruby are both 404, but I suspect that latter one is just falling into the same trap as many namespaces make of using a URL when they meant it as a URN

We're cleaning up the broken links as time goes on, but it is probably obvious to you from browsing around that some parts of the site are still very much under construction.

The JSX noise is CSTML, a data format for encoding/storing parse trees. It's our main product. E.g. a simple document might look something like ` 'true' `. It's both the concrete syntax and the semantic metadata offered as a single data stream.

The easiest way to consume a CSTML document is to print the code stored in it, e.g. `printSource(parseCSTML(document))`, which would get you `true` for my example doc. Since we store all the concrete syntax printing the tree is guaranteed to get you the exact same input program the parser saw. This means you can use this to rearrange trees of source code and then print them over the original, allowing you to implement linters, pretty-printers, or codemod engines.

These CSTML documents also contain all the information necessary to do rich presentation of the code document stored within (syntax highlighting). I'm going to release our native syntax highlighter later today hopefully!

Re: Writing Code Was Never the Bottleneck

#220

Post by LtWorf »

dkdbejwi383 wrote: post #202
a_bonobo wrote: post #171

Earlier quoted context omitted.

>This lead to a kind of effort inversion, where senior devs spent much more time on these PRs than the junior authors themselves. It's funny, I have the same problem, but with subject matter expertise. I work with internal PR people and they clearly have shifted their writing efforts to be AI-assisted or even AI-driven. Now I as the SME get these AI-written blog posts and press releases and I spend a far more time on…

Part of the solution is pushing back when you spot tons of obvious lazy LLM errors instead of fixing them yourself. Otherwise there's not much incentive for them to improve their effort.

I tried but my boss told me to get used to it. So now I no longer review code at all.
Post reply on HN