Navigating customer requirements and building something that satisfies both market's needs and company strategy can be an incredibly difficult and frustrating problem to solve. Especially if you need to also oversee the execution of the strategy. So not only you have to predict what they want or know the domain deeply enough to understand what they say they want is not what they really want, you also have to come up with a plan for executing your solution in a corporate environment.
There is a reason that books like "the staff engineer's path" cover topics such as local maximums, communication, establishing support for executing a plan or creating alignment on big efforts. In large corporate environments with multiple international customers, code is most of the time not the hardest problem.
If you have a site whose performance steadily gets worse and the rate of new features steadily declines and the rate of bugs steadily goes up, then your site/app will probably not have a great future.
All of those things depend on solid code. If staff engineers who are too busy talking and building consensus such that they aren't connected with the actual programming and situation on the ground, then all the talking and consensus-building won't matter.
This might be the reason why many personal projects are so technical and impressive - it's the itch that's not scratched at work.
I think 80% of a SWE's job is to communicate with the XFN partners (either gathering requirements, pushing back, managing up, collaborations, etc) and then plan out the actual coding (gather code pointers, look at past code, plan architecture, talk to the team). The last 10% is the coding. And then the other 10% is the maintenance of that and past code (which honestly should be a lot more but incentives are not aligned well).
It's hard for people to understand jobs they don't do. They imagine we spend 8 hours a day clacking at the keyboard.
The really hard part of this does in my opinion not so much lie in the aspects that you describe, but rather in doing this without leaving scorched earth with most/all of the stakeholders involved.
In other words:
Doing what you described is in my opinion something that can be learned, and in my opinion a central reason why many programmers consider this to be difficult is that they never learned it, and/or (related to this) were never given the opportunity to be responsible for all of this, so they lack experience.
On the other hand, navigating the whole office politics, and running the political gauntlet that is collateral to it is hell on earth. The only way to survive this is to give a big "fuck you" to everyone, which I more politely described with "leaving scorched earth with most/all the stakeholders involved" above.
"Navigating customer requirements" is mostly everyone speculating on customer needs and pushing the part they own, and whoever happens to get closer to the higher management's ear, wins. Then market decides if that's is a good thing or bad thing. If it's good, normally the person who pushed this doesn't even receive credit for it, because either the command chain too long or the stakeholder's memory too short and postfactum everyone pretends they authored good decisions and opposed bad ones.
It might be tiresome and exhausting, like all intense politics, but it's not hard in any technical sense. Most mediocre people can do it and do it.
For something to be hard and complex you need rules and professionals on all levels who understand and follow the rules and driven by meritocracy alone. That's simply never the case.
True. And there is another angle: ownership. The author also said “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”. This is like saying that a programming language designer does not own the spec of the language itself but just wants to write hte compiler. I find such altitude counterproductive. Case in point, many companies hire PMs for their internal infra org. I mean, shouldn't the engineers in the infra org know exactly what they design to build? If you don't want to own what to build, you end up letting someone else tell you what to do, except that the person is neither an expert nor even your user.
Programming is the hard part! I want to make this distinction because to me programming is about solving problems and coding is a way to express the solution.
Designing algorithms, architectures, etc can be done without a programming language. Coding is putting it down into some language.
Why would they cover programming? That's what all the books on programming are for.
Also I see no need for signal processing to make programming a hard problem. Writing correct code is hard. Writing code that makes incorrect code easy to spot and hard to write is hard.
You can be great at local maximums, communication, establishing support for executing a plan or creating alignment on big efforts, and proceeded to still create a ball of mud. Bug ridden, hard to read, hard to debug.
This is true, and this is the thing that makes me want to not be part of this dumb system anymore. If leadership on the same company can't align, that shouldn't be my problem, and I hope they get replaced by AIs that can.
Humans suck.
Just yet another case of people seeing only the extremes and not the entire spectrum
You nailed it: in a corporate setting, code is definitely not the hardest part and it’s why companies can sometimes make do with a skeleton crew of offshore engineers who make $20-$30 bucks an hour
The way harder part is building the right thing and just designing the thing soundly to begin with
This type of software is where AI absolutely kills it - problems with tons of forum posts, writing code for systems with a ton of various kinds of quality developer documentation
On the other hand, if you’re doing something novel or sending a $10bn machine to mars, you probably don’t want to yolo it with AI
I've read through these comments and, as is typical of HN, virtually none of them refute or even address the points made by TFA.