The Programmer Identity Crisis

https://hojberg.xyz/the-programmer-identity-crisis/

by imasl42 • 9 months ago

276 304 9 months ago

hojberg.xyz

protontypes2• 9 months ago

Whenever I see an em dash (—), I suspect the entire text was written by an AI.

psunavy033• 9 months ago

That says more about your lack of writing skills and understanding of grammar than AI.

happytoexplain• 9 months ago

That's simply not true, and pointlessly derogatory.

This article does not appear to be AI-written, but use of the emdash is undeniably correlated with AI writing. Your reasoning would only make sense if the emdash existed on keyboards. It's reasonable for even good writers to not know how or not care to do the extra keystrokes to type an emdash when they're just writing a blog post - that doesn't mean they have bad writing skills or don't understand grammar, as you have implied.

gdulli2• 9 months ago

That's a silly take, just because they existed and were proper grammar before AI slop popularized them doesn't mean they're not statistically likely to indicate slop today, depending on the context.

IncreasePosts• 9 months ago

Referring to an orthographic construct as grammar is not a good indication that you understand what grammar is.

DannyPage• 9 months ago

The article itself is very skeptical of AI, so I highly doubt that's the case.

Also in the footer: "Everything on this website—emdash and all—is created by a human."

amflare• 9 months ago

Ironically, I love using em dashes in my writing, but if I ever have to AI generate an email or summary or something, I will remove it for this exact reason.

dkersten3• 9 months ago

I used to use them, but stopped because I feel it makes people think that I used an AI to write.

defgeneric• 9 months ago

I'm seeing this reaction a lot from younger people (say, roughly under 25). And it's a shame this new suspicion has now translated into a prohibition on the use of dashes.

almosthere• 9 months ago

It's comical too because the only reason AI uses emdashes is because it was so common before AI.

kazinator2• 9 months ago

I use three hyphens. In my case, I picked it up from Knuth's TeX many years ago; it's a lexical notation which typesets to a proper em dash.

Three hyphens---it looks good! When I use three hyphens, it's like I dropped three fast rounds out of a magazine. It demands attention.

protontypes2• 9 months ago

Maybe because the em dash is not on the keyboard of most people? It is not about the dash, but about the long em dash.

random3• 9 months ago

Whenever I see these takes, I'm thinking of Idiocracy - a world built on very simple rules, like yours.

commandlinefan3• 9 months ago

I published a book once (way before LLMs came along). My publisher insisted that I replace parenthetical inserts with em dashes. Humans do use them.

pteetor• 9 months ago

When COBOL was born, some people said, "It's English! We won't need programmers anymore!"

When SQL was born, some people said, "It's English! We won't need programmers anymore!"

Now we have AI prompting, and some people are saying, "It's English! We won't need programmers anymore!"

Really?

Legend24402• 9 months ago

The problem I have with this argument is that it actually is English this time.

COBOL and SQL aren't English, they're formal languages with keywords that look like English. LLMs work with informal language in a way that computers have never been able to before.

skydhash4• 9 months ago

Say that to the prompt guys and their AGENT.md rules.

Formalism is way easier than whatever this guys are concocting. And true programmer bliss is live programming. Common programming is like writing a sheet music and having someone else play it. Live programming is you at the instrument tweaking each part.

layer8• 9 months ago

On the other hand, the problem is exactly that it’s not a formal language.

moritzwarhier• 9 months ago

This is true.

But in faithful adherence to some kind of uncertainty principle, LLM prompts are also not a programming language, no matter if you turn down the temperature to zero and use a specialized coding model.

They can just use programming languages as their output.

sharadov2• 9 months ago

I can't agree more.

names_are_hard• 9 months ago

The thing is... All those people were right. We no longer need the kinds of people we used to call programmers. There exists a new job, only semi related, that now goes by the name programmer. I don't know how many of the original programming professionals managed to make the transition to this new progression.

jimbokun10• 9 months ago

Every time they have been closer to being right.

greymalik• 9 months ago

One could only wonder why they became a programmer in the first place, given their seeming disinterest in coding.

To solve problems. Coding is the means to an end, not the end itself.

careful configuration of our editor, tinkering with dot files, and dev environments

That may be fun for you, but it doesn’t add value. It’s accidental complexity that I am happy to delegate.

GaryBluto2• 9 months ago

These are my thoughts exactly. Whenever I use agents to assist me in creating a simple program for myself, I carefully guide it through everything I want created, with me usually writing pages and pages of detailed plaintext instructions and specifications when it comes to the backends of things, I then modify it and design a user interface.

I very much enjoy the end product and I also enjoy designing (not necessarily programming) a program that fits my needs, but rarely implementing, as I have issues focusing on things.

whynotminot10• 9 months ago

I got a few paragraphs into this piece before rolling my eyes and putting it down.

I consider myself an engineer — a problem solver. Like you said, code is just the means to solve the problems put before me.

I’m just as content if solving the problem turns out to be a process change or user education instead of a code commit.

I have no fetish for my terminal window or IDE.

NewsaHackO3• 9 months ago

The issue is that a lot of “programmers” think bike-shedding is the essence of programming. Fifty years ago, they would have been the ones saying that not using punch cards takes away from the art of programming, and then proudly showing off multiple intricate hole punchers they designed for different scenarios.

Good problem solvers... solve problems. The technological environment will never devalue their skills. It’s only those who rest on their laurels who have this issue.

bcrosby95• 9 months ago

The point of most jobs in the world is to "solve problems". So why did you pick software over those?

MountDoom• 9 months ago

The honest answer that applies to almost everyone here is that as a kid, they liked playing computer games and heard that the job pays well.

It's interesting, because to become a plumber, you pretty much need a plumber parent or a friend to get you interested in the trade show you the ropes. Meanwhile, software engineering is closer to the universal childhood dream of "I want to become an astronaut" or "I want to be a pop star", except more attainable. It's very commoditized by now, so if you're looking for that old-school hacker ethos, you're gonna be disappointed.

whynotminot10• 9 months ago

Why would someone who likes solving problems choose a very lucrative career path solving problems… hmmm

You can also solve problems as a local handyman but that doesn’t pad the 401K quite as well as a career in software.

I feel like there’s a lot of tech-fetishist right now on the “if you don’t deeply love to write code then just leave!” train without somehow realizing that most of us have our jobs because we need to pay bills, not because it’s our burning passion.

aleph_minus_one4• 9 months ago

The point of most jobs in the world is to "solve problems". So why did you pick software over those?

Because in a lot of jobs where you (have to) solve problems, the actual problems to solve are rather "political". So, if you are not good at office politics or you are not a good diplomat, software is often a much better choice.

blashyrk• 9 months ago

coding is the means to an end

...

doesn't add value

What about intrinsic value? So many programmers on HN seem to just want to be MBAs in their heart of hearts

NeutralCrane3• 9 months ago

Some of you have never been laid off and it shows.

Intrinsic value is great, where achievable. Companies do not care at all about intrinsic value. I take pride in my work and my craft to the extent I am allowed to, but the reality is that those of us who can’t adapt to the businesses desires will be made obsolete and cut loose, regardless of whatever values we hold.

dingnuts• 9 months ago

A chef who sharpens his knives should stop because it doesn't add value

