10 ms·

Why programming is difficult (2014)

180 points by oumua_don17 7y ago

lbj 7y ago
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.
- carlmr 7y ago
  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.
  - lbj 7y ago
    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.
- dnautics 7y ago
  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.
  - lbj 7y ago
    I do get that he was playing out a "persona" in the piece, and I was commenting on that persona.
    - lostcolony 7y ago
      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?
- fanboyism 7y ago
  >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.
  - 32gbsd 7y ago
    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.
  - deleted 7y ago
    [deleted]
- GrumpyNl 7y ago
  Thats a modern age coding problem, copy it from google or stackoverflow and they dont know what they solved and how they solved it.
  - u801e 7y ago
    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.
- melling 7y ago
  The guy created the Erlang language. He probably has some idea what he’s talking about. We could make everything easier on ourselves if we had more intelligent tools. We build web pages to help us come up to speed quickly. For example, https://learnxinyminutes.com/ https://learnxinyminutes.com/ 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: Strings, collections, maps, arrays, sets, dates and times, functional concepts, sorting, regex, concurrency, ... Basically, a cookbook of examples, etc. I’m working on a Swift Cookbook to make it easier and faster for the next “guy” (person). https://github.com/melling/SwiftCookBook/blob/master/README.md https://github.com/melling/SwiftCookBook/blob/master/README.... Ideally, in the future, the recipes are built into the editor. You could ask “how to create a mutable map” then choose a computer language the get examples, etc. Our tools should know the 1000 most common things we’d like to do and be ready to assist without requiring Google. Our time is limited.
- collyw 7y ago
  > 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.
- commandlinefan 7y ago
  > I don't want to have to read a 391 page manual 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?”
- thrower123 7y ago
  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.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
dragosmocrii 7y ago
I find this article beautifully written and it resonated with me. Writing maintainable code is damn hard for larger projects. Also, I read a couple comments above, and I feel that people who wrote them have no idea who Joe was. To me Joe is an inspiration, and I think his words are usually not there to be debated ;), after all he cocreated Erlang, and Erlang and the OTP is a masterpiece imo.
gitgud 7y ago
- The output of the program is beautiful. - The input to the program is beautiful. - The program is beautiful. I think it would make more sense if the word "beautiful" was replaced with the word "correct"... It would also help strengthen his argument for why programming is so difficult!
- NateEag 7y ago
  As a musician, writer, and programmer, my experience has been that beautiful is harder than correct.
- dnautics 7y ago
  I suspect ie didn't specify correct because correctness is impossible; with the following constraint (i'm surprised he didn't have as the last bullet point): and it must run on top of an unreliable subsystem.
  - AnimalMuppet 7y ago
    On top of several unreliable subsystems. I think that's a big part of why it's so hard. You've got leaky, imperfectly understood, unreliable subsystems, and you're trying to build the best system you can on top of it. And what you produce inevitably is a leaky, imperfectly understood, unreliable system... which becomes somebody else's subsystem. And so it goes. You say: We need to create perfect subsystems! Formal verification (or robust type systems, or better requirements, or mathematical reasoning, or some other approach) will save us! But it's not that simple. It starts clear down at the hardware level. How much can you formally prove about your CPU? After taking into account it's errata sheet? The union of the errata sheets of all the revs of the CPU? If you're running on PCs, the errata sheets of every CPU that anybody could conceivably be running on? If you can't formally prove much about the CPU, how are you going to formally prove the OS and/or compiler? And if you can't formally prove those, how can you formally prove anything else? It's leaky, unreliable, incompletely understood subsystems all the way down.
    - dnautics 7y ago
