3 ms·

These factors are left out because they're rarely relevant. > 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in dis

by fouric 5y ago

These factors are left out because they're rarely relevant. > 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise. Yes, there's a known partitioning between design and implementation, and it's very difficult to do both at once. Those "business value" decisions usually occur in the design phase, when you're not being precluded by implementation. However, interruptions are not the right way of doing the design phase. Interruptions, by definition, occur when you were in the middle of some work, and if you were doing implementation work, result in you losing context (and therefore productivity) for something that is rarely design-related - and even relying on this for design/"business value" guidance is a hack, because you should be purposefully allocating some dedicated time to take a break from implementing and instead design and strategize. Replying on unplanned interruptions to do this for you is suboptimal from every perspective and will be difficult and frustrating. > 2. The ability to work in a way that allows for interruption is a skill that can be learned. Absolutely - and yet, someone who has this skill and is interrupted is still less productive than someone who has the skill and isn't productive. Unless every one of your interruptions is essential (which isn't true for the vast majority of developers, including me), then learning the skill alone is just a hack, because the root problem is that you're being unnecessarily interrupted in the first place.

lanstin 5y ago
That isn’t the root problem. Ask why fives times. Why are you being interrupted? Often it is because management would prefer less development if they have more control over the development. I have worked at places where the management genuinely trusted developers and said and did: go forth and make great products for people. (Subscriptions paid the bills). This is rare these days, they, the management structure, often prefer no work being done to work that wasn’t “prioritized.” Often they are aware of a problem but don’t understand how to fix it systemically (if you mention it, the response is, you don’t have to attend these meetings (where decisions affecting you and your work are made), not, let’s see if we can have no Meeting Days once a week. Some bosses want to prove they are tough and in charge and force meetings doe that. Some bosses want to bypass the normal scheduling process for sprint work and have working sessions to do a thing immediately. Perhaps the system is not designed with good layers of isolation and good documentation so you have to commonicate between different people a lot. To reduce the interruptions you have to go back deeper.

by fouric 5y ago

lanstin 5y ago

That isn’t the root problem. Ask why fives times. Why are you being interrupted? Often it is because management would prefer less development if they have more control over the development. I have worked at places where the management genuinely trusted developers and said and did: go forth and make great products for people. (Subscriptions paid the bills). This is rare these days, they, the management structure, often prefer no work being done to work that wasn’t “prioritized.” Often they are aware of a problem but don’t understand how to fix it systemically (if you mention it, the response is, you don’t have to attend these meetings (where decisions affecting you and your work are made), not, let’s see if we can have no Meeting Days once a week. Some bosses want to prove they are tough and in charge and force meetings doe that. Some bosses want to bypass the normal scheduling process for sprint work and have working sessions to do a thing immediately. Perhaps the system is not designed with good layers of isolation and good documentation so you have to commonicate between different people a lot. To reduce the interruptions you have to go back deeper.