A contractor who prefers a specific brand of tool is wrong because the tool is a means to an end

This is what you sound like. Just because you don't understand the value of a craftsman picking and maintaining their tools doesn't mean the value isn't real.

senordevnyc6• 9 months ago

Yes, but the point of being a chef is the food, not the knives. If there's a better way to prepare food than a knife, but you refuse to change, are you really a chef? Or are you a chef knife enthusiast?

ares623• 9 months ago

Careful with the “doesn’t add value” talk. If you follow it far enough to its logical end, you get to “Existence doesn’t add value”

cool_man_bob2• 9 months ago

That’s the point lol.

jckahn• 9 months ago

This is one of those random internet comments that I'll be thinking about for decades. Thank you for sharing it!

codyb5• 9 months ago

Configuring editors, dot files, and dev environments consistently adds value by giving you familiarity with your working environment, honing your skills with your tools, and creating a more productive space tailored to your needs.

Who else becomes the go to person for modifying build scripts?

The amount of people I know who have no idea how to work with Git after decades in the field using it is pretty amazing. It's not helpful for everyone else when you're the one they're delegating their merge conflict bullshit too cause they've never bothered to learn anything about the tools they're using.

mupuff12342• 9 months ago

Have you considered that the problem is with Git and not the users?

wolvesechoes2• 9 months ago

but it doesn’t add value

Sad to see people reduce themselves willingly to cogs inside business machine.

keeda• 9 months ago

You can spend as much time as you want on "configuration of our editor, tinkering with dot files, and dev environments" and otherwise honing your craft, the business machine will still look at you as cogs.

May seem depressing, but the bright side is that you as an individual are then free to find joy in your work wherever you can find it... whether its in delivering high-quality code, or just collecting a paycheck.

kiitos• 9 months ago

To solve problems. Coding is the means to an end, not the end itself.

solving problems is an outcome of programming, not the purpose of programming

gr4vityWall• 9 months ago

Coding is the means to an end, not the end itself. That may be fun for you, but it doesn’t add value

I'm not disagreeing with you per se, but those statements are subjective, not an objective truth. Lots of people fundamentally enjoy the process of coding, and would keep doing it even in a hypothetical world with no problems left to solve, or if they had UBI.

davidw• 9 months ago

I think the author makes a decent point with regards to 'problem solving' and better tools and how LLM's somehow feel different. Fortran is a better tool, but you can still reproducibly trace things back to assembly code through the compiler.

LLM's feel like a non-deterministic compiler that transforms English into code of some sort.

CuriouslyC6• 9 months ago

To solve problems. Coding is the means to an end, not the end itself.

100% this. I think a lot of the people who are angry at AI coding for them are "code calligraphers" who care more about the form of the thing they're making than the problem that it solves. I can't see how someone's who's primarily solution focused would shed a tear at AI coding for them.

toprerules3• 9 months ago

Coding is the means to an end, not the end itself.

For the early MIT hackers, and for many of us still today, it absolutely is.

It's also not about the input mechanisms, which have changed over the years. Solving problems, turning complexity into simplicity, cool hacks, that's what the hacker ethos is about. It's not about driving "value".

I suppose you also feel that there's no value in learning a musical instrument either.

RamtinJ953• 9 months ago

I think "Identity Crisis" is a bit over dramatic, but I for the most part agree with the sentiment. I have written something in the same vane, but still different enough that I would love to comment it but its just way more efficient to point to my post. I hope that is OK: https://handmadeoasis.com/ai-and-software-engineering-the-co...

mncharity• 9 months ago

I liked your emphasis on individual diversity, and an attendant need to explore, select, adapt, and integrate tooling. With associated self-awareness. Pushing that further, your "categories" seem more like exemplars/prototypes/archetypes/user-stories, helpful discussion points in a high-dimensional space of blended blobs. And as you illustrate, it branches not just on the individual, but also on what they are up to. And not just on work vs hobby, but on context and task.

It'd be neat to have a big user story catalog/map, which tracks what various services are able to help with.

I was a kid in NE43 instead of TFA's Building 26 across the street - with Lisp Machines and 1980s MIT AI's "Programmer's Apprentice" dreams. I years ago gave up on ever having a "this... doesn't suck" dev env, on being able to "dance code". We've had such a badly crippling research and industrial policy, and profession... "not in my lifetime" I thought. Knock on wood, I'm so happy for this chance at being wrong. And also, for "let's just imagine for a moment, ignoring the utterly absurd resources it would take to create, science education content that wasn't a wretched disaster... what might that look like?" - here too it's LLMs, or no chance at all.

RamtinJ953• 9 months ago

That is actually a great idea, and I agree it would be very useful to have such a catalog/map!

I wonder though if the space is mature enough for such a map or if it would become to generic to say anything meaningful.

jimbokun10• 9 months ago

I can think of few truer identity crises than having a craft you have spent years honing and perfecting automated away.

RamtinJ953• 9 months ago

I fully agree with that statement, but I dont agree with the premise that, that is whats happening currently.

antigremlin2• 9 months ago

That is a very thoughtful piece. Thank you for posting it. I especially like the idea of that new mode of programming (or problem solving, whatever you call it) when people very much enjoy getting an LLM to do what they want.

This is both new and old, because it's the same joy (or dopamine hit) of making a machine do your bidding. Honing your prompts is not that different to honing your shell scripts. I think many people overlook this aspect.

oldestofsports• 9 months ago

Getting rid of the programmer has always been the wet dream of managers, and LLMs are being sold as the solution.

Maybe it is

commandlinefan3• 9 months ago

This comes up whenever _anything_ is automated: "this is the end of programming as a career!" I heard this about Rational Rose in the 90's, and Visual Basic in the 80's.

I don't think I'm sticking my head in the sand - an advanced enough intelligence could absolutely take over programming tasks - but I also think that such an intelligence would be able to take over _every_ thought-related task. And that may not be a bad thing! Although the nature of our economy would have to change quite a bit to accommodate it.

