Questionable Questions
Week 9
The Harm of Poorly Posed Questions
November 13, 2014
As I heard many times before starting Dev Bootcamp – and have since come to believe on my own – being a programmer means knowing how to learn quickly. With the tech industry constantly changing and developers being responsible for knowing many languages and technologies, being a fast learner is a crucial aspect of being a programmer. And learning is dependent on asking good questions. Good questions are an amazing tool when you consider how often questions are asked in an unproductive way and how quickly bad questions can get you off track.
Good questions are specific, well explained, contextualized, and don’t make assumptions. That means, for example, that when you’re asking a question you need to explain the language you’re coding in, the problem you’re trying to solve, the approach you took, and any error messages you might have received. Not making assumptions is a very important point. You may have been wrestling with a problem for hours and are very familiar with it, but you have to keep in mind others are coming to it cold and will need to digest it first. You can’t assume they know what you know. It’s your job to help them understand it quickly so you can both get to solving it. This can’t be done passively, for example by just showing them the chunk of code you’re working on and expecting them to parse it instantly. Instead, you need to walk them through your thought process.
Sometimes I err on the side of being brief so as not to bog people down with details. I know how frustrating it can be to spend a lot of time trying to understand the problem before you even start solving it. At times I realize I was too brief and didn’t include enough details. For example, once I asked on our cohort Google+ community how to write driver test code to test for an argument error message. I got a few answers that didn’t exactly address my problem, and it soon dawned on me that my question wasn’t detailed enough. I didn’t explain what challenge I was working on, how I had tried to solve it, or what my thoughts were; I just asked the question. I realize now I should have explained more at the outset. I’m often wary of my question being too long or unwieldy and people ignoring it. But my cohort and DBC’s larger community has been very helpful and understanding, so I realized I shouldn’t be afraid to ask questions.
Sometimes I also have a tendency to want to work through programming challenges entirely on my own. While I think this is a necessary trait for programmers at times, it definitely has its downsides and needs to be balanced. Phase 0 has helped me get past that mental block of wanting to figure out problems on my own and has taught me how productive collaboration really is. There have been many times I was hopelessly stuck and forced to ask a question I had been toiling over. When I saw that other people had been struggling with the same problem, I realize how stubborn I had been and that I should have asked for help earlier. The important thing is not about who’s right, it’s about making sure you learn the material.
Phase 0 has undoubtedly made me better at asking questions and learning quickly, and it’s given me a good crash-course start to my journey to becoming a team-oriented developer with soft skills and hard skills. When I start Phase 1 on Monday, I’ll definitely take these lessons with me so I can learn as effectively as possible. With the pace and expectations of DBC, I know I’ll have no time to waste on poorly posed questions.
