
95% of Programming Isn’t Hard (and other random thoughts) - chmaynard
https://macwright.com/2020/08/01/recently.html
======
Grimm1
My one friend writes code for satellites. My other friend is a security
vulnerability researcher working on the Linux kernel. I write code to process
terabytes, potentially petabytes of data consistently and performant. I don't
really know people who do frontend professionally in my personal life but I
can't imagine keeping a webapp serving millions of people on many different
devices performantly is easy.

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.

~~~
cosmodisk
What you described here falls within 5% of all programming jobs.The rest 95%
aren't that demanding.

~~~
rtlfe
I would guess that most satellite and big data code falls into the non-hard
category. In my experience working with things that sound similarly
challenging, it's usually the case that one person or a small group of people
do most of the "hard" part early on and then a much larger team spends years
doing relatively simple work expanding on the foundation they built.

~~~
Grimm1
I think there are a lot of other issues with that and don't think your
experiences reflect the norm, or at the least they certainly run counter to
mine so far.

~~~
jrott
In my experience with being on a big data team is that most days you don't
have to do anything all that hard but it always comes up eventually.

------
Consultant32452
What percentage of the population is even intellectually/psychologically
capable of programming at a professional level? My guess is significantly less
than half. That's not a we're smart and they're not. There's many jobs I'm
psychologically ill-equipped to perform. For programming to be easy you have
to have just the right amount of autistic/systemizing brain type, which
appears to be significantly genetic. Everything in programming is abstract, so
you have to be able to hold very large completely abstract systems in your
brain. That's a different skill/aptitude than, for example, holding all the
working parts of an internal combustion engine in your mind.

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.

~~~
ExtremisAndy
I pretty much agree here. I am an example of someone who simply does not have
the genes for it, so to speak. I have loved programming since I was a little
boy but am horrible at it. I can learn a language's basic syntax just fine
(and usually in very little time), and have written many little tools/small
apps that I have personally found helpful in automating certain aspects of my
life and work. So I certainly value what little bit I can do. But every time
I've tried to study a serious book on data structures and algorithms, it's
been a disaster. I simply lack basic problem-solving skills. I try but I'm
just not good at it. I mean, I can usually come up with working code to do
whatever I've ever wanted to do, and I'm certainly thankful for that since
it's ok if my personal projects aren't terribly efficient. But professional
programming would never be a possibility for me. I'd get laughed out of an
interview b/c of the convoluted/entirely-too-complicated ways I solve
problems. I just wish I had a good sense of what algorithms/data structures to
use where. That would certainly help me a lot! But I'm just not sure I "have
what it takes", if you know what I mean, to develop that skill.

~~~
stuartd
> I can usually come up with working code to do whatever I've ever wanted to
> do

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)

~~~
ExtremisAndy
Yeah, my wording wasn't great, so your confusion with my post is my fault for
not being clearer. I obviously can solve problems to some degree otherwise I
wouldn't be able to even create the simple tools I've made to solve some
problems in my work. What I guess I'm trying to say is that I don't solve them
WELL or efficiently. I'll use a DS/algorithm that, sure, technically works and
gets the job done but is by no means the most efficient way to do it. Someone
who has the common problem-solving sense I lack would have solved the problem
more efficiently, more quickly and with more attractive code. That's what I
was aiming for.

------
cle
> 95% of programming isn’t hard

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

~~~
MetallicCloud
I've been walking for a good number of years now, yet every now and again I'll
trip on something, or bump into a wall. I wouldn't call walking hard.

~~~
akvadrako
I would call walking hard - most animals are just very good at it.

No programmer is good enough to build a walking algorithm that is 1% as good.

------
fish45
> 5% or less of programming is hard: it’s the stuff that interview questions
> refer to. You might need to think about algorithms, might need to try out
> multiple strategies before deciding on the one.

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.