I might be wrong: Doug Hofstadter, who is way, way smarter than me, once predicted that no machine would ever beat a human at chess unless it was the type of machine that said "I'm bored of chess now, I would prefer to talk about poetry". Maybe coding can be distilled to a set of heuristics the way chess programs have (I don't think so, but maybe).

Whether we're right or wrong, there's not much we can do about it except continue to learn.

pmg1013• 9 months ago

Visual Basic didn't exist in the 80's. First release was 1991.

Thanks for reminding me about Rational Rose though! That was a nostalgia trip

pjmlp3• 9 months ago

I can tell that nowadays in what concerns distributed systems built on top of SaaS enterprise products, using MACH architecture approach, my programming at work is quite minimal.

Most of my programming skills are kept up to date on side projects, thanfully I can managed the time to do them, between family and friends.

mathieudombrock• 9 months ago

I found this article really interesting. This is pretty much exactly how I feel about LLM programming.

I really enjoy programming and like the author said, it's my hobby.

On some level I kind of resent the fact that I don't really get to do my hobby for work any more. It's something fundamentally different now.

knuckleheads• 9 months ago

Creative puzzle-solving is left to the machines, and we become mere operators disassociated from our craft.

For me, at least, this has not been the case. If I leave the creative puzzle-solving to the machine, it's gonna get creative alright, and create me a mess to clean up. Whether this will be true in the future, hard to say. But, for now, I am happy to let the machines write all the React code I don't feel like writing while I think about other things.

Additionally, as an aside, I already don't think coding is always a craft. I think we want it to be one because it gives us the aura of craftspeople. We want to imagine ourselves as bent over a hunk of marble, carving a masterpiece in our own way, in our time. And for some of us, that is true. For most programmers in human history though, they were already slinging slop before anybody had coined the term. Where is the inherent dignity and human spirit on display in the internal admin tool at a second tier insurance company? Certainly, there is business value there, but it doesn't require a Michalengo to make something that takes in a pdf and spits out a slightly changed pdf.

Most code is already industrial code, which is precisely the opposite of code as craft. We are dissociated from the code we write, the company owns it, not us, which is by definition the opposite of a craftsmen and craft mode of production. I think AI is putting a finer, sharper point on this, but it was already there and has been since the beginning of the field.

thorn• 9 months ago

Thank you, author. This essay made my day. It resonates with my thinking of last months. I tried to use AI at work, but most of times I regrettably scratched whatever it did and did stuff on my own. So many points I agree with. Delegating thinking to AI is the worst thing I can do to my career. AI at best is mediocre text generator.

So funny to read how people attack author using non-related to the essay’s message criticism.

cardanome2• 9 months ago

The worst thing for me is that I am actually good at LLM-based coding

My coworkers that are in love with this new world are producing complete AI slop and still take ages to complete tasks. Meanwhile I can finally play my strength as I actually know software architecture, can ask the LLM to consider important corner case and so on.

Plus, I am naturally good at context management. Being neurodivergent has given me decades of practice in working with entities that have a different way of thinking that me own. I have more mechanical empathy for the LLM because I don't confuse it for a human. My coworkers meanwhile get super frustrated that the LLM can not read their mind.

That said, LLMs are getting better. My advantage will not last. And the more AI slop gets produced the more we need LLMs to cope with all the AI slop in our code bases. A vicious cycle. No one will actually know what the code does. Soon my job will mostly consist of praying to the machine gods.

interroboink• 9 months ago

It seems to me that someone like you, seen from the outside (e.g. from a code-reviewing colleague), simply appears to be getting more productive, with no drop in quality. Maybe some stylistic shifts.

I don't think anyone is complaining about that too much. I wonder how many people there are like you, where we don't get much data. If people don't complain about it, we generally don't hear about it, because they're just quietly moving on with their work.

Not to be confused with the AI hypesters who are loudly touting the benefits with dubious claims, of course (:

intuitionist• 9 months ago

A Russell conjugation: my LLM-based coding output, your Claude throwaway code, his complete AI slop.

GaryBluto2• 9 months ago

Creative puzzle-solving is left to the machines, and we become mere operators disassociated from our craft.

You could say that about programming languages in general. "Why are we leaving all the direct binary programming for the compilers?"

AfterHIA• 9 months ago

John Von Neumann famously questioned the value of compilers. Eventually we get the keyboard kids that have dominated computing since the early 70's in some form or another whether in a forward thinking way like Dan Ingalls or in an idealic way like the gcc/Free Software crowd. In parallel to this you have people like Laurel, Sutherland, Nelson who live in lateral thinking land.

The real issue is that we've been in-store for a big paradigm shift in how we interact with computers for decades at this point. SketchPad let us do competent, constraints based mathematics with images. Video games and the Logo language demonstrate the potential for programming using, "kinetics." In the future we won't code with symbols we'll dance our intent into and through the machine.

https://www.youtube.com/watch?v=6orsmFndx_o http://www.squeakland.org/tutorials/ https://vimeo.com/27344103

JKCalhoun• 9 months ago

Full disclosure: I am old.

When I started programming for Corporate™ back 1995, it was a wildly different career than what it has become. Say what you want about the lunatics running the asylum, but we liked it that way. Engineering knew their audience, knew the tech stack, knew what was going on in "the industry", ultimately called the shots.

Your code was your private sandbox. Want to rewrite it every other release? Go for it. Like to put your curly braces on a new line? Like TABs (good for you)? Go for it. It's your code, you own it. (You break it, you fix it.)

No unit tests (we called that parameter checking). No code reviews (well, nothing formal — often, time was spent in co-workers offices talking over approaches, white-boarding API… Often if a bug was discovered or known, you just fixed it. There may have been a formal process beginning, but to the lunatics, that was optional.

You can imagine how management felt — having to essentially just trust the devs to deliver.

In the end management won, of course.

When I am asked if I am sorry that I left Apple, I have to tell people, no. I miss working at Apple in the 90's, but that Apple was never coming back. And I hate to say it, but I suspect the industry itself will never return to those "cowboy coding" days. It was fun while it lasted.

dugmartin• 9 months ago

I started around the same time. No unit tests but we did have code reviews because of ISO 9001 requirements. That meant printing out the diffs on the laser printer and corralling 3 people into a meeting room to pour over them and then have them literally sign off on the change. This was for an RTOS that ran big industrial controls in things like steel plants and offshore oil rigs.

Project management was a 40 foot Gantt chart printed out on laser printer paper and taped to the wall. The sweet sound of waterfall.

jay_kyburz3• 9 months ago

Try game dev. It's still like that today.

scruple• 9 months ago

Depends. I see the teams around me slowly being corralled like cattle, no longer doing the corralling. My own team is still chiefly cowboys but the writing is on the wall and as we grow younger we lose more and more footing in this battle.

toast0• 9 months ago

And I hate to say it, but I suspect the industry itself will never return to those "cowboy coding" days. It was fun while it lasted.

I don't think the industry will return to it, but I suspect there will be isolated environments for cowboys. When I was at WhatsApp (2011-2019), we were pretty far on the cowboy side of the spectrum... although I suspect it's different now.

IMHO, what's appropriate depends on how expensive errors are to detect before production, and how expensive errors are when detected after production. I lean into reducing the cost to fix errors rather than trying to detect errors earlier. OTOH, I do try not to make embarrassing errors, so I try to test for things that are reasonable to test for.

antonymoose• 9 months ago

Back when I started in the late 2000s you had much clearer lines around your career path and speciality.

There was a difference between a sysadmin and a programmer. Now, I’m expected to be my own sysadmin-ops guy while also delivering features. While I worked on my systems chops for fun on the side, I purposely avoided it on the work side, I don’t usually enjoy how bad vendor documentation, training, etc. can be in the real world of Corporate America.

anal_reactor• 9 months ago

Unfortunately, the problem with cowboy coding is that it takes one idiot in the team to ruin it for everyone. As company grows, there are more and more idiots by pure chance, which means you need bigger and bigger walls to contain the blast radius. If you have a team of trustworrthy engineers then cowboy coding is extremely efficient, but it simply doesn't scale, especially considering how difficult it is to evaluate the quality of given candidate when hiring.

I believe that cowboy coding might still be practiced in small companies, or in small corporate pockets, where the number of engineers doesn't need to scale.

alganet• 9 months ago

I believe this sentiment to be a mistake.

The IT world is waiting for a revolution. Only in order to blame that revolution for the mistakes of a few powerful people.

I would not be surprised if all this revolutionary sentiment is manufactured. That thing about "Luddites" (not a thing that will stick by the way), this nostalgic stuff, all of it.

We need to be much smarter than that and not fall for such obvious traps.

An identity is a target on your back. We don't need one. We don't need to unite to a cause, we're already amongst one of the most united kinds of workers there is, and we don't need a galvanizing identity to do it.

furyofantares• 9 months ago

Ignoring LLMs for a second, some code I write is done in sort of full-craft full-diligence mode, where I am only committing something where I am very proud of it's structure and of every line of code. I know it inside and out, I have reasons for every decision, major or minor, and I don't know of any ways to make it better. Not only is the code excellent, I've also produced a person (me) who is an expert in that code.

Most code is not like that. Most code I want to get something done, and so I achieve something quite a bit below that bar. But some things I get to write in that way, and it is very rewarding to do so. It's my favorite code to write by a mile.

Back to LLMs - I find it is both easier than ever and harder than ever to write code in that mode. Easier than ever because, if I can actually get and stay in that mode psychologically, I can get the result I want faster, and the bar is higher. Even though I am able to write MUCH better code than an LLM is, I can write even better code with LLM assistance.

But it is harder than ever to get into that mode and stay in that mode. It is so easy to just skim LLM-generated code, and it looks good and it works. But it's bad code, maybe just a little bit at first, but it gets worse and worse the more you let through. Heck, sometimes it just starts out as not-excellent code, but every time you accept it without enough diligence the next output is worse. And by the time you notice it's often too late, you've slopped yourself, while also failing to produce an expert in the code that's been written.

emerongi• 9 months ago

Within the past 2 months, as I've started to use AI more, I've had this trajectory:

  1. only using AI for small things, very impressed by it
  2. giving AI bigger tasks and figuring out how to use it well for those bigger tasks
  3. full-agentic mode where AI just does its thing and I review the code at the end
  4. realising that I still need to think through all the code and that AI is not the shortcut I was hoping it to be (e.g. where I can give it a high-level plan and be reasonably satisfied with the final code)
  5. going back to giving AI small tasks

I've found AI is very useful for research, proof-of-concepts and throwaway code of "this works, but is completely unacceptable in production". It's work I tend to do anyway before I start tackling the final solution.

Big-picture coding is in my hands, but AI is good at filling in the logic for functions and helping out with other small things.

dennisy• 9 months ago

I absolutely loved this piece.

I also agree with comments on this thread stating that problem solving should be the focus and not the code.

However my view is that our ability to solve problems which require a specific type of deep thought will diminish over time as we allow for AI to do more of this type of thinking.

Purely asking for a feature is not “problem solving”.

akra• 9 months ago

I think you can enjoy both aspects - both the problem solving and the craft. There will be people who agree that of course from a rational perspective solving the problem is what matters, but for them personally the "fun" is gone. Generally people that identify themselves as "programmers" as the article does would be the people who enjoy problem solving/tinkering/building.

JambalayaJimbo• 9 months ago

What if you want to be a better problem solver (in the tech domain)? Where should you focus your efforts? That's what is confusing to me. There is a massive war between the LLM optimists and pessimists. Whenever I personally use LLM tools, they are disappointing albeit still useful. The optimists tell me I should be learning how to prompt better, that I should be spending time learning about agentic patterns. The pessimists tell me that I should be focusing on fundamentals.

groby_b• 9 months ago

OK, but if you can't find out how to use new tools well, how good are you really as a craftsperson?

"We've always done it this way" is the path of calcification, not of a vibrant craft. And there are certainly many ways you can use LLMs to craft better things, without slop and vibecoding.

bentt• 9 months ago

Some people code to talk and don't want anything said for them. That's okay. Photography and paintings landed in different places with different purposes.

But all of Programming isn't the same thing. We just need new names for different types of programmers. I'm sure there were farmers that lamented the advent of machines because of how it threatened their identity, their connection to the land, etc....

but I want to personally thank the farmers who just got after growing food for the rest of us.

strix_varius• 9 months ago

To me, the most salient point was this:

Code reviewing coworkers are rapidly losing their minds as they come to the crushing realization that they are now the first layer of quality control instead of one of the last. Asked to review; forced to pick apart. Calling out freshly added functions that are never called, hallucinated library additions, and obvious runtime or compilation errors. All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”

LLMs have made Brandolini's law ("The amount of energy needed to refute bullshit is an order of magnitude larger than to produce it") perhaps understated. When an inexperienced or just inexpert developer can generate thousands of lines of code in minutes, the responsibility for keeping a system correct & sane gets offloaded to the reviewers who still know how to reason with human intelligence.

As a litmus test, look at a PR's added/removed LoC delta. LLM-written ones are almost entirely additive, whereas good senior engineers often remove as much code as they add.

CjHuber• 9 months ago

I'd say it depends on how coding assistants are used, when on autopilot I'd agree, as they don't really take the time to reflect on the work they've done before going on with the next feature of the spec. But in a collaborative process that's of course different as you are pointing out things you want to have implemented in a different way. But I get your point, most PR's you'd flag as AI generated slop are the ones where someone just ran them on autopilot and was somewhat satisfied with the outcome, while treating the resulting code as blackbox

jihadjihad• 9 months ago

whereas good senior engineers often remove as much code as they add

https://www.folklore.org/Negative_2000_Lines_Of_Code.html

MisterTea• 9 months ago

"One of my most productive days was throwing away 1000 lines of code." - Ken Thompson

Etheryte• 9 months ago

In my opinion this is another case where people look at it as a technical problem when it's actually a people problem. If someone does it once, they get a stern message about it. If it happens twice, it gets rejected and sent to their manager. Regardless of how you authored a pull request, you are signing off on it with your name. If it's garbage, then you're responsible.

Ekaros• 9 months ago

Maybe the process should have actual two stage pull requests. First stage is you have to comment the request and show some test cases against it. And only then next person has to take a look. Not sure if such flow is even possible with current tools.

tyleo3• 9 months ago

I agree and I’m surprised more people don’t get this. Bad behaviors aren’t suddenly okay because AI makes them easy.

If you are wasting time you may be value negative to a business. If you are value negative over the long run you should be let go.

We’re ultimately here to make money, not just pump out characters into text files.

lezojeda• 9 months ago

What do you do if the manager enables it?

Macha• 9 months ago

The problem is leadership buy in. The person throwing the LLM slop at github has great metrics when the leadership are looking at cursor usage, lines of code, PR numbers, while the person slowing down to actually read wtf the other people are submitting is now so drowning in slop that they have less time to produce on their own. So the execs look at it as the person complaining "not keeping up with the times".

lubujackson• 9 months ago

The solve is just rejecting the commit with a "clean this up" message as soon as you spot some BS. Trust is earned!

crazygringo• 9 months ago

This a million times. If you do this three times, that's grounds for firing. You're literally not doing your job and lying that you are.

It's bizarre to me that people want to blame LLMs instead of the employees themselves.

(With open source projects and slop pull requests, it's another story of course.)

travisgriggs2• 9 months ago

I largely agree with sibling responses.

BUT...

How do have code review be an educational experience for onboarding/teaching if any bad submission is cut down with due prejudice?

I am happy to work with a junior engineer and is trying, and we have to loop on some silly mistakes, and pick and choose which battles to balance building confidence with developing good skills.

But I am not happy to have a junior engineer throw LLM stuff at me, inspired the confidence that the psycophantic AI engendered in it, and then have to churn on that. And if you're not in the same office, how do you even hope to sift through which bad parts are which kind?

pfannkuchen2• 9 months ago

Yeah it doesn’t really seem different from people copy/pasting from stack overflow without reading through it. This isn’t really a new thing, though I guess nobody was really acting like SO was the second coming so it’s probably happening more now.

aleph_minus_one4• 9 months ago

The problem rather is that you still have to stay somewhat agreeable while calling out the bullshit. If you were "socially allowed" to treat colleagues like

All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”

as they really deserve, the problem would disappear really fast.

So the problem that you outlined is rather social, and not the LLMs per se (even though they very often do produce shitty code).

AnimalMuppet2• 9 months ago

They should get a clear explanation of the problem and of the team expectations the first time it happens.

If it happens a second time? A stern talk from their manager.

A third time? PIP or fired.

Let your manager be the bad guy. That's part of what they're for.

Your manager won't do that? Then your team is broken in a way you can't fix. Appeal to their manager, first, and if that fails put your resume on the street.

ge96• 9 months ago

I'm working on the second project handed to me that was vibe-coded. What annoys me assuming it runs is the high number of READMEs which I'm not even sure which one to use/if applicable.

They are usually verbose/include things like "how to run a virtual env for python"

cutemonster• 9 months ago

Lots of READMEs? Might make total sense, if lines of code added, is a metrics the managers look at.

Can't be any compilation errors in a README, no need to worry about bugs. And if they're long and boring enough, no one will ever read them.

AI generated READMEs = free metrics bonus points, for the performance reviews :-)

CaptainOfCoit• 9 months ago

All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”

Now I don't do code reviews in large teams anymore, but if I did and something like that happened, I'd allow it exactly once, otherwise I'd try to get the person fired. Barring that, I'd probably leave, as that sounds like a horrible experience.

bloppe6• 9 months ago

Ya, there's not much you can do when leadership is so terrible. If this kind of workflow is genuinely blessed by management, I would just start using Claude for code reviews too. Then when things break and people want to point fingers at the code reviewer, I'd direct them to Claude. If it's good enough to write code without scrutiny, it's good enough to review code without scrutiny.

cookiengineer• 9 months ago

You have two options: Burn out because you need to correct every stupid line of code, or... Start to not give a damn about quality of code and live a happy life while getting paid.

The sane option is to join the cult. Just accept every pull request. Git blame won't show your name anyways. If CEOs want you to use AI, then tell AIs to do your review, even better.

jakub_g• 9 months ago

I feel like I went through this stage ahead of time, a decade ago, when I was junior dev, and was starting my days by: first reviewing the work of a senior dev who was cramming out code and breaking things at the speed of light (without LLMs); and then leaving a few dozen comments on pull requests of the offshore team. By midday I had enough for the day.

Now that I'm no longer at that company since a few years ago, I'm invincible. No LLM can scare me!

yodsanklai• 9 months ago

All while the author—who clearly only skimmed their “own” code—is taking no responsibility, going “whoopsie, Claude wrote that. Silly AI, ha-ha.”

After you made your colleagues upset submitting crappy code for review, you start to pay attention.

LLM-written ones are almost entirely additive,

Unless you noticed that code has to be removed, and you instruct the LLM to do so.

I don't think LLMs really change the dynamics here. "Good programmers" will still submit good code, easy for their colleagues to review, whether it was written with the help of an LLM or not.

000ooo000• 9 months ago

After you made your colleagues upset submitting crappy code for review, you start to pay attention.

If the only thing keeping you from submitting crappy code is an emotional response from coworkers, you are not a "good programmer", no matter what you instruct your LLM.

zamalek• 9 months ago

LLM-written ones are almost entirely additive

I have noticed Claude's extreme and obtuse reluctance to delete code, even code that it just wrote that I told it is wrong. For example, it might produce a fn:

   fn foo(bar)

And then I say, no, I actually wanted you to "foo with a frobnitz", so now we get:

   fn foo(bar) // Never called
   fn foo_with_frobnitz(bar)

igor474• 9 months ago

This tendency must get reenforced through RL in the training phase. It's very high profile when an LLM deletes the wrong thing, eg https://arstechnica.com/information-technology/2025/07/ai-co...

smoody072• 9 months ago

This is a broader issue about how where we place blame when LLMs are involved. Humans seem to want to parrot the work and take credit when it’s correct while deflecting blame when it’s wrong. With a few well placed lawsuits this paradigm will shift imho

y0eswddl3• 9 months ago

that's just capitalism 101 - privatize profits, socialize failures

brailsafe• 9 months ago

I think this is why I've been feeling less productive overall lately. Partly due to the fact that more code is expected to be produced more quickly, and partly because using an agent or something puts me into the wrong frame of mind where I don't really have the full context of what I've written and why, and the amount of quality work I can produce is necessarily qualified by how much I can reliably review, line-by-line, over whatever period of time.

I've been using them more conservatively, slowing down, and manually writing things more. It's easier when I'm just replicating logic over a bunch of different well-defined properties of a clear type definition or spec, but even then results are a bit questionable sometimes.

Quis_sum• 9 months ago

I am probably too old school: Unless properly documented (the "whats" and especially the "whys") and provided with a test harness (plus the test cases, including all fringe cases btw.) just reject it straight away. And in the case it is provided and you have a hard time understanding it, reject it as well with the comment that, the "demi-god" (author) should provide documentation which mere mortals can follow.

That principle can be applied to both LLM slop and handcrafted rubbish. Eventually most people will get it.

sqircles• 9 months ago

How are these "engineers" maintaining jobs? How is pushing code generated by someone/something else that hasn't even as much as been looked at before acceptable in any realm?

Better yet- why are there orgs that accept this behavior? I know mine is far from it, as they should be.

pjmlp3• 9 months ago

To be honest I already reached that identity crisis even before LLMs.

Nowadays many enterprise projects have become placing SaaS products together, via low code/no code integrations.

A SaaS product for the CMS, another one for assets, another for ecommerce and payments, another for sending emails, another for marketing, some edge product for hosting the frontend, finally some no code tools to integrate everything, or some serverless code hosted somewhere.

Welcome to MACH architecture.

Agents now made this even less about programming, as the integrations can be orchestrated via agents, instead of low code/no code/serverless.

kharak• 9 months ago

I'm in the opposite camp. Programming has never been fun to me, and LLMs are a godsend to deal with all the parts I don't care for. LLMs have accelerated my learning speed and productivity, and believe it or not, programming even started to become fun and engaging!

I will never, ever go back to the time before.

muldvarp3• 9 months ago

I think in a few years, we will realize that LLMs have impacted our lives in a deeply negative way. The relatively small improvements LLMs bring to my life will be vastly outweighted by the negatives.

If LLM abilities stagnate around the current level it's not even out of the question that LLMs will negatively impact productivity simply because of all of the AI slop we'll have to deal with.

igor474• 9 months ago

Hmmm. Interesting prediction. I think even on social media, the consensus is still shaky, and social media is an unalloyed bad IMHO. I think personal cars impacted our lives in a deeply negative way but most people disagree. There is really no consensus on LLMs right now, I think if they stagnate this is where the discourse will stagnate also.

More likely, like other tools, it will be possible to point to clear harms and clear benefits, and people will disagree about the overall impact.

int_19h13• 9 months ago

Let's be clear about one thing, though. LLMs are simply tools, which can be used for good or for bad. It's specific people who do and promote the latter - top management of tech companies, for example. It's those people who are creating the negatives in my life and who tank quality for the sake of "productivity". Point the finger and say it out loud. They shouldn't be able to hide behind the tech.

debo_• 9 months ago

As an aside, I've been using copilot code review before handing off any of my code to colleagues. It's a bit pedantic, but it generally catches all the most stupid things I've done so that the final code review tends to be pretty smooth.

I hate to suggest that the fix to LLM slop is more LLMs, but in this case it's working for me. My coworkers also seem to appreciate the gesture.

jimbokun10• 9 months ago

It’s fascinating idea, though, to invert the process and have devs develop and LLMs do the code reviews. Might be more productive in the long run.

bloppe6• 9 months ago

I agree that LLMs are great for a cursory review, but crucially, when you ask copilot to review your code, you actually read and think about everything copilot tells you in the response. The biggest issues arise because people will blindly submit AI-generated code without reading or thinking about it.

BubbleRings• 9 months ago

Hi op. “Conform or be cast out” ha. Read your article then right after got an email announcing Rush tickets going on sale. Must be a sign I should go.

I forwarded your article to my son the dev, since your post captured the magic of being a programmer so well.

And yes Levy’s book Hackers is most excellent.

apprentice7• 9 months ago

Subdivisions is my favourite song of all time and I thought about Rush as well while reading that line.

sharadov2• 9 months ago

Great read, unlike technologies of the past that automated away the dangerous/boring/repetitive/soul-sucking jobs, LLM's are an assault on our thinking.

Social media already reduced our attention spans to that of goldfish, open offices made any sort of deep meaningful work impossible.

I hope this madness dies before it devours us.

jimbokun10• 9 months ago

Probably too late.

bloppe6• 9 months ago

People have long talked about how reading code is far more important than writing code when working as a professional SWE. LLMs have only increased the relative importance of code review. If you're not doing a detailed code review of every line your LLM generates (just like you should have always been doing while reviewing human-generated code), you're doing a bad job. Sure, it's less fun, but that's not the point. You're a professional.

lordnacho• 9 months ago

Truly, the ideas in this essay are reflected in this comment section.

It's like that trope of the little angel and demon sitting on the protagonist's shoulders.

"I can get more work done"

"But it's not proper work"

"Sometimes it doesn't matter if it's proper work, not everything is important"

"But you won't learn the tools"

"Tools are incidental"

"I feel like I'm not close to the craft"

"Your colleagues weren't really reading your PRs anyway"

"This isn't just another tool"

"This is just another tool"

And so on forever.

I'm staying to think that if you don't have both these opposing views swirling around in your mind, you haven't thought enough about it.

jamboca• 9 months ago

I am a programmer. I don’t think LLMs will replace/wipe out software engineers.

The author sounds like a scribe meditating on the arrival of the printing press.

aeblyve3• 9 months ago

This process has been affecting most of the world's workers for the past several centuries. Programming has received a special treatment for the last few decades, and it's understandable that HN users would jump to protect their life investment, but it need not.

Hand-coding can continue, just like knitting co-exists with machine looms, but it need not ultimately maintain a grip on the software productive process.

It is better to come to terms with this reality sooner rather than later in my opinion.

fellowniusmonk• 9 months ago

I started writing code in basic on a beige box. My first code on windows was a vb6 window that looked like the AOL login screen and used open email relays to send me passwords.

I've written a ton of code in my life and while I've been a successful startup CTO, I've always stayed in IC level roles (I'm in one right now in addition to hobby coding) outside of that, data structures and pipelines, keep it simple, all that stuff that makes a thing work and maintainable.

But here is the thing, writing code isn't my identity, being a programmer, vim vs emacs, mechanical keyboard, RTFM noob, pure functions, serverless, leetcode, cargo culting, complexity merchants, resume driven dev, early semantic css lunacy, these are thing outside of me.

I have explored all of these things, had them be part of my life for better or worse, but they aren't who I am.

I am a guy born with a bunch of heart defects who is happy to be here and trying new stuff, I want to explore in space and abstraction through the short slice of time I've got.

I want to figure stuff out and make things and sometimes that's with a keyboard and sometimes that's with a hammer.

I think there are a lot of societal status issues (devs were mostly low social status until The Social Network came out) and personal identity issues.

I've seen that for 40 years, anything tied to a persons identity is basically a thing they can't be honest about, can't update their priors on, can't reason about.

And people who feel secure and appreciated don't give much grace to those who don't, a lot of callous people out there, in the dev community too.

I don't know why people are so fast to narrow the scope of who they are.

Humans emit meaning like stars emit photons.

The natural world would go on without us, but as far as we have empirically observed we make the maximally complex, multi modally coherent meaning of the universe.

We are each like a unique write head in the random walk of giving the universe meaning.

There are a ton of issues from a network resilience and maximizing the random meaning generation walk where Ai and consolidation are extremely dangerous, I think as far as new stuff in the pipeline it's between Ai and artificial wombs that have the greatest risks for narrowing the scope of human discovery and unique meaning expansion to a catastrophic point.

But so many of these arguments are just post-hoc rationalizations to poorly justify what at root is this loss of self identity, we were always in the business of automating jobs out from under people, this is very weak tea and crocodile tears.

The simple fact is, all our tools should allow us to have materially more comfortable and free lives, the Ai isn't the problem, it's the fact that devs didn't understand that tech is best when empowering people to think and connect better and have more freedom and self determination with their time.

If that isn't happening it's not the codes fault, it's the network architecture of our current human power structures fault.

aeblyve3• 9 months ago

Agree, and well said. There are no points for hard work, only results -- this is an extremely liberating principle when taken to the limit and we should be happy to say goodbye to an era of manual software-writing being the norm, even if it costs the ego of some guy who spent the last 20 years being told SWE made him a demi-god.

isaacremuant2• 9 months ago

This is so funny to me.

Hand-coding is no longer "the future"?

Did an AI write your post or did you "hand write it"?

Code needs to be simple and maintainable and do what it needs to do. Auto complete wasn't a huge time saver because writing code wasn't the bottleneck then and it definitely is not the bottleneck now. How much you rely on an LLM won't necessarily change the quality or speed of what you produce. Specially if you pretend you're just doing "superior prompting with no hand coding involved".

LLMs are awesome but the IDE didn't replace the console text editor, even if it's popular.

bdangubic3• 9 months ago

Code needs to be simple and maintainable and do what it needs to do.

And yet after 3 decades in the industry I can tell you this fantasy exists only on snarky HN comments.

Hand-coding is no longer "the future"?

hand-coding is 100% not the future, there are teams already that absolutely do not hand-code anything anymore (I help with one of them that used to have 19 "hand-coders" :) ). The typing for sure will get phased out. it is quite insane that it took "AI" to make people realize how silly and wasteful is to type characters into IDEs/editors. the sooner you see this clearly the better it will be for your career

How much you rely on an LLM won't necessarily change the quality or speed of what you produce.

if it doesn't you need to spend more time and learn and learn and learn more. 4/6/8 terminals at a time doing all various things for you etc etc :)

Izkata3• 9 months ago

How much you rely on an LLM won't necessarily change the quality or speed of what you produce.

I wouldn't say that, everything I've seen at work indicates the quality will change downwards.

muldvarp3• 9 months ago

I think there is only a very narrow band where LLMs are good enough at producing software that "hand-coding" is genuinely dead but at the same time bad enough that (expensive) humans still need to be paid to be in the loop.

nothrabannosir2• 9 months ago

This process has been affecting most of the world's workers for the past several centuries.

It has also been responsible for predicting revolutions which never failed to materialize. 3D printing would make some kind of manufacturing obsolete, computers would make about half the world's jobs obsolete, etc etc.

Hand coding can be the knitting to the loom, or it can be industrialized plastic injection molding to 3D printing. How do you know? That distinction is not a detail--it's the whole point.

It's survivorship bias to only look at horses, cars, calculators, and whatever other real job market shifting technologies occurred in the past and assume that's how it always happens. You have to include all predictions which never panned out.

As human beings we just tend no to do that.

[EDIT: this being Pedantry News let me get ahead of an inevitable reply: 3D printing is used industrially, and it does have tremendous value. It enabled new ways of working, it grew the economy, and in some cases yes it even replaced processes which used to depend on injection molding. But by and large, the original predictions of "out with the old, in with the new" did not pan out. It was not the automobile to the horse and buggy. It was mostly additive, complementary, and turned out to have different use cases. That's the distinction.]

aeblyve3• 9 months ago

Hand coding can be the knitting to the loom, or it can be industrialized plastic injection molding to 3D printing. How do you know? That distinction is not a detail--it's the whole point.

One could have made a reasonable remark in the past about how injection molding is dramatically faster than 3D printing (it applies material everywhere, all at once), scales better for large parts, et cetera. This isn't really true for what I'm calling hand-coding.

Obviously nothing about the future can be known for certain... but there are obvious trends that need not stop at software engineering.

casey2• 9 months ago

Programmer isn't a real thing, all these classes of people are made up. The biggesdt difference between an iPad Toddler and Dijkstra is that the toddler is much more efficient at programming.

Sure you can discover things that aren't intuitively obvious and these things may be useful, but that's more scientist than anything to do with programming. programming + science = computer science programming + engineering = software engineering programming + iPad = interactive computing programming + AI = vibe coding Don't equate programming with software engineering when they are clearly two distinct things. This article would more accurately be called the software engineers' identity crisis. Maybe some hobby engineers (programming + craft) might also be feeling this depending on how many external tools they already rely on. What's really shocking is how many software engineers claim to put in Herculean effort in their code, but ship it on top (or adjacent if you have an API) of "platforms" that could scarcely be less predictable. These platforms have to work very hard to build trust, but it's all meaningless cause users are locked in anyway. When user abuse is rampant people are going to look for deus ex machina and some slimy guy will be there to sell it to them.

rafaelero2• 9 months ago

It's honestly not that deep. If AI increases productivity, we should accept it. If it doesn't, then the hype will eventually fade out. In any case, having attachment to the craft is a bit cringe. Technological progress trumps any emotional attachment.

toprerules3• 9 months ago

I sincerely wonder how some people go around having 0 emotional attachment to any of their hobbies or passions - or maybe you're just extremely unfortunate and live your life completely focused on producing output for someone else.

rafaelero2• 9 months ago

Contributing to human welfare through technological advances and productivity gains is a much better place to deposit my hopes and emotions, imo.

travisgriggs2• 9 months ago

I would love to read a study on why people so readily believe and trust in AI chatbots.

We associate authority experts with a) quick and b) broad answers. It's like when we're listening to a radio show and they patch in "Dr So N. So" an expert in Whatever from Academia Forever U. They seem to know their stuff because a) they don't see "I don't know, let me get back to you after I've looked into that" and they can share a breadth of associated validations.

