Team-Driven Developer
A newsletter with tips and tools for building software as a team
|
Picking the Right Tools
Could you survive out in the wilderness on your own? No food provided. In the middle of nowhere. Just yourself and a few sets of tools. Would you make it?
It’s the premise of the aptly named show Alone. You might have heard of it.
I’ve only recently discovered the show, but I must say: it’s thrilling.
And as I’ve watched the show, I’ve thought a lot about the tools each contestant brings. Did they make a list of possible items and compare their utility with an algorithm, or did they copy other contestants’ lists from prior seasons? Did they wing it?
We find ourselves in similar, but not life-threatening situations in software. Tools, frameworks, vendors, etc., abound in our quest to build great products for our customers.
Many questions emerge around this topic: How do you pick these tools on a budget? When does it make sense to buy vs. build? What do you do when you find yourself “stuck” with the tools you’ve chosen so far (dreaded vendor lock-in)?
Today, I'm sharing a handful of first principles I've been considering to help you answer those questions.
Team Building Exercise
This week's Team-Building exercise is to answer a simple question as a team:
What tool are we missing?
While it's a simple question, the answer is likely hard to come up with. You must know your current pain points, your available toolset (and the gaps they have), and what needs you anticipate in the coming weeks/months. Some engineers are thinking about better collaborative tooling; some might see a gap in observability, while others might think about missing platform capabilities. Whatever answer people give, seek to understand why they see it as a need.
After everyone has answered, try picking one or two tools to make headway one. Assign action items to research and formally propose a new tool to the team or organization. Even if it's a long shot, it is worth it if the whole team sees the need.
As I mentioned in the article, you don't want to spend too much time doing this. Timebox these efforts to a week or so (if that) to avoid wasting time. Of course, if you do find a really incredible tool that fits your needs, don't be afraid to make a great pitch when it counts.
Aside from getting to research the tool landscape and possibly get something stood up to use, I bet you'll discover new ways to leverage your existing tech to accomplish some use cases you didn't think about before. Sometimes, seeing what other people are doing can inspire you to do something interesting or similar yourself.
Happy coding!
Here are some more resources from me to help you build better teams!
- 📕 Code Review Champion - My book on code reviews will help you become a world-class code reviewer. From giving kind feedback to navigating conflict, this book can help anyone wanting to sharpen their code review skills.
- ❓Questions for Devs - Building a team takes more than catching up about your weekend at standup. I've used these questions to build relationships with my team and push past the same old surface-level conversations.
- 📋 Pull Request Template - Maximize your efforts in pull requests by giving context right at the beginning of a new pull request. Copy and paste this template into your repo, and voilà!
- 📊 Code Review Metrics - Start measuring how your team tracks against a few common code review metrics. This python script will pull your GitHub pull requests and generate a CSV you can slice-n-dice to get the data you want. It also has graphs! As this is an open-source project, your contributions and feedback would be great!
|
Other Creators I Recommend
|
Build It Better Newsletter
by Jonas Fleur-Aime
Creating great software is not just about completing new features faster, submitting more pull requests, or fixing bugs. Every Wednesday I publish tips and tactics to help you meet tough deadlines, tackle tech debt, handle scope creep, manage stakeholders, make sure you're building what customers actually want, and more. I'll draw on what I've learned after spending 15 yrs as a software developer, Engineering Manager, CTO, and startup advisor.
|
113 Cherry St #92768, Seattle, WA 98104
Unsubscribe · Preferences