CodeMage

> The structure of your code, the algorithms you choose, etc. are all dictated by the requirements.

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.

> Writing code is just means of conveyance, no?

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.

> Is writing hard? I expect most can agree that determining what to write, especially if you have an objective (e.g. becoming a best-selling novelist), can be extremely hard — but writing itself?

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".

> What is hard about it? Young children seem to pick it up with ease. It cannot be that hard?

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.

> the actual programming is not the hard part

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.

Good thing he's so good at respecting rules that say he can't do things. And good thing that he's had to face the punishment for breaking some of those rules. Imagine reading what you wrote if he were repeatedly allowed to break rules without any consequences.

> Such a world still has room for unlicensed developers too -- I'd certainly be among them.

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.

> Left to their own devices, engineers would build the cheapest bridge they could sell that hopefully won't collapse.

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.

> No one has ever made a purchasing decision based on how good your code is.

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.

The "not having children" part of the comment was clearly marked as a footnote attached to the quote about how children are "easily produced".

Thanks. I don't actually have an iPhone, so my freshly acquired "knowledge" of this was based on reading about it on the Internet and I misunderstood what I read.

I just learned about this, too. It turns out that in the US, being an iPhone user is cool and being an Android user is lame, and you can tell who's who in group chats, because the messages that go over iMessage are represented with blue speech bubbles and the rest are in green bubbles.

> If state-level spy agencies wanted to spy on someone's porn habits, they do not need to kindly ask Discord to collect that person's ID.

The first time I ever had a conversation about privacy concerns with anyone was around 1999. I've been hearing this kind of argument ever since then. Meanwhile, the erosion of privacy since back then has been nothing short of staggering.

We're at the point where we have government using Palantir to target the people, yet somehow privacy concerns keep falling on deaf ears and keep producing the same old "government doesn't need this latest privacy-eroding change" knee-jerk non-argument.

No, they might not need it, strictly speaking, but it sure as hell comes in handy, not to mention that it shifts the Overton window and serves as a stepping stone for the next invasion of privacy.

Every time I hear an argument like this one, it's always phrased in terms of "the government is greedy and/or incompetent, therefore taxes are bad" and never in terms of "the government is greedy and/or incompetent, therefore our systems of controlling our government are not good enough".

Except that a company, no matter how heterogenous, has an overarching organization, whereas the open-source community doesn't.

There is no CEO of open source, there are no open-source shareholders, there are no open-source quarterly earnings reports, there are no open-source P&G policies (with or without stack ranking), and so on.

It does, but what does that say about the state of communication in our industry? I've seen a lot of writing that reads like an AI produced it in contexts where I could be pretty sure no AI was involved. We want to sound professional, so we sanitize how we write so much that it becomes... whatever this current situation is.

No offense intended to @yz-yu, by the way. I miss the times when more people wrote in an eccentric style -- like Steve Yegge -- but that doesn't detract from what you wrote.

Yeah, people do seem to think that em dashes are an indicator of GenAI. I have been accused of using AI to write my posts on a forum, precisely because of em dashes. That's how I found out about that particular sniff test people use.

Hasn't made me change the way I write, though. Especially because I never actually type an em dash character myself. Back when I started using computers, we only had ASCII, so I got used to writing with double dashes. Nowadays, a lot of software is smart enough to convert a double dash into an em dash. Discourse does that and that's how I ended up being accused of being an AI bot.

Getting rid of malware is good. A private for-profit company exercising its power over the Internet, not so much. We should have appropriate organizations for this.

As GP pointed out, "hero" is a word with overloaded semantics. I think Adams was using different semantics for different occurrences of "hero" in that phrase. Arthur Dent has a "heroism", as in a kind of courage that people would want to emulate, without being "heroic", as in performing great sacrifices for a noble cause.

I also believe Adams was trying to point out, very gently, the same cultural difference I called out in the comment I replied to, i.e. that the American culture attaches certain expectations and connotations to the word "hero" not because they are intrinsic to it, but because of American bias.

> I've often dreamed of a system where normal users, give money as a promotion for a certain issue to be fixed or even created

It might be good to have such a system as an option, but I wouldn't want it to become an expectation. I've got a couple of side projects that are out on GitHub. They have open source licenses and anyone is welcome to fork them, send bug reports, or pull requests, but I don't want to have any obligation of supporting those projects.

> Every place where the marketing types are making us take on dev workloads has always deprioritized bugs.

My point is that they will continue to do so no matter how easy it is to fix bugs. It's a people problem, not a tech problem.

One of my favorite details about Neal Stephenson's "Snow Crash" is the name he chose for his main character: Hiro Protagonist. It's not just a lovely bit of wordplay, it immediately makes you think about whether the protagonist is a "hero" or not.

