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

191–200 of 505 posts

Re: Thoughts on slowing the fuck down

#191

Post by Aurornis »

perrygeo wrote: post #145
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…

> 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. 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?

The overwhelming majority of real jobs are not related to these things you read about on Hacker News.

I help a local group with resume reviews and job search advice. A common theme is that junior devs really want to do work in these new frameworks, tools, libraries, or other trending topics they've been reading about, but discover that the job market is much more boring. The jobs working on those fun and new topics are few and far between, generally reserved for the few developers who are willing to sacrifice a lot to work on them or very senior developers who are preferred for those jobs.

Re: Thoughts on slowing the fuck down

#193

Post by zephen »

kerblang wrote: post #128
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…

Engineering is two things: 1. Applied physics - Software is immediately disqualified. Symbols have no physics. 2. Ethics - Lives and livelihoods depend on you getting it right. Software people want to be disqualified because that stuff is so boring, but this is becoming a more serious issue with every passing day.

> Software is immediately disqualified. Symbols have no physics.

Many physical processes are controlled by software.

Re: Thoughts on slowing the fuck down

#194

Post by mysterydip »

perrygeo wrote: post #145
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…

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

I’ve seen so many articles of “introducing flimflam: a squiggle for burfy” it makes my head spin.

Re: Thoughts on slowing the fuck down

#195

Post by Towaway69 »

fantasizr wrote: post #154
Towaway69 wrote: post #124

What the article doesn't touch on is the vendor lock-in that is currently underway. Many corps are now moving to an AI-based development process that is reliant on the big AI providers. Once the codebase has become fully agentic, i.e., only agents fundamentally understand it and can modify it, the prices will start rising. After all, these loss making AI companies will eventually need to recoup on their investments.…

this is a good point. Some of the ai companies are trying to hook cs students so they'll only know "dev" as a function of their products. First one's free as they say (the drug dealers).

I agree, that is the great danger that CS students aren't even taught the fundamentals of "computer science" any longer. It would be the equivalent of physics students not learning Newtons laws or e-m-c-squared.

Probably there is an issue with how much there is in CS - each programming language basically represents a different fundamental approach to coding machines. Each paradigm has its application, even COBOL ;)

Perhaps CS has not - yet - found its fundamental rules and approaches. Unlike other sciences that have hard rules and well trodden approaches - the speed of light is fixed but not the speed of a bit.

Re: Thoughts on slowing the fuck down

#196

Post by [deleted] »

tock wrote: post #91
abletonlive wrote: post #75

Earlier quoted context omitted.

- NFTS doomers? I mean I appreciate the humor here. - Surveillance schizos - Society still works - Global Pedophile Cabal schizos - Again, funny use of 'doomers' but that's what the current society seems to be run by so I wouldn't say it's fitting for doomerism. - People who predicted the flood of people entering Software via bootcamps, etc. would never cause any problems because their god of software is consuming th…

What do you think is a valid doomer warning that came true? Or do you think literally everything that is pessimistic is doomerism?

[deleted]

Re: Thoughts on slowing the fuck down

#197

Post by PaulHoule »

Towaway69 wrote: post #148
PaulHoule wrote: post #130

Earlier quoted context omitted.

Perrow’s book Normal Accidents postulates that, given advances which could improve safety, people just decide to emphasize throughput, speed, profits, etc. he turned out to be wrong about aviation (got much safer over time) and maritime shipping (there was a perception of a safety crisis in the late 1970s with oil tankers exploding, now you just hear about the odd exceptional event.)

> Perrow argues that multiple and unexpected failures are built into society's complex and tightly coupled systems, and that accidents are unavoidable and cannot be designed around.[1] This is definitely something that is happening with software systems. The question is: is having an AI that is fundamentally undecipherable in its intention to extend these systems a good approach? Or is an approach of slowing down and…

The other day I was thinking about how stupid little things in the Javascript ecosystem where you have to change your configuration file "just because" are a real billion-dollar mistake and speculating that I could sue some of the developers in small claims court.

Right away I scoffed when I heard people had 20 agents running in parallel because I've been at my share of startups with 20 person teams that tend to break down somewhere between:

- 20 people that get about as much done as an optimal 5 person team with a lot more burnout and backlash

- There is a sprint every two weeks but the product is never done

and people who are running those teams don't know which one they are!

I'm sure there are better ones out there but even one or two SD north of the mean you find that people are in over their heads. All the ceremony of agile hypnotizes people into thinking they are making progress (we closed tickets!) and have a plan (Sprint board!) and know what they are doing (user stories!)

Put on your fieldworker hat and interview the manager about how the team works [1] and the state of the code base and compare that to the ground truth of the code and you tend to find the manager's mental is somewhere between "just plain wrong" and "not even wrong". Teams like that get things done because there are a few members, maybe even dyads and triads, who know what time it is and quietly make sure the things that are important-but-ignored-by-management are taken care of.

Take away those moral subjects and eliminate the filtering mechanisms that make that 20-person manager better than average and I can't help but think 'gas town' is a joke that isn't even funny. Seems folks have forgotten that Yegge used to blog that he owed all his success in software development to chronic cannabis use, like if wasn't for all that weed there wouldn't be any Google today.

[1] I'll take even odds he doesn't know how long the build takes!

Re: Thoughts on slowing the fuck down

#198

Post by moeffju »

vardalab wrote: post #46
jaffee wrote: post #16

> You installed Beads, completely oblivious to the fact that it's basically uninstallable malware. Did I miss something? I haven't used it in a minute, but why is the author claiming that it's "uninstallable malware"?

It's not really malware, but it's a mess. It installed so much shit and it interfered with your git hooks and stuff. It was kind of messy. I kind of gave up on it. I just went back to using built-in claude code todowrite tasks.

Try https://github.com/hmans/beans - I find it a refreshingly pragmatic take that works great with my agents use.

Re: Thoughts on slowing the fuck down

#199

Post by VorpalWay »

mckn1ght wrote: post #134
beachy wrote: post #110

Earlier quoted context omitted.

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

I have talked to colleagues who wrote software running on microcontrollers a decade ago, that software still runs fine. So yes there is set and forget software. And it is all around us, mostly in microcontrollers. But microcontrollers far outnumber classical computers (trivially: each classical computer or phone contain many microcontrollers such as SSD controllers, power management, wifi, ethernet, cellular,... And then you can add appliances, cars etc to that).

If something in software works and isn't internet connected it really is set and forget. And far too many things are being connected needlessly these days. I don't need or want an online washing machine or car.

Re: Thoughts on slowing the fuck down

#200

Post by blargey »

perrygeo wrote: post #145
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…

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

> I strongly suspect that vast majority of the "innovation" in recent years has gone straight to supporting the funding model and institution of the software profession, rather than actual software engineering.

Feels like there’s a counter to the frequent citation of Jevon’s Paradox in there somewhere, in the context of LLM impact on the software dev market. Overestimation of external demand for software, or at least any that can be fulfilled by a human-in-the-loop / one-dev-to-many-users model? The end goal of LLMs feels like, in effect, the Last Framework, and the end of (money in) meta-engineering by devs for devs.

Post reply on HN