Be Wrong And Ask A Lot of Questions

        Back when I was first starting out my career, on my first day, as I was walking into the office for the first time, my manager told me this: "If you're ever stuck on something for more than 10 minutes, ask me for help." I asked him for help approximately 30 times that day. It was a learning experience for me, someone who was used to bashing his head against problems for hours and would never reach out for help prior to starting my career. I believe that this open process helped me ramp up significantly faster and kept me from drowning during the early days. While I ask for help slightly less than that these days, I keep that lesson in my heart to this day and am always ready to ask for help. You should never feel bad for asking for help. All great engineers, regardless of experience level, ask for help frequently.

When to ask for Help

  1. For access to information, do a basic search and then ask for help immediately. It's very common that someone will know something you don't and they will usually have context that documents do not.
  2. For solving generic or straightforward problems, first try and understand everything you can about the problem in context. Next, try a naive solution and see if it works. Then, ask for help.
  3. For solving large scale technical problems, come up with multiple technical solutions to the problem and ask for advice on which one might be better. If you don't have this level of information, you likely have several simpler questions that you should ask first. This is not a bad thing as more generic questions usually have clearer answers.

How to ask for Help

  1. Gather as much information as you readily can on the issue and put links and info in a document together.
  2. Write a long, cohesive question where someone could solve your problem without addition information. Include relevant links. I've had many stack overflow questions answered because I included failed build runs, code links, etc.
  3. Give evidence that you tried to solve the problem yourself, preferably in a way that makes it easier for the person to answer your question. Try to take care of as much of the issue as you are able to. People are always happier to help if they know you tried to solve every part you could. It's okay to be wrong and to ask someone for the right answer. Being wrong often gives quite a bit more detail about what you're trying to do than the question itself will. According to Cunningham's Law, "the best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer." This is generally true.
  4. Don't include extraneous details in your question. Go through your question in the end and try and see what you can cut while maintaining intent and answerability.
  5. Be respectful of people's time and effort. Don't just say "Hey" and hope they respond. Let them read through the question and what information you have at their own time and their own pace.
  6. Express the appropriate amount of urgency with which this question needs to be answered. If it's more urgent, you can say so explicitly, or you may need to set up a meeting to discuss details.
  7. If the person you approached doesn't know the answer, they may know someone who does. If they don't, ask your team chat. If your team chat doesn't know, post the question on stackoverflow and link it to the org or company chat.

Conclusion

When you need help, you should never be afraid to ask for it. With that, question asking is a skill, and a useful one. The more you develop it, the better information you'll get when you ask, and the less you'll have to back and forth when you do get answers. Framing the question and asking it may be sufficient for you to answer the question yourself in some cases. Technical questions often aren't merely questions, but are instead a part of a process for solving a larger problem. Having a more detailed, better written question will help you with that process, regardless of whether someone answers it.

Comments

Post a Comment

Popular posts from this blog

Using Kanban Boards to Stay Organized and to Stay Motivated

I often work with Trello or Notion as Kanban boards. I maintain tasks for everything that I do. This helps me keep organized when I'm working on a large number of tasks, or especially if I have ideas for tasks that I am not actively working on. It creates a clear, constant document of the state of the tasks I'm working on. And more than anything, it shows to me what I've accomplished and lives on as a constant motivator for me. Why Kanban Boards Matter for You and Your Team One best practice that anyone working on a large project should adopt is to have at least one Kanban board task they're working on at any given time. Kanban boards are a visual way to track progress on tasks, enabling you to see the status of each task and its associated details. By consistently updating your tasks on a Kanban board, you'll reap several benefits: Greater personal efficiency : As you wrap up your day or put a project on hold, having detailed information on your Kanban board task h
Read more

Low Level Design Part 1: Reading and Gathering Information

Start out your document writing day 1 with a long list of open questions. As you read documents, you should slowly grow a longer and longer list of open questions. Maintain this list and keep adding to it while you write the doc. Questions are often more important than answers as they represent unknowns you need to disambiguate. You will need to ask people for most of your open questions. This is okay and most engineers are very happy to answer such questions. In general, people will feel more complimented rather than inconvenienced when their expertise is requested. If you can't find an answer to something and don't know who to ask, ask your manager or a senior engineer on your team. What if no one knows in your team? Formulate your question into something brief and meaningful and post it in your org or company-wide chat. If your question is technical, ask it as a stack overflow question and link it in the chat along with your question. Link to everything as hyperlinks in the
Read more

Low Level Design Part 3: Estimates

You should include your task breakdown and estimates in the low level design in the appendix if it's available. Design your project with the idea of disambiguating hard questions in mind. Frontload as much ambiguity in the project as possible. Changes in estimates months in advance are preferable to ones right before the deadline universally. Usually, the best way to do this is to write a thin vertical of your project first and then start fleshing out the functionality after that. If you haven't worked with a library, platform, language, etc. your estimates on that topic will have low accuracy due to unknowns. You can reduce this effect with additional reading, especially of code, or by writing code using that library yourself. Call out everything that you don't know.  Low accuracy estimates almost always take more time to complete rather than less . If you estimate a task as a week, the shortest it can be is an hour. The longest it can be is infinity. This asymmetry means
Read more