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

261–270 of 505 posts

Re: Thoughts on slowing the fuck down

#261

Post by nizsle »

organsnyder wrote: post #118
anthk wrote: post #59

Earlier quoted context omitted.

In Europe they are. Call yourself an Engineer without a degree and your company and you will be sued with a big fine, because here you must be legally accountable on disasters and ofc there are hard constraints .

Canada also (at least some provinces). I have quite a few Canadian software engineer colleagues with their iron rings to prove it.

An iron ring does not technically make you an engineer in Canada. It just says you graduated from an engineering program. A P.Eng, which is a professional engineer's license is something you acquire after multiple years of experience and testing.

Re: Thoughts on slowing the fuck down

#262

Post by marcosdumay »

6510 wrote: post #226

I keep returning to this thought: Assuming our abstraction architecture is missing something fundamental, what is it? My gut says something simple is missing that makes all of the difference. One thought I had was that our problem lives between all the things taking something in and spitting something out. Perhaps 90% of the work writing a "function" should be to formally register it as taking in data type foo 1.54.3…

You seem to be describing a type system.

Re: Thoughts on slowing the fuck down

#263

Post by zer00eyz »

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

> People don't realize how much software engineering has improved.

It has, but we have gotten there by stacking turtles, by building so many layers of abstraction that things no longer make sense.

Think about this hardware -> hypervisor -> vm -> container -> python/node/ruby run time all to compile it back down to Bytecode to run on a cpu.

Some layers exist because of the push/pull between systems being single user (PC) and multi user (mainframe). We exacerbated the problem when "installable software" became a "hard problem" and wanted to mix in "isolation".

And most of that software is written on another pile of abstractions. Most codebases have disgustingly large dependency trees. People keep talking about how "no one is reviewing all this ai generated code"... Well the majority of devs sure as shit arent reviewing that dependency tree... Just yesterday there was yet another "supply chain attack".

How do you protect yourself from such a thing... stack on more software. You cant really use "sub repositories/modules" in git. It was never built that way because Linus didnt need that. The rest of us really do... so we add something like artifactory to protect us from the massive pile of stuff that you're dependent on but NOT looking at. It's all just more turtles on more piles.

Lots of corporate devs I know are really bad at reviewing code (open source much less so). The PR code review process in many orgs is to either find the person who rubber-stamps and avoid the people who only bike shed. I suspect it's because we have spent the last 20 years on the leet code interview where memorizing algorithms and answering brain teasers was the filter. Not reading, reviewing, debugging and stepping through code... Our entire industry is "what is the new thing", "next framework" pilled because of this.

You are right that it got better, but we got there by doing all the wrong things, and were going to have to rip a lot of things apart and "do better".

Re: Thoughts on slowing the fuck down

#264

Post by didgetmaster »

jimbokun wrote: post #202
perrygeo wrote: post #145

Earlier quoted context omitted.

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

In my lifetime software has given us: * the ability to find essentially any information ever created by anyone anywhere at anytime, * the ability to communicate with anyone on Earth over any distance instantaneously in audio, video, or text, * the ability to order any product made anywhere and have it delivered to our door in a day or two, * the ability to work with anyone across the world on shared tasks and project…

I see the next really big task for software as the ability to separate the signal from the noise. Sifting the wheat from the chaff has gone from a 'nice to have' to 'rescue my sanity'.

Maybe agents and AI in general will help with that. Maybe it will just make the problem worse.

Re: Thoughts on slowing the fuck down

#265

Post by devin »

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…

Absolutely agree.

I'm watching a team which is producing insane amounts of code for their team size, but the level of thought that has gone into all of the details that would make their product a fit predator to run at scale and solve the underlying business problem has been neglected.

Moving really fast in the wrong direction is no help to anyone.

Re: Thoughts on slowing the fuck down

#266

Post by Towaway69 »

emporas wrote: post #255
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.…

Code is so low entropy that smaller and more economical models will be up to the task the same as gigantic models from big providers are today. No worries there, the huge improvements we see today from GPT and Claude, are at their heart just Reinforcement Learning (CoT, chain of thought and thinking tokens are just one example of many). RL is the cheapest kind of training one can perform, as far as I understand. Plea…

> the open source invisible hand makes everything completely free.

In this case the limitation is the compute. Very few people have the compute required for AI/LLMs locally or for free (comparable to the performance of Claude). So yes, there are plenty of Open Source models that can be used locally but you need to invest in hardware to make that happen and especially if you want the quality that is available from the commercial offerings.

Not to speak of the training of those models. It's all there to make it possible to do this locally however where's the hardware? AWS? Google? There are hidden costs of the Open Source model in this case.

Re: Thoughts on slowing the fuck down

#267

Post by sarchertech »

joshgachnang wrote: post #244
jimbokun wrote: post #225

Earlier quoted context omitted.

You are going to allow a product from a company you have no reason to trust write important software for you and put it into production without checking the code to see what it does?

A lot of us use software written by other people we have no reason to trust and we haven't reviewed - most of open source libraries.

At least with any open source library I use, many other people have.

Re: Thoughts on slowing the fuck down

#268

Post by mikestorrent »

HeWhoLurksLate wrote: post #237
jimbokun wrote: post #202

Earlier quoted context omitted.

In my lifetime software has given us: * the ability to find essentially any information ever created by anyone anywhere at anytime, * the ability to communicate with anyone on Earth over any distance instantaneously in audio, video, or text, * the ability to order any product made anywhere and have it delivered to our door in a day or two, * the ability to work with anyone across the world on shared tasks and project…

I have watched artists thoughtfully integrate digital lighting and the like at a scale I'd never seen before the LLMs rolled up and made it possible to get programs to work without knowing how to program. The fundamental ceiling of what an LLM can do when connected to an IDE is incredible , and orders of magnitude higher than the limits of any no-code / low-code platform conceived thus far. "Democratizing" software -…

Now this is the right take. It's one thing for us to do navel-gazing into the recursive autononomous future; it's another to step back and see what Normal People can do, now that the walls are coming down around our profession. Creating new walls is probably not the answer! From the Cathedral and Bazaar, we now have an entire metaphorical city of development happening, by people who would not have thought it possible a few years ago.

I don't know what the future of my job holds other than what it always had: helping people who have good ideas to get them done properly.

Re: Thoughts on slowing the fuck down

#269

Post by sarchertech »

enraged_camel wrote: post #220
vinyl7 wrote: post #213

Earlier quoted context omitted.

It may exist (with a loose term of exist) but they are all mostly garbage. There's still plenty opportunity to make non-garbage version of things that already exist

This is technically true but also a bit naive. Established incumbents are very difficult to dislodge with merely a better version of their products. This becomes more true the larger the product and the average customer size. A good example is QuickBooks, which is a really janky accounting/bookkeeping software that is almost universally hated, but newer and better solutions haven't been able to capture much market sh…

It’s hard to actually build a better QuickBooks because to build a better QuickBooks you need 1000+ integrations that each took hundreds of man hours to build.

Re: Thoughts on slowing the fuck down

#270

Post by linkregister »

kemiller2002 wrote: post #24
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…

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…

It's an understandable mistake to make; culturally an engineer is defined by the building of physical objects that have extremely high reliability expectations. But "engineer" originally referred to someone who used their ingenuity to build or do things in a manner not routine or primarily physical [1]. Basically an inventor who produced. The main engineering accreditation body in the United States adds the requirement of a professional education, but it is more or less the same [2].

We're engineers.

1. https://en.wikipedia.org/wiki/Engineer#Definition

2. https://www.abet.org/accreditation/accreditation-criteria/cr...

Post reply on HN