3 ms·

>"why did you hire this guy in the first place, or why did you not fire him?" Because many companies are actually looking for these guys following the principl

>"why did you hire this guy in the first place, or why did you not fire him?" Because many companies are actually looking for these guys following the principles to a T initially. It's only midway through they complain about them lacking flexibility, if ever. Then later everyone complains about the incomprehensible mess while a few go "that's the way things are, we just need smarter people to understand our solutions". And of course, it takes them 10 years to do something with a huge team which only took a small team a few years.

zelphirkalt 4y ago
While one can certainly over-engineer everything into N levels of abstraction either with OOP stuff or with FP stuff like higher-order functions (or higher-higher-...-order functions for that matter), I could well imagine, that a person who knows FP stuff would not have as much of a problem with a specific code base and when that person leaves and only OOP-only people are left, they scratch their heads and call it an "unreadable mess". So I would not rule out that possibility, without having seen the actual code. Documentation is a point though. One should always document at least for a bit stupider version of oneself. One day in the future that self will come back and "not get it". That said, it is at least possible, that the company in question needs to hire a smarter person, or simply a more FP informed person. Also entirely possible, that the code is over-engineered and way too complicated for what it achieves. Without seeing an example ...
- BlargMcLarg 4y ago
  Honestly, I'm done trying to flip the script and approach it as a "well maybe they truly need smarter people to read the code". Companies are openly looking for people giving them a spoonfed answer on 'good code concepts'. Most of these concepts have no academic basis, can be argued rationally both for and against, are shown to be damaging on a daily basis, and seem to have nothing going for them but 'preference' and 'context matters'. At best they form a way to talk about some things, often buzzwordy. If companies are filtering based on whether you can regurgitate SOLID, DRY, etc., it becomes a self-fulfilling prophecy. At least some fanatics will treat those things as the solution to every problem and create something illegible to the majority of the population. You don't solve that by pushing the burden on the majority to adapt, you solve that by being a smarter strategist and stop letting fanatics do as they please. It's exactly as you say, write code with the commoner in mind, not the genius. Writing code is part literature. Don't blame others if your writing is prose, obtuse and completely misses its target audience. Most people aren't born with great writing skills, start cultivating those instead of trying instant 'good code concept' solutions.
  - zelphirkalt 4y ago
    Oh I definitely agree with writing code being a bit similar to writing prose. Along with that comes "naming is hard". It can take several iterations of renaming and restructuring things, taking a step back and thinking about how the program reads and how close that is to being easy to understand, without looking too much at the actual implementation and so on. And it does take practice, no question. I would add though, that the opposite of DRY and SOLID are feared for good reason. Just imagine, if you had duplication everywhere, because the previous developer did not understand or did not take time to introduce fitting, suitable abstractions or indirections. So these principles are definitely worth something. I guess learning to apply them in the right moments is also something, that needs practice.
  - wnkrshm 4y ago
    In my mind a fitting analogy to building software is like designing and building a machine or a physical tool in mechanical engineering: like a CNC machine, a laser cutter with an optical system for processing etc. There are no rules in designing a machine except for: These are the requirements. First drafts will be analyzed and iterated on by simulation and prototyping (e.g. for mechanical resonances, thermal deformation) - an inexperienced engineering team will have to do a lot of testing and prototyping and failing, while a team who has some experience in building a machine in a specific domain will know what to look out for and what can be compromised on. There are best practices but I feel they are always domain-specific (e.g. everyone wants to put their precise machine on a big block of mass to isolate it from the environment on a machine in a shop floor, while the best-practice for a similar application working on a plane is totally different).

zelphirkalt 4y ago

While one can certainly over-engineer everything into N levels of abstraction either with OOP stuff or with FP stuff like higher-order functions (or higher-higher-...-order functions for that matter), I could well imagine, that a person who knows FP stuff would not have as much of a problem with a specific code base and when that person leaves and only OOP-only people are left, they scratch their heads and call it an "unreadable mess". So I would not rule out that possibility, without having seen the actual code. Documentation is a point though. One should always document at least for a bit stupider version of oneself. One day in the future that self will come back and "not get it". That said, it is at least possible, that the company in question needs to hire a smarter person, or simply a more FP informed person. Also entirely possible, that the code is over-engineered and way too complicated for what it achieves. Without seeing an example ...

BlargMcLarg 4y ago
Honestly, I'm done trying to flip the script and approach it as a "well maybe they truly need smarter people to read the code". Companies are openly looking for people giving them a spoonfed answer on 'good code concepts'. Most of these concepts have no academic basis, can be argued rationally both for and against, are shown to be damaging on a daily basis, and seem to have nothing going for them but 'preference' and 'context matters'. At best they form a way to talk about some things, often buzzwordy. If companies are filtering based on whether you can regurgitate SOLID, DRY, etc., it becomes a self-fulfilling prophecy. At least some fanatics will treat those things as the solution to every problem and create something illegible to the majority of the population. You don't solve that by pushing the burden on the majority to adapt, you solve that by being a smarter strategist and stop letting fanatics do as they please. It's exactly as you say, write code with the commoner in mind, not the genius. Writing code is part literature. Don't blame others if your writing is prose, obtuse and completely misses its target audience. Most people aren't born with great writing skills, start cultivating those instead of trying instant 'good code concept' solutions.
- zelphirkalt 4y ago
  Oh I definitely agree with writing code being a bit similar to writing prose. Along with that comes "naming is hard". It can take several iterations of renaming and restructuring things, taking a step back and thinking about how the program reads and how close that is to being easy to understand, without looking too much at the actual implementation and so on. And it does take practice, no question. I would add though, that the opposite of DRY and SOLID are feared for good reason. Just imagine, if you had duplication everywhere, because the previous developer did not understand or did not take time to introduce fitting, suitable abstractions or indirections. So these principles are definitely worth something. I guess learning to apply them in the right moments is also something, that needs practice.
- wnkrshm 4y ago
  In my mind a fitting analogy to building software is like designing and building a machine or a physical tool in mechanical engineering: like a CNC machine, a laser cutter with an optical system for processing etc. There are no rules in designing a machine except for: These are the requirements. First drafts will be analyzed and iterated on by simulation and prototyping (e.g. for mechanical resonances, thermal deformation) - an inexperienced engineering team will have to do a lot of testing and prototyping and failing, while a team who has some experience in building a machine in a specific domain will know what to look out for and what can be compromised on. There are best practices but I feel they are always domain-specific (e.g. everyone wants to put their precise machine on a big block of mass to isolate it from the environment on a machine in a shop floor, while the best-practice for a similar application working on a plane is totally different).