6 ms·

Screw this. Developers should advocate for their craft and for quality, and business metrics should hold an adversarial position to balance things out. We defin

Screw this. Developers should advocate for their craft and for quality, and business metrics should hold an adversarial position to balance things out. We definitely should not be accepting the narrative that developers just do what they are told and don't push back on what we know is good for product - we are in a unique position of power, we should recognise this and use it for the betterment of the industry as a whole. The alternative is we let corporate greed slide our standards of quality into the gutter thereby making the job at hand miserable.

sreekotay 4y ago
Very much agree with this. That said given the quality of what they have put out, I'd surmise the issue here is morelikely they don't feel the same pain on load times? Bandwidth too good, rigs too powerful, dev envs overpowered, etc. to enable developer velocity can often also mask real world problems. Hell, even hot reload can mean you don't see load as often and are able to easily rationalize as "not that big a deal" - I wouldn't necessarily take it as a sign they are not deeply invested in their craft.
- s0l1dsnak3123 4y ago
  I very much agree with you as well actually. One of the things that I've instituted at my work is our methodology for acquiring test phones for our product (WhatsApp for hospitals, basically). We go to a supermarket and buy the most eye-catching box of the budget phones available in the phone aisle. We've squashed so many bugs and performance problems this way. It's cheaper, it instils empathy in product decisions, and our customers love the user experience as a result. Similarly, one of my first big decisions after joining was to wean ourselves from our AWS addiction using Kubernetes. This also allowed us to design a dev env that fits on a modern machine comfortably, but can scale to entire Hospital Trusts in production. Once again: focusing on portability now means we can sell our product on-prem and hybrid, because we designed our developer UX this way.
- foobarian 4y ago
  I don't know, this seems like it was a pure CPU problem on good hardware. But anyway a developer who has 10 hour days and backlog stretching beyond the horizon will not have idle time to go try things out. It needs to be someone's explicit job to go hunt down things like this. And given it was data-size dependent, I wouldn't be surprised this was not an issue at the start while someone who's job it was to look for this kind of issue was looking. And the issue appeared after they got retasked to something else. In fact maybe this is the only kind of issue that you end up with after all is said and done. Just like in WW2 they reinforced the parts of the fuselage on returning fighter craft without bullet holes, because if a bullet hit there, the craft would not return.
blowski 4y ago
Sounds like an extremely false dichotomy. There is also the solution that you set up your own company, or convince your manager your time is best spent on this. I’ve worked around too many startups ruled by developers. They’re being run into the ground because those developers think technical NFRs as defined by them are the be all and end all. They’re not. Those same developers will happily spend months fiddling with the system without making any actual improvements and call it “paying down technical debt”. Give me a PM (or good engineer) that understands the bigger picture every time.
- s0l1dsnak3123 4y ago
  > There is also the solution that you set up your own company, or convince your manager your time is best spent on this. This is the definition of a flippant comment. Why should society require we become the lord of our own domain or a political chameleon just so that we can advocate for decent standards? Should people who live on flood plains "just move" when the tide comes in? Ridiculous. Understanding the bigger picture includes understanding the developer's point of view. > I’ve worked around too many startups ruled by developers. They’re being run into the ground because those developers think technical NFRs as defined by them are the be all and end all. They’re not. Those same developers will happily spend months fiddling with the system without making any actual improvements and call it “paying down technical debt”. Sounds like those super-clever managers didn't understand what the hell was going on to me. Perhaps they should've held their nose and tried to learn about their product so they can understand and communicate that bigger picture they speak of instead of abdicating their adversarial role and leaving dev teams rudderless.
  - blowski 4y ago
    What makes you think they didn’t understand the developers’ point of view? Maybe they understood it, but didn’t agree with it.
    - s0l1dsnak3123 4y ago
      > Give me a PM (or good engineer) that understands the bigger picture every time. I was referring to this sentence: you're now telling us that the ideal good engineer understands the developer's point of view but doesn't agree with it. It sounds like you just want to be surrounded by yes men to me. The perfect recipe for a failed startup.
heretogetout 4y ago
This is why I try to hold developers accountable for actions their software performs or allows, like auto-banning accounts or not supporting billing limits.
tshaddox 4y ago
> Developers should advocate for their craft and for quality, and business metrics should hold an adversarial position to balance things out. What makes you think this isn't the case? Business metrics holding an adversarial position over other interests obviously doesn't preclude business metrics defeating other interests.
- pdimitar 4y ago
  In my experience, business interests always override everything else. Often times to the detriment of the business, and often as soon as mere 3 to 6 months in the future.