LLMs simulate this experience, by giving broadish, confident, answers very quickly. We have been trained by life's many experiences to trust these types of answers.

smoody072• 9 months ago

It really is a higher level language for coding though. Not as precise as Fortran but far more upside. I imagine monks bemoaning the printing press that took away the joy of their perfectly handwritten bibles they made in solitude

igor474• 9 months ago

Welcome to HN! I don't think you understood TFA. A) LLM prompting is categorically different from Fortan, not another version of it that's 'less precise'. B) 'upside' again is entirely different from craftsmanship.

altairprime• 9 months ago

LLMs seem like a nuke-it-from-orbit solution to the complexities of software. Rather than addressing the actual problems, we reached for something far more complex and nebulous to cure the symptoms.

The author overlooks a core motivation of AI here: to centralize the high-skill high-cost “creative” workers into just the companies that design AIs, so that every other business in the world can fire their creative workers and go back to having industrial cogs that do what they’re told instead of coming up with ‘improvements’ that impact profits. It’s not that the companies are reaching for something complex and nebulous. It’s that companies are being told “AI lets you eject your complex and nebulous creative workers”, which is a vast reduction in nearly everyone’s business complexity. Put in the terms of a classic story, “The Wizard of Oz”, no one bothers to look behind the curtain because everything is easier for them — and if there’s one constant across both people and corporations, it’s the willingness to disregard long-term concerns for short-term improvements so long as someone else has to pay the tradeoff.

