sasbury.com

I was already out of graduate school when the world wide web became public knowledge and Mosaic hit the streets for the first time. I had already formed most of my habits for learning new things. Some of those habits have been updated. Some remain the same.

When I went to school, writing a research paper began with a lot of research at the library. I might start with an encyclopedia, but the higher the grade, the more likely I was to have to go to the library and start looking up books in the card catalog. When I hit graduate school, this process was augmented to include journal searches. Research was a hard process.

Fast forward to today. Today's college students probably start their research paper on Google, DuckDuckGo or Bing. Research journals are often indexed on-line, even if the contents aren't available for free.

So here is the difference between me and many of the young people I work with.

---

When research involves a long painful trip to the library, you learn that the primary method for learning and research is to ask someone. When I wanted to know what books to read or if there was a formula I needed to know, I asked a teacher. Sometimes, the teacher would send me the library, but even in that case they sent me with a specific search plan target.

But, when research involves typing a question into Google, you don't need to ask as many questions of other people.

---

Its that simple, I learned to ask questions first, others learned to search the Internet first. When I started working at Fog Creek, I noticed that my co-workers seemed to get annoyed by the number of questions I asked. It took me a long time to realize that what they were expecting is for me to check DuckDuckGo for something before I asked in chat. There is even a web site called let me Google that for you created by someone clearly tired of answering "obvious" questions.

And you know what, they are right. Searching on-line for programming questions often leads you to stack overflow where many questions are already answered at length. Which means that asking general programming questions really is a waste of your co-workers time. So the lesson for us "more experienced" developers, is to think about our resources. We have to reprogram ourself to search the global community of developer answers before we ask the person sitting next to us.

But I don't intend to let the "less experienced" folks off the hook. There are still a lot of areas where questions are better than searching.

Lets look at an example. Suppose I am working on a part of FogBugz, and I know that Carl (name changed to protect the innocent) has been working on FogBugz for years. I want to know if we have a function that checks if a user name is valid. So I ask on chat "Do we have a function that tells if a name is valid?" Should Carl answer "Look at the code" or should Carl answer "Yes" or should Carl answer "Yes, look at ..."?

I would argue that the best answer is the last one. Carl should tell me if I would be crazy to search for a function that isn't there, and also point me at the right place for the function in question. In fact, many of the guys on the FogBugz team did exactly this for me. Most of the time. But there is a line here. When is the question too lazy? When should Carl just say "go look at the code"?

I propose a few heuristics and guidelines for when a co-worker asks a question, especially in the group chat situation common when there are several remote workers:

• Don't ignore the question

• If someone asks a questions that is probably on stack overflow, or in the doc, ask yourself this, is the person learning about a new technology or process? If so, provide some direction. If not, perhaps just point them to the appropriate "let me Google that for you" response. So if I am new to Ruby and I ask a simple questions, maybe take a moment to answer and talk to me about that feature. But if I ask how do you concatenate strings in Ruby and you know that I know python, just send me to the doc.

• If someone asks a yes or no question, especially one related to proprietary knowledge, you should answer yes or no, at a minimum. If possible, point to a file or function.

• If someone asks the same yes or no question over and over, or very related questions, I think it is okay to refer them to previous answers or say look at the code.

• If someone is asking too many simple questions, maybe let them know and schedule some training time, or point them at a book or something.

• If someone asks a very open ended questions, ask your self if they need guidance or just to go read a book, and respond accordingly.

If you are one of us "experienced developers" that learned to learn before Google, then keep these in mind as well. If you can Google for it, give it a shot. StackOverflow is a great site and often has more than one great answer for your question. When it doesn't, don't be afraid to ask. Maybe even include the Google search you did so people know you aren't over-using their time.

process life fogcreek