Live data from Hacker News

We mourn our craft

nolanlawson.com

461–470 of 918 posts

Re: We mourn our craft

#461
post #216

These comments are comical. How hard is it to understand that human beings are experiential creatures. Our experiences matter, to survival, to culture, and identity. I mourn the horse masters and stable boys of a century past because of their craft. Years of intuition and experience. Why do you watch a chess master play, or a live concert, or any form of human creation? Should we automate parts of our profession? Yes…

Very well put. Two things are true at the same time, this makes people uneasy.

In fact, contrary things are so very often both true at the same time, in different ways.

Figuring out how to live in the uncomfortableness of non-absolutes, how to live in a world filled with dualisms, is IMO one of the primary and necessary maturities for surviving and thriving in this reality.

Re: We mourn our craft

#462
post #14

Earlier quoted context omitted.

For me it's because the same tech is doing it to everyone else in a more effective way (i.e. artists especially). I'm an "art enjoyer" since I was a child and to see it decimated by people who I once looked up to is heartbreaking. Also, if it only affected software, I would've been happy to switch to a more artistic career, but welp there goes that plan.

I feel very similarly, I always thought of software engineering as being my future career. I'm young, I just really got my foot into the industry in my early twenties. It feels like the thing I wanted to do died right when I was allowed to start. I also always felt that if I didn't get to do development, I would try to get into arts which has always been a dream of mine, and now it feels that that died, too. I wish I…

Yeah, the thing that’s different about this technical revolution compared to the previous ones is that it’s not only trying to take out multiple industries, but the creative process as a whole.

Re: We mourn our craft

#463
post #256

Earlier quoted context omitted.

The people outside of us didn’t care about your beautiful code before. Now we can quickly build their boring applications and spend more time building beautiful things for our community’s sake. Yes, there are economic concerns, but as far as “craft” goes, nothing is stopping us from continuing to enjoy it.

Except that's not really true, because the work expands to fill the time allotted. Now we can build more boring applications with fewer people.

Yes, it is true that companies are always hungry for more. But once again, those same companies never cared about beautiful code. They wanted us to build something that works as quickly as possible. In my experience, the beauty of programming was often enjoyed outside of work for this very reason, and we can still enjoy it outside of work for it's own sake.

Re: We mourn our craft

#464
I cannot empathise. If you love writing code, there is nothing stopping you writing code. I write code for fun with no commercial intent all the time, and have for decades. Very few oil painters had a salary.

This is a complaint someone is making about their job propspects thinly wrapped in floral language. I know for some people (it seems especially prominent in Americans I've found) their identity is linked to their job. This is a chance to work on this. You can decouple yourself and redefine yourself as a person.

Who knows? Once you're done you may go write some code for fun again.

Re: We mourn our craft

#465

Earlier quoted context omitted.

> "build the right things" [vs] "build things right" I think this (frequent) comparison is incorrect. There are times when quality doesn't matter and times that it does. Without that context these discussions are meaningless . If I build my own table no one really gives a shit about the quality besides me and maybe my friends judging me. But if I sell it, well then people certainly care[0] and they have every right t…

Of course. I mean, my view is that it needs to be "build the right things right", vs "build things right and then discover if they are the right things". It's a stab at premature optimisation, focusing on code elegance more than delivering working software. Code simplicity, good design, scalability, are super important for maintainability, even in the age of AI (maybe even more so). But considering that AI will more…

  >  it needs to be "build the right things right", vs "build things right and then discover if they are the right things"
I still think this is a bad comparison and I hoped my prior comment would handle this. Frankly, you're always going to end up in the second situation[0] simply because of 2 hard truths. 1) you're not omniscient and 2) even if you were, the environment isn't static.

  > But considering that AI will more and more "build things right" by default
And this is something I don't believe. I say a lot more here[1] but you can skip my entire comment and just read what Dijkstra has to say himself. I dislike that we often pigeonhole this LLM coding conversation into one about a deterministic vs probabilistic language. Really the reason I'm not in favor of LLMs is because I'm not in favor of natural language programming[2]. The reason I'm not in favor of natural language programming has nothing to do with its probabilistic nature and everything to do with its lack of precision[3].

I'm with Dijkstra because, like him, I believe we invented symbolic formalism for a reason. Like him, I believe that abstraction is incredibly useful and powerful, but it is about the right abstraction for the job.

[0] https://news.ycombinator.com/item?id=46911268

[1] https://news.ycombinator.com/item?id=46928421

[2] At the end of the day, that's what they are. Even if they produce code you're still treating it as a transpiler: turning natural language into code.

[3] Okay, technically it does but that's because probability has to do with this[4] and I'm trying to communicate better and most people aren't going to connect the dots (pun intended) between function mapping and probabilities. The lack of precision is inherently representable through the language of probability but most people aren't familiar with terms like "image" and "pre-image" nor "push-forward" and "pull-back". The pedantic nature of this note is precisely illustrative of my point.

