We mourn our craft
881–890 of 918 posts
Re: We mourn our craft
#882This perspective was mine 6 months ago. And god damn, I do miss the feeling of crafting something truly beautiful in code sometimes. But then, as I've been pushed into this new world we're living in, I've come to realize a couple things: Nothing I've ever built has lasted more than a few years. Either the company went under, or I left and someone else showed up and rewrote it to suit their ideals. Most of us are doin…
Interesting, I still have code I wrote 20 years ago being used in production.
With a little bit of smug satisfaction about the fact that my 20-year-old mission-critical code is running flawlessly, noticed by people only when it needs to be rebooted to update some connectivity configuration, while the 11 teams of some overpriced consultancy that was supposed to replace it have been struggling for five years now, having swallowed ten times the budget and not even being close to matching the functionality of my own code.
This gap will only widen with the generation of LLM coders.
Re: We mourn our craft
#883"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…
You left out the key line “and you don’t believe me, wait six months”. These models are getting better all the time. The term “vibe coding” was only coined a year ago, around the same time as the release of Claude Code. It doesn’t matter if you don’t think it’s good yet, because it’s brand new tech and it keeps improving.
Re: We mourn our craft
#884Earlier quoted context omitted.
Except it's not. Traditional algorithms are well understood because they're deterministic formulas. We know what the output is if we know the input. The surprises that happen with traditional algorithms are when they're applied in non-traditional scenarios as an experiment. Whereas with LLMs, we get surprised even when using them in an expected way. This is why so much research happens investigating how these models…
I don’t know what to tell you other than to say that the concept of determinism in engineering is extremely new Everything you said right now holds equally true for chemical engineering and biomedical engineering so like you need get some experience
Re: We mourn our craft
#885Earlier quoted context omitted.
We know why they work, but not how . SotA models are an empirical goldmine, we are learning a lot about how information and intelligence organize themselves under various constraints. This is why there are new papers published every single day which further explore the capabilities and inner-workings of these models.
You can look at the weights and traces all you like with telemetry and tracing If you don’t own the model then you have a problem that has nothing to do with technology
Re: We mourn our craft
#886LLMs 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…
Re: We mourn our craft
#887Earlier quoted context omitted.
But it write mostly useless documentation Which take time to read and decipher. And worse, if you are using it for public documentation, sometimes it hallucinate endpoints (i don't want to say too much here, but it happened recently to a quite used B2B SaaS).
Loop it. Use another agent (from a different company helps) to review the code and documentation and call out any inconsistencies. I run a bunch of jobs weekly to review docs for inconsistencies and write a plan to fix. It still needs humans in the loop if the agents don’t converge after a few turns, but it’s largely automatic (I baby sat it for a few months validating each change).
Re: We mourn our craft
#888Earlier quoted context omitted.
But it write mostly useless documentation Which take time to read and decipher. And worse, if you are using it for public documentation, sometimes it hallucinate endpoints (i don't want to say too much here, but it happened recently to a quite used B2B SaaS).
It can generate useful documentation or useless documentation. It doesn't take very long to instruct the LLM to generate the documentation, and then check if it matches your understanding of the project later. Most real documentation is about as wrong as LLM-generated documentation anyway. Documenting code is a language-to-language translation task, that LLMs are designed for.
Re: We mourn our craft
#889Earlier quoted context omitted.
> why would I ever hire a junior developer Because a junior developer doesn't stay a junior developer forever. The value of junior developers has never been the code they write. In fact, in my experience they're initially a net negative, as more senior developers take time to help them learn. But it's an investment, because they will grow into more senior developers.
The question really is what you think the long term direction of SWE as a profession is. If we need juniors later and senior's become expensive that's a nice problem to have mostly and can be fixed via training and knowledge transfer. Conversely people being hired and trained, especially when young into a sinking industry isn't doing anyone any favors. While I think both sides have an argument on the eventual SWE car…
Yes exactly!
What will SWE look like in 1 year? 5 years? 10?
Hiring juniors implies you're building something that's going to last long enough that the cost of training them will pay off. And hiring now implies that there's some useful knowledge/skill you can impart upon them to prepare them.
I think two things are true: there will be way fewer developer type jobs, full stop. And I also think whatever "developers" are / do day to day will be completely alien from what we do now.
If I "zoom out" and put my capitalist had on, this is the time to stop hiring and figure out who you already have who is capable of adapting. People who don't adapt will not have a role.
> If you think that the industry shrinks then its better to hold off so you get more out of your current staff, and you don't "hire to fire". Hopefully the industry on average shrinks in proportion to natural retirement of staff - I've seen this happen for example in local manufacturing where the plant lives but slowly winds down over time and as people retire they aren't replaced.
You can look even closer than that - look at some legacy techs like mainframe / COBOL / etc. Stuff that basically wound down but lasted long enough to keep seniors gainfully employed as they turned off the lights on the way out.
Re: We mourn our craft
#890I 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…
> we're definitely in a golden age of computing. Certainly not. Computers are still magic, but much of that magic is now controlled and being restricted by someone other than you. Today most people's only computer is a cell phone, which is heavily locked down and designed for media consumption and to collect and give away every scrap of their personal/private data. Most people's desktop computers aren't much better.…