All I Need to Know About Engineering Leadership I Learned From Leave No Trace – Jacob Kaplan-Moss

Sumana challenged me to apply the principles of Leave No Trace to engineering leadership, so here we go:

Obvious. Good leaders in any context plan and prepare for their adventures.

Translation: Choose Boring Technology.

Sustainability in the outdoors requires travel on durable surfaces (rock, gravel, established trails and campsites, forest loam) to avoid overly impacting fragile ecosystems. In software, we also think about sustainability, but in a different sense. Were less concerned about impacting fragile ecosystems; instead, we choose durable surfaces (aka proven technology) because theyre well-understood and predictable. This is turn helps engineering itself be more sustainable: constantly switching technology because someone new didnt pan out (or, worse, because something shiny new showed up) is exhausting.

Translation: pay down technical debt; clean up old software before introducing new things. Most companies reward shipping more than they do cleanup or decommissioning deprecated or unused software. Good engineers understand that removing cruft and paying down technical debt is just as important as launching new things. Clean up after yourself, both in the woods and in your Git repos.

Translation: contribute upstream. When you use open source, dont take it with you; offer back any improvements you make to the community (even if the license doesnt strictly require it). Same goes for internal software: if you work on something maintained by another team, offer improvements and bug fixes back to that team (rather than working around them in your own code).

Translation: prevent and mitigate data breaches, particularly those that impact end-users.

In the wilderness, we avoid or are very careful with fires to protect the ecosystem from wildfires. A wildfire amplifies a small mistake into impact at a massive scale. In software, the same is true of security issues particularly data breaches. Data breaches often dont impact the authors of the vulnerable software, but they often do cause lots of pain for thousands or millions of people who just wanted to buy a pizza or whatever. So, just like were very cautious of fire impacts in the woods, good engineers aim to be very cautious around security issues.

Translation: Chestertons Fence: dont destroy what you dont understand.

We respect wildlife in the wilderness because were in their house. We dont fully understand the complexity of most ecosystems, so we seek to minimize our impact on those ecosystems since we cant always predict what outcomes our interactions with nature might have.

In software, many disastrous mistakes stem from not understanding why a system was built the way it was, but changing it anyway. Its super common for a new leader to come in, see something they see as useless, and get rid of it without understanding the implications. Good leaders make sure they understand before they mess around.

No translation needed.

I always welcome feedback on my writing please feel free to get in touch if you have comments. I also try to help people with job searches, career advice, and other things; see some ways I can help. If you want to find out when I've posted new articles, subscribe for updates.

Read more here:

All I Need to Know About Engineering Leadership I Learned From Leave No Trace - Jacob Kaplan-Moss

Related Posts

Comments are closed.