pts_ 7y ago
Oh but many people will say it's child's play and management is where it's at. And then they you will have 10 people doing the work of 1.
lmilcin 7y ago
I think the reason programming is difficult is that really we are dealing with incomplete information while the device that runs your program does not care you have incomplete information and wants to screw you the first time you do something not right in the slightest. Programming is not just understanding how the device, language, libraries work (ie. getting more complete information) but also limiting the ways the adversary can screw you and limiting the fallout. Programming is difficult because developers don't appreciate how important the part of managing this incomplete information is. "I wrote this and it works! Yeay!" And then it goes in prod and fails instantly because you did not take this or that into account. Some bright developers have the ability to manage this. But the problem is that they can't work really well with other developers (at a typical corp) who don't appreciate the problem the same way. This puts them in this untenable positions where they can either do something by themselves, very efficiently, or rely on extremely inefficient process if they want to work with other developers.
- BlameKaneda 7y ago
  > "...we are dealing with incomplete information while the device that runs your program does not care you have incomplete information and wants to screw you the first time you do something not right in the slightest." Suppose you're becoming pretty comfortable with your skills in a foreign language and you've become pretty decent at speaking it. Occasionally you'll make a mistake---you'll pronounce a word incorrectly, misplace a verb, etc---and chances are the person you're speaking with will be able to figure out what you meant to say. Unfortunately, computers don't work that way. If you're writing a function and your syntax is incorrect, the browser won't understand what you're trying to do.
  - grawprog 7y ago
    >Unfortunately, computers don't work that way. If you're writing a function and your syntax is incorrect, the browser won't understand what you're trying to do. Or worse, you and the computer have different understandings about what you're trying to do and it goes along quietly incorrectly for a while until that little mistake causes a problem somewhere else entirely because that one misunderstanding caused a cascade of misunderstandings that kept building up until it finally blew out everywhere all over your program and the quest to find where the problem started begins, well before the task of fixing the problem can start.
imtringued 7y ago
There is a reason why people make a distinction between "Programming" and "Software Engineering". Programming is just the act of writing code. All you have to do is learn a programming language and you are set. "Software Engineering" encompasses everything else on top of programming. You need knowledge of these things: build systems (Make/Gradle), filesystems, networking (IP/TCP/HTTP), Data formats (JSON/XML), Databases(SQL/KV), software architecture, layout/styling, documentation (both reading and writing). This list is just scratching the surface but we can agree that all of these things are critical to build applications. These topics clearly aren't exclusive to "Programming" and knowing them doesn't mean you are a "Programmer". You could also be a sysadmin that is managing a large cluster for multiple applications. But if you are a Software Engineer and not just a mere "Programmer" you know that your job is much much more difficult than merely the "Programmer" part.
- amelius 7y ago
  But what to do if you have a CS degree with knowledge of all the things you mentioned and perhaps more, but people keep calling you "programmer"?
  - duggan 7y ago
    As long as I'm paid a software engineering salary to develop software, I could be called a clown for all the difference it makes. If you're programming, you're a programmer. Or a coder. Or a software developer. Or a software engineer. There is no consensus on the distinction between any of these things. Just lots of people with opinions because it's easy to have an opinion on.
    - notabee 7y ago
      Titles are both a bikeshed and something that can have significant impact on salary, unfortunately. As long as non-technical recruiters are hiring based on buzzwords, it matters.
  - varjag 7y ago
    A science degree is not an engineering degree, and one is not practicing science in their hot startup. So, fair enough.
contravariant 7y ago
I feel like the constraints he added are a bit too restrictive, they would force a program to be perfect whereas for most circumstances it would be enough for a program to be bug-free. The real problem seems to be writing bug-free programs, which seems to be difficult mostly because it is hard to specify what a program should do formally (i.e. in code). Note that bugs are never about the program not doing what it is told, but are always a mismatch between the program and the programmers mental model of the program.
- mint2 7y ago
  Not to mention, the program can be completely bug free but still terrible when put in real life because any one of the 10,000 things about its intended use was unknown or not prioritized.
