Questions are part of software development. There is so much on the job training, and the field is young. The first electronic computer was built in 1945, so general-purpose programmable computers and the software that runs them haven’t been around for long.
Sometimes you’ll be forced to make technical decisions without understanding everything. Asking the right questions can help you make these kinds of decisions in the least bad way possible.
As a new developer, make sure you understand how and when to ask questions. Asking great questions is as much about research before and listening to the answer after as it is about the content of your query.
Ask smart prepared questions
Dear new developer,
First, there are no dumb questions.
But there are unprepared ones.
The closer you are to someone, the more you can ask a question off the cuff. For example, if you are asking a peer how to connect to the database, you can expect an answer. However, if you look around, you may find the answer without even asking your colleagues; this is often the quickest way to solve your problem.
But asking someone on the Internet the same question: “how do I connect to the database?”, will probably result in silence on their part and frustration on yours. Why? They have neither the context nor the connection to you which your coworker does. You must provide them with both.
The best way to prepare is to write up the question in enough detail that you'd feel comfortable posting it on a question and answer site like Stack Overflow.
You may find the answer yourself, perhaps documented in an internal wiki, the chat system, or on the Internet. Awesome! You just saved yourself time, learned a new resource, and didn’t interrupt anybody.
You clarify the question. When you write, you are forced to make the implicit explicit. How does the problem arise, exactly? Where? When? All of this is helpful for anyone trying to answer your question.
Documenting the exact steps to replicate your question often suggests additional things to try: “ah, so I didn’t investigate upgrading that library, I should try that.”
Look at both internal company resources and the wider Internet when researching your question.
A wiki or a README in a source code repository can have what you need. Another internal resource is implicitly built documentation, such as an email list, commit log, or past chat. Source code can help answer a question too.
Question and answer sites like Stack Overflow and the other Stack Exchange sites
Internet-accessible forums
Mailing lists, which usually have web-accessible archives
Slacks and Facebook groups, where there’s a lot of content that is not indexed by web search engines like Google
IRC channels, often hosted by freenode
Software issue trackers at GitHub, GitLab, or elsewhere
YouTube and other video sites
All are fair game for your research. I typically start by using Google to search for specific terms. But be aware, as noted, some of these resources aren’t available to search engines—you’ll need to know about a Slack’s existence before you can search it for the answer to your question.
By the way, the ability to search the Internet for answers is one reason for using commonplace technology—the resources available for a popular language framework typically dwarf the documentation available for a homegrown solution. This is a reason to avoid building custom frameworks whenever possible.
There’s a trade-off in doing research, of course. Doing this research properly is time-consuming and may be frustrating. I always recommend asking more experienced peers how much time to spend doing research. If the project is on a tight timeline, it may be better to ask a less prepared question more quickly. This is especially true if you are asking a team member.
In a meta way, be prepared to ask questions to determine how much time to spend preparing to ask questions.
Side note: Asking where the copier is or what’s a good lunch joint is technically a question, but not what I’m writing about.
Sincerely,
Dan
How to ask a question on the Internet
Dear new developer,
When you encounter a bug that stumps you, it’s natural to ask questions of communities on the Internet. After all, there are a lot of smart people out there. If you ask a question, make sure you do it well. Maximize your chances of having your question answered: ask it in the clearest, most concise way possible.
Please realize that the people in these communities aren’t usually paid to answer your questions. No matter how frustrated you are, or how broken something is, be kind and polite. Being rude will ensure your question is ignored.
It isn’t precise. What does “won’t start” mean?
It puts most of the effort on the question answerer to replicate your situation, either by guessing or asking you for more details.
You haven’t shown any effort. How have you tried to solve the issue? We don’t know.
Contrast the preceding question with this question:
“I can’t figure out why my nodejs application won’t start. I’m using nodejs version 12.3 and express v4.1. I’m running on the latest macOS but have also tested on Ubuntu 20.04.
When I start the application by running “node server/index.js”, I see this message in the log files: EADDRINUSE, Address already in use
But when I use netstat to look for anything bound to port 3000, which is what my node server should be attaching to, I don’t see anything.
You can see a simplified version of the source code at http://github.com/username/brokennode/if you’d like to take a look.
I’ve Googled around for the error message and haven’t found anything useful. Can anyone help me? Thanks in advance.”
Anyone can tell that the asker has put in effort to answer the question on their own, including searching the Web and reviewing logs. A possible answerer can easily download the code and try it. It is clear exactly what “the app won’t start” means.
Specify your problem in detail. If it’s a bug, spend the time to narrow it down to the smallest set of replication steps. Include code or a test if you can. If it is a question, narrow the scope of the question as much as possible.
Show you’ve done your research. This includes searches; links to pertinent issues, videos, or posts; and any logs or output around the issue. Make sure you remove sensitive information from the logs.
Follow up if you have not found an answer. Wait for a day or so and follow up with additional information if you haven’t found a solution. You’ve probably been doing additional research or troubleshooting, so share it.
Express gratitude. If someone takes the time to answer your question, or even to clarify a point, make sure to thank them.
If you do get an answer to a question, whether through your own research, someone’s assistance, or a combination, respond to your question with the answer. It’s frustrating to find a post on the Internet where one’s exact question has been asked, but never answered. Close the loop.
It’s not easy to take the time to prepare a good question. I have been a new developer under pressure. I’ve seen many frustratingly vague questions on the Internet. I understand your desire to get your problem solved as soon as possible.
Real people
Not getting paid by you
No matter how obvious the bug seems, or how much it is impacting you, treat people helping you kindly. Every time you ask a question on the Internet, you are tasking a set of volunteers.
Treat them right.
Sincerely,
Dan
Don’t be afraid to ask questions
Noel Worden started his career as a photographer, shifted gears to become a cabinetmaker, then graduated from the coding bootcamp Bloc. He is currently working as a software engineer for MojoTech in Boulder, Colorado.
Dear new developer,
Don’t be afraid to ask questions. It can be stressful and humbling to reach out and ask a question, but it can be the best way to stop spinning your wheels and make progress. It’s stressful because as a new developer you are trying to prove yourself to your peers and superiors. It’s humbling because you are admitting to someone that you don’t know something. Giving consideration to when and how you ask a question can make for a much smoother interaction.
Is this meant to be a learning experience?—If so, you’ll want to spend more time looking for the answer before reaching out to anyone.
How long do you have to complete the task?—The more time you have before the task is due, the more time you should spend looking for the answer yourself.
How busy is the rest of your team and/or your mentor?—If no one has the time to help, you unfortunately don’t have many options other than to stick it out and try to find the solution yourself until you see an opportunity to ask for help.
Is the sticking point something relatively “small” and holding you up from the bigger task?—Is it something like a bug in the project setup, or a hang-up of a similar nature, that doesn’t have anything directly to do with the task? These types of hang-ups can be difficult to Google, or solve by experimentation, and are scenarios where asking for help earlier than later is probably a good idea.
Have you worked through other aspects of the task?—Sometimes skipping over the sticking point and working on other pieces can lead to an “aha moment.” It can also help to gather multiple questions and therefore get multiple answers from one help session.
Once you’ve decided to reach out for help, the phrasing of the question can be important. When I ask a question, I often try to go over what I’ve already tried, what I’ve Googled, and then what exactly is stumping me. This shows that I’ve made a solid effort to solve it myself, gives the other person as much context as possible, and prevents the person giving assistance from experiencing the frustration of repeating the same unsuccessful troubleshooting attempts.
Most importantly, above all else, don’t be afraid to ask questions. Everyone was a new developer at one point in their career, and asking questions is a legitimate way to learn.
Sincerely,
Noel
Technical decisions in the face of uncertainty
Dear new developer,
Sometimes you are confronted with decisions for which you simply don’t know the correct answer. This has happened to me many times over the years.
Once, a client wanted to build an online quiz. They needed the ability to edit questions and answers without paying a developer. They wanted the quiz to feel like an application rather than a website. I had never built anything like this before, but I was the best person to choose the underlying technology.
The clock was ticking. I had to make a choice.
When you are in such a situation, you will not have time or money to do all the research you feel you need. You may be doing something that has never been done before. You may be pressed for a decision in a meeting.
If you, as a new developer, have to make a choice about a fundamental architectural decision like a platform, library, or framework, you are most likely in a small team moving fast or at a company with few engineers. You may feel in over your head and incapable of making the correct decision.
Waffling on the decision
Performing a thorough, lengthy examination of all possible solutions, putting together a spreadsheet and a set of slides to make sure you haven’t missed anything
Googling for an answer and mindlessly picking the first result
Punting the choice to someone nontechnical
Silently deciding without discussing the decision with team members
These will either lead to a hasty decision or a sluggish decision or waste the experience of your team.
Now you know what to avoid. What should you do instead?
First, make sure that you must make the decision. Then ensure you have the proper business context. The number of options to consider and the amount of research to be done depend on the scope of the decision.
How much of the business will this part of the system touch?—If it is constrained, spend less time. If you are implementing a small component or choosing a service that is only used by a portion of the organization, like GitHub for your code repository, then unwinding the choice will be easier. If you are picking a development language used for a core product, many parts of the business will depend on it, so do more research.
How irreversible is the decision?—Most decisions aren’t irreversible given enough time and money, but some are easier to roll back than others. Swapping out one in-memory cache provider for another is easy, but changing from one database vendor to another is more complicated. And changing a cloud provider can, depending on the amount of data involved, take years of effort.
Does your company have internal solutions that you might leverage?—The bigger the company, the more likely the problem has been solved before. Finding that solution will be quicker than rebuilding it.
Can you defer the decision?—Is there a manual process or a service you can buy that will solve the problem? In some cases, it is worth it even if it buys you only a few months.
Make the best decision you can with the information you have. Scale your research based on the impact on the business. However, I want to acknowledge the uncomfortable tension between knowledge and action that is at the root of any decision made with incomplete knowledge—which is to say, all of them!
Learn what you can. This includes finding out as much as possible about the problem, including any current solutions.
Bounce ideas off of others in the company. Make your ideas or questions specific, both in how you ask and who you ask. This focus will help avoid analysis paralysis while still tapping others’ experience.
When you feel you have a grasp on the problem, ask for solution recommendations. Start with your current colleagues. Even if you can’t find someone who has direct experience with the problem, there may be people with related know-how.
Search the Web. See what other folks have done. If the technology is evolving, limit search results to “the past year” or you’ll end up reading misleading old solutions.
Look on social media. Find experts on social networks like Twitter and LinkedIn and ask them questions. Even better, look at their blogs and websites to see if they’ve already covered the topic.
Look at communities with experienced people, such as Slacks, forums, and open source project email lists. It’s better to see if your question has been answered previously rather than pop into these communities and ask right away—requests from people new to the community can annoy regular members if asked without research. But if you don’t see any answers to your question, mention you searched beforehand and ask.
Realize that no decision is perfect. In 20 years of development, I can tell you that I’ve never made a perfect decision—they all involved trade-offs and a lack of knowledge.
Communicate your uncertainty to the business. This includes both concerns you have about being in over your head and any other risks that your research has found.
Arrive at a recommendation. Get approval and buy-in from the team. Revise it based on feedback.
Implement it.
New developer, hopefully you won’t be forced to make a far-reaching architectural decision until you have more experience. But sometimes, it happens.
Oh, and if you wanted to know how my quiz conundrum ended up, some of the choices I made were implemented. Others were swapped out as the team changed and the project progressed . Overall, the app was a success.
Sincerely,
Dan
Getting answers from busy people
Dear new developer,
How big is “the ask”?—The bigger the question you are asking, the more effort you should put in. After all, you’re asking for more of their time, energy, or reputation, so the least you can do is make more effort. For example, asking for a high-level opinion on a technology is less effort than asking for help with a specific problem you are troubleshooting.
How well do you know the busy person?—The less you know them, the more upfront work you should do. Contacting someone you’ve worked with, even years ago, is easier than a cold email to an expert you just found on LinkedIn.
How interested is the person in the topic you’re asking about?—If you ask me about, say, embedded C programming, you won’t get a response, because, frankly, I don’t know much about it. But if you asked me about software career advice for new developers, I’m likely to respond.
Effort on your part shows that you are serious. It qualifies you, especially if you persist.
However, please, don’t annoy anyone. There’s a line between persistence and bugging someone. My rule of thumb is to ask at most three times. Since busy people are busy, sometimes they mean to answer and the email just falls to the bottom of their inbox. I’ve definitely had people answer follow-up emails when I’ve waited a week. I always preface any email I send asking for a favor with an easy out: “hey, feel free to tell me to buzz off.” And I mean it.
Trying to figure out your question
Explaining your attempts in written form
Listening to answers or suggestions
Continuing to make progress on the question with the additional information
There’s even a bonus! Struggling with the question sometimes leads you to solutions or answers without you ever contacting that busy person.
Effort shows that you are serious but doesn’t guarantee an answer, unfortunately. On the other hand, putting in zero effort when communicating with a busy person usually leads to being ignored or dismissed.
Sincerely,
Dan
Ask the hard questions
Dear new developer,
In every meeting or conference call, does someone mention a concept that you don’t quite understand? That often happens to me.
“The marketing funnel is part of the sales process.”
“We can just flurbuzz the bazznod.”
“We have plenty of runway.”
“Why is marketing connected to sales in that manner?”
“What does that mean? I don’t know what a bazznod is.”
“I’m sorry, I don’t understand. Could you repeat that? How do you define runway?”
Asking these questions is important. Otherwise, everyone will be talking past each other. This will only lead to pain down the road when a misunderstanding is crystallized in people, process, or code. And you’re not alone. When I have trouble understanding a concept or statement, I’ve found that other team members almost always do as well.
I’ve been asking hard questions my entire career. When I worked at a web consulting company in the early 2000s, there were often company-wide conference calls discussing our precarious financial state. I got a reputation as “the question guy” because I wasn’t afraid of asking the CEO an awkward question in front of the entire company.
Pay attention before you ask. If you are asking a question which was just answered, or about something you should know, you will lack credibility.
Don’t worry about looking dumb. If it is a fuzzy concept, chances are high others in the room are unsure about the precise meaning as well.
Ask the question from a place of humility. Make it about you. I like to use the phrase “I’m sorry, I don’t understand what you just said” as a preface.
Approach the question with positive intent. Don’t ask gotcha questions or try to prove you are smarter than the speaker.
If the answer is fuzzy or you don’t understand it, consider asking a second time. “Thanks, but I’m afraid I still don’t get it. Could you explain it to me again?”
If the speaker doesn’t answer or hedges again, offer to take it offline. Follow up and have the conversation later. Time may be limited and this may be the most efficient way to get your question answered.
Recognize if the topic is sensitive—legal, personnel, or financial matters—you may not get a clear answer. At that point, getting the speaker to define terms but omit details may clarify the concept for you and is probably all you’re going to get.
Consider if anyone else in the room cares about the answer to your question. Will the audience benefit from hearing the answer? If not, then make a note to yourself to ask this later via an email, chat message, or another form of one-on-one communication.
However, consider your social capital. If you are new to the company or a new developer, you may not have much. Spend it when you must know the answer. An alternative is noting your question and asking it in a less public place—a one to one, an email, or a private chat message.
Finally, the goal here is never to “get” the speaker by asking an awkward question. Rather, it is to help get everyone on the same page.
Asking tough questions pins down nebulous concepts we work with every day. This helps everyone make better decisions .
Sincerely,
Dan
You know more than you think
Cara Borenstein is a founder at Bytebase—a collaboration tool for lightweight knowledge sharing.
Dear new developer,
A couple of years ago, I started my first job in Silicon Valley. I was a junior software engineer at a fast-moving company, and I was so excited to have the opportunity to learn. I worked hard. I looked up terms I wasn’t familiar with. I was constantly asking “how?”—“how do I do this?”, “how does this work?” I was shipping code and learning fast.
Only after a number of months did I realize I was doing something wrong and letting my team down.
It came to my team’s attention that we had chosen the wrong type of core technology for one of our main projects. The team leaders wanted to understand why we had chosen this technology.
I had no idea why we had chosen this technology because I had never asked. Had I asked, we would’ve realized pretty quickly that this technology wasn’t a good choice for our system. But I was confident that my senior teammate always knew the right choices to make.
I didn’t think I knew enough to ask. I had what’s commonly referred to as “imposter syndrome.”
My failure to ask why wasn’t just a missed learning opportunity for me. It resulted in my team making an expensive mistake of choosing a wrong technology.
Now I can see that I did know enough to ask why and it was my responsibility to do so. The same goes for you, new developer.
Software engineering is a lot about trade-offs—choosing one software design over another. Design trade-offs are often not completely clear-cut, and they warrant a discussion. You don’t need to have decades of experience to be able to understand the choices you and your team make. You just need to do your part to make sure your team has these discussions.
When you ask your teammates why, you push them to explain their thought processes. This helps your team to more thoroughly evaluate different options and to eventually arrive at better decisions.
Moreover, these “whys” create some of the best documentation for future engineers that join the team. If the thought process behind a choice wasn’t obvious to you, it will likely be confusing to many future team members too.
How to ask “why”
Here are some tips that have worked well for me.
First, make sure that you are asking “why” with a mindset of learning and understanding, not blaming. This will shape how you phrase your question. For example, you can start your question with “I’d like to understand why we…” or “I’m unclear as to why we…”.
Then identify one person who is likely best to discuss “why” with. More often than not, you’ll want to start by asking one senior engineer on your team or your technical lead. After speaking with them, if there’s further discussion or changes needed, you can bring this to the rest of your team together.
To initiate your question, bring it up informally without an expectation of immediately discussing it. This can be in an informal conversation, at your team’s daily stand-up, or in a Slack message. For example, you might ask—“Hey teammate, I’m confused as to why we’re… Do you have time later today or tomorrow to go over it?” With this approach, you can communicate your question while being respectful of your teammate’s time.
How to document “why”
Now that you’ve asked “why,” you may have driven some changes in your team’s plans, but you definitely have learned something interesting. Write it down! This is some of the most useful documentation your team can have.
Your question
A summary of what you discovered
Any constraints that impacted your team’s choice
Any other options your team considered and the pros/cons
Any action items for your team given what you learned
Ask your teammate to review your written “why” to make sure you didn’t miss anything and are on the same page. Once it’s approved, share it with the entire team.
Create a “start with why” folder
Write a new document for each “why” within this folder
Add a hypertext link to this document from each software doc that’s impacted
Start asking “why”
So, new developer, asking “why” will help you learn faster and help your team make better choices. And writing down “why” will provide your team with useful documentation for future work. So get started now. Start asking “why.”
Sincerely,
Cara
Trade-offs
Dear new developer,
I want to build perfect systems . There is something beautiful about flawless code solving a problem elegantly and succinctly, especially if it comes with tests and documentation.
But every time I start to work on real-world problems, trade-offs intrude. Let’s take the example of a website to display information about a business. It will be updated occasionally.
How prominent is the business? A local coffee shop has different needs than a national retailer.
What is the brand of the business?
How often will updates occur?
How many pages of information are expected?
What is the business trying to achieve? An online presence? Acquiring future customers? Lowering customer service request frequency?
Who will update the website? How skilled are they?
What is the budget?
What is the timeline?
Who is available to do the work?
Every one of these questions influences the system I’ll build. A website for a local jeweler who wants to show up in web searches, display store hours, and highlight occasional sales calls for one type of technology. A website for a regional newspaper which is to be updated hourly and handle large spikes of traffic requires a different solution.
You need to find out what the goals are and have that inform the trade-offs you make. The preceding questions will help align everyone around common objectives.
Nothing is fixed in stone, however. These choices evolve over time. I have worked on several applications that were implemented in perfectly good technologies for their time, but now feel their age.
Sincerely,
Dan
Improving Stack Overflow
Dear new developer,
Stack Overflow is the top developer question and answer site on the Internet at the time I write this. You should help improve it.
Searchers—Those who are looking for answers, usually via Google or other search engines
Answerers—Those who are looking to showcase knowledge, usually by answering questions
Askers—Those who have a specific question
Every developer with Internet access is a searcher. At least, I’ve not met any software developers who don’t use Stack Overflow. But you can search haphazardly or you can search precisely.
Do it well by understanding the question you arrive at. How does it apply to your problem? Read all the answers.
Vote up both questions and answers that you find useful. Voting provides a signal to Stack Overflow and is a low effort way to add value. I know it is easier to take the first answer and move on with your current task, but please take a little time and help everyone else.
Additionally, aim to be an answerer or an asker. See if you can answer questions or add comments to clarify them. Politely point to other answers. It can be fun to improve on an existing answer too. Take the time to share your knowledge.
If you have a question and you find that it hasn’t been answered on Stack Overflow, take time to build out a solid question post. If you end up finding the answer to your query, self-answer it to help future searchers.
Any help you provide on Stack Overflow will last for years and will touch many. Currently, I have approximately 4000 reputation points on Stack Overflow, but my questions and answers have reached over a million people .
Sincerely,
Dan
How to say “I don’t know”
Dear new developer,
When you are asked a question that you can’t answer, but you kinda, sorta might be able to come up with a plausible response, it is tempting to just wing it. Few people enjoy admitting ignorance. I know I do not.
One word of advice for you: Don’t.
Your answer could be incorrect and be revealed as such by another team member immediately. In this case, you have egg on your face because you were wrong. People may forgive this once or twice, but in time trust in you will erode.
Your suggestion could be incorrect and not be discovered until later, perhaps by a user reporting a bug or through data loss. This negatively affects the system.
You could be correct, but for the wrong reasons. You will probably suggest this answer in the future. But since you don’t really know why this answer is correct, you won’t know when it’s not applicable.
I hope I’ve convinced you that it’s a bad idea to guess. What to do instead? The right way to answer is to say: “I don’t know but let me find out.” Let’s break that down.
First, you admit that you aren’t certain of the answer. But you then focus on what the questioner really wants: a correct answer. That’s what you’re promising them.
Next, write down the question. A notepad, your calendar, email it to yourself—any way you won’t forget it. Carve out some time to find the right answer.
Finally, follow up. If it’s a weighty or thorny question, provide status updates as you make progress. Feel free to collaborate with your team and the questioner as well—you own finding the answer, but that doesn’t mean you can’t ask for help.
By the way, if you believe what you said is correct, but are wrong, that’s a different type of error—one that I find more forgivable. Technology changes all the time. If, for instance, you “knew” that it was appropriate to concatenate your web assets to minimize browser connect requests to improve your website performance, you’d be correct in a world of HTTP/1.1. But in a world of HTTP/2, concatenating assets has little to no benefit.
Internet protocols aside, the point is it's okay to be wrong.
But when someone asks you a question and you aren’t sure of the answer, don’t just guess. Say “I don’t know,” then find out.
Sincerely,
Dan
In conclusion
Asking questions, in the right way and at the right time, helps you find the knowledge you need to do your job. You can ask questions in person. You can ask them of the crowds on the Internet. You can even ask them of yourself.
Be prepared. Do the research. And when you have to make a decision based on less than perfect information, scale your efforts based on the impact of the choice.