4 ms·

I wondered about this a lot, while using certain software at work, and noticing that there are certain kinds of low quality that annoy me in different ways, and

I wondered about this a lot, while using certain software at work, and noticing that there are certain kinds of low quality that annoy me in different ways, and the one I focused on is the maddening kind of software crap where you know it could be good if they just looked at it and got a few brave people to fix it! Why don’t they? It’s because, first principle, the kind of quality dip that drives you nuts, is the one that shows good engineers working with bad engineers. It’s a situation that sets off all our ridiculousness sensors and indignity flags. But a company that gets large enough is always going to converge on the same ratio of good to bad engineers that exists in the industry. It’s like reading a comic book with a really good artist and a really bad inker or something — you just feel the difference so preconciously. With small companies, they usually attract like, so the good engineers push the bad ones out or vice versa and we just think the product is good or bad. It’s the mix that drives us crazy.

threatripper 3y ago
I don't think it is this. Good engineers could solve those problems if they had the time to. I think it's more about the people who make decisions not caring enough about the product quality. And also that most quality issues do not show up in metrics. So solving those issues just isn't a priority at all and if it becomes a low priority then low priority workers get assigned to it. Good people learn to follow the money and they learn to follow metrics that prove their success. Problems without metrics are not real. Stop bringing them up in discussions.
- makk 3y ago
  In my experience, most engineers are bad at advocating for the resources needed to make the changes and most product managers are bad at prioritizing fixes without clear guidance from engineering. Catch-22.
  - pooper 3y ago
    My manager talks the talk about how every developer in the team should be able to do all tasks. Why are we waiting for the database administrator guy to do the SQL part instead of doing it ourselves and yet I have a feeling he is not even a developer at all. At least my skip clearly has some development experience and even some self awareness that what used to be "best practices" then are now known to be bad now but at least I feel like he understands the general process. This whole idea of anyone can work on any ticket but we won't give them any time to review everyone else's changes is what grinds my gears. I should not have to "manage up". Management should just do its job.
    - sgarland 3y ago
      > every developer in the team should be able to do all tasks I hate this. People have strengths, even if they’re all technically backend / frontend / whatever. Should you have more than one person who can perform a given task? Ideally yes, but let’s not pretend that Alice isn’t objectively better at SQL than James, but worse at async functions. Let people do what they’re best at, and enjoy the most.
      - bee_rider 3y ago
        I could see why management wouldn’t want to do that. By not getting Alice some practice on async functions, aren’t they making the team more fragile? Everything in moderation of course, but the team wouldn’t want to start leaning on each other’s specialization to the point that it all falls apart if somebody quits.
        pooper 3y ago
        I would love it if we were all "cross function" but that comes at a cost of reduced velocity. First of all, a manager shouldn't be side channel dm his reports questioning the estimates/story points the team collectively decided at all but in this situation you have to live with reduced capacity forever if you want everyone to be a jack of all trades. Management wants to have its cake and eat it too. I feel like if you object to an estimate, you must have to do the task yourself with the reduced estimate. This falls flat because I suspect my manager has ZERO programming/qa/development or even business analyst experience. Just my personal opinion that if you think the estimate is wrong, you should take the task yourself and do it in less time or shut up. You know how we talk about developers not able to do fizzbuzz with ten years' experience? I suspect he is whatever the equivalent of that is for managers.
- packetlost 3y ago
  There's also a lot of other factors. Touching things that otherwise work but are ugly introduces risk of regressions. Good tests are a mitigation strategy, but they are not and will never be perfect. Not everything needs to be so risk averse, but some projects do.
127 3y ago
I'm the only engineer for my product. The feedback from the customers is very positive. They like most of the parts. Yet there are also many problems and annoying issues. They exist because extremely complex multidimensional issues. Majority of those issues could be solved by heroic use of mental and physical energy. Yet the cost/benefit for my life and mental health goes too high.
- pdimitar 3y ago
  You are the exception however. Most people just dissociate and collect paychecks because bureaucracy and clueless managers burned them out. I don't blame the engineers, not by default anyway, though there are still some pretty dense people I wouldn't grace with the word "programmer" at all. We should blame leadership 90% of the time and history shows that we are right to do so.

threatripper 3y ago

I don't think it is this. Good engineers could solve those problems if they had the time to. I think it's more about the people who make decisions not caring enough about the product quality. And also that most quality issues do not show up in metrics. So solving those issues just isn't a priority at all and if it becomes a low priority then low priority workers get assigned to it. Good people learn to follow the money and they learn to follow metrics that prove their success. Problems without metrics are not real. Stop bringing them up in discussions.

makk 3y ago
In my experience, most engineers are bad at advocating for the resources needed to make the changes and most product managers are bad at prioritizing fixes without clear guidance from engineering. Catch-22.
- pooper 3y ago
  My manager talks the talk about how every developer in the team should be able to do all tasks. Why are we waiting for the database administrator guy to do the SQL part instead of doing it ourselves and yet I have a feeling he is not even a developer at all. At least my skip clearly has some development experience and even some self awareness that what used to be "best practices" then are now known to be bad now but at least I feel like he understands the general process. This whole idea of anyone can work on any ticket but we won't give them any time to review everyone else's changes is what grinds my gears. I should not have to "manage up". Management should just do its job.
  - sgarland 3y ago
    > every developer in the team should be able to do all tasks I hate this. People have strengths, even if they’re all technically backend / frontend / whatever. Should you have more than one person who can perform a given task? Ideally yes, but let’s not pretend that Alice isn’t objectively better at SQL than James, but worse at async functions. Let people do what they’re best at, and enjoy the most.
    - bee_rider 3y ago
      I could see why management wouldn’t want to do that. By not getting Alice some practice on async functions, aren’t they making the team more fragile? Everything in moderation of course, but the team wouldn’t want to start leaning on each other’s specialization to the point that it all falls apart if somebody quits.
      - pooper 3y ago
        I would love it if we were all "cross function" but that comes at a cost of reduced velocity. First of all, a manager shouldn't be side channel dm his reports questioning the estimates/story points the team collectively decided at all but in this situation you have to live with reduced capacity forever if you want everyone to be a jack of all trades. Management wants to have its cake and eat it too. I feel like if you object to an estimate, you must have to do the task yourself with the reduced estimate. This falls flat because I suspect my manager has ZERO programming/qa/development or even business analyst experience. Just my personal opinion that if you think the estimate is wrong, you should take the task yourself and do it in less time or shut up. You know how we talk about developers not able to do fizzbuzz with ten years' experience? I suspect he is whatever the equivalent of that is for managers.
packetlost 3y ago
There's also a lot of other factors. Touching things that otherwise work but are ugly introduces risk of regressions. Good tests are a mitigation strategy, but they are not and will never be perfect. Not everything needs to be so risk averse, but some projects do.

127 3y ago

I'm the only engineer for my product. The feedback from the customers is very positive. They like most of the parts. Yet there are also many problems and annoying issues. They exist because extremely complex multidimensional issues. Majority of those issues could be solved by heroic use of mental and physical energy. Yet the cost/benefit for my life and mental health goes too high.

pdimitar 3y ago
You are the exception however. Most people just dissociate and collect paychecks because bureaucracy and clueless managers burned them out. I don't blame the engineers, not by default anyway, though there are still some pretty dense people I wouldn't grace with the word "programmer" at all. We should blame leadership 90% of the time and history shows that we are right to do so.