i like the article and what it says, but not sure why cursing was necessary
Thoughts on slowing the fuck down
161–170 of 505 posts
Re: Thoughts on slowing the fuck down
#162Earlier quoted context omitted.
That's a great shout because I'm sure a lot of people would otherwise just discredit this take as just another anti-ai skeptic. But he probably has more experience working with LLM's and agents than most of us on this site, so his opinion holds more weight than most.
If you were going to dismiss an argument because of who it comes from rather than its content, that is a flaw in your thinking. The argument is correct, or it isn't, no matter who said it.
Your ability to evaluate whether the argument is correct is limited. In theory, the author and the correctness of the argument are unrelated; in practice, the degree of experience the author has with the topic they’re making an argument on does indeed have some correlation with the argument and should influence the attention you give to arguments, especially counterintuitive ones.
Re: Thoughts on slowing the fuck down
#163I 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…
The way the authors of the book on material strengths got those numbers, was through testing. If you're using mature technologies, that testing has been done by others and you can rely on it for your design, at least in a general way. Otherwise you have to do the testing yourself, which is something a structural engineering project might do also, if it's unusual in some way.
Re: Thoughts on slowing the fuck down
#164Earlier quoted context omitted.
> Nothing should go straight to prod ever, ever ever, ever Air Traffic Controller software - sure. 99% of other softwares around that are not mission-critical (like Facebook) just punch it to production - "move fast and break shit" has been cool way before "AI"
There's a lot of software in between Air Traffic Controller and Facebook. And honestly would Meta be okay with Instagram or Facebook going down even for just a few minutes? I'd think at this point that'd be considered a fairly severe incident. Even if we ignore criticality, things just get really messy and confusing if you push a bunch of broken stuff and only try to start understanding what's actually going on after…
> And honestly would Meta be okay with Instagram or Facebook going down even for just a few minutes?
sure, they coined the term “move fast and break things”
and not every “bug” brings the system down, there is bugs after bugs after bugs in both facebook and insta being pushed to production daily, it is fine… it is (almost) always fine. if you are at a place where “deploying to production” is a “thing” you better be at some super mission-critical-lives-at-stake project or you should find another project to work on.
Re: Thoughts on slowing the fuck down
#165I 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…
> What are you building? This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs? Hard to sha…
>> The last 10 years in the software industry in particular seems full of meta-work. Building new frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. All to build... what exactly? Are these tools necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs?
This is because all the low-hanging fruit has already been built. CRM. Invoicing. HR. Project/task management. And hundreds of others in various flavors.
Re: Thoughts on slowing the fuck down
#166I 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…
> What are you building? This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs? Hard to sha…
This is a good point. I've seen people with really complex AI setups (multiple agents collaborating for hours). But what are they building? Are they building a react app with an express backend? A next js app? Which itself is a layer on top of an abstraction?
I haven't tried this myself but I'm curious if an LLM could build a scalable, maintainable app that doesn't use a framework or external libraries. Could be danger due to lack of training data but I think it's important to build stuff that people use, not stuff that people use to build stuff that people use to build stuff that....
Not that meta frameworks aren't valuable, but I think they're often solving the wrong problem.
Re: Thoughts on slowing the fuck down
#167Earlier quoted context omitted.
Name a single time doomers were right about anything. Doomers consistently overstate their expected outcome in every single domain and consistently fail to predict how society evolves and adapts. Again: The only people that fear what is coming are those that lack imagination and think we are going to run out of things to do, or run out of problems to create and solve.
> Name a single time doomers were right about anything. - NFTs - Surveillance schizos - Global Pedophile Cabal schizos - Anyone who didn’t believe we were a year out from Star Trek living when LLMs first started picking up steam - People who predicted the flood of people entering Software via bootcamps, etc. would never cause any problems because their god of software is consuming the world too quickly for supply and…
> People who predicted the flood of people entering Software via bootcamps, etc. would never cause any problems because their god of software is consuming the world too quickly for supply and demand to ever be a real concern.
How was this group vindicated? It absolutely has caused problems at orgs and in the industry.
Just look at all the linkedin/twitter/youtube garbage of influencers trying to post boot camp tier advice and a sizable portion of new developers latching on to often questionable advice/viewpoints.
Re: Thoughts on slowing the fuck down
#168I 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…
> What are you building? This x1000. The last 10 years in the software industry in particular seems full of meta-work. New frameworks, new tools, new virtualization layers, new distributed systems, new dev tooling, new org charts. Ultimately so we can build... what exactly? Are these necessary to build what we actually need? Or are they necessary to prop up an unsustainable industry by inventing new jobs? Hard to sha…
> Are these tools necessary to build what we actually need?
I think the entire software industry has reached a saturation point. There's not really anything missing anymore. Existing tools do 99% of what we humans could need, so you're just getting recycled and regurgitated versions of existing tools... slap a different logo and a veneer on it, and its a product.
Re: Thoughts on slowing the fuck down
#169I 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…
There are also fundamentally different acceptance criteria for a bridge vs a website. Failure modes differ. Consequences of failure are nowhere near the same, so risk tolerance is adjusted accordingly. Perhaps true "engineering" really boils down to risk management... is what you're building so potentially destructive that it requires extremely careful thought and risk management? Engineering. If what you're building can fail, and really cause no harm, that's just building.
Re: Thoughts on slowing the fuck down
#170I 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…
One would as sensibly dismiss the concept of an assembly line as "how to build a car if you cannot."
Dijkstra was a mathematician. It is a necessary discipline. If it alone were sufficient, then the "program correctness" fans would have simply and inarguably outdone everyone else forty years ago at the peak of their efforts, instead of having resorted to eloquently whiny, but still whiny, thinkpieces (such as the 1988 example [1] quoted here above) about how and why they would like history to understand them as having failed.
[1] https://www.cs.utexas.edu/~EWD/ewd10xx/EWD1036.PDF [2]
[2] I will freely grant that the man both wrote and lettered with rare beauty, which shames me even in this photocopier-burned example when I compare it to the cheerful but largely unrefined loops and scrawls of my own daily hand.