I agree that programming is difficult, but Im not sure he understands why he's finding it so difficult.
> "I Google a bit and after a while find a posting where some poor unfortunate soul has encountered exactly the same problem that I have. My heart leaps for joy. My trembling fingers enter the magic spell that will remove the curse, and ... nothing. The problem remains."
and
> "I'm lazy, I'm a good for nothing slacker. But when I want to put a diagram into LaTeX I don't want to have to read a 391 page manual first. Now I know you will accuse me of laziness and of being of unsound moral character,"
I wouldnt go so far as questioning his morality. But if you're not constantly focused on learning, even the minor details of the stacks you're working with, you'll increase the difficulty enormously. He sums up the danger of that attitude perfectly in his closing remark
> "Fortunately eleven minutes with the Google casino worked. The second suggestion of how to fix my problem worked - and I still don't know why emacs could not find aspell - and life is too short to find out why."
He's fixed it now. He has no idea what was wrong or how to arrive at a solution. Next time he faces, even the same problem, he'll be back on Google trying his luck.
>Next time he faces, even the same problem, he'll be back on Google trying his luck.
There isn't a next time because Joe died last year.
I think you misunderstand the point. Time is truly limited thing you have in life, and you are using much of that time understanding minor tool that are not the major point of what you are trying to do, that doesn't seem productive and is indeed infuriating.
About the final mark, those eleven minutes should even be needed, things break unfortuntatly, and if who has deep understanding of every single tool you put your hands on, you will not have the time to do whatever you need to do.
A few years ago, I had the "pleasure" of have to use docker on windows, on a complex stack, the docker windows client was always breaking with the solution always being revert to previous version, wait issue fix, update. Ofc, before that we needed to waste some time to check if it was I who broke something or if it was an update. The lesson was, only update sporadically, which also has its downsides. Or should I instead have a deep understand on how docker for windows client worker and submitting the fix myself? Do you know if I had the time for it?
Too many things in our field are held by duct tape that is always tearing. I'm also culprit of that. But saying that because tools not being newbie friendly, or some tools breaking it's the fault of the user is not really a good a approach. Being a programmer shouldn't be about fixing your editor every time it breaks, or spend hours learning arcane tools that are not about programming.
Webdev seems to be a duct tape paradise full of beginner tutorials that go nowhere. And when the hard problems popup the suggestion is to google search instead of KISS. I dont know somethings will always be difficult.
But it would be better if our tools could bring us up to speed as we learn.
If we know one computer language well, shouldn’t a tool be able to guide us quickly to the syntax and idiomatic concepts in another language? We know many concepts:
Joe Armstrong is the co-creator of erlang, so I'm pretty sure he knows why programming is difficult, he's just being personable and cheeky in this essay.
He's also got a habit of asking why and finding out (keep in mind by training he was a physics PhD), this essay notwithstanding.
You were commenting on the persona, but also stated "Im not sure he understands why he's finding it so difficult."
If you believe the statements he was making were rhetorical in nature, but are dismissive of them, while also crediting that as an individual he was insanely intelligent, with both a level of experience and a level of curiosity that outshines most of us...perhaps you missed the points he was making?
Well he does point at that issue, under time restrictions you cannot focus on the minutiae of every technology you work on. If you work in C++ all day maybe you have the time to learn 90% of the most common problems. But if you typeset in LaTeX once a year, it's a really bad investment of your time. If not finding aspell happened once in 10 years then it's also a bad investment of your time if it takes much longer to learn the why.
I'm a big fan of learning the why. But it only makes sense if you use the technology enough.
I agree, of course there are some practical concerns. I dont dig too deep into a BSOD memory error, I mostly just replace the block. But in general, I recommend following the rabbit hole just far enough to eliminate most surprises.
I don’t have any problem with reading a 391 page manual first: I’ll come away with a solid understanding of what I’m doing, and I’ll be far more effective in the future. Reading the manual is an investment that pays off ten-fold in short order. The problem isn’t that I don’t want to read a manual, it’s that the “scrum master” breathing down my neck to increase my “velocity” and close tickets sees me reading the manual and says “why are you wasting time reading when you could just randomly google until you find a solution or interrupt your also busy coworkers with inane questions that they don’t really know the answers to either?”
Programmers should be, and indeed have to be, fundamentally lazy, to be any good. My entire goal in life is, and always has been, to get the shit that other people shovel onto my plate done as quickly and efficiently as I can, so I can get back to the much more interesting things that I'd rather be doing. A good programmer will go to great lengths to avoid doing time-consuming tedious bullshit.
With regards to fixing bullshit transient bugs in other people's software: usually understanding the full root cause does not matter. It's going to update, and bring forth a whole new suite of bugs and oddities in short order. Your machine is a weird, ungovernable collection of state that cannot be fully understood and rarely presents the same way twice. If I had a dollar for every time I followed the definition of insanity and did the same thing over and over to get different results, I wouldn't need to work anymore.
But when you have found a StackOverflow post that ends up working to fix some whack-a-mole stupid thing, it's not like you move on and that knowledge goes poof into the aether. You might forget some details of what it was, but the next time something along those lines comes up, there will at least be the trace of a memory of what fixed it the last time. Over time, you build up this pattern matching apparatus, and in a couple years you can look at a bizarre nested exception trace generated from deep inside some Javabean hell, and you know that, "Oh, something is wonky with DNS on this machine" or whatever. It looks like magic from the outside, but it is utterly mundane.
I'll look up things on stackoverflow/google, but I'll also read through the corresponding documentation in the man page or info document to gain a better understanding of the solution. Sometimes, I find a better way to do what I need after reading through the actual documentation.
I guess we could look at stackoverflow/google as a more sophisticated index rather than as a sole resource.
> He's fixed it now. He has no idea what was wrong or how to arrive at a solution. Next time he faces, even the same problem, he'll be back on Google trying his luck.
Do it enough times and you will start to see patterns and gain an understanding - I would hope.
> "I Google a bit and after a while find a posting where some poor unfortunate soul has encountered exactly the same problem that I have. My heart leaps for joy. My trembling fingers enter the magic spell that will remove the curse, and ... nothing. The problem remains."
and
> "I'm lazy, I'm a good for nothing slacker. But when I want to put a diagram into LaTeX I don't want to have to read a 391 page manual first. Now I know you will accuse me of laziness and of being of unsound moral character,"
I wouldnt go so far as questioning his morality. But if you're not constantly focused on learning, even the minor details of the stacks you're working with, you'll increase the difficulty enormously. He sums up the danger of that attitude perfectly in his closing remark
> "Fortunately eleven minutes with the Google casino worked. The second suggestion of how to fix my problem worked - and I still don't know why emacs could not find aspell - and life is too short to find out why."
He's fixed it now. He has no idea what was wrong or how to arrive at a solution. Next time he faces, even the same problem, he'll be back on Google trying his luck.