jkingsbery 7y ago
"After a week of struggling with a broken LDAP sever written in C and badly documented I had a lapse of memory and forget that my boss said and accidentally implemented a server from scratch in Erlang during my lunch break." Joe was awesome, on so many levels. You have to love the healthy rebellious streak and the talent to back it up.
jblakey 7y ago
Love this article! I don't think the guy is playing a 'persona' at all in this piece. These are the kinds of things he thinks about on a daily basis. Heck, these are the kinds of things I think about on a daily basis too, and I'm sure most devs who have been writing code for a few years do. In my daily work, I don't have time to understand everything. There, i've said it. I'm not lazy. I'm not stupid. I just don't have time when I'm trying to get a task/job/chore done. I appreciate good abstraction/encapsulation. A good tool does this. A bad tool fails to do this. Same with documentation, really. Don't get me started!:)
- mdonahoe 7y ago
  FYI Joe died last year and is best known for inventing Erlang. https://en.m.wikipedia.org/wiki/Joe_Armstrong_(programmer) https://en.m.wikipedia.org/wiki/Joe_Armstrong_(programmer)
0x445442 7y ago
I think there are a number of major problems with the industry. Technology jumping based on anecdotal evidence of the efficacy of doing so. Jumping around so often precludes a lot of practitioners from gaining a deep experience and understanding with the tools they're working with. This may be the only industry I know where pertinent knowledge and experience matters little. The notion of "Full Stack Developers" gives the impression that one can be proficient top to bottom. What I find interesting about the label is full seems to usually be bounded on the lower end at a place much higher than a place where I would use the term full. This is one of the many areas in our industry where hubris is in play. Specialization is usually preferable for quality and scaling. Real world business continually drives the fast and cheap legs of the stool to be chosen by management. However, I think this grates against most practitioners who not only care about quality but would admit, the aspect of quality is one of the major reasons they are even in the field to begin with. There is a large natural tension at play here. I think it's this tension that Joe was articulating. It's seems to me the most satisfied folks in this field are the ones fortunate enough to be compensated for working within a bounded context where over time they can gain more and more experience and knowledge. This naturally leads to a growing confidence and a sense of control over the context with which they work.
- adventured 7y ago
  I've spent most of my adult life as as "full stack" developer, out of necessity: I build the whole banana on my own and typically work on projects on my own (about 3/4 of the last 20 years). I'm better at some aspects than others and I enjoy some aspects more than others, of course (and I offload/automate anywhere I can). From the late 1990s until five or six years ago, it was fairly easy to keep up with the latest interesting stuff in terms of full stack. Adjustments were modest year to year. At this point I've entirely given up trying to keep up with the very rapid fad switching that has been going on. Real full stack is now only possible if you freeze pretty strictly across the stack and don't try to keep up as the next fad rolls in for a given part of the stack. If you try to keep up with all the fads now, it'll burn you out (and most likely make you hate what you do as you realize how pointless the constant switching is). I've found - as you'd expect - that abandoning the stack rat race hasn't had any negative impact. Most of the latest fads are entirely unnecessary and bring nothing to the table that prior numerous solutions didn't already deliver toward building, launching and maintaining product.
ptah 7y ago
"Before I learned the art, a punch was just a punch, and a kick, just a kick. After I learned the art, a punch was no longer a punch, a kick, no longer a kick. Now that I understand the art, a punch is just a punch and a kick is just a kick." - Bruce Lee
TacticalCoder 7y ago
Re- the Emacs config suddenly breaking... I do something getting more and more common: I put my entire Emacs config in Git. It's a bit more work when upgrading packages (because you have to commit them too) but then there's hardly ever any breakage that's not one Git checkout away (I'd say anyway that Emacs doesn't that often break at all: it's more the usual package dependencies SNAFU of our trade that bites Emacs users once in a while when they upgrade this or that package). On a funny side note I had a very bad Emacs breakage recently and at first couldn't understand why checking out the latest known correct Git version wasn't working on my main machine. It was working on another computer (btw copying my entire Emacs config is, well, also one git command away, so is backuping). Turns out: for whatever reason the file containing the list of files recently opened by Emacs got corrupted in a very strange way and that's one of the rare Emacs file I'm not committing into Git. Took me a few minutes to sort out.
- PerryCox 7y ago
  I do the same with my .vim folder. You can place your .vimrc file in there as .vim/vimrc and now everything is backed up in git. I've been working this way for a few years now and can get setup on a new machine in a matter of minutes.
