The other day, I saw my coworker’s kid on my Instagram feed. She’s cute, about two years old, and she was playing with a toy.
The toy was just a cardboard box hanging from a string.
Kids simply don’t have the same perspective on the world as we do. They’re immensely curious about things that we find mundane, and they love playing with these everyday objects. It’s as if they’re always asking, what is this thing and what can I do with it? Whether it’s how it feels, how it tastes, or what happens when it falls on the floor, they’re always figuring out what properties an object has.
I’d like to see more of this with engineers. I feel like it’s more absent than it should be—for a group of people who like building things and understanding how things work, it seems like we do a surprisingly small amount of discovery when it comes to learning about the tools and technologies that we use and have available to us.
When you don’t play around and learn how to use your tools, you are only able to use your tools in the specific ways that you’ve been taught. You can’t use them to their full effect, which limits how effective you can be and limits how you approach problems. As the saying goes, if all you have is a hammer, everything looks like a nail.
Obstacles
There are some typical barriers that prevent us from getting better at using our tools. Some are real, some are imagined.
Obstacle 1: You forget that you are using a tool.
Take Git. I imagine that many developers are content with knowing how to pull, push, and commit. Some might also be comfortable with creating and navigating around branches. They have a hammer, but they only know how to use its face.
A friend, Acrefoot, mentioned to me that companies with stronger engineering cultures will actually take some time to address this. They teach some more advanced commands, aimed at handling some common but more fringe cases that come up during development. For example, interactive add or rebase. This is called git-fu.
Obstacle 2: You don’t know how to learn about your tools.
We use Bazel as our build tool, but I suspect that many of our engineers don’t know what Bazel is, despite using it practically every day. They turn to the person next to them, but that person is almost as clueless as they are.
The important thing to remember is that tools are created to serve a purpose. The best starting point to understanding a tool is often the tool’s documentation. Many sites come with a getting started or intro page, as well as a best practices page. Those are the most important places to start. You can return to the docs as you have more specific use cases in mind.
Sometimes, the documentation is poorly written, too complex, or even nonexistent. Even when this isn’t the case, you can often find bridging documentation in the form of articles or Stack Overflow answers.
If you’re forced to use a tool within your organization, someone must have chosen (hopefully intentionally) to use that tool. This means that someone (not necessarily the same someone) knows what your organization is trying to do with that tool.
Obstacle 3: You have too much on your plate.
I get it. With all of the things we already have to do, where’s the time to actually dive into a topic?
I have a rather unsatisfying answer here—you just have to find and carve out some time. I’ve found that it helps me to set small, incremental milestones. I also approach this differently based on whether or not I’m acting in as individual contributor or a manager.
As an individual contributor, I focus on understanding the tools that I frequently use—the more I use something, the more familiar I should be with it. Additionally, odds are that someone else in my organization is frequently using the same tools. This makes it extremely useful to document and share the learnings I find.
As a manager, I either no longer or infrequently use the tools that my people are using. I’m off the hook for understanding a tool myself. However, it’s crucial that I ensure that my team understands the tools, because they are the ones using them. I need to be aware of the tools that everyone’s using and coordinate them appropriately. Delegation is pretty useful here—I assign someone to become an expert and share their findings on how to use a tool in a particular way.