------
ZinnZirconium
The hardest part of programming is finding workarounds for undocumented bugs.
And I don't mean the kinds of details people have to be told on stackoverflow
after refusing to read the manual. I mean genuinely showstopping bugs with
nonobvious workarounds like HTML5 audio didn't fire the ended event in Safari
until iOS 13.4. There's a guy who complained about it on his blog for eight
years until Apple allegedly fixed it. And I say allegedly because I consider
the fix to be broken and I still use a workaround which I had to discover for
myself through original research.

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.

------
ricardobeat
> every time that someone tries to use JavaScript objects for data, they write
> a security vulnerability by way of prototype pollution

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

~~~
redmorphium
Concretely, at least on Node:

    
    
        const myData = {};
        myData[rawUserInput()].key = value;
    
    

This is vulnerable if rawUserInput() returns `__proto__`: `key` on the
prototype may be set to value if `myData` had `__proto__` set. If the hacker
controls `key` and `value` then they can effectively modify `key` field on all
objects.

[https://github.com/HoLyVieR/prototype-pollution-
nsec18/blob/...](https://github.com/HoLyVieR/prototype-pollution-
nsec18/blob/master/paper/JavaScript_prototype_pollution_attack_in_NodeJS.pdf)

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.

~~~
ricardobeat
Indeed, though you'll only manage to break or DDOS the server by doing that.

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.

~~~
redmorphium
It could be serious.

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();
    
    

If the hacker is able to set `Object.prototype.userIsAuthenticated` then the
auth check is now bypassed.

So I think the break / DDOS is pretty serious here.

------
PaulDavisThe1st
>Once you’re settled in, 95% of programming isn’t hard. It doesn’t involve
algorithms, hard design problems, performance or storage constraints. It isn’t
worth blogging about.

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.

~~~
3pt14159
I think you're right, but in a different way than I understand that you mean.

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.

------
greg7mdp
I kind of disagree. When programming isn't hard, it is because it is not done
right, and the coder uses repetition instead of higher level abstraction.

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.

~~~
dmitriid
> When programming isn't hard, it is because it is not done right, and the
> coder uses repetition instead of higher level abstraction.

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.

~~~
ozim
They are supposed to ... but finding correct abstractions is hard. After a
year or two abstractions usually are not correct anymore. That is why "favor
composition instead of inheritance" is important because hierarchy of
inheritance is fragile abstraction and if you compose things it is easier to
swap one thing with other if they have the same interface.

------
phendrenad2
Almost everything I've ever attempted to do on my own, once I did enough
research into how to do it, turned out to be extremely easy. The only time
it's been difficult is when some other person put arbitrary and/or unexpected
rules or limitations in place. Examples:

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

------
codr7
It's as hard as you want it to be, right at the limit of what you're currently
capable of dealing with if done right.

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.

~~~
odyssey7
> I tend to write code in short (2-4h) but very intense bursts with plenty of
> rest in between

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.

------
grosales
At the end of the day, we all implement systems - large and small. The more
moving parts a system has, the more complex its implementation tends to be.
Decomposing large systems with moving parts takes many tries to master.

------
boris-ning-usds
The rest of the 5%... well, that obviously is reserved for naming things.

------
rtlfe
> Once you’re settled in, 95% of programming isn’t hard. It doesn’t involve
> algorithms, hard design problems, performance or storage constraints.

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.

------
humbleMouse
I like the article title and agree, the other points the author make are valid
but seem like randomly picked issues.

~~~
wwright
He says at the start that he just kept some notes for the last month and was
publishing them all

------
specialist
TLDR: People are hard, computers are easy.

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.

------
brian_herman
I feel like there are two articles here one about politics and the other one
about programming. I don't see how they are related in the way the author
presented?

------
AnimalMuppet
> The obsession with citing facts in paranoid literature that Hofstadter
> mentions is no longer a thing: modern paranoia is untethered.

The paranoid now cite "facts" that are stated somewhere online. They still
cite them, though, as though they definitively settled the case.

------
alexashka
The author should ask himself if he is doing 5% writing (and thinking) or 95%
writing.

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.

~~~
tmcw
I commit my full force of being to craft the highest quality posts on my
personal blog for you, this is really 1% stuff.

~~~
awake
Thank you for your effort. It clearly shows both in your work which is
prolific and creative as well as in your writing.

