Posted by senko 1 day ago
When I think of code, I like to compare it to old complex physical machines. Think automaton. If you zoom in enough, what you see is indeed somewhat simple. But zoom out and the answer changes.
Then there is maintenance, manufacturing, tooling, etc.
I suspect that as humans living in a physical world, we understand intuitively the vast knowledge and skills required to design and build different kinds of machines. Software tends to hide inside boxes that look similar, but are infinitely variable.
They think communication, alignment, gathering requirements, and other political bullshit is the hard part because they have never actually solved or had to grapple with a truly hard problem.
That’s fine, but it shows the corporate programmer who is probably in meetings all day has a vastly different reality than those of us who have had to solve open problems with no solution written somewhere because there is none.
- The sorcerer: Have meetings with others until you know just how valuable a solution to this hard problem actually is, characterize it well, pool resources use cases and documentation, and then work with whatever wizard (or university thereof) is known to be able to solve that kind of problem. Have them find a solution to the hard problem and publish it. Use that publication as context, and have your LLMs integrate the solution.
- The wizard: Find hard problems with adequate funding behind them. Solve them. Don't worry about stakeholders or integrations--the problems are hard enough on their own.
It used to be we found ourselves jumping back and forth between sorcerer and wizard. But there are so many hard problems with solutions that are now in the training data for these models. A relevant skill for the sorcerer, besides the skills that are relevant in those meetings, is not solving hard problems head on, but being a sort of remixer of existing solutions to hard problems.
I think this would actually be better, because more hard problems would get solved in the open where they can benefit everybody, rather than ending up as IP-shaped ammo for zero sum games.
> those of us who have had to solve open problems with no solution written somewhere because there is none.
Probably because solving said 'truly hard problem' is niche with little or limited value as few people have tried to solve it (otherwise a solutions will likely have been written).
To be less tongue-in-cheek, your logic is flawed. We simply have too many hard problems than we do smart people, unfortunately.
And the ones we do have seem to like optimizing comfort over risk, such as taking cush consultancy positions.
With one massive exception: the "There's no median programmer" section stuck out like a sore thumb. It seemed to be going out of its way to unload a bunch of chips from the author's shoulder about other developers in a way that... didn't really add any value?
The title prepared me for a section about how actually, when we talk about software development, it's very risky to generalise. Instead I was mainly reminded of the Goomba fallacy.
I think it's interesting to think about why software engineer compensation have looked different to management or product ownership compensation, but I also think trying to generalise suffers from the problem that... there's no median product manager.
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
Don’t call yourself a programmer: “Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired. You know Salesforce, widely perceived among engineers to be a Software as a Services company? Their motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)Besides, there was a whole back-and-forth among multiple bloggers and comment sites (including here: https://news.ycombinator.com/item?id=3170766) from back then in response that agreed or disagreed with that patio11 post. Here's one: https://web.archive.org/web/20111126183459/http://www.jacque... Here's another (though a couple years later): https://yosefk.com/blog/do-call-yourself-a-programmer-and-ot... From the second one's conclusion:
> When I introduce myself, I usually call myself a programmer, regardless of my current work on chip architecture and management and stuff. I got into programming for the money, so it's not like I'm overflowing with pride when uttering "programmer". I just think programming is a great career and the right thing to call myself for me.
> There's an alternative approach where you program, but you don't call it that, and you use programming as a starting point from which you transition to some form of being involved in business as directly as possible.
> It sounds a bit roundabout to me – why not just get an MBA instead? – but maybe it's the right path for some (especially considering that some prestigious MBA programs want you to have industry experience before you can even enroll.)
> The important thing is to choose the path that suits your preferences, follow it consistently, and realize where your approach is most likely to succeed. Because where I work, someone applying for a programming position and not calling himself a programmer will not make a good impression.
Sometimes calling yourself a "Software Engineer", or focusing on "$X company revenue definitely attributed to my efforts" rather than the technical details, is the right thing to do. Sometimes it's not. In any case I'll continue explaining to outsiders that "software engineer" is mostly just a fancy term for "programmer", and to programmers to call themselves whatever they think will best give them a chance at working where, on what, and for how much money they desire.
The more interesting part, to me, is the 15 year old recognition that programmers' jobs are to replace other workers. It's definitely not a new thought at all, but it's interesting to reflect on considering how the dynamics are starting to turn the other way around.
Saying this as someone who knows many programming languages... but I don't consider myself a programmer because that's too job-oriented. Like.. I write code for fun and "programming" isn't fun.. it's a living. This approach has let me follow multidisciplinary paths by framing my career away from the code-as-my-product mentality.
Occasionally I see a tech person in SV upset about AI automating away jobs. My dude, your whole job is to automate away jobs.
lol, I hope most coders are not this jaded.
The author's main thesis, that coding is hard, conflates what an individual finds easy or hard, with what is easy or hard for an average person.
You can guess which companies and people were hit the hardest, when it turned out that all that software could eventually be generated by a machine.