igor474• 9 months ago

Yes! This happened in so many industries. Banking is my go to example, where we used to have local bankers making decisions based on local knowledge of their community, but then decision making was centralized into remote central HQs and the local bankers moved into living below the API, while the central HQ guys began to make all the bucks. See also "seeing like a state" and the concept of legibility.

effdee2• 9 months ago

The use of HAL 9000 in the top divider is a nice touch.

effdee2• 9 months ago

Hint: click it!

throw_9fdf9• 9 months ago

When I became a software engineer about two decades ago, I held a similar world view as the OP: programming is a craft, I'm an artist, a creator, a hacker.

With years, as I matured, and the industry matured, I came to realize that corporate programming is assembly line work but with a much bigger paycheck. You can dance around it as much as you want, but in the end, if you truly zoom out, you will realize that it's no different from an assembly line. There are managers to oversee your work and your time allocations; there is a belief that more people = more output; and everyone past your manager's manager seem to think that what you do is trivial and can be easily replaced by robots. So a software engineer who calls himself an artist is basically that same as a woodworker who works for a big furniture company, and yet insists on calling himself an artist, and referring to their work as craft, while in reality they assemble someone's else vision and product, by using industry standard tools.

And at first, I tried to resist. I held strong opinions as the OP. How come they came for MY CRAFT?! But then I realized that there is no craft. Sure, a handful of people work on really cool things. But if you look around, most companies are just plain dumb REST services with a new an outfit slapped on them. There is no craft. The craft has been distilled and filtered into 3-4 popular frameworks that dictate how things should be written, and chances are if I take an engineer and drop them in another company using the same framework, they won't even notice. Craft is when you build something new and unique, not when you deploy NextJS to Vercel with shadcn/ui and look like the other 99% of new-age SaaS offerings.

