3 ms·

Re: Despite the perceived smartness, our industry has a weird anti-intellectualism deeply ingrained in it. Programming is a profession - you're supposed to get

by tabtab 7y ago

Re: Despite the perceived smartness, our industry has a weird anti-intellectualism deeply ingrained in it. Programming is a profession - you're supposed to get better over time. Unfortunately, programming is statistically a dead-end job. Ageism kicks in and one has to bail out of programming to get more money, because old programmers are on average not valued in the market-place. I'm just the messenger. Part of it is the fad-driven nature of our industry that whips around what's "in" technology like the tail of a captured fish. Until Fad Cops clamp down on nonsense and excess, it's a young person's game. Many companies stick with COBOL not because it's better, but because it's stable, like Latin, because it's a "dead language". Nobody comes along and gums it up with spaghetti "Design Patterns" or 7 layers of microservices because "the big boys are doing it!". Warren Buffett has said part of his success is due to his ability to say "no" when everyone else is saying "yes". He willingly lets others be the guinea pig. As far as functional programming, it takes a different mindset than imperative programming, and for many there is a relatively long learning curve until they match or exceed their imperative productivity. If programming is a dead-end career, per above, that curve may not be economical. I personally find functional harder to debug because it's harder to "x-ray the pipes" of intermediate steps, and have not got over that difficulty yet. I personally find it easier to break up imperative code into smaller intermediate steps or parts, subject to inspection via debuggers or Write() statements. Somebody once said: "Functional makes it easier to express what you want, but imperative makes it easier to see what you actually have." That rang so true for me.

TeMPOraL 7y ago
There is something to that, but it applies at the (predicted) end of one's career. But what I'm writing about applies at the beginning - the idea that being forever stuck at a level of skill only a tiny bit higher than what an average developer enters their first job with. EDIT: RE debugging functional code, I don't find it in any way more difficult than imperative - but with a caveat that my functional programming experience is limited to typical for Lisp, Clojure and Erlang, and not e.g. Haskell. With functional code, you just hook up in some place in the pipeline and start leaking what's coming in and out of there to the outside world (stdout, REPL, debugger). Because it's functional, you can be sure you're not missing any hidden state. You can keep replying the calls manually, perhaps tweaking inputs, to identify the problem. After finding and fixing a bug, it's relatively trivial to turn your debugging work into a regression test. It seems to me that your complaint is less about functional code and more about point-free style, which is arguably a bit more difficult to hook into, but only because debugging tools aren't really optimized for it.
- tabtab 7y ago
  One has to write code intended for a variety of readers having different skill levels. In practice you have to "dumb it down" to a degree.
  - TeMPOraL 7y ago
    To a degree. Not to the lowest possible level. You can and should have some expectations of the people who work on the project, and if new people don't meet those expectations, they should be trained on the job until they do. It's better than forgoing the leverage the more complex tools give you. I mean, imagine if civil engineers started restricting their designs to work only with hand shovels, on the assumption that excavators are evil because a random construction worker won't know how to operate one.
    - tabtab 7y ago
      It's a matter of economics of the labor pool. Companies often want high-skilled developers on the cheap, and then act surprised when they can't actually find any at their offer level (or they have poor people/team skills). Nor do they often want to pay and/or wait for training. Maybe there is a good reason they do that but from our techie perspective can't see. Unless you walk a mile in an owner's shoes, it's hard to say. Either way, they probably won't change this pattern, and thus one should code for a lower common denominator. We can't re-code the world.
      - TeMPOraL 7y ago
        > Either way, they probably won't change this pattern, and thus one should code for a lower common denominator. Why? Unless they get push back from the HR/upper management, it's the tech team that makes this decision, in big part by setting expectations and minimum accepted competence level. It's thus the technical team that can change this pattern, by not making itself to code to the lowest common denominator, by setting standards, by embracing perpetual learning as part of the job. Setting an appropriately high bar for both ourselves and our future teammates is part of the job too. Our non-technical bosses ain't gonna to do this for us - how could they? They don't have the necessary technical expertise; they depend on us to provide it.

by tabtab 7y ago

TeMPOraL 7y ago

There is something to that, but it applies at the (predicted) end of one's career. But what I'm writing about applies at the beginning - the idea that being forever stuck at a level of skill only a tiny bit higher than what an average developer enters their first job with. EDIT: RE debugging functional code, I don't find it in any way more difficult than imperative - but with a caveat that my functional programming experience is limited to typical for Lisp, Clojure and Erlang, and not e.g. Haskell. With functional code, you just hook up in some place in the pipeline and start leaking what's coming in and out of there to the outside world (stdout, REPL, debugger). Because it's functional, you can be sure you're not missing any hidden state. You can keep replying the calls manually, perhaps tweaking inputs, to identify the problem. After finding and fixing a bug, it's relatively trivial to turn your debugging work into a regression test. It seems to me that your complaint is less about functional code and more about point-free style, which is arguably a bit more difficult to hook into, but only because debugging tools aren't really optimized for it.

tabtab 7y ago
One has to write code intended for a variety of readers having different skill levels. In practice you have to "dumb it down" to a degree.
- TeMPOraL 7y ago
  To a degree. Not to the lowest possible level. You can and should have some expectations of the people who work on the project, and if new people don't meet those expectations, they should be trained on the job until they do. It's better than forgoing the leverage the more complex tools give you. I mean, imagine if civil engineers started restricting their designs to work only with hand shovels, on the assumption that excavators are evil because a random construction worker won't know how to operate one.
  - tabtab 7y ago
    It's a matter of economics of the labor pool. Companies often want high-skilled developers on the cheap, and then act surprised when they can't actually find any at their offer level (or they have poor people/team skills). Nor do they often want to pay and/or wait for training. Maybe there is a good reason they do that but from our techie perspective can't see. Unless you walk a mile in an owner's shoes, it's hard to say. Either way, they probably won't change this pattern, and thus one should code for a lower common denominator. We can't re-code the world.
    - TeMPOraL 7y ago
      > Either way, they probably won't change this pattern, and thus one should code for a lower common denominator. Why? Unless they get push back from the HR/upper management, it's the tech team that makes this decision, in big part by setting expectations and minimum accepted competence level. It's thus the technical team that can change this pattern, by not making itself to code to the lowest common denominator, by setting standards, by embracing perpetual learning as part of the job. Setting an appropriately high bar for both ourselves and our future teammates is part of the job too. Our non-technical bosses ain't gonna to do this for us - how could they? They don't have the necessary technical expertise; they depend on us to provide it.