95% of Programming Isn’t Hard (and other random thoughts)
macwright.com
macwright.com
My point is it really depends on the scale or depth of the work you're doing. It's pretty easy to keep things running smoothly for a smaller company or one not doing hardware etc etc but I think this really misses the mark for a lot of work, there's a scale or depth where you can't get away with not using what the author says is only used in interviews.
Lots of frontend work is using the same paradigm (human input triggers events that interact with components to manipulate state and make network requests) over and over for different screens.
The web has just replaced the technological components, but the basic model is more or less identical (and arguably still hasn't reached the same level of sophistication that the forms software of, say, 1988 had (though this is certainly arguable)).
How often do you hear that you just need to rewrite everything at that point? How often does that payoff?
On paper it looks cool and complicated, in reality it's not that hard. Lot of fields in CS don't move that much especially things based on C / asm, kernel, embeded ect ...
I agree that most kernel programming isn’t computer-science hard, but its peopleware-hard: you need to maintain compatibility and get signoff and step very carefully forward because any change can affect so many disparate groupa.
Programming is "easy" for only a tiny percentage of the population. That's just regular programming problems, not particularly difficult concepts/tasks I see many posts referring to.
1. Most people could be trained to code. The most important trait in a programmer is persistence. Momentum built from solving past problems is a powerful force.
2. The idea of needing to be atypical in order to be successful is damaging and wrong. What matters is practice.
I understand what you are trying to get at, but there a lot of very smart people outside of the realm of software development. The ideas you are perpetuating raise the barrier to entry.
But to say that half the population bus not capable of programming? That is elitist nonsense. Especially given the breath of the field.
Abstract thinking is really not that easy. Just try to go to a shopping mall and teach people simple math or programming concepts.
I have taught at least a dozen people to code. A good number had no idea what was going on for a while, but left knowing how to handle the basics.
Coding, math, and related subjects are made harder than needed by focusing on the abstract too much. Most of the concepts taught in a typical computer science degree are not difficult once you strip away the terminology.
I'm also not sure how you see these opinions stemming from an elitist filter bubble. I know what I know because of how I've been educated. Anyone who put in the same amount of work (within a reasonable margin) would know the same things.
You appear to have hallucinated a version of what I've said and are arguing against that.
I could be misunderstanding something about what you're saying.
Is that elitist?
It didn't matter how many questions you got right on the test, but rather, if you answered the questions in a consistent matter. even if you were wrong, as long as you were wrong consistently, you'd do well.
If you saw a question, and then a very similar problem 3 pages later, and answered them wildly differently, you wouldn't make it.
the conclusion was that if you were building patterns in your brain, or using logic to build up answers, you were good to go.
Is it really different though? “Why isn’t this engine working?” [traces through combustion path to find problem] doesn’t require ‘holding all the steps in you mind’ but it does require knowing them and how they interact, whereas “how do I make this engine more efficient?” does require a mental model of the whole engine and how the parts interact?
These seem broadly to me as analogous to respectively maintenance programming and systems development.
Edit: I think the part I don’t understand is why you think the abstract system (the code) is qualitatively different from the concrete system (the engine).
https://www.goodtherapy.org/blog/psychpedia/abstract-thinkin...
To me, programming is simply an acquired skill. The vast majority of the population could do it.
Understanding what the problem is ... that's something else.
I wouldn't worry about it. I had a guy I mentored who couldn't code his way out of a paper bag in spite of having had a programming job for 5+ years at that point. I taught him how to program and while he did improve significantly, he realized he wasn't going to make it as a programmer. Now he works in infosec where he's largely administering software with occasional scripting type stuff. He gets to do the scripting/programming bits he likes and makes a ton of money. He's actually my boss now. There's a lot of this kind of work that I think is really rewarding. I hope you find a good fit for you.
Been working as a programmer for 25 years, and I’ve never read (or considered reading, or felt the need to read) a book on data structures or algorithms.
Also, I’ve seen plenty of people who are employed as programmers who simply cannot come up with working code. I don’t see how you can write working code without problem-solving skills, as by definition you’re solving a problem by writing working code..?
(I don’t really have a point, sorry, this just resonated with me)
> It’s easy to screw up the 95%, though
To me, those just don't seem like compatible assertions. If something isn't easy to get right, what else do I call it but "hard"?
No programmer is good enough to build a walking algorithm that is 1% as good.
The author is correct that most programs don't need complex or clever leetcode type algorithms, but IMO program architecture is just as difficult to get right for any program longer than a thousand lines.
The only part of programming which is easy is copying example code from the documentation. Once you build a nontrivial project that solves a real problem you're already working beyond the trivial. Real work gets real challenging real fast. If you're staying within the percentage of programming that's still easy then you're just doing copypasta and not really programming.
I would love to hear more on this, as it makes little sense as written. You never touch prototypes when using data objects, is the author talking about constructors pre-ES6? Or the fact you can shadow methods from the Object prototype? I don't remember seeing any exploits based on that (vs "that’s, really often, a problem").
const myData = {};
myData[rawUserInput()].key = value;
https://github.com/HoLyVieR/prototype-pollution-nsec18/blob/...
A common way is as described by that paper ^
Recursive merge functions, unless if they check for this vulnerability, are often susceptible, since JSON.parse defines __proto__ on its return values.
It seems that the Ghost vulnerability explained in the paper relied on the handlebars engine calling the equivalent of `eval()` on a string value, in the global scope, plus a path traversal vulnerability allowing loading a template from node_modules.
Are there are any other examples of this being exploited in a meaningful way? Even if you end up passing raw user input to key and value, user payloads will never be able to define a function, so the possibilities are very limited. I think having every NPM library that does object assignment using a user-provided key be marked as 'vulnerable to prototype pollution' is quite different from it 'being a problem very often' in practice. Happy to be shown otherwise.
Let's say your company's code is open-source, and the attacker knows there is code somewhere like this:
let state = getState(); // returns empty {} if user not authenticated
if (!state.userIsAuthenticated) {
respond(401);
}
showBankAccount();
So I think the break / DDOS is pretty serious here.
You'll see prototype pollution CVEs in such libraries as jQuery, Lodash, handlebars, ajv (and transitively, request). A pretty good set of modules that are heavily used.
Scroll through the latest vunerabilities in the database and you'll see prototype pollution popping up very reliably https://snyk.io/vuln?type=npm
Is my understanding correct in saying that this is a peculiarly JavaScript issue because you can overwrite language constructs on the object prototype?
Whereas in other languages I can't affect the language core constructs?
In other languages, the data kind of object - dicts in python, hashes in ruby - allows you to associate any key with any value. In JavaScript, the hybrid kind of object that's used for both, allows you to associate keys with values, but has some keys that are special, like __proto__, that override language constructs and cause chaos and vulnerabilities.
There used to be much concern around the idea that you might load some third party js that adds thing to the base Object prototype, which will then be enumerated with for..in loops on all your data objects.
I always thought this was a stupid vulnerability because if you're executing malicious javascript, you are already screwed in a much more direct way
[Edit: i was mixing this up with a slightly different vulnerability that is a bit sillier than the one they are reffering to]
Once you're settled in ... having dealt with architectural design in a way that allows you to continue doing something with the code for 20 years or more.
OK, sure, 100% of programming isn't hard. But if you think that the hard part is only 5%, you're not doing the right job.
Whatever project I'm on I try my best to take on the hardest tasks. This allows me to code against things that are actually a challenge. Large refactorings, risky features, hard we-arn't-sure-if-this-is-possible tasks. This makes 40% of what I do hard. But it isn't because I'm writing software for ICMBs or satellites. I'm the dude that takes on the tough stuff and makes it work, and I think more developers would do themselves a favour if they did the same thing. Maybe you don't need to quit your job in order to change the ratio. If there is work at your present place that seems hard then volunteer for it. It will make you a better software developer.
Regardless of the programming task, it is usually hard to find the best way to do it, and not trivial to implement it correctly. This is demonstrated by the fact that most code sucks.
Aren't higher level abstractions supposed to make programming easier?
And yes, for the vast majority of programmers programming is easy thanks to existing high level abstractions, and it's usually the business domain that is hard.
I think that because everyone starts with few visible abstractions, they get the sense that adding abstractions adds ease. Removing or changing them is often just as valuable.
Simple repeatable solutions are better and more maintainable than constantly abstracting things to a higher level. I write systems and code with operations and developer ease in mind, not some academic idea of abstraction.
I'll be quite honest, if this is the same sentiment behind my experience at work (convoluted tangles of conditionals everywhere, 100+ line functions doing simple things - just to name a few), abstraction isn't just some academic idea.
I work with people who follow the path of least resistance and leave everyone else with the path of most resistance when we have to figure out what the hell is wrong with their code and fix the glaring oversights and errors they left behind.
Just like true developers write all their code in notepad and real developers etch bits on disk with magnetic needles.
"Oh you want to make a website? You knew how to make a website in 2004? Well too bad, the tools you used in 2004 are now hopelessly broken. New tools have arisen to take their place, but you have to learn everything from scratch."
"Oh you want to make a video game? You learned OpenGL? Too bad that won't work on iOS. Looks like it's back to the studying phase for you..."
"Oh you want to compile Hadoop from scratch? Too bad it's a 9,000-step process, and anything could go wrong along the way."
"Oh you want to add a feature at the company you work for? Too bad someone wrote that module in an unnecessarily confusing way, so have fun tracing through that mess to figure out how it works before you can add the feature."
I've found these cases account for 95% of programming. So I guess I'm saying that 95% of programming is hard.
I find that with increased experience, writing (any kind of) code is more intense. Because I'm pattern matching 35 years of experience at every turn.
As a result, I tend to write code in short (2-4h) but very intense bursts with plenty of rest in between lately.
At any level it’s a great idea to ruminate and plan what you’re going to do. Alas, current management trends are about keeping developers busy typing — which is something of a vicious cycle.
It sounds like OP thinks the hard parts are algorithm design and architecture. I wouldn't even really consider those programming. They're things you need to do before you can start programming.
Matt Levine is a columnist for Bloomberg.com. His columns are typically a random collection of thoughts on current events, from the point of view of economics.
The only hard part about programming, and computers in general, is other people.
The OC mentions JavaScript, something insightful about data and objects. Just imagine: where would JavaScript be today without people like Brendan Eichmann?
I imagine other industries are more or less the same wrt the work vs the people.
The paranoid now cite "facts" that are stated somewhere online. They still cite them, though, as though they definitively settled the case.
An honest contemplation of this question would likely result in a very different set of ideas and likely a different presentation format to go along with it.