This post is part of a blog series called Leveling Up: A Guide for Programmers. The series covers skills you can use to learn faster, more easily, and more strategically as a programmer.
This is the second in a three part miniseries about asking for help:
- Asking for Help
- Who to Ask, How to Ask
- Getting Mentors
In the last post, we talked about deciding when to ask questions of our colleagues. In this post we’ll take a step back and situate the idea of asking for help within a collection of ways that we can seek support on a particular question. Then we’ll zoom back in and talk about who to ask for help, and also about how we can ask for help.
When I’m trying to figure out how to use a piece of software, my sources, in rough order of priority, go:
1. The tests of the code itself, if it is open source (high legibility, high reliability, high speed of access)
For open source projects or apps that I am working on, I often have quick access to the tests. They provide an accurate picture of the software I’m using (that is, if they have to pass during deployment, anyway). They’re also often written precisely with other developers’ questions in mind.
2. The implementation of the code itself, if it is open source (dodgier legibility, high reliability, high speed of access)
Again, I have fast access here, and since this is the code itself, it’s as direct a source as I can get for how the code works. Legibility, I find, depends on the app and the project. The Swift core repo, the matplotlib library, and the pandas library are all really excellent, usually legible examples. I’ve seen some rough ones, too (see the XML parser story from this post).
We’ve talked in detail about a version of this before when we covered commit tracing (back when this series was only six posts long and I thought we were ever going to stop writing it 😂). Commit tracing skills also apply to examining someone else’s code. (You can see examples where I walk you through someone else’s code here and here).
3. The documentation (dodgy legibility, dodgy reliability, high speed of access)
As software projects get larger, it’s hard for teams to keep every piece of documentation up to date. This is firstly because there is no direct connection between the code and the documentation (as there is for tests), and secondly because documentation on many developer teams is a second-class concern (which is unfortunate). For any project, docs sometimes fall out of date.
4. Stack Overflow, askquestions.tech, or other results from googling my question (dodgy legibility, dodgy reliability, high speed of access).
Internet comment people can sometimes be right and save me hours of time. They can also sometimes be wrong and unkind to boot. For fast-changing APIs, most of the questions on the internet will pertain to the way it used to be before its latest iteration, since the tech has spent more time in all its previous iterations than its newest one. A good example of this is UIView.animate vs UIViewAnimation in iOS development. The latter is the updated way, with many technical advantages. The former is the one you find on almost every StackOverflow post.
Recommendation here: if someone on the internet helps you, it is nice to thank them.
First of all, that lets other people know that this solution worked.
Second of all, helping people on the internet can be pretty thankless sometimes, but we need people to do it, and thankfully for some reason people still do it. So it’s nice to reward when they do.
5. The word of a developer advocate on how to do it (high legibility, high reliability, medium speed of access).
Dev advocates are paid to evangelize their software and help developer communities learn to use it. They’re usually great communicators and very knowledgable about their product. I’ll try to befriend one first thing when I start using a technology that has them. They’re very busy, so it might take a while to get their answer. I’ll sometimes ping them if I’m stuck and keep searching on my own until they get back to me.
6. The word of a developer I trust on how to do it (high legibility, dodgy reliability, high speed of access).
Unless you’re a principal IC (and sometimes even if you’re a principal IC), you have colleagues with more or different field experiences than you do. These people can provide valuable insight when you’re facing a problem.
For me, in the course of a week, I’m writing Ruby, Python, Swift, C, sometimes Java, and sometimes Go. So when I run into a language or framework question, I ask folks who only (or mostly) write the thing I’m trying to write. I start with people I know. If I don’t know anyone who works with this tool, I’ll reach out to folks on Twitter or LinkedIn. I know I’m less likely to get a response here because I have no established relationship, but I’ve been regularly floored by people’s generosity.
My colleagues might not know the latest and greatest the way a dev advocate does.
How to ask them: I generally ask via email or slack if I know them. I tend to reach out on twitter or LinkedIn if I don’t know them, or sometimes via email. I start by making sure they know I’m reaching out because I trust and respect their knowledge and views on the thing I’m asking about. I think people don’t hear this often enough (plus it butters them up a little :). Then I ask. I make the question as targeted and specific as possible, and I share what I have already tried. If I’m weighing a few options, I share those too. I want it to be easy for them to answer in 10 seconds. Paradoxically, the more optimized my question is for getting a 10 second answer, the more likely it is that my colleague responds with additional insight and context!
7. The word of a core maintainer on how to do it (dodgy legibility, high reliability, low speed of access).
Not every project has dev advocates. Open-source ones often fall into this category. Sometimes I can access the writing (or ask questions) of the maintainers. Maintainers are usually overwhelmed. Maintaining an open-source project is a lot of work, and maintainers are usually fielding dozens to hundreds of complaints at a time from community members (often about software they wrote for free).
As you can imagine, this is frustrating for them. Some maintainers make a rule of ignoring community requests so they can focus on the tool. If I do get a response from one, I run the risk that it might sound curt, or it might be unclear (unlike dev advocates, maintainers aren’t necessarily great communicators, though sometimes they are.) I don’t blame them, and I’m glad they’re out here writing the thing I use, usually at no cost to me. But I don’t depend on them for answers.
How to ask them: I generally see if the tool has a gitter forum, and I ask there. The bonus here is that if the maintainer doesn’t respond, a power user might respond instead. If there’s no gitter forum, I open a github issue—sometimes with suggested changes, sometimes with just a question. I make sure to thank the maintainers for their work on the project, then ask my question, and again make it as targeted and specific as possible.
And Finally
If I had a devil of a time figuring out how to do something and then I finally succeeded, I try to write a blog post about what worked for me. Sometimes these posts take off (which is how I learned that hundreds of people get gray hairs trying to do a card flip animation in Android).
More importantly, it’s a way to pay it forward. Our jobs would be a lot harder without those strangers on the internet helping us out along the way.
Conclusion
We’ve talked about several options available to you for getting answers to specific questions. I like to check the tests, then the code itself (if I have access to those things), then the documentation, then internet questions.
I like to back up those sources with answers from developer advocates, colleagues, or (if possible) a maintainer or power user of the thing I have questions about. In these cases, I’ll make sure that the person understands how much I appreciate them. Then I’ll keep my question as specific as possible and share as much context as I think will be useful to them.
The methods we’ve discussed here work great when you have one or two specific questions. This is not how I approach the task of finding a long-term mentor. That’s different. We will talk about that in the next post of this series.
If you liked this post, you might also like:
The rest of the leveling up series, which is getting absurdly long by popular demand
This older piece about Michael Feathers’ approach to edge-free programming
This piece about the relationship between tech teams and app features (includes a photo I took while hanging off the side of a golf cart in Mexico)