So I gave up. And I mainly use AI at my $DAY_JOB. Because why not? It was mundane work before (same REST endpoints, but with different names; copying and pasting around common code blocks), and now I don't suffer that much anymore. Instead of navigating the slop that my coworkers wrote before AI, I just review what AI wrote, in small pieces, and make sure it works as expected. Clean code? Hexagonal architecture? Separation of concerns? Give me a break. These are tools for "architects" and "tech leads" to earn a pat on their shoulder and stroke their ego, so they can move to a different company, collecting a bigger paycheck, while I get stuck with their overengineered solutions.

If I want to craft, I write code in my free time when I'm not limited by corner-cutting philosophy, abusive deadlines, and (some) incompetent coworkers each with their ego spanning to the moon as if instead of building a REST service for 7 users, they are building a world transforming and life-saving device for billions (powered by web3/blockchain/AI of course).

</rant>

antigremlin2• 9 months ago

While I don't disagree that there's no craft most of the time, it's interesting to note that the anti-analogy with art and artists doesn't really work (or works in an unexpected way).

I'm visiting a lot of museums and exhibitions for a number of years now, without having any kind of art education, etc. After some time you start seeing patterns and understand more even if you still haven't read your art history. What strikes me time and time again, is that there's a huge amount of repetition even in great artists' work. It's definitely not an assembly line, but they do the same thing over and over again for years and years. That was true centuries ago and that's true today.

