Ask HN: Is looking at the code slowing us down?

rrstagi about 2 hours ago 11 comments

FR version is available. Content is displayed in original English for accuracy.

I know this scares many people, but you can control things with QA, evals, ship quality gates and so on... I know we might have more bugs in the short term, but is not looking at the code the right direction we should go for the long term?

Several important developers switched to this new idea, the ones who work in production grade stuff (one example is Antirez, who just wrote some tweets that inspired this post)

⚡ Community Insights

Discussion Sentiment

93% Positive

Analyzed from 589 words in the discussion.

Discussion (11 Comments)Read Original on HackerNews

mikgp•about 2 hours ago

Slowing us down from what?

In the context of many other measures I think speed is an important measure. Maybe even the key measure. I’ve even written a blog post entitled “reading code is an anti-pattern.”

But if the metric is, slowing us down from having more lines in production then the answer is unequivocally yes.

If the answer is providing customer value, or having a sustainable engineering culture. Then I’m not so sure. I’m not saying I believe the opposite, but it feels like excessively optimizing on the wrong thing.

Ultimately I think this asks the wrong question, I think most other surrounding questions is the right one which is - how do you safely and quickly deploy the right code to production that delivers customer value.

I think that will continue going forward involve doing so in an automated fashion, but then the right question isn’t, “should we stop reading code”. But something like “what is the right way to ship intent to production”

Because if you do the first without the second…

rstagi•about 1 hour ago

Yes I meant delivering value ofc, and I love the framing you propose, so my question is: are we already at the point where we could go safely faster, if we didn’t look at the code?

mikgp•22 minutes ago

I think it’s a maturity model question, and an individual ability question. And maybe an industry tooling question.

Individual ability? Newer engineers should read and write more code than experienced engineers.

Maturity model? Teams with better access to objective specifications can read less code than teams without it. Teams with more experience with building loops and validation frameworks the same.

Industry tooling? I think we need more work on the spec driven development front. Some set of standards as to how we define contracts that LLMs can operate against that are more deterministic.

verdverm•about 2 hours ago

I see significant decline in product quality this year among those companies most pilled (Ant, Goog, Msft, etc...). I had been commenting that Atlassian turned a page and Jira was running quite well, but this year... their internal push on Rovo has shown in their product, and their new `twg` CLI is some real slop where help text doesn't match the code.

al_borland•about 1 hour ago

Speed has never been my number one goal. I’m not sure why I’d start to optimize for that now.

rstagi•about 1 hour ago

Speeding up delivering value to the users seem a pretty good goal to me tbh

al_borland•21 minutes ago

You mention in the original post having more bugs. When I use something for the first time and it has a bunch of bugs that prevent me from using it, I never bother using it again. That loss of trust is hard to win back and it erases the potential value. I want to deliver a good experience to the user, first and foremost, so they actually come back.

As a user, I’d rather the developers release later with a solid product/feature.

As a developer, I’d rather release something that won’t be a support nightmare.

theandrewbailey•about 2 hours ago

Looking both ways before crossing the street slows you down too, but it's done for good reasons. Ignore reading code at your own peril.

rstagi•about 2 hours ago

Great example! You usually don’t look both ways if you have a semaphor though, so maybe all we need is good semaphors. I hope the metaphor holds :)

rvz•about 2 hours ago

> I know we might have more bugs in the short term, but is not looking at the code the right direction we should go for the long term?

Would you drive without looking at the road (or blindfolded) because we now have autonomous vehicles?

Not looking at where you are driving and also never looking or understanding what the code does, makes no sense in the long term. Especially in the event of a disaster.

Both have something called "liability" and it gets expensive when it goes wrong.

> Several important developers switched to this new idea, the ones who work in production grade stuff (one example is Antirez, who just wrote some tweets that inspired this post)

Does that mean we should blindly follow them? Just because someone else is doing it does not mean you should too.

A better questions is...have we lost the ability to think for ourselves because we have LLMs doing all the thinking instead?

verdverm•about 2 hours ago

The issue is long-term code quality. These things are not good at it. They locally optimize, reimplement (inconsistently), and are overly defensive. You can only observe this by looking at the code they produce.