4 ms·

If you modify this to interpret "everything will be paused" as applying just locally to a single team owning a specific area or product, it sounds a lot more se

by ytpete 4y ago

If you modify this to interpret "everything will be paused" as applying just locally to a single team owning a specific area or product, it sounds a lot more sensible. I've been on multiple teams that organically chose to try an approach like that when faced with growing quality debt. A CTO can globally foster a culture that is applied locally in concrete decisions.

wpietri 4y ago
Sure, if we talk about something he didn't say, it could be better. But even then I think it's a big mistake. The point of coding is to make things for people. If we stop making things for people and do something else, however virtuous that something else might seem, I think we aren't moving in the direction of long-term improvement. One of the biggest roots of low quality is high time pressure. So I'm fine throttling back feature to 80%, 50%, maybe even 20% of the long-term capacity so that everybody can start learning to work in ways where technical debt decreases and quality practices get properly established. But I think it's vital that we keep that x% of forward motion. For all sorts of reasons, but the biggest being that everybody, techies and product people most definitely included, need to learn to work together such that quality stays high. If the product people just wander off for a few months while the devs do mop and bucket work, what people generally learn is to repeat the cycle of making such a big mess that another big cleanup is needed down the road.
- mjburgess 4y ago
  That isnt the purpose of coding, no. That's its purpose for the first keystrokes, but thereafter, when a user has a product, it is to make that product an ideal experience for that user. One imagines the vast majority of "coding" taking place on MS office for the last 30 years has not been to "make things", but to improve the quality of what they have made.
  - wpietri 4y ago
    I can't quite imagine you not understanding this from what I wrote, but for me "making things for people" includes "making things better for people".

by ytpete 4y ago

wpietri 4y ago

Sure, if we talk about something he didn't say, it could be better. But even then I think it's a big mistake. The point of coding is to make things for people. If we stop making things for people and do something else, however virtuous that something else might seem, I think we aren't moving in the direction of long-term improvement. One of the biggest roots of low quality is high time pressure. So I'm fine throttling back feature to 80%, 50%, maybe even 20% of the long-term capacity so that everybody can start learning to work in ways where technical debt decreases and quality practices get properly established. But I think it's vital that we keep that x% of forward motion. For all sorts of reasons, but the biggest being that everybody, techies and product people most definitely included, need to learn to work together such that quality stays high. If the product people just wander off for a few months while the devs do mop and bucket work, what people generally learn is to repeat the cycle of making such a big mess that another big cleanup is needed down the road.

mjburgess 4y ago
That isnt the purpose of coding, no. That's its purpose for the first keystrokes, but thereafter, when a user has a product, it is to make that product an ideal experience for that user. One imagines the vast majority of "coding" taking place on MS office for the last 30 years has not been to "make things", but to improve the quality of what they have made.
- wpietri 4y ago
  I can't quite imagine you not understanding this from what I wrote, but for me "making things for people" includes "making things better for people".