4 ms·

> it's self-inflicted dumbing-down. I really don't understand where this rampant support for antiintellectualism comes from I don't think it is about dumbing-d

> it's self-inflicted dumbing-down. I really don't understand where this rampant support for antiintellectualism comes from I don't think it is about dumbing-down or antiintellectualism. It is about knowledge. No matter how clever or smart you are, you do not know everything. So any special knowledge (about the OS, the language, etc) you have to be aware of to understand code is a barrier. I specifically don't mean domain knowledge. You got to know stuff about the problem you're trying to solve, sure. I mean knowledge about the tool you use to solve the problem. Its just a tool. Nothing else. A tool should be practical, the less you need to know to use it, the better. If you want to write a manual for a machine, you wouldn't use poetry, right? Of course some stuff is worth it. If there's a language construct that makes lots of things "better" (whatever that means) - cool, we should use that. But it should be some generic thing that can be applied to many problems (so its worth learning about it), not some specific thing that solves specific problems more clever.

TeMPOraL 5y ago
'unscaled gave a good example elsewhere in the thread[0]. "Our junior engineers understand for loops better than map-filter-reduce chains, so let's use for loops instead of spending a few days teaching them". This stuff really happens. Back in the day, in a company that just transitioned from Java 7 to Java 8 across its main projects, I've been told by the boss to maybe not use lambdas too much, because certain co-workers like John Doe[1] aren't so experienced and might not understand them. Thankfully, I was just starting another project with (initially) just a single "less experienced" dev, so I taught him these and related things quickly, and we proceeded to write simpler code, making full use of lambdas and stream APIs where appropriate. And aforementioned John Doe? Half a year later, he discovered on his own that Java 8 had lambdas, grokked them in like 2 hours, and went around the company, evangelizing their use for everyone. > I mean knowledge about the tool you use to solve the problem. Its just a tool. Nothing else. A tool should be practical, the less you need to know to use it, the better. A tool does not exist in isolation from the process. It's a part of it. Everywhere else than software industry, this seems to be understood. If you don't know how to operate the tools you work with, you're considered incompetent, not trained for the work you're performing. The solution to that isn't to dumb down tools - it's to train the operators. You have to pay a little bit up front to upskill your workers, and you then get to continuously reap the benefits of improved productivity due to better use of better tools. Should modern construction be done only with hand shovels, sticks and ropes, because junior construction workers will be confused by excavators and welders? That's how all this talk about junior-friendly code reads to me: an extreme case of being penny wise, pound foolish. Software development is a profession, the job of a junior is first and foremost to learn their trade[2]. -- [0] - https://news.ycombinator.com/item?id=27420543 https://news.ycombinator.com/item?id=27420543 [1] - Name intentionally omitted; the guy has been working in the company for many more years than I have - and was way better than our boss gave him credit for. [2] - Well, unless your company is structured around the idea that juniors do all the work, and seniors are "using their experience to multiply productivity of everyone" aka. just managers without the authority. Which is another trend in the industry that's worrying to me, because it pins the proficiency of the work to whatever junior hires learned before getting the job. And then we're surprised that tech debt is at all-times high everywhere.
- j_wtf_all_taken 5y ago
  The examples you gave are exactly the ones I mean with generic solutions. Stuff you can apply to many things, like lambdas. Such things exist in many programming languages. Yes, that's stuff people should learn and keep up with. But using some weird quirk or very uncommon language construct just to save a couple of lines of code (and show how well you know the language) - tempting, but just don't. And use long, understandable variable names! Don't be a mathematician, you're an engineer! (totally unrelated but its just really annoying)
  - deleted 5y ago
    [deleted]

TeMPOraL 5y ago

'unscaled gave a good example elsewhere in the thread[0]. "Our junior engineers understand for loops better than map-filter-reduce chains, so let's use for loops instead of spending a few days teaching them". This stuff really happens. Back in the day, in a company that just transitioned from Java 7 to Java 8 across its main projects, I've been told by the boss to maybe not use lambdas too much, because certain co-workers like John Doe[1] aren't so experienced and might not understand them. Thankfully, I was just starting another project with (initially) just a single "less experienced" dev, so I taught him these and related things quickly, and we proceeded to write simpler code, making full use of lambdas and stream APIs where appropriate. And aforementioned John Doe? Half a year later, he discovered on his own that Java 8 had lambdas, grokked them in like 2 hours, and went around the company, evangelizing their use for everyone. > I mean knowledge about the tool you use to solve the problem. Its just a tool. Nothing else. A tool should be practical, the less you need to know to use it, the better. A tool does not exist in isolation from the process. It's a part of it. Everywhere else than software industry, this seems to be understood. If you don't know how to operate the tools you work with, you're considered incompetent, not trained for the work you're performing. The solution to that isn't to dumb down tools - it's to train the operators. You have to pay a little bit up front to upskill your workers, and you then get to continuously reap the benefits of improved productivity due to better use of better tools. Should modern construction be done only with hand shovels, sticks and ropes, because junior construction workers will be confused by excavators and welders? That's how all this talk about junior-friendly code reads to me: an extreme case of being penny wise, pound foolish. Software development is a profession, the job of a junior is first and foremost to learn their trade[2]. -- [0] - https://news.ycombinator.com/item?id=27420543 https://news.ycombinator.com/item?id=27420543 [1] - Name intentionally omitted; the guy has been working in the company for many more years than I have - and was way better than our boss gave him credit for. [2] - Well, unless your company is structured around the idea that juniors do all the work, and seniors are "using their experience to multiply productivity of everyone" aka. just managers without the authority. Which is another trend in the industry that's worrying to me, because it pins the proficiency of the work to whatever junior hires learned before getting the job. And then we're surprised that tech debt is at all-times high everywhere.

j_wtf_all_taken 5y ago
The examples you gave are exactly the ones I mean with generic solutions. Stuff you can apply to many things, like lambdas. Such things exist in many programming languages. Yes, that's stuff people should learn and keep up with. But using some weird quirk or very uncommon language construct just to save a couple of lines of code (and show how well you know the language) - tempting, but just don't. And use long, understandable variable names! Don't be a mathematician, you're an engineer! (totally unrelated but its just really annoying)
- deleted 5y ago
  [deleted]