Code Rot Is a Process Decision
<p>I’ve had the great fortune to work for an organization that made a good-faith effort to empower its teams. And I’ve worked at other places that didn’t.</p>
<p>In my role as a dev lead, therefore, I’ve seen firsthand the difference between the two: empowered and… what’s the opposite of empowered? Not exactly disempowered, more… <em>unpowered</em>.</p>
<p>“Unpowered” because there’s no ‘oomph’ to it. It constantly needs to be prodded and pushed. It won’t move by itself.</p>
<p>What do I mean by that? Let’s talk about the way unpowered organizations affect technical work.</p>
<p>Oh boy. So many topics to choose from — ineffective use of resources; poor documentation; a lack of meaningful ways to improve the process from below.</p>
<p>But I’m a dev lead. I’m coming at this from an engineering perspective. Most books and articles on the empowered process don’t look too deeply into how it directly improves the engineering process.</p>
<p>I’m here to rectify this situation. But to understand how empowerment propels us forward, we must first understand how a lack of empowerment holds us back.</p>
<p><a href="https://betterprogramming.pub/code-rot-is-a-process-decision-d4b37cf1e26b">Website</a></p>