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

Thoughts on slowing the fuck down

mariozechner.at

Post reply on HN
Print view View original

101–110 of 505 posts

Re: Thoughts on slowing the fuck down

#101

Post by tayo42 »

dec0dedab0de wrote: post #93
badlibrarian wrote: post #5

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understand…

I'm not even sure building software is an engineering discipline at this point. Maybe it never was. It's a craft.

Software reminds me more of construction or home contracting work then engineering.

We do the actual building of things

Re: Thoughts on slowing the fuck down

#102

Post by SoftTalker »

JoshTriplett wrote: post #89
AnimalMuppet wrote: post #80

Earlier quoted context omitted.

Depends on the country. In some countries, it is a legal axiom (or at least identity). For the other countries, though, arguing "some countries do it that way" is as persuasive as "some countries drive on the other side of the road." It's true, but so what? Why should we change to do it their way?

> Depends on the country. In some countries, it is a legal axiom (or at least identity). As I said, "That may be true in some jurisdictions, but it's not axiomatically or definitionally true.". The law is emphatically not an axiom , nor is it definitionally right or wrong, or correct or incorrect; it only defines what's legal or illegal. When the article raised the question of whether "building software is an enginee…

To my mind, the term "engineering discipline" implies something roughly analogous to Electrical Engineering, Civil Engineering, Mechanical Engineering, Chemical Engineering.

There is no such rigorous definition for "software engineer" which normally is just a self-granted title meaning "I write code."

Re: Thoughts on slowing the fuck down

#103

Post by bonoboTP »

somethingsome wrote: post #86
kemiller2002 wrote: post #24

Earlier quoted context omitted.

Maybe back in the beginning, but I don't think it's an engineering discipline now. I don't think that's bad though. I always thought we tagged on the word "engineer" so that we could make more money. I'm ok with not being one. The engineers I've known are very strict in their approach which is good since I don't want my deck to fall down. Most of us are too risky with our approach. We love to try new things and patte…

At the same time, if you remove 'engineer' , informatics should fall under the faculty of Science, so scientists, which are even more rigorous than engineers ;) Maybe software tinkerer?

> scientists, which are even more rigorous than engineers ;)

You should see the code that scientists write...

Re: Thoughts on slowing the fuck down

#104

Post by _dwt »

badlibrarian wrote: post #5

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understand…

> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".

- Edsger Dijkstra, 1988

I think, unfortunately, he may have had us all dead to rights on this one.

Re: Thoughts on slowing the fuck down

#105

Post by AnimalMuppet »

bikelang wrote: post #32
ketzo wrote: post #6

I think the core idea here is a good one. But in many agent-skeptical pieces, I keep seeing this specific sentiment that “agent-written code is not production-ready,” and that just feels… wrong! It’s just completely insane to me to look at the output of Claude code or Codex with frontier models and say “no, nothing that comes out of this can go straight to prod — I need to review every line.” Yes, there are still iss…

Were you not reviewing every line when a human wrote it before it went to prod? I think the output of these tools is about as good as a human would write - which means it needs thorough review if I’m going to be on the hook to resolve its issues at 2AM.

Maybe that's the distinction. If I write it, you can call me at 2AM. If an AI wrote it, call the AI at 2AM.

Oh, it can't take the phone call and fix the issue? Then I'm reviewing its output before it goes into prod.

Re: Thoughts on slowing the fuck down

#106

Post by metobehonest »

abletonlive wrote: post #65
margalabargala wrote: post #52

Earlier quoted context omitted.

Climate change would be a big one. Also, there have been plenty of awful things caused by technological progress. Tons of death and poverty was created by the transition to factories and mechanization 150 years ago. Did we come out the other end with higher living standards? Yes, but that doesn't make the decades of brutal transition period any less awful for those affected.

