Live data from Hacker News

We mourn our craft

nolanlawson.com

741–750 of 918 posts

Re: We mourn our craft

#741
post #543

Earlier quoted context omitted.

"Not as good and costs a lot in hardware" still sounds like I'm at a disadvantage.

$3000 is not that much for hardware (like a refurbished MBP Max with decent amount of RAM), and you'd be surprised how much more useful a thing that is slightly worse than the expensive thing is when you don't have anxiety about token usage.

$3000 might not be much to a wealthy software engineer in the US, but to, say, a college student in Portugal, it's a big expense.

Open source software democratized software in a huge way.

Re: We mourn our craft

#742
post #733

"They can write code better than you or I can" They can not. They can make some average code. On Friday one suggested an NSI installer script that would never bundle some needed files in the actual installer. I can only imagine that a lot of people have made the same mistake (used CopyFiles instead of File ) and posted that mistake on the internet. The true disaster of that being that then testing out that installer…

So it can write better code than your below average software engineer. It still cuts out 40-50% of workforce out. For above average engineers its very good. For bottom half not so much. Translate for Mgrs - it replaces offshore completely.

And it will run rings around me in all the languages I don't know; every case in which my standard would be shockingly bad (I speak no APL whatsoever, for example) it would do better (in some cases, though, it would confidently produce an outcome that was actually worse than my null outcome).

Re: We mourn our craft

#743

Earlier quoted context omitted.

The original pithy comment I was replying to was arguing that we’ll become dependent to a service run by another company. I don’t see that being true for two reasons: 1. You are not forced to use the AI in the first place. 2. If you want to use one, you can self host it one of the open models. That at any moment in time the open models are not equivalent in capabilities to the SOTA paid models is beside the point .

Ok. I don’t think hosting a capable open model is seriously a realistic option for the vast majority of consumers.

Full LLM, no. Not yet.

But there’s new things like sweep [0] that you now can do locally.

And 2-3 years ago capable open models weren’t even a thing. Now we’ve made progress on that front. And I believe they’ll keep improving (both on accessibility and competency).

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

Re: We mourn our craft

#744

Earlier quoted context omitted.

Same. I was born in 84 and have been doing software since 97 it’s never been easier, better or more accessible time to make literally anything - by far. Also if you prefer to code by hand literally nobody is stopping you AND even that is easier. Cause if you wanted to code for console games you literally couldn’t in the 90s without 100k specialized dev machine. It’s not even close. This “I’m a victim because my softw…

I'm not going to code by hand if it's 4x slower than having Claude do it. Yes, I can do that, but it just feels bad. The analogy I like is it's like driving vs. walking. We were healthier when we walked everywhere, but it's very hard to quit driving and go back even if it's going to be better for you.

Coding will take 4 times less time, but review will take almost the same amount of time if not more if the solution does not worl out of the box or has unforseen corner cases.

LLMs were trained on public code libraries and unfortunately most pf that OSS code is garbage.

There are ofcourse raisins there, but those are far in between.

Top it off with hallucinations and suddenly you spend more time debugging messy AI code when you could write the same in a fraction of that time.

The easier the task, the better job LLMs do, the harder the task the worse results you get.

Source: working with those tools daily.

Using your analogy:

- by car it will be 30km uphill, coz of how the road is built

- walking it will be 1km straight line

Re: We mourn our craft

#745
This post is rather like a recent similar post "I miss thinking hard about things". Top comment quoted a metaphor relating to clay. No offense this blog article feels as if an LLM ingested that post and thread and produced a gestalt of it

Re: We mourn our craft

#746
To me this sentiment is silly. Programming was never about the act of writing, but about making the computer do something. Now we can ask computers to helps us write instructions for them. Great if you ask me. And no, your job is not going away because human maintainers will always be required to review changes, communicate with stakeholders and provide a vision for the projects. I have yet to see a chatbot that can REDUCE entropy inside a codebases rather than continuously increase it with more and more slop.

Re: We mourn our craft

#747

Earlier quoted context omitted.

I’ve got 8 year old Go code that still compiles fine on the latest Go compiler. Go has its warts but backwards compatibility isn’t one of them. The language is almost as durable as Perl.

8 years is not that long, if it can still compile in say 20 years then sure but 8 years in this industry isn't that long at all (unless you're into self flagellation by working on the web).

Except 8 years is impressive by modern standards. These days, most popular ecosystems have breaking changes that would cause even just 2-year-old code bases to fail to compile. It's shit and I hate it. But that's one of the reasons I favour Go and Perl -- I know my code will continue to compile with very little maintenance years later.

Plus 8 years was just an example, not the furthest back Go will support. I've just pulled a project I'd written against Go 1.0 (the literal first release of Golang). It's 16 years old now, uses C interop too (so not a trivial Go program), and I've not touched the code in the years since. It compiled without any issues.

Go is one of the very few programming languages that has an official backwards compatibility guarantee. This does lead to some issues of its own (eg some implementations of new features have been somewhat less elegant because the Go team favoured an approach that didn't introduce changes to the existing syntax).

Re: We mourn our craft

#748

Earlier quoted context omitted.

I see what these can do and I'm already thinking, why would I ever hire a junior developer? I can fire up opencode and tell it to work multiple issues at once myself. The bottleneck becomes how fast you can write the spec or figure out what the product should actually be, not how quickly you can implement it. So the future of our profession looks grim indeed. There will be far fewer of us employed. I also miss writin…

You hire the junior developer because you can get them to learn your codebase and business domain at a discount, and then reap their productivity as they turn senior. You don’t get that with an LLM since it only operates on whatever is in its context. (If you prefer to hire seniors that’s fine too - my rates are triple that of a junior and you’re paying full price for the time it takes me learning your codebase, and…

> then reap their productivity as they turn senior

What companies are retaining employees long enough for this?

Re: We mourn our craft

#749

Earlier quoted context omitted.

8 years is not that long, if it can still compile in say 20 years then sure but 8 years in this industry isn't that long at all (unless you're into self flagellation by working on the web).

8 years is only "not that long" because we have gotten better at compatibility. How many similar programs written in 1999 compiled without issue in 2007? The dependency and tooling environment is as robust as it's ever been.

> because we have gotten better at compatibility.

Have we though? I feel the opposite it true. These days developers expect users of their modules and frameworks will be regularly updating those dependencies and doing so dynamically from the web.

While this is true for active code bases. You can quickly find stable but unmaintained code will eventually rot as its dependencies deprecate.

There aren't many languages out there where their wider ecosystem thinks about API-stability in terms of years.

Re: We mourn our craft

#750

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…

There are many tens (hundreds?) of billions of dollars being poured into the smartest minds in the world to push this thing forward I'm not so confident that it'll only be code monkeys for too long

[dead]
Post reply on HN