Live data from Hacker News

Thoughts on slowing the fuck down

mariozechner.at

131–140 of 505 posts

Re: Thoughts on slowing the fuck down

#131

Earlier quoted context omitted.

I’ve had jobs where my title was “software engineer”, but I never refer to myself as such outside of work. When I tell others what I do, I say I am a software developer. It may seem a pointless distinction, but to me there is a distinction. Neither myself nor the vast majority of other “software engineers” in our field are living up to what it should mean to be an “engineer”. The people that make bridges and building…

I was won over by this distinction from another senior some years ago. I think he said… “Developers build things. Engineers build them and keep them running.” I like the linguistic point from a standpoint of emphasizing a long term responsibility.

I like this one from Russ Cox:

"Software engineering is what happens to programming when you add time and other programmers."

Re: Thoughts on slowing the fuck down

#132
post #97

Earlier quoted context omitted.

It's tough to not interpret this as "I don't care about my website". Do you not check the copy? Or what if AI one-shots something that will harm your reputation in the metadata?

Then I'll read the diffs after the fact and have fix AI it. ¯\_(ツ)_/¯

That sounds better. I assume the stakes are low enough that you are happy reviewing after the fact, but setting up a workflow to check the diffs before pushing to production shouldn't be too difficult

Re: Thoughts on slowing the fuck down

#133
post #20

Earlier quoted context omitted.

We live in a world where every line of code written by a human should be reviewed by another human. We can't even do that! Nothing should go straight to prod ever, ever ever, ever.

> Nothing should go straight to prod ever, ever ever, ever. I'm one-shotting AI code for my website without even looking at it. Straight to prod (well, github->cf worker). It is glorious.

Prod in this context doesn't refer to one person's website for their personal project. It refers to an environment where downtime has consequences, generally one that multiple people work on and that many people rely on.

Re: Thoughts on slowing the fuck down

#134
post #110
post #99

Earlier quoted context omitted.

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

Software packages are more complicated than you make them out to be. Off the top of my head:

- license restrictions, relicensing

- patches, especially to fix CVEs, that break assumptions you made in your consumption of the package

- supply chain attacks

- sunsetting

There’s no real “set it and forget it” with software reuse. For that matter, there’s no “set it and forget it” in civil engineering either, it also requires monitoring and maintenance.

Re: Thoughts on slowing the fuck down

#135

Earlier quoted context omitted.

> Nothing should go straight to prod ever, ever ever, ever. I'm one-shotting AI code for my website without even looking at it. Straight to prod (well, github->cf worker). It is glorious.

Prod in this context doesn't refer to one person's website for their personal project. It refers to an environment where downtime has consequences, generally one that multiple people work on and that many people rely on.

This is a bit of a no true Scotsman take but I agree with it anyway.

Re: Thoughts on slowing the fuck down

#136

Eh I think its self-correcting problem Companies will face the maintenance and availability consequences of these tools but it may take a while for the feedback loop to close

Unfortunately, I think the lesson from recent history seems to be that outside of highly-regulated industries, customers and businesses will accept terrible quality as long as it's cheap.

Nah, there is a quality floor that consumers are willing to accept. Once you get below that, where it's actually affecting their lives in a meaningful way, it will self-correct as companies will exploit the new market created for quality products.

Re: Thoughts on slowing the fuck down

#137
post #12

Earlier quoted context omitted.

Maybe in the future humans won't need to pour over every line. However I quickly learn which interns I can trust and which I need to pour over their code - I don't trust AI because it has been wrong too often. I'm not saying AI is useless - I do most of my coding with an agent, but I don't trust it until I verify every line.

I did this for a while… and until Opus 4.5, I couldn't fully trust the model. But at this point, while it does make the occasional mistake, I don't need to scrutinize every line. Unit and integration tests catch the bugs we can imagine, and the bugs we can't imagine take us by surprise, which is how it has always been.

Even with 4.6 I find there are a lot of mistakes it makes that I won't allow. Though it is also really good at finding complex thread issues that would take me forever...

Re: Thoughts on slowing the fuck down

#139
post #129

Earlier quoted context omitted.

This is my business website.

[Note: It may be very risky to submit anything to this users site] I'm not sure doing silly things, then advertizing it is a great way to do business, but to each their own.

So many assumptions.

It is a static website hosted on CF workers.

Post reply on HN