I sometimes wonder whether that's a better idea for these micro-optimizations, rather than looking at the assembly code and trying to coax the compiler into generating what you want.
That said, I'm not keen on "argue and you're off the project" work environment.
The original joke deliberately says "two hard problems" and then lists three. The "off by one errors" being the 3rd problem is the punchline of the joke.
> Which goes on to prove that bottleneck isn't in writing the code. It is in reading and understanding the code.
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.
That's very true, which is why I find it insulting that so many AI proponents use the word "typing" to refer to writing code. It carries an implication that if you enjoy writing code by hand, you enjoy a mindless activity.
> I think a lot of HN truly believes that Software Developer is the only important role at their company.
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.
I liked it immediately, but I couldn't quite put my finger on it until I saw your comment.
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.
What I find ironic is that "this reads like an AI" is a phrase that is rapidly losing its meaning, partly due to advances in AI, but also because it's being worn out, just like every other generic phrase used to dismiss someone's work out of hand without providing any additional context.
> It's like saying "we shouldn't worry about enforcing traffic laws because we need to use our resources to bring war criminals to justice"
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.
I have to ask: did you read what I wrote before you replied to me? I know the question might come across as an attack, but it's not. I'm genuinely curious about what process lead to your comment being a reply to mine, when mine explicitly states the following:
> 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.
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.
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.