Lessons from being a Lead Programmer on a Mobile App in a Distributed Environment

First of all, that’s a long title. It was also a large role. In 2012 I started working on PlayRank, a mobile social sports app that looks like just a simple iOS app, but really ended up being a high-quality client for a brand-new social network (in only 6 months). I learned a lot leading the engineering side of things, and here are notes I made right after shipping it in January of 2013 (with recent editing and clean-up). They aren’t really mobile-app-specific, but could be applied to rapid development of something in a distributed team environment.

  1. Be as available as possible
    1. People will be online at different times
    2. Be as clear about your availability as possible
    3. Potentially shift your availability to align with others
    4. Have a backup option – for example email, other asynchronous forms of communication
  2. Collaborate across different mediums
    1. Chat, voice chat, email, bug/task tracker, GDrive/documents
    2. Annotated screenshots
    3. Use a common platform, even if you dislike it
      1. No room for ego in lean/rapid/team development, it will cost you the project
    4. Keep track of the various group chats there will be, to make sure you are aware of what is going on, can address problems and questions as soon as possible, clarify or ask for clarification for ill-defined things
  3. Think ahead for setup/questions
    1. Try to ask questions and identify issues far ahead of time
    2. Availability windows may not align, or may be narrow for some teammates
    3. Generally a good rule to follow with remote communications, like web hosts, etc
  4. Be extremely disciplined
    1. Keep everything in version control
    2. (Ideally) Document everything (with GDrive it’s really hard to find an excuse not to do this)
    3. Write useful change-list descriptions (“fixed stuff”, “thing improvements”, “updates to blah” ARE NOT USEFUL)
      1. Very useful for looking back (YOU WILL DO THIS)
      2. Include fixed bug numbers, but also include their titles! Who wants to look up a bug manually when most of the time the title provides enough information?
    4. Commit often
      1. Get the bare minimum of a task done, commit it. Keep working, commit again. Don’t break the build (do I really need to say that? Test your changes before putting them in!), but don’t wait until something is 100% fully complete before committing anything at all.
      2. This helps me keep my mind clear when programming, so I can only worry about ‘the current differences between the repo and my local copy’
      3. When working with others, it gives them an idea of where you are going
        1. Also in what area of the app you are working, so you both can avoid too many conflicts
    5. Keep your task/bug tracker up to date
      1. Some developers don’t like them, but you have to embrace them
        1. If you need more information or help, ASK
      2. Producers will love you for this
    6. Write detailed build notes
      1. Useful for looking back
      2. Useful to communicate progress to the rest of the team
        1. Progress is being made, assets are being integrated
      3. Producers will love you for it
    7. Check your diffs before you commit
      1. You’ll find leftover test code, unintended for checkin changes
  5. Demonstrate leadership
    1. Ask how people are doing
    2. Clearly communicate the progress of what you are responsible for (see disciplined list)
    3. Listen and provide feedback upon request from teammates
    4. Be extremely disciplined (see section 4 of this list) – as a lead you need to demonstrate and embody this
    5. Be prepared to take on unfinished, unassigned, or unexpected tasks
      1. But be equally attentive for opportunities to delegate
    6. Be clear about the required tools
      1. Some teammates may be resistant, but they should be using the proper tools to address the problems at hand
    7. Get familiar with your target market, use similar products to see how they work
      1. Do experiments
      2. I was guilty of not doing enough of this, instead I thought I could ask teammates that do use the target market products questions about how they work – it’s much better just to make dummy accounts and research yourself

Many of these lessons apply to non-distributed teams, to non-developers, are generally good things to do, etc. But they all stuck out to me from this experience. I hope that maybe there is something on this list that helps you, and if you have any comments or questions about any of them please let me know.

Posted in industry Tagged with: , ,

Subscribe via Email

I'll keep you up to date with my posts by email.

Follow me on Twitter

Google+
%d bloggers like this: