The people AI evangelists often say "typing" instead of "writing code", because they don't really understand -- or it's not lucrative for them to acknowledge -- what makes writing code hard.

We don't just write code to be executed by machines, we also write it to be read by humans. Code reviews, debugging, future changes -- all of these things involve reading and understanding the code someone wrote. And until we have an AI that we can actually hold responsible for its actions, we can't delegate the understanding to it.

I doubt that. A lot of HN might have believed that some 10 years ago, perhaps, but most of those people have either matured or been driven away by the shift in the discourse.

I was one of the people who used to believe that, but the years of experience have taught me several important lessons that changed my mind. That change in attitude came both from my own failures and from having the rare privilege to work with people who were actually good at those other roles you listed.

> This is an exaggeration, but you see these themes all over the comment section.

And you'll keep seeing those comments, just like you'll keep seeing the comments about how developers are hypocritical divas. Those comments come from people's bad experiences.

Workplace political games are a thing. Unnecessary meetings and documents are a thing. Problematic, unprofessional developers are a thing.

To me, "vegetarianism" is a much better label than "organic" or "GenAI-free". People who buy "organic" and "free range" do so because they believe it's better: higher quality, healthier, etc. (Whether they're right depends a lot on the requirements placed on that label and how those requirements are enforced, but that's tangential here.)

On the other hand, vegetarianism used to be this weird, niche thing that people made fun of. Vegetarians had to fight for acceptance. This is exactly how I feel about this new world that I find myself in, where AI is being shoved down everyone's throat and where developers (like me) who resist it are treated like a weird, niche group of outcasts.

It most definitely isn't. At no point did anyone in this discussion say "we shouldn't worry about small time corruption". In fact, I explicitly said the opposite. And then I highlighted it after you essentially accused me of doing so, as you're doing again.

> Creating an "urgency chain" is effectively the same thing as justifying behavior.

No, it's not. No one is "creating" an "urgency chain". Justice isn't binary. Things can be more or less just, they're not either perfectly just or completely unjust with nothing in between. Similarly, different people have different levels of impact. That's the definition of power in this context: the level of impact your actions have. No one is "creating" these concepts out of thin air.

What is happening here is that people are complaining about injustice and other people -- like you and the person I initially replied to -- are trying to delegitimize those complaints by stating that "all corruption is bad".

Let me repeat this, in case it got lost despite earlier repetitions: yes, we all know that "all corruption is bad". Just like we all know that "all lives matter", but pointing out that banality only got popular after the "black lives matter" slogan surfaced in response to a systemic injustice against African Americans.

You're doing the same kind of thing here.

> Caring about prioritizing things where we do not have coercive power is pointless.

On the contrary. If you always give up on caring because you don't have coercive power, you will never rectify injustices caused by imbalance of coercive power.

> Those people you are replying to are not saying that this soldier should get away with his corruption because more powerful people are getting away with theirs. They are saying that those who abuse greater power are doing greater harm, and that their corruption should be punished with greater urgency.

This is true, just like "all lives matter" is true, and it misses the point in the exact same way.

Those people you are replying to are not saying that this soldier should get away with his corruption because more powerful people are getting away with theirs. They are saying that those who abuse greater power are doing greater harm, and that their corruption should be punished with greater urgency.

On top of the harm the powerful people inflict directly through their corrupt actions, there's a secondary effect on the society at large. Unlike trickle-down economics, trickle-down corruption is a real thing. People see those in power get away with corruption and say "Why should I do the right thing?"

Of course, the usual answer from those in power ends up being "because we have the power to punish you and you don't have the power to punish us". And that's how you end up with the arrest and prosecution of a US soldier on the same 5 counts that the top politicians and their cronies are getting away with on a daily basis, aided by the president himself.

Only if you expand the meaning of the word "requirements" to encompass a full specification of the solution.

> Is it choosing between for and while what you think is hard?

You want to know what I think? I think this conversation is crossing into rudeness.

Yes, which is why I have been making the distinction between "programming" and "writing code" all this time.

Programming is hard because it's not merely writing code. Determining what to program is not the same as determining what code to write. "What to program" is about requirements. Going from "what to program" to "what code to write" is what programming is about.

Being able to transcribe sentences in a certain language is the skill kids pick up in elementary schools. Being a writer requires a whole set of skills built on top of that.

The reason why I brought up that difference in the first place is because both of these are called "writing". When a fan says "I heard the author is writing the next book in the series" or when an author says "I haven't been able to focus on writing due to my health issues", they're not talking about the low-level transcription skill.

> "What to program" being hard was accepted from the onset and so far we see no disagreement with that.

Similar to your interpretation of "writing", you're choosing to interpret "programming" as a process of transcribing an algorithm into a certain programming language, and everything else ends up being defined as "what to program".

That's an overly reductive interpretation, given the original context:

> For reasons which it would take a while to unpack, if is often the case that the best (or sometimes only) way to find out what programming actually needs to be done, is to program something that's not it, and then replace it. This may need to be done multiple times. Programming is only occasionally the final product, it is much more often the means of working through what it is that is actually needed.

> [...]

> Most of what is being done, during programming, is working through the problem space in a way which will make it more obvious what your mistakes are, in your understanding of the problem and what a solution would look like.

Notice that the original comment talks defines "determining what to program" as a process of refining your understanding of the problem itself.

In my reading of the original comment, understanding what your users need is "what to program". Writing code that solves your users' requirements is "programming".

That's like saying "becoming a writer can't be that hard, since kids learn how to write in the elementary school".

Given a set of requirements, there are many different ways to write a program to satisfy them. Some of those programs will be more efficient than others. Some will scale better. Some will end up having subtle bugs that are hard to reproduce.

We've all been hearing that a lot and it's made a lot of people forget that, although programming might not be the hardest part, it's still hard.

Sign me up. When I started programming as a 7 year old kid, it wasn't because I dreamed of spending my days on endless meetings and documents. But hey, 40 years later, I'm working as a senior "engineer" and with that comes a heavy emphasis on project management.

Sure, you're expected to know how to solve interesting technical challenges, but that's more of a nice-to-have. It's nowhere near important as being able to make a project look successful despite the fact that the middle management convinced the senior "leadership" to do that project out of sheer ambition and without bringing on board the people who actually talk to the users, so now you're stuck without clear requirements, without a clear way to measure success, and with accumulating tech debt gumming up the works while your boss works with various "stakeholders" to "pivot" over and over so he doesn't have to go to the senior leadership to explain why we're delaying launch again.

And what I'm describing is one of the best places I've ever worked at across more than 25 years of my professional career. Hell, I'm lucky that senior "engineer" is what they call a "terminal" position here, i.e. I'm allowed to settle in it without having to work towards a promotion. From what I've been told, there are places where you have to get to be a staff engineer or they'll eventually let you go.

I don't know about anyone else, but I find the whole situation fucking insane.

I don't know any real (i.e. non-software) engineers, but I would love to ask them whether what you said is true. For years now, I've been convinced that we should've stuck with calling ourselves "software developers", rather than trying to crib the respectability of engineering without understanding what makes that discipline respectable.

Our toxic little industry would benefit a lot from looking at other fields, like medicine, and taking steps to become more responsible for the outcomes of our work.

There are two reasons for this. One is that the people who make purchasing decisions are often not the people who suffer from your bad code. If the user is not the customer, then your software can be shitty to the point of being a constant headache, because the user is powerless to replace it.

The other reason is that there's no such thing as "free market" anymore. We've been sold the idea that "if someone does it better, then they'll win", but that's a fragile idea that needs constant protection from bad actors. The last time that protection was enacted was when the DOJ went against Microsoft.

> Sure, if you vibe code a massive bug into your product then that'll manifest as an outcome that impacts the user negatively.

Any semblance of accountability for that has been diluted so much that it's not worth mentioning. A bug someone wrote into some cloud service can end up causing huge real-world damage in people's lives, but those people are so far removed from the suits that made the important decisions that they're powerless to change anything and won't ever see that damage redressed in any way.

So yeah, I'm in camp #2 and I'm bitter about AI, because it's just accelerating and exacerbating the enshittification.

Someone on the HN wrote recently that everyone who's foaming at the mouth about how AI helps us ship faster is forgetting that velocity is a vector -- it's not just about how fast you're going, but also in what direction.

I'd go further and say that I'm not even convinced we're moving that much faster. We're just cranking out the code faster, but if we actually had to review that code properly and make all the necessary fixes, I'm pretty sure we would end up with a net loss of velocity.