3 ms·

Here is the thing: what prevents me from learning a new technology is not that I don't get the "big picture" concept which inspired it. Cognitive load-wise, the

Here is the thing: what prevents me from learning a new technology is not that I don't get the "big picture" concept which inspired it. Cognitive load-wise, these concepts aren't difficult to grasp in the abstract. What slows me down is the little implementation detail that is causing this weird bug that I just don't understand. And if it is a new technology, then stack overflow doesn't have the answer. So, to take the example the author gives, when Rails was new, its not that I didn't understand the MVC framework and how the roles were different. I didn't understand that RVM had to be set to a default ruby version every time I restarted the console.

sharadov 8y ago
You nailed it, I'll pick up the technology, but then get stuck in some silly bug which I can't find the solution to and abandon it after getting frustrated.
- DanielBMarkham 8y ago
  But that's actually the work: getting stuck, sticking with it, and reasoning your way out of being stuck. That's programming. Fair enough if you avoid certain situations because this is where you end up -- I do the same thing -- but the work is the work whether it's a new language or some oddball patch/upgrade that made things act funky in ways they didn't before.
  - dmortin 8y ago
    There is a difference between learning a system and getting stuck on some configuration detail. It's very frustrating when you want to understand a system and you're stuck with some error which is not your fault, but it's some bug in the new technology and instead of learning the technology you spend time with hunting some configuration bug. That won't help you learning the technology, because that bug will be fixed in some configuration script and later users won't even encounter it, because the tooling will generate the proper scripts for the first time. So it's often not that kind of knowledge which proves to be useful later, but some implementation detail which you won't ever encounter again.
    - bunderbunder 8y ago
      This is roughly my litmus test: Do I see a lot of examples of people running into problems, and the solution turns out to be an obscure configuration (or worse, a case where the default configuration is something that should never be done)? Do I see evidence of a lot of cases where the right way to do things is not the obvious way to do things? Both of these are red flags. Sure, I can learn how to steer around all the potholes. But so will everyone else who works on the project. Eventually someone will miss some important detail, or go on a refactoring expedition and end up removing a bunch of what appears to be excess complication but is actually a carefully constructed workaround for some wart in the system (the comment explaining this having long since been deleted - or maybe migrated to the team wiki, where all good information goes to die - by someone who had been watching a lot of Uncle Bob videos on YouTube at the time), and then production bugs sneak in, and eventually people quite rationally start to blame the technology.
      - davidjnelson 8y ago
        I agree it's a great idea to leave comments in code, for things that are done in a non obvious way for good reasons.
        xsmasher 8y ago
        The highest purpose a comment can serve is to explain why you're doing something (which looks) stupid.
  - sharadov 8y ago
    I've the tenacity to work through understanding it, but when there is an obvious configuration issue which has been overlooked or not spelled out clearly - that's what irks me.
  - deleted 8y ago
    [deleted]

sharadov 8y ago

You nailed it, I'll pick up the technology, but then get stuck in some silly bug which I can't find the solution to and abandon it after getting frustrated.

DanielBMarkham 8y ago
But that's actually the work: getting stuck, sticking with it, and reasoning your way out of being stuck. That's programming. Fair enough if you avoid certain situations because this is where you end up -- I do the same thing -- but the work is the work whether it's a new language or some oddball patch/upgrade that made things act funky in ways they didn't before.
- dmortin 8y ago
  There is a difference between learning a system and getting stuck on some configuration detail. It's very frustrating when you want to understand a system and you're stuck with some error which is not your fault, but it's some bug in the new technology and instead of learning the technology you spend time with hunting some configuration bug. That won't help you learning the technology, because that bug will be fixed in some configuration script and later users won't even encounter it, because the tooling will generate the proper scripts for the first time. So it's often not that kind of knowledge which proves to be useful later, but some implementation detail which you won't ever encounter again.
  - bunderbunder 8y ago
    This is roughly my litmus test: Do I see a lot of examples of people running into problems, and the solution turns out to be an obscure configuration (or worse, a case where the default configuration is something that should never be done)? Do I see evidence of a lot of cases where the right way to do things is not the obvious way to do things? Both of these are red flags. Sure, I can learn how to steer around all the potholes. But so will everyone else who works on the project. Eventually someone will miss some important detail, or go on a refactoring expedition and end up removing a bunch of what appears to be excess complication but is actually a carefully constructed workaround for some wart in the system (the comment explaining this having long since been deleted - or maybe migrated to the team wiki, where all good information goes to die - by someone who had been watching a lot of Uncle Bob videos on YouTube at the time), and then production bugs sneak in, and eventually people quite rationally start to blame the technology.
    - davidjnelson 8y ago
      I agree it's a great idea to leave comments in code, for things that are done in a non obvious way for good reasons.
      - xsmasher 8y ago
        The highest purpose a comment can serve is to explain why you're doing something (which looks) stupid.
- sharadov 8y ago
  I've the tenacity to work through understanding it, but when there is an obvious configuration issue which has been overlooked or not spelled out clearly - that's what irks me.
- deleted 8y ago
  [deleted]