- samatman 7y ago
  Same, but with my entire .config folder.
quinnydinny 7y ago
I think I'll start using the phrase "Google Casino" now.
commandlinefan 7y ago
It's kind of the worst of both worlds: it looks like it should be easy, but it's confoundingly difficult in ways that are impossible to see unless you're actually trying to practice it.
- hhas01 7y ago
  Given any non-deterministic problem, 98% programmers will treat it as a deterministic nail and hit it with their favorite C until one or both is dead.
- wool_gather 7y ago
  Is this not true of most difficult things?
  - commandlinefan 7y ago
    When I look at the high regard most people hold, say, lawyers and doctors in, who also do hard things (that are accepted as hard), I’d have to say no.
40acres 7y ago
For me, programming is difficult because once you reach a certain level of complexity it's very difficult to keep a robust enough model of the program in your head. TDD has really helped me in this regard because it forces me to start building the model from ground up as opposed to in media res.
yters 7y ago
My experience has been we have a big pile of complexity with some way of doing things. New shiny tech promises to eliminate this complexity. Perhaps it does, but also introduces new level of complexity. Old complexity hasn't fully vanished either, but now its problems have to be solved through the new level of complexity, resulting in a further emergent level of complexity. Fortunately, there is a new shiny technology that will make all this complexity go away.
dang 7y ago
Discussed at the time: https://news.ycombinator.com/item?id=7197255 https://news.ycombinator.com/item?id=7197255 2016: https://news.ycombinator.com/item?id=11002731 https://news.ycombinator.com/item?id=11002731 2019: https://news.ycombinator.com/item?id=19717877 https://news.ycombinator.com/item?id=19717877

180 points by oumua_don17 7y ago

lbj 7y ago

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.

carlmr 7y ago
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.
- lbj 7y ago
  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.
dnautics 7y ago
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.
- lbj 7y ago
  I do get that he was playing out a "persona" in the piece, and I was commenting on that persona.
  - lostcolony 7y ago
    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?
fanboyism 7y ago
>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.
- 32gbsd 7y ago
  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.
- deleted 7y ago
  [deleted]
GrumpyNl 7y ago
Thats a modern age coding problem, copy it from google or stackoverflow and they dont know what they solved and how they solved it.
- u801e 7y ago
  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.
melling 7y ago
The guy created the Erlang language. He probably has some idea what he’s talking about. We could make everything easier on ourselves if we had more intelligent tools. We build web pages to help us come up to speed quickly. For example, https://learnxinyminutes.com/ https://learnxinyminutes.com/ 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: Strings, collections, maps, arrays, sets, dates and times, functional concepts, sorting, regex, concurrency, ... Basically, a cookbook of examples, etc. I’m working on a Swift Cookbook to make it easier and faster for the next “guy” (person). https://github.com/melling/SwiftCookBook/blob/master/README.md https://github.com/melling/SwiftCookBook/blob/master/README.... Ideally, in the future, the recipes are built into the editor. You could ask “how to create a mutable map” then choose a computer language the get examples, etc. Our tools should know the 1000 most common things we’d like to do and be ready to assist without requiring Google. Our time is limited.
collyw 7y ago
> 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.
commandlinefan 7y ago
> I don't want to have to read a 391 page manual 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?”
thrower123 7y ago
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.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]

dragosmocrii 7y ago

I find this article beautifully written and it resonated with me. Writing maintainable code is damn hard for larger projects. Also, I read a couple comments above, and I feel that people who wrote them have no idea who Joe was. To me Joe is an inspiration, and I think his words are usually not there to be debated ;), after all he cocreated Erlang, and Erlang and the OTP is a masterpiece imo.