deleted 4y ago
[deleted]

sreekotay 4y ago

Very much agree with this. That said given the quality of what they have put out, I'd surmise the issue here is morelikely they don't feel the same pain on load times? Bandwidth too good, rigs too powerful, dev envs overpowered, etc. to enable developer velocity can often also mask real world problems. Hell, even hot reload can mean you don't see load as often and are able to easily rationalize as "not that big a deal" - I wouldn't necessarily take it as a sign they are not deeply invested in their craft.

s0l1dsnak3123 4y ago
I very much agree with you as well actually. One of the things that I've instituted at my work is our methodology for acquiring test phones for our product (WhatsApp for hospitals, basically). We go to a supermarket and buy the most eye-catching box of the budget phones available in the phone aisle. We've squashed so many bugs and performance problems this way. It's cheaper, it instils empathy in product decisions, and our customers love the user experience as a result. Similarly, one of my first big decisions after joining was to wean ourselves from our AWS addiction using Kubernetes. This also allowed us to design a dev env that fits on a modern machine comfortably, but can scale to entire Hospital Trusts in production. Once again: focusing on portability now means we can sell our product on-prem and hybrid, because we designed our developer UX this way.
foobarian 4y ago
I don't know, this seems like it was a pure CPU problem on good hardware. But anyway a developer who has 10 hour days and backlog stretching beyond the horizon will not have idle time to go try things out. It needs to be someone's explicit job to go hunt down things like this. And given it was data-size dependent, I wouldn't be surprised this was not an issue at the start while someone who's job it was to look for this kind of issue was looking. And the issue appeared after they got retasked to something else. In fact maybe this is the only kind of issue that you end up with after all is said and done. Just like in WW2 they reinforced the parts of the fuselage on returning fighter craft without bullet holes, because if a bullet hit there, the craft would not return.

blowski 4y ago

Sounds like an extremely false dichotomy. There is also the solution that you set up your own company, or convince your manager your time is best spent on this. I’ve worked around too many startups ruled by developers. They’re being run into the ground because those developers think technical NFRs as defined by them are the be all and end all. They’re not. Those same developers will happily spend months fiddling with the system without making any actual improvements and call it “paying down technical debt”. Give me a PM (or good engineer) that understands the bigger picture every time.

s0l1dsnak3123 4y ago
> There is also the solution that you set up your own company, or convince your manager your time is best spent on this. This is the definition of a flippant comment. Why should society require we become the lord of our own domain or a political chameleon just so that we can advocate for decent standards? Should people who live on flood plains "just move" when the tide comes in? Ridiculous. Understanding the bigger picture includes understanding the developer's point of view. > I’ve worked around too many startups ruled by developers. They’re being run into the ground because those developers think technical NFRs as defined by them are the be all and end all. They’re not. Those same developers will happily spend months fiddling with the system without making any actual improvements and call it “paying down technical debt”. Sounds like those super-clever managers didn't understand what the hell was going on to me. Perhaps they should've held their nose and tried to learn about their product so they can understand and communicate that bigger picture they speak of instead of abdicating their adversarial role and leaving dev teams rudderless.
- blowski 4y ago
  What makes you think they didn’t understand the developers’ point of view? Maybe they understood it, but didn’t agree with it.
  - s0l1dsnak3123 4y ago
    > Give me a PM (or good engineer) that understands the bigger picture every time. I was referring to this sentence: you're now telling us that the ideal good engineer understands the developer's point of view but doesn't agree with it. It sounds like you just want to be surrounded by yes men to me. The perfect recipe for a failed startup.

heretogetout 4y ago

This is why I try to hold developers accountable for actions their software performs or allows, like auto-banning accounts or not supporting billing limits.

tshaddox 4y ago

> Developers should advocate for their craft and for quality, and business metrics should hold an adversarial position to balance things out. What makes you think this isn't the case? Business metrics holding an adversarial position over other interests obviously doesn't preclude business metrics defeating other interests.

pdimitar 4y ago
In my experience, business interests always override everything else. Often times to the detriment of the business, and often as soon as mere 3 to 6 months in the future.

deleted 4y ago

[deleted]