At hack.summit() I heard a talk by Qi Lu, a researcher at Microsoft, who said, basically, “there are two kinds of developers. The first kind, you give them a task, and they disappear for half an hour, and then they come back with some question about it. The second kind, you give them a task, and they disappear for two weeks and then come back and ask what to do next.” Qi Lu then advises us to be the second kind.
On the other hand, Jeff Atwood writes,
When interviewing candidates for programming positions, I always look for someone who is brave enough to say “I don’t know” when they need to. Candidates who can’t or won’t do this get red flagged; those types of programmers are dangerous. “Can-do” attitudes have a superficial allure, but they’re actually poison in our field.
So what do I do? Suppose I am Schrodinger’s programmer, about to become programmer 1 or programmer 2. I have just left the boss’s office, and after an hour or two of writing code, I’ve hit my first real obstacle. Do I go back, admit that I don’t know, please Jeff but anger Qi? Or do I bury myself in code for two weeks, and at the end of it hopefully be programmer type 2?
I think these two pieces of advice only appear to contradict; the authors are pushing us towards a golden mean from opposite directions.
Qi Lu is running a research department, so his employees are answering questions that no one else knows the answer to anyway. I think Mr. Lu is not criticizing people who won’t admit they’re wrong, or criticizing people who work in a team; he’s criticizing people who whine that the work is hard instead of doing the work. This criticism is especially fair in a research department, because there’s no reason to expect that the programmer down the hall knows the answer; struggling through uncharted territory is the job.
I also think Jeff is not giving a free pass to people who don’t know anything or who whine instead of working; I think instead he’s stating that teamwork and humility are super important to building good software, and if you’re interviewing a candidate who’s too insecure or too arrogant to admit they don’t know everything, that is a serious red flag to future teamwork.
I think the real lesson here is this: if the best way forward is to get some help from a colleague, then get the help! If the best way forward is to slog through, slog through. The two things you don’t do are: (1) ask for help as a way of procrastinating when you really should figure it out on your own, or (2) refrain from asking for help out of shyness or nerves or whatever, when getting a little help would really be the best path forward.
On the other hand, if we did take both these pieces of advice really at face value, and Qi Lu were really telling us not to ask for help, I have to side with Jeff. It’s been said often that great software is built by great teams, not great programmers, and I’m inclined to agree. Few things are more helpful than a second set of eyes or a second opinion, and I wouldn’t want to work somewhere that discouraged asking questions.
This situation (that is, deciding whether to get help) seems to be also a place to figure out what’s normal on the team you work with, and go from there. Maybe deciding whether to ask for help (which is something you should expect to do fairly often when you’re new to this job) is a matter of both the kind of project and the kind of team. For example, I’ve heard senior devs complain that they can never finish a pomodoro for all the new people asking for help, and I’ve heard younger devs be asked not to waste all day spinning their wheels again.
Till next week, happy learning!