gitgud 7y ago

- The output of the program is beautiful. - The input to the program is beautiful. - The program is beautiful. I think it would make more sense if the word "beautiful" was replaced with the word "correct"... It would also help strengthen his argument for why programming is so difficult!

NateEag 7y ago
As a musician, writer, and programmer, my experience has been that beautiful is harder than correct.
dnautics 7y ago
I suspect ie didn't specify correct because correctness is impossible; with the following constraint (i'm surprised he didn't have as the last bullet point): and it must run on top of an unreliable subsystem.
- AnimalMuppet 7y ago
  On top of several unreliable subsystems. I think that's a big part of why it's so hard. You've got leaky, imperfectly understood, unreliable subsystems, and you're trying to build the best system you can on top of it. And what you produce inevitably is a leaky, imperfectly understood, unreliable system... which becomes somebody else's subsystem. And so it goes. You say: We need to create perfect subsystems! Formal verification (or robust type systems, or better requirements, or mathematical reasoning, or some other approach) will save us! But it's not that simple. It starts clear down at the hardware level. How much can you formally prove about your CPU? After taking into account it's errata sheet? The union of the errata sheets of all the revs of the CPU? If you're running on PCs, the errata sheets of every CPU that anybody could conceivably be running on? If you can't formally prove much about the CPU, how are you going to formally prove the OS and/or compiler? And if you can't formally prove those, how can you formally prove anything else? It's leaky, unreliable, incompletely understood subsystems all the way down.
  - dnautics 7y ago

pts_ 7y ago

Oh but many people will say it's child's play and management is where it's at. And then they you will have 10 people doing the work of 1.

lmilcin 7y ago

I think the reason programming is difficult is that really we are dealing with incomplete information while the device that runs your program does not care you have incomplete information and wants to screw you the first time you do something not right in the slightest. Programming is not just understanding how the device, language, libraries work (ie. getting more complete information) but also limiting the ways the adversary can screw you and limiting the fallout. Programming is difficult because developers don't appreciate how important the part of managing this incomplete information is. "I wrote this and it works! Yeay!" And then it goes in prod and fails instantly because you did not take this or that into account. Some bright developers have the ability to manage this. But the problem is that they can't work really well with other developers (at a typical corp) who don't appreciate the problem the same way. This puts them in this untenable positions where they can either do something by themselves, very efficiently, or rely on extremely inefficient process if they want to work with other developers.

BlameKaneda 7y ago
> "...we are dealing with incomplete information while the device that runs your program does not care you have incomplete information and wants to screw you the first time you do something not right in the slightest." Suppose you're becoming pretty comfortable with your skills in a foreign language and you've become pretty decent at speaking it. Occasionally you'll make a mistake---you'll pronounce a word incorrectly, misplace a verb, etc---and chances are the person you're speaking with will be able to figure out what you meant to say. Unfortunately, computers don't work that way. If you're writing a function and your syntax is incorrect, the browser won't understand what you're trying to do.
- grawprog 7y ago
  >Unfortunately, computers don't work that way. If you're writing a function and your syntax is incorrect, the browser won't understand what you're trying to do. Or worse, you and the computer have different understandings about what you're trying to do and it goes along quietly incorrectly for a while until that little mistake causes a problem somewhere else entirely because that one misunderstanding caused a cascade of misunderstandings that kept building up until it finally blew out everywhere all over your program and the quest to find where the problem started begins, well before the task of fixing the problem can start.

imtringued 7y ago

