Modest Tools

Finding answers without asking questions

· Alex P.

Huge part of software development is about finding answers. Whether you’re debugging a tricky issue, trying to understand a new codebase, or just looking for the best way to implement a feature, you need to find the right information.

It’s easy when a question you have is about a well-known technology or a popular library. You just Google it and you’re done. But what if the question is about your company’s internal tools, processes, or practices? What do you do then?

Most people in this situation begin by asking their colleagues. Via a message on Slack, if they are merciful, or by dragging them into a meeting, if they are not. But there is a better way. You can save other people’s time and learn a lot in the process by finding the answer yourself. Here are a few techniques that I use all the time.

Just read the docs

Your team’s wiki, Confluence, or README files are the first place to look for answers. They are the most likely places where the information you need is stored. But they are also the most likely places where the information you need is outdated, incomplete, or just plain wrong. So, read them, but don’t trust them blindly.

Search Slack

Lots of valuable information that will never make it into a Confluence page or a README file is shared in Slack. If you’re a remote-first company, Slack is the natural place to ask questions, raise issues and argue about engineering decisions. Yes, it would have been great if all the good stuff was later saved in a well-organized knowledge base, but that’s not how it works in practice. So search Slack.

Here are the types of things I often find in Slack:

  1. Bug reports and workarounds. If you’re seeing a new bug, there is a good chance that some other developer has already faced it. In that case, they probably shared their frustration in Slack. Search for the error message or just read the last few days of messages in the relevant channels. There is a good chance you’ll find something useful. If not, be the first to report the bug and help the next person who runs into it.

  2. Information about internal tools and processes. If you’re not sure how to deploy your changes, how to run the tests, or how to set up your development environment, search Slack. Someone has probably asked the same question before. And if not, ask it yourself, but do it in a public channel. It’s much better than asking it in a private message, because then only two people will benefit from the answer. In general, prefer public channels over private messages.

  3. Historical context. If one day you decide to, for example, introduce end-to-end testing to your project, you might want to know about the previous attempts (trust me, there were some). Search Slack for “e2e” and you might find some valuable information. This is especially useful if you’re new to the project and you want to understand why things are the way they are.

Sadly lots of valuable information is shared and then lost in virtual meetings, private messages, and direct conversations. If it’s up to you, avoid making more of those. Share your knowledge in public channels or documents.

Search the codebase

This is where you can find the most accurate and up-to-date information about your project. But boi is it hard to find. Here are some of my favorite techniques:

  1. Use git blame. You can get so much information from git blame. It will show you the last commit that touched each line of code. The commit message, the author, and the date of the commit are all there. This is especially useful when you’re trying to understand why a certain piece of code was written the way it was. I suggest using Git features that are built into your IDE, but if you’re a command-line person, here is how you can do it:
git blame file_name
  1. Use grep/rg with reverse sorting by modification time. This is a great way to learn about the latest practices and coding conventions. Finding a usage example of a React component that is 2 weeks old is much more valuable than finding one that is 2 years old. Here is how you can do it:
rg --sort=modified "function_name"

This command will search for “function_name” in all files in the current directory and its subdirectories, and sort the results by modification time, with the most recent files first. If you don’t have ripgrep installed, you can use grep, but it will be slower.

  1. Use git bisect. If you have absolutely no idea where to look for the source of a certain bug, you can use git bisect. The only thing you need to know to start bisecting is that the bug wasn’t there in the past. Find any commit where the bug wasn’t present and you will eventually find the commit that introduced it. Explaining the details of git bisect is beyond the scope of this post, but you can find the basics here.

In conclusion

This list is by no means exhaustive. I just wanted to share a few techniques that I use a lot in my day-to-day work. I hope you find them useful. And remember, if you find yourself spending unreasonable amounts of time trying to find the answer on your own, it’s probably time to ask for help. Go break someone’s flow, you now have a good reason to do so.