[4] https://www.mathsisfun.com/sets/injective-surjective-bijecti...

Re: We mourn our craft

#466

LLMs are only a threat if you see your job as a code monkey. In that case you're likely already obsoleted by outsourced staff who can do your job much cheaper. If you see your job as a "thinking about what code to write (or not)" monkey, then you're safe. I expect most seniors and above to be in this position, and LLMs are absolutely not replacing you here - they can augment you in certain situations. The perks of a…

Yes. And I'm excited as hell. But I also have no idea how people are going to think about what code to write when they don't write code. Maybe this is all fine, is ok, but it does make me quite nervous!

That is definitely a problem, but I would say it’s a problem of hiring and the billion-dollars worth of potential market cap resting on performative bullshit that encourages companies to not hire juniors to send a signal to capture some of those billions regardless of actual impact on productivity.

LLMs benefit juniors, they do not replace them. Juniors can learn from LLMs just fine and will actually be more productive with them.

When I was a junior my “LLM” was StackOverflow and the senior guy next to me (who no doubt was tired of my antics), but I would’ve loved to have an actual LLM - it would’ve handled all my stupid questions just fine and freed up senior time for the more architectural questions or those where I wasn’t convinced by the LLM response. Also, at least in my case, I learnt a lot more from reading existing production code than writing it - LLMs don’t change anything there.

Re: We mourn our craft

#467
post #88

I'll believe it when I start seeing examples of good and useful software being created with LLMs or some increase in software quality. So far it's just AI doom posting, hype bloggers that haven't shipped anything, anecdotes without evidence, increase in CVEs, increase in outages, and degraded software quality.

Well, on the surface it may seem like there’s nothing being created of value, but I can assure you every company from seed stage to unicorns are heavily using claude code, cursor, and the like to produce software. At this point, most software you touch has been modified and enhanced with the use of LLMs. The difference in pace of shipping with and without AI assistance is staggering.

Like the new features in Windows 11? They’ve just anointed a “software quality czar” and I suspect this is not coincidence.

Re: We mourn our craft

#468

Earlier quoted context omitted.

The quality of local models is still abysmal compared to commercial SOTA models. You're not going to run something like Gemini or Claude locally. I have some "serious" hardware with 128G of VRAM and the results are still laughable. If I moved up to 512G, it still wouldn't be enough. You need serious hardware to get both quality and speed. If I can get "quality" at a couple tokens a second, it's not worth bothering. T…

Good by what standard? Compared to SOTA today? No they're not. But they are better than the SOTA in 2020, and likely 2023. We have a magical pseudo-thinking machine that we can run locally completely under our control, and instead the goal posts have moved to "but it's not as fast as the proprietary could".

My comparison was today's local AI to today's SOTA commercial AI. Both have improved, no argument.

It's more cost effective for someone to pay $20 to $100 month for a Claude subscription compared to buying a 512 gig Mac Studio for $10K. We won't discuss the cost of the NVidia rig.

I mess around with local AI all the time. It's a fun hobby, but the quality is still night and day.

Re: We mourn our craft

#469

I started programming over 40 years ago because it felt like computers were magic. They feel more magic today than ever before. We're literally living in the 1980s fantasy where you could talk to your computer and it had a personality. I can't believe it's actually happening, and I've never had more fun computing. I can't empathize with the complaint that we've "lost something" at all. We're on the precipice of somet…

The golden age for me is any period where you have the fully documented systems. Hardware that ships with documentation about what instructions it supports. With example code. Like my 8-bit micros did. And software that’s open and can be modified. Instead what we have is: - AI which are little black boxes and beyond our ability to fully reason. - perpetual subscription services for the same software we used to “own”.…

Actually this makes me think of an interesting point. We DO have too many layers of software.. and rebuilding is always so cost prohibative.

Maybe an iteresting route is using LLMs to flatten/simplify.. so we can dig out from some of the complexity.

Re: We mourn our craft

#470

Earlier quoted context omitted.

The golden age for me is any period where you have the fully documented systems. Hardware that ships with documentation about what instructions it supports. With example code. Like my 8-bit micros did. And software that’s open and can be modified. Instead what we have is: - AI which are little black boxes and beyond our ability to fully reason. - perpetual subscription services for the same software we used to “own”.…

Have you tried using GenAI to write documentation? You can literally point it to a folder and say, analyze everything in this folder and write a document about it. And it will do it. It's more thorough than anything a human could do, especially in the time frame we're talking about. If GenAI could only write documentation it would still be a game changer.

The problems about documentation I described wasn’t about the effort of writing it. It was that modern chipsets are trade secrets.

When you bought a computer in the 80s, you’d get a technical manual about the internal workings of the hardware. In some cases even going as far as detailing what the registers did on their graphics chipset or CPU.

GenAI wouldn’t help here for modern hardware because GenAI doesn’t have access to those specifications. And if it did, then it would already be documented so we wouldnt need GenAI to write it ;)

Post reply on HN