There is a reason why people make a distinction between "Programming" and "Software Engineering". Programming is just the act of writing code. All you have to do is learn a programming language and you are set. "Software Engineering" encompasses everything else on top of programming. You need knowledge of these things: build systems (Make/Gradle), filesystems, networking (IP/TCP/HTTP), Data formats (JSON/XML), Databases(SQL/KV), software architecture, layout/styling, documentation (both reading and writing). This list is just scratching the surface but we can agree that all of these things are critical to build applications. These topics clearly aren't exclusive to "Programming" and knowing them doesn't mean you are a "Programmer". You could also be a sysadmin that is managing a large cluster for multiple applications. But if you are a Software Engineer and not just a mere "Programmer" you know that your job is much much more difficult than merely the "Programmer" part.

amelius 7y ago
But what to do if you have a CS degree with knowledge of all the things you mentioned and perhaps more, but people keep calling you "programmer"?
- duggan 7y ago
  As long as I'm paid a software engineering salary to develop software, I could be called a clown for all the difference it makes. If you're programming, you're a programmer. Or a coder. Or a software developer. Or a software engineer. There is no consensus on the distinction between any of these things. Just lots of people with opinions because it's easy to have an opinion on.
  - notabee 7y ago
    Titles are both a bikeshed and something that can have significant impact on salary, unfortunately. As long as non-technical recruiters are hiring based on buzzwords, it matters.
- varjag 7y ago
  A science degree is not an engineering degree, and one is not practicing science in their hot startup. So, fair enough.

contravariant 7y ago

I feel like the constraints he added are a bit too restrictive, they would force a program to be perfect whereas for most circumstances it would be enough for a program to be bug-free. The real problem seems to be writing bug-free programs, which seems to be difficult mostly because it is hard to specify what a program should do formally (i.e. in code). Note that bugs are never about the program not doing what it is told, but are always a mismatch between the program and the programmers mental model of the program.

mint2 7y ago
Not to mention, the program can be completely bug free but still terrible when put in real life because any one of the 10,000 things about its intended use was unknown or not prioritized.

jkingsbery 7y ago

"After a week of struggling with a broken LDAP sever written in C and badly documented I had a lapse of memory and forget that my boss said and accidentally implemented a server from scratch in Erlang during my lunch break." Joe was awesome, on so many levels. You have to love the healthy rebellious streak and the talent to back it up.

jblakey 7y ago

Love this article! I don't think the guy is playing a 'persona' at all in this piece. These are the kinds of things he thinks about on a daily basis. Heck, these are the kinds of things I think about on a daily basis too, and I'm sure most devs who have been writing code for a few years do. In my daily work, I don't have time to understand everything. There, i've said it. I'm not lazy. I'm not stupid. I just don't have time when I'm trying to get a task/job/chore done. I appreciate good abstraction/encapsulation. A good tool does this. A bad tool fails to do this. Same with documentation, really. Don't get me started!:)

mdonahoe 7y ago
FYI Joe died last year and is best known for inventing Erlang. https://en.m.wikipedia.org/wiki/Joe_Armstrong_(programmer) https://en.m.wikipedia.org/wiki/Joe_Armstrong_(programmer)

0x445442 7y ago

I think there are a number of major problems with the industry. Technology jumping based on anecdotal evidence of the efficacy of doing so. Jumping around so often precludes a lot of practitioners from gaining a deep experience and understanding with the tools they're working with. This may be the only industry I know where pertinent knowledge and experience matters little. The notion of "Full Stack Developers" gives the impression that one can be proficient top to bottom. What I find interesting about the label is full seems to usually be bounded on the lower end at a place much higher than a place where I would use the term full. This is one of the many areas in our industry where hubris is in play. Specialization is usually preferable for quality and scaling. Real world business continually drives the fast and cheap legs of the stool to be chosen by management. However, I think this grates against most practitioners who not only care about quality but would admit, the aspect of quality is one of the major reasons they are even in the field to begin with. There is a large natural tension at play here. I think it's this tension that Joe was articulating. It's seems to me the most satisfied folks in this field are the ones fortunate enough to be compensated for working within a bounded context where over time they can gain more and more experience and knowledge. This naturally leads to a growing confidence and a sense of control over the context with which they work.