This overloaded meaning of the word "hero" is especially pertinent when discussing the differences between the interpretation of "hero" in US culture and other cultures. Outside overt dictatorships, the US is the only country I know of where people are taught that anyone who serves or served in the military is automatically a "hero", regardless of whether they've actually done anything that would normally be considered heroic.

"We can fix it later" is not the staple of Marketing Driven Development. It's not why Windows has been getting more user-hostile and invasive, why its user experience has been getting worse and worse.

Enshittification is not primarily caused by "we can fix it later", because "we can fix it later" implies that there's something to fix. The changes we've seen in Windows and Google Search and many other products and services are there because that's what makes profit for Microsoft and Google and such, regardless of whether it's good for their users or not.

You won't fix that with AI. Hell, you couldn't even fix Windows with AI. Just because the company is making greedy, user-hostile decisions, it doesn't mean that their software is simple to develop. If you think Windows will somehow get better because of AI, then you're oversimplifying to an astonishing degree.

I've lost count of people who have read Tolkien's work and never dug deeper than "cool fantasy story" level. I was no different when I read the Lord of the Rings as a teenager. Unlike C. S. Lewis, Tolkien does not shove his message down your throat.

Quis custodiet ipsos custodes? If all ICE did was deport immigrants, following the established laws and procedures, I would agree with you. As it stands, ICE is more evil, because they are abusing power and breaking laws they are supposed to uphold. And they're able to do so because people like you enabled those who are letting ICE get away with it.

> There's a lot of thinking that Congress won't allow Trump to withdraw from NATO

I wonder how that is supposed to work when the Executive branch has proven they can do whatever they want regardless of the other two branches. The rules are worthless if there are no consequences for breaking them.

> Then I thought "why not just remove the borrow checker?" without any real motivation.

Reminds me of a chemistry kit I had as a kid. None of this tame, safe stuff you can buy these days. Mine was a gift from my dad and I never thought of asking him where he dug it up, but it had stuff like pure sulfuric acid in it.

One day, when I was done with all of the experiments I had planned to do, I decided to mix a few things and heat them up, just for fun, without any real motivation other than "let's see what happens".

Let's just say I was lucky we only had to replace some of the clothes my mom had left out for me to put away. ;)

> Another point is, as you guys are well aware, the borrow checker will reject some valid programs in order to never pass any invalid program. What if I'm sure about what I'm doing and I don't want that check to run?

Then you do it using the "unsafe" keyword, and you think long and hard about how to design and structure the code so that the unsafe code is small in scope, surface, and blast radius.

That's precisely what unsafe code is for: to get around the borrow checker and assert you know what you're doing. Of course, if you're wrong, that means your program will blow up, but at least you know that the culprit is hiding in one of those unsafe areas, rather than literally anywhere in the whole codebase.

Alternately, you can switch to a language with a different ethos.

The ethos of Rust is caring for memory safety so much that you willingly limit yourself in terms of what kind of code you write and you only step out of those limits reluctantly and with great care. That's something that resonates with a lot of people and Rust has been built on top of that for years.

If you suddenly take the product of those years of hard work, strip out the foundation it has been built on, and unironically offer it as a good idea, a lot of people won't like it and will tell you so. Mind, I'm not excusing the personal attacks, I'm just explaining the reaction.

Yes, and I agree with that. But my reply was to a comment that seemed to dispute that idea and imply that if you wanted to stop growing at some point, then you should shift to academia.

That said, there is an expectation of unlimited growth and it comes from a different source: ageism. At my age, the implicit expectation is that I will apply for a staff or even principal role. Applying for a "merely" senior role often rings alarm bells.

That trend -- and certain others -- are what's making me consider taking up teaching instead.

FWIW, I'm starting to seriously consider this as a strategy that will allow me to get to retirement without completely messing up my health due to stress and burnout.

That said, there's something deeply wrong with our industry if that's the way we expect things to work. I never felt that teaching was my calling, but I might end up being forced into it anyway and taking up a job that someone with proper passion and vocation could fill. Why? Because my own industry doesn't understand that unlimited growth is not sustainable.

For that matter, "growth" is not the right word, either. We're all being told that scaling the ladder is the same thing as growing and developing, but it's not.

What makes this whole thing worse is the concept of "non-terminal" levels, i.e. levels that you're not allowed to stay at indefinitely, which means that you must either get promoted or fired.

I can understand not wanting to let people stay in a junior position forever, but I've seen this taken to a ridiculous extreme, where the ladder starts at a junior level, then goes through intermediate and senior to settle on staff engineer as the first "terminal" position.

Someone should explain to the people who dream up these policies that the Peter Principle is not something we should aim for.

It's even worse when you combine this with age. I'm nearing 47 years old now and have 26 years of professional experience, and I'm not just tired, but exhausted by the relentless push to make me go higher up on the ladder. Let me settle down where I'm at my most competent and let me build shit instead of going to interminable meetings to figure out what we want to build and who should be responsible for it. I'm old enough to remember the time when managers were at least expected to be more useful in that regard.