software engineering and stewardship

a popular attention book attuned me to how much words shape my reality. one particular word therein has been haunting my thoughts: “stewardship." it also caught my eye in the editor's letter of a springtime issue of bon appétit and my ear in my parents’ verbal bulletin on the goings-on of my childhood church. i've encountered "stewardship" before but must've relegated it to the background of my brain; only now are the enmeshed notions of responsibility and care that it signifies giving me pause.



this word germination period coincided with me giving my two weeks' notice at my last job. though i knew my egress was sensible, i couldn't help but feel a twinge of guilt as my final days drew near: wasn't leaving the opposite of looking after? dwelling on these mixed feelings led me to grapple more broadly with (what i perceive to be) lack of stewardship in my current line of work.



software engineers are notorious for bopping from job to job. i've been advised to leave roles as soon as they make me feel stagnant, languishing sans challenge, and i'd wager that other software engineers have received similar guidance. when a desire to learn (or simply earn) more arises, we're told stop shipping and jump ship. we are forever optimizing our next opportunities for personal gain.



what's left unwritten is the wreckage left in the wake of this constant leaving. i'm ruminating on the following unfortunate possibilities:

  • engineers feel little compunction about long-term maintainability because they won't be around to deal with the consequences of their code.

  • past mistakes might not become future learnings if none of the mistake-makers stick around to counsel or remember to document before they go.

  • a patchy organizational memory precipitates a bloated, unfocused product.



that last bit spooks me the most. a selfish worry: how can i trust that my contributions have purpose if the companies i work for are wont to grow more and more scatterbrained by the year? a societal one: does dropping the ball on software custodianship harm end users? are software engineers exacerbating an increasingly vacuous online world, whiling away the lifetimes of a worldful of internet citizens when we could be engaged in... i don't know, something more intentional, perhaps even helpful?



my scrying may be overblown but i'm certainly nervous.



if there's an inkling of truth in what i've augured, the onus is not on individual software engineers to Be Better, but rather on engineering leaders to combat systemic churn. perhaps alternative business models — cooperatives, unions — would better incentivize ownership and thus stewardship across the org chart? maybe orgs should empower teams to devote whole sprints to tightening core features and sweeping away cruft? the tech world of today may balk at these seemingly twee strategies, but an industry so obsessed with disruption should try to self-disrupt for a change.



i'd love to hear from others thinking about stewardship and SWE transience because i'm struggling to come up with a value-driven way for me to respond as but one individual mired in a problem so much bigger than me.

To reply you need to sign in.