adventured 7y ago
I've spent most of my adult life as as "full stack" developer, out of necessity: I build the whole banana on my own and typically work on projects on my own (about 3/4 of the last 20 years). I'm better at some aspects than others and I enjoy some aspects more than others, of course (and I offload/automate anywhere I can). From the late 1990s until five or six years ago, it was fairly easy to keep up with the latest interesting stuff in terms of full stack. Adjustments were modest year to year. At this point I've entirely given up trying to keep up with the very rapid fad switching that has been going on. Real full stack is now only possible if you freeze pretty strictly across the stack and don't try to keep up as the next fad rolls in for a given part of the stack. If you try to keep up with all the fads now, it'll burn you out (and most likely make you hate what you do as you realize how pointless the constant switching is). I've found - as you'd expect - that abandoning the stack rat race hasn't had any negative impact. Most of the latest fads are entirely unnecessary and bring nothing to the table that prior numerous solutions didn't already deliver toward building, launching and maintaining product.

ptah 7y ago

"Before I learned the art, a punch was just a punch, and a kick, just a kick. After I learned the art, a punch was no longer a punch, a kick, no longer a kick. Now that I understand the art, a punch is just a punch and a kick is just a kick." - Bruce Lee

TacticalCoder 7y ago

Re- the Emacs config suddenly breaking... I do something getting more and more common: I put my entire Emacs config in Git. It's a bit more work when upgrading packages (because you have to commit them too) but then there's hardly ever any breakage that's not one Git checkout away (I'd say anyway that Emacs doesn't that often break at all: it's more the usual package dependencies SNAFU of our trade that bites Emacs users once in a while when they upgrade this or that package). On a funny side note I had a very bad Emacs breakage recently and at first couldn't understand why checking out the latest known correct Git version wasn't working on my main machine. It was working on another computer (btw copying my entire Emacs config is, well, also one git command away, so is backuping). Turns out: for whatever reason the file containing the list of files recently opened by Emacs got corrupted in a very strange way and that's one of the rare Emacs file I'm not committing into Git. Took me a few minutes to sort out.

PerryCox 7y ago
I do the same with my .vim folder. You can place your .vimrc file in there as .vim/vimrc and now everything is backed up in git. I've been working this way for a few years now and can get setup on a new machine in a matter of minutes.
samatman 7y ago
Same, but with my entire .config folder.

quinnydinny 7y ago

I think I'll start using the phrase "Google Casino" now.

commandlinefan 7y ago

It's kind of the worst of both worlds: it looks like it should be easy, but it's confoundingly difficult in ways that are impossible to see unless you're actually trying to practice it.

hhas01 7y ago
Given any non-deterministic problem, 98% programmers will treat it as a deterministic nail and hit it with their favorite C until one or both is dead.
wool_gather 7y ago
Is this not true of most difficult things?
- commandlinefan 7y ago
  When I look at the high regard most people hold, say, lawyers and doctors in, who also do hard things (that are accepted as hard), I’d have to say no.

40acres 7y ago

For me, programming is difficult because once you reach a certain level of complexity it's very difficult to keep a robust enough model of the program in your head. TDD has really helped me in this regard because it forces me to start building the model from ground up as opposed to in media res.

yters 7y ago

My experience has been we have a big pile of complexity with some way of doing things. New shiny tech promises to eliminate this complexity. Perhaps it does, but also introduces new level of complexity. Old complexity hasn't fully vanished either, but now its problems have to be solved through the new level of complexity, resulting in a further emergent level of complexity. Fortunately, there is a new shiny technology that will make all this complexity go away.

dang 7y ago

Discussed at the time: https://news.ycombinator.com/item?id=7197255 https://news.ycombinator.com/item?id=7197255 2016: https://news.ycombinator.com/item?id=11002731 https://news.ycombinator.com/item?id=11002731 2019: https://news.ycombinator.com/item?id=19717877 https://news.ycombinator.com/item?id=19717877