KronisLV• 9 months ago

I see your positive view on programming and raise you this: https://www.stilldrinking.org/programming-sucks

The fact of the matter is, that a lot of the development work out there is just boilerplate: build scripts, bootstrapping and configuration, defining mappings for Web APIs and ORMs (or any type of DB interaction), as well as dealing with endless build chain errors and stuff I honestly think is bullshit.

When I see a TypeScript error that's borderline incomprehensible, sometimes I just want to turn to an LLM (or any tool, if there were enough of formalized methods and automatic fixes/refactoring to make LLMs irrelevant, I'd be glad!) and tell it "Here's the intent, make it work."

It's fun to me to dig into the code when I want to reason about the problem space and the domain, but NOT very much so when I have to do menial plumbing. Or work with underdocumented code by people long gone. Or work on crappy workarounds and bandaids on top of bandaids, that were pushed out the door due to looming deadlines, sometimes by myself 2 months prior. Or work with a bad pattern in the codebase, knowing that refactoring it might take changes in 30 times that I don't have enough time for right now. LLM makes some of those issues dissolve, or at least have so little friction that they become solvable.

Assumption: when I use LLMs, I treat it as any other code, e.g. it must compile, it must be readable, make sense and also work.

spicymaki• 9 months ago

I feel that for long time people coming into the industry did not really care about code as a craft, but more of code as easy money.

