Software engineers are all about principles and patterns.

Short acronyms like DRY, YAGNI, KIS, etc., are used everywhere within the industry to try and concisely communicate an axiom of how to write software.

One principle that arises within software engineering is that of reusability. We have this idea that we can build software components once and reuse them everywhere. The idea is that by building reusable components, we can increase efficiency, decrease cost, and even increase safety (since the reusable component will have been, theoretically, tested and verified).

Based on this idea, we’ll propose spending large amounts of time and effort building reusable components ahead of a large re-architecture. We’ll mention that this investment will pay for itself in saved cost over time, even if it costs a lot initially.

But this past week, I read an article that has challenged some of these conclusions. The article, titled The Reusability Fallacy, pushes against the concept that building reusable modules upfront will ever lead to their promises of cost savings and efficiency, especially at the architectural layer.

In this week's article, I dive into why I think reusability isn't something you assert at the beginning of a project but something you discover as you constantly pay attention and refactor your code.
​

Team-Building Exercise

In the last issue of Team-Driven Developer, I shared why it is important to "footing the ladder" for others. I also encouraged you to look for new ways to do so on your teams.

For this week's Team-Building Exercise, I'm encouraging you to follow up on that. What ways did your team think of to help each other more effectively and safely build great software? Were any of them a surprise? Hopefully, you've been able to practice those ideas a few times.

The next step is not just your immediate team but also encouraging other teams to find ways to help each other in small ways that have a big impact. How can your team help other teams accomplish their work more effectively?
​
A big one I've seen is sharing tips and techniques around observability and incident triage. No one likes being on-call (at least, I don't know anyone who does), and engineers always want to find new ways to uncover the root cause of an issue and the right next step to take when faced with an incident.
​
You can help other teams by sharing what you've learned on your team to help observe your system more effectively. You can save log views or metrics views for easy reuse. You can update incident SOPs if they are wrong. You can share your notes about issues across your teams rather than just within them.

Creating a "lending a proactive hand" culture can go a long way.

Here are some more resources from me to help you build better teams!​

Other Creators I Recommend

Daniel Schaefer Subscribe if you are a software developer that has the technical skills, but you're looking for opportunities to enhance your soft skills to advance in your career. Subscribe​

Looking for your next tech job? You're in the right spot. I'm Dr. Kyle Elliott, the founder and tech career coach behind CaffeinatedKyle.com, and I love giving away free resources that help to ensure your job search and career success. Join 7,435+ fellow job seekers who have downloaded my free Job Search Launch Guide. Subscribe​

113 Cherry St #92768, Seattle, WA 98104
​Unsubscribe · Preferences​

​

​