Mark Needham

Thoughts on Software Development

Ask someone vs work it out yourself

with 3 comments

Back in 2007/2008 when I worked on my first couple of projects at ThoughtWorks I always found it strange how frequently my colleagues would try and figure something out themselves rather than asking someone else (who already knew how to do it) how to do it.

Fast forward to 2010 and I find myself being the one encouraging people to figure things out themselves.

There’s still merit in communicating with colleagues when we’ve tried to work out how to do something and haven’t managed to figure it out but it’s also useful to not have this as our default mode.

This seems to be particularly the case when working offshore if we have a reasonable idea that someone onshore might be able to help us with something we’re working on.

We can stop and wait for them to start their work day but frequently we’ll be able to make some progress without their input and then if we really do need help we can always get it later on.

While someone else can often solve a problem quicker than us the disadvantage is that we don’t tend to learn by watching others but rather by struggling ourselves.

In my first job it was suggested to me by a colleague that I should try and solve any problems alone for an hour before asking someone else for help.

Having said that I do think it’s still useful to know which people in a team have expertise in certain areas so that we can ask them for help when required.

Written by Mark Needham

December 14th, 2010 at 6:04 pm

Posted in Software Development

Tagged with

«
»
  • http://www.wikyblog.com/AmanKing Aman King

    Yes, in a distributed setting and when what you’re trying to “learn” is picking up familiarity with code areas and related domain knowledge, I’d agree that an offshore team can spend some time exploring code and if needed, asking offshore BAs for business context, for stuff that onsite may have done but needs changes.

    In such a case, my hope is that the code written is easily readable and navigable and has unit tests to act as documentation.

    However, in general, when it comes to performing a “task” (distinct from code familiarity or domain knowledge) which is probably new for you but not for someone else (like writing a cap task to perform something), I would shoot for asking someone who knows and not wasting time learning this yourself. I believe it is important that project time is used to make progress.

    I also agree that you’re more likely to learn something and remember it if you struggle first and solve it yourself with minimal personal help… but that is what pet projects and off-project learning is for.

  • http://www.markhneedham.com Mark Needham

    Actually it’s interesting that you point out a Cap task as being something you’d ask for help on because that’s one of the things I suggested we could figure out ourselves rather than asking a guy in the States :-D

    It took maybe an hour to understand how everything fits together/the conventions etc and now we can pretty much do it ourself if we need to.

    If the person who knew how to do Cap was in the same room I’m sure we’d have asked for help though

  • http://www.wikyblog.com/AmanKing Aman King

    LOL.

    > I believe it is important that project time is used to make progress.

    Well, that’s the goal. I definitely wouldn’t wait for overlap hours to kick in to ask about something non-domain-related like writing a cap task.

    An assumption of mine was that for such non-domain-related things, there would probably be someone on the same co-located team who’s done it before… if not, I would ask people a few tables away who are on another project but probably have written cap tasks before.

    But ahem, seriously, you have no one who’s written cap tasks in your team??? :-D