This was first salient to me when I saw posts about opensource developers who make critical infrastructure living hand to mouth. Then the day in the life of a software engineer working in a coffee shop. Then the bootcamps or just learn to code movement. Then the leetcode grinders. Then developers living in cars in SF due to lack of affordable housing. Now it is about developers vibe coding themselves out of a job.

The issue is and will always be that developers are not true professionals. The standards are loosely enforced and we do a poor job of controlling who comes in and out of the industry. There are no ethics codes, skillsets are arbitrary, and we don't have any representation. Worst yet we bought into this egocentric mindset where abuses to workers and customers are overlooked.

This makes no sense to me. Lawyers have bar associations, doctors have medical associations, coders have existential angst.

Now the bosses are like automate your way out of a job or you will lose your job.

I always ask myself, in what other "profession" would its members be so hostile to their own interests?

nuancebydefault• 9 months ago

I think the profession of teacher comes close. There are extremely good and extremely bad teachers and everything in between. Knowing the subject you teach very well does not guarantee you can teach it well, often on the contrary.

Maybe coders can see themselves as teachers to the machine. Either they teach character by character, or vibe idea by vibe idea, or anything in between.

yuye• 9 months ago

Because there's a difference between a "coder" and a software engineer.

Someone who finished a bootcamp might be able to write a simple program in Python, but that doesn't make them a software engineer.

I've said this out loud before and have gotten told I'm an elitist, that my degree doesn't make me better at software than those without one. That majoring in computer science teaches you only esoteric knowledge that can't be applied in a "real job".

On the other hand, the industry being less strict about degrees can be considered a positive. There definitely do exist extremely talented self-taught software engineers that have made a great career for themselves.

But I definitely agree with the need of some sort of standard. I don't care if some bootcamper gets a job at the latest "AI on the blockchain as a service" unicorn startup, good for them. I'd rather have people with formal degrees work on something like a Therac-25, though.

pirates• 9 months ago

As one of the “self taught software engineers that made a great career for myself”, I think you are correct. Maybe not so much in the “better or worse” sense, but there are definitely moments in my “real job” where I can recognize that the thing we’re talking about or working on is something that my colleagues had formal instruction on and I didn’t, and usually in cases like this they’re better suited to talk about and work though the problem. To me the biggest difference is that they had the time/opportunity to work on a huge breadth of different problems and develop their pattern matching ability, whereas I only get to work on problems specific to my role/employer, so anything extra I have to learn on my own time. But they already know it.

int_19h13• 9 months ago

You don't need a degree to learn CS theory, though. Many of us who are self-taught, have learned about that as well (yes, there are people reading SCIP as a hobby).

And conversely, a CS degree doesn't necessarily mean that the person has actually learned what they were taught.

marssaxman• 9 months ago

Now the bosses are like automate your way out of a job or you will lose your job.

That is and always has been part of the job. Automating away labor is what we do, and there's no form of labor we understand better or have more opportunity to automate than our own.

csomar• 9 months ago

Professions that have "associations" are limited by physical geography. The "association" is a political power play although I concede that it offers certain guarantees about the people working in the profession.

Programming can't be constrained in that fashion. Having a "Software Developer" association will 1. not solve the problem; and maybe make it worse and 2. move all of the industry outside of the US.

bagacrap4• 9 months ago

Simple, the offshore engineers don't have a license to write code that runs in the US. That is what lawyers have done.

aryairani• 9 months ago

There aren’t enough swear words in the English language to adequately describe how frustrating computers and programming can be, but we have at least always been able to count on them for precision: to perform exactly as instructed through programming.

This is so true. That feeling when you're debugging an issue in your code, only to rule out all the possibilities and have to expand your search to include not-your-code: the tooling, the libraries, the operating system, the hardware. This is the worst feeling in debugging, when the problem and the solution /might/ be outside of your control. With LLM/GenAI, the primary problem solving surface is nondeterministic by design, very much out of your control, and you will likely be gaslit into believing that you're just not hitting it right. Like a tube tv that has to be slapped just the right way to restore proper reception. (Sorry, bots, no offense intended.)

What’s next, TPS reports?

I bet LLMs are really good at producing TPS reports w/ cover sheet.

game_the0ry• 9 months ago

I am sad about losing "the craft" but fwiw I think there will still be creative to work to be done at the edge of what we know and do as programmers. LLMs only synthesize what's known (the training data) and I think there will still be space for human creativity. At least for now.

bagacrap4• 9 months ago

I am definitely going to reuse the term "slop-jockey".

The Programmer Identity Crisis

Related Stories