Witty Writeups
Someone at work gave me some helpful advice on Friday and I realized that there is another step in learning how to ask questions.
The first stage in asking questions is the “help it’s broken” stage. It’s pretty much what it sounds like - something isn’t work, it didn’t compiled, maybe there was a seg fault, god forbid a merge conflict and you just give up immediately and ask for help. It’s what I call the “CS 5 on the first day” level of asking for help. It’s not particularly sophisticated as methods go because it doesn’t help the person who you’re asking for help from understand anything about your problem. It’s only really okay if you don’t expect to have a hand in fixing the problem or if you don’t know how else to ask for help. A slightly more sophisticated version of this: “helps it seg faulted or a I got a null pointer exception.”
The second stage of asking for help is “help its broken and I tried x, y, z”. This is a more advanced way of asking questions. For a tutor it’s nice because it brings me up to speed oh what has been tried already so I don’t waste your time. It’s also more advanced because this means you at least tried something. A lot of problems can be solved with a simple print statement, a check for the empty case, some simple debugging. But that’s for another post.
That brings me to last Friday. I realized that asking for help at a job is different from asking for help from another fellow software engineer. At tutoring for classes, it is my job to help the students. Even if they don’t form the questions well, it’s still my job to help. I like helping. Part of my helping is also helping them form the questions. The point is that I’m there to help. I work on homework when I don’t have questions but for the most part, I know the solution and I know the kinds of problem they are stuck on. But at work it’s not the same. Yeah, the team is there when the newbie or the intern (me) needs help. And it definitely is worth it to ask questions instead of struggling for an entire morning on something related to the build that is very team specific. However, the team is composed of software engineers who themselves have stuff to do. So this brings me to the newest type of questions - distilling your question to the essence: What is wrong, and what is the essence of what you don’t understand, what you need from the other person. This way, you make sure that you spend their time well and don’t waste it asking small question after small question. This is especially important for software engineers who may have their day broken up enough by meetings which makes it hard to do critical thinking that leads to building better software.
The essence is that you need to think about the other person- how can you help them best help you. Another lesson in empathy. Stay tuned for a post about “things I learned being an adult for the summer.”
26 Jul 2015