> Climate change would be a big one. That's generous. Climate scientists were right, climate doomers were definitely wrong. Society is mostly unchanged due to climate change. That's not to say climate has no effect, but it is certainly still not some doomer scenario that's played out. New York and Florida are most certainly not underwater as predicted by the famous "Inconvenient Truth". People still live in deserts j…

The CO2 concentration continues to climb year after year, at an accelerating rate. The world hasn't ended yet because it's still 2026 but it doesn't mean it won't.

We're on a hothouse earth trajectory. All signs point to you not being aware of serious climate research and hanging on to a naive Steven Pinker "everything is always improving" outlook.

Re: Thoughts on slowing the fuck down

#107

Post by layer8 »

ketzo wrote: post #6

I think the core idea here is a good one. But in many agent-skeptical pieces, I keep seeing this specific sentiment that “agent-written code is not production-ready,” and that just feels… wrong! It’s just completely insane to me to look at the output of Claude code or Codex with frontier models and say “no, nothing that comes out of this can go straight to prod — I need to review every line.” Yes, there are still iss…

It’s not archaic, it’s due diligence, until we can expect AI to reliably apply the same level of diligence — which we’re still pretty far off from.

Re: Thoughts on slowing the fuck down

#108

Post by Towaway69 »

skybrian wrote: post #87
badlibrarian wrote: post #5

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understand…

People don't realize how much software engineering has improved. I remember when most teams didn't use version control, and if we did have it, it was crappy. Go through the Joel Test [1] and think about what it was like at companies where the answers to most of those questions was "no." [1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...

At the same time, systems have become far more complex. Back when version control was crap, there weren't a thousand APIs to integrate and a million software package dependencies to manage.

Sure everything seems to have gotten better and that's why we now need AIs to understand our code bases - that we created with our great version control tooling.

Fundamentally we're still monkeys at keyboards just that now there are infinitely many digital monkeys.

Re: Thoughts on slowing the fuck down

#109

Post by slopinthebag »

ketzo wrote: post #6

I think the core idea here is a good one. But in many agent-skeptical pieces, I keep seeing this specific sentiment that “agent-written code is not production-ready,” and that just feels… wrong! It’s just completely insane to me to look at the output of Claude code or Codex with frontier models and say “no, nothing that comes out of this can go straight to prod — I need to review every line.” Yes, there are still iss…

If you keep the scope small enough it can be production ready ootb, and with some stuff (eg. a throwaway React component) who really cares. But I think it's insane to look at the output of Claude Code or Codex with frontier models and say "yep, that looks good to me".

Fwiw OP isn't an agent skeptic, he wrote one of the most popular agent frameworks.

Re: Thoughts on slowing the fuck down

#110

Post by beachy »

dstroot wrote: post #99
badlibrarian wrote: post #5

I suppose everyone on HN reaches a certain point with these kind of thought pieces and I just reached mine. What are you building? Does the tool help or hurt? People answered this wrong in the Ruby era, they answered it wrong in the PHP era, they answered it wrong in the Lotus Notes and Visual BASIC era. After five or six cycles it does become a bit fatiguing. Use the tool sanely. Work at a pace where your understand…

> I'm not even sure building software is an engineering discipline at this point. Maybe it never was. If I engineer a bridge I know the load the bridge is designed to carry. Then I add a factor of safety. When I build a website can anyone on the product side actually predict traffic? When building a bridge I can consult a book of materials and understand how much a material deforms under load, what is breaking point…

Software and bridges are entirely different.

If I need a bridge, and there's a perfectly beautiful bridge one town over that spans the same distance - that's useless to me. Because I need my own bridge. Bridges are partly a design problem but mainly a build problem.

In software, if I find a library that does exactly what I need, then my task is done. I just use that library. Software is purely a design problem.

With agentic coding, we're about to enter a new phase of plenty. If everyone is now a 10x developer then there's going to be more software written in the next few years than in the last few decades.

That massive flurry of creativity will move the industry even further from the calm, rational, constrained world of engineering disciplines.

Post reply on HN