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 understanding of what you are building does not exceed the reality of the mess you and your team are actually building if budgets allow.

This seldom happens, even in solo hobby projects once you cost everything in.

It's not about agile or waterfall or "functional" or abstracting your dependencies via Podman or Docker or VMware or whatever that nix crap is. Or using an agent to catch the bugs in the agent that's talking to an LLM you have next to no control over that's deleting your production database while you slept, then asking it to make illustrations for the postmortem blog post you ask it to write that you think elevates your status in the community but probably doesn't.

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

> 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 is, it’s expected lifespan, etc. Does this exist for servers, web frameworks, network load balancers, etc.?

I actually believe that software “could” be an engineering discipline but we have a long way to go