5 ms·

But where do we draw the line? If someone does not understand the idea behind interfaces or proper exception handling, who is to blame? If you write Java and St

But where do we draw the line? If someone does not understand the idea behind interfaces or proper exception handling, who is to blame? If you write Java and Streams are the natural solution, but the developer you work with never bothered to look them up, because they are "complex" and "FP-something"? These are polemic examples, but there is a line where sticking to the lowest common knowledge will hurt your best developers by either sucking the joy out of their work or by forcing write them a lot of boilerplate code. And I've heard of teams, where the whole team would ban features of a new standard of the language, because they've written code for 20 years without them before.

baobabKoodaa 5y ago
> But where do we draw the line? Well, we can draw the line based on who is going to maintain the code after we are gone. If we know that the organization is only going to hire rockstar ninja experts, then we can make code that is readable for rockstar ninja experts. If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. If you think mediocre developers can't understand streams, then don't use streams. (Personally I think your examples of interfaces, exception handling, and streams, are all things that have their time and place, so it would be fine to use them when needed, and just expect that developers after you will know/learn that stuff.)
- 908B64B197 5y ago
  > If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. There's a secret third option: The organization could just hire good devs.
  - baobabKoodaa 5y ago
    > There's a secret third option: The organization could just hire good devs. That's rarely up to the individual developer to decide. If you cook a complex bowl of abstraction soup, knowing that mediocre developers will maintain it after you, that's on your conscience.
    - pojzon 5y ago
      The evaluation objective for those medicore devs should be to „get up to speed” or the company will never improve and soon become overrun by competition.
      - baobabKoodaa 5y ago
        Aha. And should every single company employ above-average developers? How does that work out, mathematically?
        908B64B197 5y ago
        It doesn't: The average startup goes bankrupt.
        baobabKoodaa 5y ago
        The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". Ok, sure. So, in your view, a developer who leaves behind over-architected complexity to "mediocre" developers is a surefire recipe for going bankrupt... and this was supposed to be in defense of overarchitecting complex codebases? To me it sounds like going bankrupt is bad, so we as developers should strive to prevent our employers from going bankrupt, no? So if you work for a startup that you know is going to hire mediocre developers after you, surely you should strive to leave behind the kind of codebase that doesn't bankrupt the company after you leave?
        908B64B197 5y ago
        > The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". For a lot of corporations, making the jump to software is effectively starting a new company within the company. > To me it sounds like going bankrupt is bad, so we as developers should strive to prevent our employers from going bankrupt, no? Bad hires tank companies. > So if you work for a startup that you know is going to hire mediocre developers after you, surely you should strive to leave behind the kind of codebase that doesn't bankrupt the company after you leave? That's a red flag right here. It means sell your RSU as soon as you can.

baobabKoodaa 5y ago

> But where do we draw the line? Well, we can draw the line based on who is going to maintain the code after we are gone. If we know that the organization is only going to hire rockstar ninja experts, then we can make code that is readable for rockstar ninja experts. If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. If you think mediocre developers can't understand streams, then don't use streams. (Personally I think your examples of interfaces, exception handling, and streams, are all things that have their time and place, so it would be fine to use them when needed, and just expect that developers after you will know/learn that stuff.)

908B64B197 5y ago
> If we know that the organization is going to hire mediocre developers, then we need to make code that is understandable by mediocre developers. There's a secret third option: The organization could just hire good devs.
- baobabKoodaa 5y ago
  > There's a secret third option: The organization could just hire good devs. That's rarely up to the individual developer to decide. If you cook a complex bowl of abstraction soup, knowing that mediocre developers will maintain it after you, that's on your conscience.
  - pojzon 5y ago
    The evaluation objective for those medicore devs should be to „get up to speed” or the company will never improve and soon become overrun by competition.
    - baobabKoodaa 5y ago
      Aha. And should every single company employ above-average developers? How does that work out, mathematically?
      - 908B64B197 5y ago
        It doesn't: The average startup goes bankrupt.
        baobabKoodaa 5y ago
        The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". Ok, sure. So, in your view, a developer who leaves behind over-architected complexity to "mediocre" developers is a surefire recipe for going bankrupt... and this was supposed to be in defense of overarchitecting complex codebases? To me it sounds like going bankrupt is bad, so we as developers should strive to prevent our employers from going bankrupt, no? So if you work for a startup that you know is going to hire mediocre developers after you, surely you should strive to leave behind the kind of codebase that doesn't bankrupt the company after you leave?
        908B64B197 5y ago
        > The average corporation doesn't go bankrupt, so you moved the goalpost from "corporation" to "startup". For a lot of corporations, making the jump to software is effectively starting a new company within the company. > To me it sounds like going bankrupt is bad, so we as developers should strive to prevent our employers from going bankrupt, no? Bad hires tank companies. > So if you work for a startup that you know is going to hire mediocre developers after you, surely you should strive to leave behind the kind of codebase that doesn't bankrupt the company after you leave? That's a red flag right here. It means sell your RSU as soon as you can.