Classic Technical Lead Blunder

A couple days ago I saw a post (EDIT:  the post was removed) relating a depressing situation that sounded sadly familiar to me and I have to respond.  The author relates a story of getting to the end of a time-constrained project and realizing that the other developer’s code is bad.  I can easily relate to the author’s plight because I’ve been in the exact situation at least twice.  My diagnosis for both the author’s current project and my past experiences is simple.  The technical lead (me) failed to lead the technical effort.


 


My problem was that my first official developer job was in a completely dysfunctional organization.  That’s actually a mixed blessing in a way.  You can get more opportunities because it’s easy to stand out, but it stinks in the long run because you don’t get to learn the right way to do things very often.  I was by far and away the most productive coder and the guy with the design vision, but I didn’t know squat about leading or coaching other developers (plenty of people will say I still don’t).  I was forced (ok, I basically seized the role when nobody else was looking) into a technical lead role on my very first significant project.  I’d never had any role model for being a technical lead, much less a good role model.  I made the typical blunder that many first-time technical leads do.  I put the headphones on and hunkered down with what I thought were the most difficult pieces of code and did them.  I gave the other developers what I thought were easier tasks and generally ignored them as much as I could. 


 


I answered questions here and there, but I wasn’t that involved with their coding.  When I finally got around to looking at their code I often didn’t like what I saw.  I rewrote several pieces of their code behind their backs at the last moment.  I essentially wasted the efforts of the other developers.  Two of the developers was truly incompetent but the other two were bright folks that had even less experience than me.  One of the developers was so bad that I started calling him the “Canary” when the “Reduction in Force” rumors started when the tech industry crashed in 2001.  The project was very successful, but could have been much less stressful if I’d invested much more time into the other developers.  They probably would have gotten a lot more out of the project, too.  One of the reasons I think that shop was and is so bad is the complete lack of coaching for technical folks.


 


Losing Strategies



  • Drive by shootings — I mean code reviews.  I’m sure code reviews are useful somewhere, but I’ve never been in one that wasn’t either a complete waste of time or a source of resentment.  Relying on code reviews to catch bad code after the code is written is inefficient and just plain stupid.  Code reviews can easily turn into a case of the prosecution versus the defense.
  • Poor or infrequent communication between the technical team members.  On a couple of occasions some of the developers on my team were on the other side of a cubicle farm.  Co-locating a technical is a no-brainer.  I wonder how much inefficiency exists in large IT organizations where they don’t co-locate development teams.  Technical documentation like design specs are a poor form of documentation.  The only good thing about technical specs is that they’re more durable than a conversation.  Tossing specs over the wall to a development team and walking away doesn’t work.
  • Detailed work assignments.  My experience has been that feeling is that the more detailed work assignment you give another developer; the crappier code comes back to you because they will mechanically implement your design without thinking.  I’ve got a case of this on the system I inherited when our very bright boss gave some specific design advice to the team building the system that this team followed without question.  The advice wasn’t necessarily bad, but there were definitely simpler alternatives to what was built. 
  • I design, you just code.  Even before I had ever heard of XP I always believed that coding, design, and architecture are too interdependent to be done by separate people.  Developers can internalize a design strategy better if they contributed to making the design strategy.  Over and over again I’ve found that it just doesn’t work to give someone a detailed design without a lot of verbal and whiteboard communication.  I think there’s also an issue of developer pride and ownership.  I think coders do a better job when they feel some sort of ownership stake in what they’re coding.
  • Ignoring the other developers to concentrate on my work.  I have to constantly remind myself to focus on the team’s velocity as opposed to my velocity.  I still think that I’m most effective early in the morning when I’m heads down into code with zero interruptions, but that doesn’t help the other developers.  It’s not just a matter of trusting the other developers – but that is often an issue.  It’s also about talking over the design, looking for duplication, and creating a shared vision.

 


Winning Strategies



  • Involve every developer in the design work.  Over and over again I’ve found that developers have a better working understanding of a system’s design when they’ve been involved with creating the design.  Many agile practitioners are hostile to design sessions because of a fear of speculative design or an assumption that it’s jus wasting time (but the agile community is also mellowing in recent years).  I think design sessions in front of a whiteboard with the team is a create way to get the team on the same page.  Most agile projects involve a “tasking” activity to break down user stories so they can be estimated in iteration planning.  The “tasking” meeting is essentially a design meeting.
  • Pair programming has been very effective in my experience for communicating design knowledge throughout a team.  It’s also a great mechanism to coach other developers.  Pairing can be used as an ongoing code review to eliminate problems more rapidly without the nastiness of a formal code review.  Bad coding practices can be caught very quickly.  On a project last year most of the other developers were Java and GUI guys that hadn’t worked with database or persistence code very much.  Because we were pairing I noticed that they weren’t attending to connection hygiene very well.  I caught the issue very early and explained why it was important to manage database connectivity.  Waiting for a formal code review a couple months into the project to read other people’s code would have allowed that problem to fester.
  • Collective code ownership.  Nobody works in a silo.  Every developer, at least in a small team, should have some visibility into the entire codebase.  Determining and enforcing best practices can be a lot easier when people are rotated through the code.
  • Think out loud.  This is purely an exhortation to me because I never do this well enough.  If you’re one of the primary people doing design on project, talk about your design thoughts all the time.  Involve your teammates as much as possible.
  • Coach the other developers.  If you’re the senior most developer your most important contribution may be the coaching you give other developers, not necessarily the code you write.  Helping other developers is an investment in your team and organization.  Besides, they undoubtedly have something to teach you too. 
  • Co-location of the developers and the rest of the team.

 


 


You could easily argue that the ability to communicate ideas to other developers is one of the most valuable skills a lead could possibly have.  I don’t think anybody can be a technical lead without good technical skills, but not every strong developer is fit to be a lead.  Heck, I’m the veritable poster child for this.


 


Of course, you’re always going to have trouble if the ratio of “needs coaching” to “able to coach” gets too high.  The idea that all you need is one smart guy on a project to tell everyone else what to do is a nonstarter in my book.  No process or goofy accreditation effort, be it wild-eyed XP, UML out the wazoo, Six Sigma Ninjas, or CMMI Level Umpteen, is ever going to change the fact that producing good software requires good people.  Some people want to be the bright shining star of an organization, and the easiest way to do that is work with bad people.  I’ve gotten to work on a couple of very strong teams at both my current and previous employer.  That’s been vastly more fulfilling and less stressful than being “the” guy on a weak team. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Pair Programming, Ranting. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.pottytrainingdogs.org/ potty training dogs

    I don’t think anybody can be a technical lead without good technical skills,

  • http://www.ipsw2010.eu/ ipsw

    I gave the other developers what I thought were easier tasks and generally ignored them as much as I could.  onlinedrugstore

  • online drugstore

    I gave the other developers what I thought were easier tasks and generally ignored them as much as I could.  

  • http://www.cnatrainingcareerguide.com/ CNA Training

    I had the same situation happen to a friend of mine I knew in college. He was extremely upset and driven at the same time so he pulled it off. 

  • http://gethairfree.com/home-laser-hair-removal/tria-laser-hair-removal-reviews Tria laser hair review

    Just looking around some blogs, seems a pretty nice platform you are
    using. I’m currently using WordPress for a few of my sites but looking
    to change one of them over to a platform similar to yours as a trial
    run.

  • http://www.marketwire.com/press-release/acn-inc-exceeds-last-years-giving-during-ronald-mcdonald-house-charlotte-north-carolina-1669220.htm ACN

      I made the typical blunder that many first-time technical leads do.

  • http://www.londonguitarinstitute.co.uk/ guitar lessons London

    The juxtaposition of losing and winning strategies is good. Your point
    that you need to fight the urge to not trust the team is one of most
    challenging parts of being a lead for the first time.

  • http://duihelpnow.com/ dui help

    I don’t think anybody can be a technical lead without good technical
    skills, but not every strong developer is fit to be a lead.  Heck, I’m
    the veritable poster child for this. 

  • http://www.exerciseequipmentexpert.com.au/ exercise equipment

    Helping
    other developers is an investment in your team and organization. 
    Besides, they undoubtedly have something to teach you too.  

     

  • http://www.dreambox-8000.com/products_all.html dreambox 800 hd

    I think that these person will surely get some thing good for there works.

  • http://www.gamesracers.com/ click here

    I gave the other developers what I thought were easier tasks and generally ignored them as much as I could. 

     

  • http://www.dissertationwritingservice.org/ Dissertation writing service

    But for the new coders out there, take from someone who has been beaten
    up by the worst and the best, you’ll find this situation where you
    inherit someone else’s bad code / sloppy work to be the norm 

  • http://www.academicwriting.biz/ academic writing

    But for the new coders out there, take from someone who has been beaten
    up by the worst and the best, you’ll find this situation where you
    inherit someone else’s bad code / sloppy work to be the norm

  • http://jikjok.com/coupons/where-to-get-office-depot-coupons/ click here

    I don’t think anybody can be a technical lead without good technical skills, but not every strong developer is fit to be a lead.  Heck, I’m the veritable poster child for this.

  • http://onlinedisabilityinsurancecompanies.com/ disability insurance companies

    Loved to read your blog. I would like to suggest you that traffic show
    most people read blogs on Mondays. So it should encourage blogger to
    write new write ups over the weekend primarily.

  • http://cnatrainingexperts.com/ Go Here

    Helping other developers is an investment in your team and organization.  Besides, they undoubtedly have something to teach you too.  

  • http://howtogetridofpimples.co.nz/ Acne Diagram

    The technical lead (me) failed to lead the technical effort. 

  • amita sexana

    MS Access Repair Software
    access password recovery
    Access Password Recovery Tool
    MS Access Password Recovery
    Excel Recovery
    download free key logger
    Access Password Recovery
    Chat Archive Recovery
    Database conversion software
    Excel file repair
    Data Recovery Tool
    Web Hosting
    Data wiper software
    Digital camera photo recovery software
    Disk Recovery Software
    Data recovery software free download
    Database Converters
    Free Keylogger
    Excel Files Recovery
    MS Access Password Recovery Tool
    Excel Recovery
    free keylogger software
    Floppy Recovery
    Excel Repair Software
    How to Repair Corrupted Excel Files
    recover msn password
    Excel recovery Software
    Floppy Disk Recovery
    Windows Data Recovery
    Keystroke Logger
    Hard drive data recovery
    Recover My Excel Files
    Windows Recovery Tools
    IE Password Recovery
    IPod Recovery
    Key logger
    Excel Recovery Tool
    download a free keylogger
    keyloggers free
    keylogger freeware
    Keylogger Spy Software
    keylogger software free
    keystroke capture
    Keylogger
    Recovery Password
    free keylogger downloads
    best keylogger free
    msn password recovery
    Free Download Outlook Express Password Recovery Software
    password finder
    Keylogger Software Download
    Password Recovery
    password recovery software
    password recovery software free
    pen drive data recovery software
    Pen Drive Recovery
    PowerPoint Repair Tool
    Chat Recovery Software
    Recover Excel Software
    Fix Excel files
    Email Recovery
    Mobile phone data recovery software
    recovery for excel
    Repair Excel Files
    Advanced Excel Repair
    Data Recovery Software
    Sim Card Recovery
    SIM Card Data Recovery
    Key logger software
    downloadable keylogger
    download keylogger freeware
    free invisible keylogger
    data recovery
    Download Free Keylogger
    keystroke recorder
    software keylogger
    remote key logger
    SIM card recovery software
    SIM card data recovery software
    Backlinks Checker Tool
    remote keylogger free
    Spy Keylogger
    USB drive data recovery
    Free Backlink Finder Tool
    datarecovery
    Recover ZIP files
    keylogger
    Data recovery software for NTFS
    Recovery Format Data
    Partition recovery software
    SEO
    Backlinks Checker
    Mobile Phone Sim Card Recovery
    Word File Repair Tool
    data recovery services

    Thank you for you to tell us more interesting information, Thank you

  • http://www.dog-barrier.com/ heated dog beds

    My diagnosis for both the author’s current project and my past
    experiences is simple

  • http://www.soapberries.com/ high efficiency detergent

    But for the new coders out there, take from someone who has been beaten
    up by the worst and the best, you’ll find this situation where you
    inherit someone else’s bad code / sloppy work to be the norm.

  • http://www.bostoncedar.com/prestige/prestige.html western red cedar price

    My diagnosis for both the author’s current project and my past
    experiences is simple.  The technical lead (me) failed to lead the
    technical effort.

  • http://www.bostoncedar.com/douglas_fir/douglas_fir.html douglas fir flooring

    The juxtaposition of losing and winning strategies is good. Your point
    that you need to fight the urge to not trust the team is one of most
    challenging parts of being a lead for the first time.

  • http://www.dvdsreleasedates.com/ new movies on dvd

    I gave the other developers what I thought were easier tasks and generally ignored them as much as I could. 

  • http://www.bostoncedar.com/decking/douglas_fir.html douglas fir lumber

    my past experiences is simple.  The technical lead (me) failed to lead the technical effort.

  • http://lovetester2.com/ love tester

    most difficult pieces of code and did them.  I gave the other developers what I thought were easier tasks and generally ignored them as much as I could.  

  • http://WWW.disneyvcation.com/ Walt Disney World

    echnical leads do.  I put the headphones on and hunkered down with what I thought were the most difficult pieces of code and did them.  I gave the other developers what I thought were easier tasks and generally ignored them as much as I could. 

  • http://www.kissdegree.com/college-de...hnical-degree/ technical degree

    uch less stressful if I’d invested much more time into the other developers.  They
    probably would have gotten a lot more out of the project, too.  One of
    the reasons I think that shop was and is so bad is the complete lack of
    coaching for technical folks.

  • http://sharpsnooker.com.au/snooker-cues/peradon-cues.html Peradon cue

    My diagnosis for both the author’s current project and my past experiences is simple.  The technical lead (me) failed to lead the technical effort.

  • Anonymous

    I can easily relate to the author’s plight because I’ve been in the exact situation at least twice.  My diagnosis for both the author’s current project and my past experiences is simple.  The technical lead (me) failed to lead the technical effort.

  • http://www.giftbasketstore.com/ Gift baskets

    . I frankly don’t like sitting in a meeting for more than 15 minutes
    (our Scrum limit) and an hour (or longer) wallowing through code doesn’t
    seem to be condusive to a healthy collaborative environment.

  • Prerak

    It is a very good article and will certainly help me executin my duties. Thanks a lot.

  • http://www.dotnetfunda.com/profile/Sheonarayan.aspx Sheo Narayan

    Pretty good explanations, this is what I was looking for since long time.

    Thanks Miller

  • http://weblogs.asp.net/bsimser Bil Simser

    @Jeremy: I’m torn on the code review comment. I frankly don’t like sitting in a meeting for more than 15 minutes (our Scrum limit) and an hour (or longer) wallowing through code doesn’t seem to be condusive to a healthy collaborative environment. Most of the time it’s “this is bad”, “this needs work”, “why didn’t you try this”. All good suggestions, but sometimes never even implemented due to cost concerns (another issue). However, with peer reviews you run the problem of the team. On a small Agile team of say 4 devs (2 senior, 2 junior paired) your gene pool quickly empties out as the senior guys are always reviewing the junior guys and you’re left with 2 peoples opinion (or sometimes 1). Not sure how to resolve that and pitch the code review free zone to my client as a result of that (situation I”m in right now). A good discussion to have (psst, come up to Canada in August for some good ALT.NET’ing)

  • http://activeengine.wordpress.com ActiveEngine Sensei

    @Jeremy Great post. The juxtaposition of losing and winning strategies is good. Your point that you need to fight the urge to not trust the team is one of most challenging parts of being a lead for the first time.

    @Jeff Above all the qualities that you will need will be honesty, integrity and patience. But for the new coders out there, take from someone who has been beaten up by the worst and the best, you’ll find this situation where you inherit someone else’s bad code / sloppy work to be the norm.

    Mostly that is fostered by the business units not caring about how you do what is important. Many times you’ll find that the person who created the mess that you’re stuck with was LOVED by the customer / business unit because he / she gave them what they wanted instead of what they needed. As a leader, you will need every ability at your disposal to communicate this back to the customer in their terms. Now you have discredit someone who, in their eyes, was a great asset to them.

  • Jeff

    Just read this post and am amazed at how similar it is to my situation. Came into a crap situation, seized the lead role thinking I could fix things. Now a little while in, and I’ve been stuck in the ‘losing strategies’. Worst thing is, I’ve been aware of it for a while, but inertia is hard to overcome! Great post. I’m working on eliminating those losing strategies, and moving to the winning strategies.

  • Jeremy D. Miller

    Jay,

    Thanks for your comment. My negativity towards formal code reviews is strictly based on bad experiences in the past. I’d still rather lean on pairing or more informal peer reviews than the heavier formal code reviews. I think constant pairing and iteration retrospectives accomplish the same goals as code reviews in a more pleasant way.

  • Jay

    An interesting view point and I agree with most of it. The only thing I have a problem with is your view of code reviews. I think that the kind of response that you portray is more indicative of the participants than the practice. Code review should not be perceived as some sort of kangaroo court. It should be seen as an opportunity to learn from one’s mistakes and figure out new and interesting ways of doing things. I’ve seen some very indignant responses to code reviews, but I have to say, that is usually based on the coder deciding that they are god’s gift. If all parties involved carry out the review in the way in which it is meant to be carried out, I can’t see how it can be problematic. Just my opinion based on my experience of being on the receiving end of code reviews and what I got out of it. I always learn from them.

    Jay

  • http://hrboyceiii.blogspot.com Harris

    Jeremy,

    The AppDev group I work in, unfortunately, has to be very numbers-oriented right now; how do you bill pair-programming time? Obviously, an Agile team bills differently than a waterfall team (which we are…sigh…), but I would appreciate to hear your thoughts on either, or both…

    Thanks,

    H

  • http://www.brock.ac.uk/blogs/jon Jon Rowett

    just to add to the general noises of approval – fantastic post. thanks.

  • http://dotnetjunkies.com/WebLog/thomasswilliams/ Thomas Williams

    G’day Jeremy, thanks for this informative post. It makes a great read – it’s always good to learn from others and hear some of the “war stories”, but it’s even better to see some intelligent reflection and tips, as you’ve provided here.

    Cheers,

    Thomas

  • Jeremy D. Miller

    You gotta get you’re foot in the door somehow. “Messed up” is pretty well situation normal.

  • DawlinLi

    The interesting part is that I am in the exact same situation you were in when you first got your official developer job.

    I am in my official developer job right now (just graduated from college last year) and it’s also a mess :D.

  • Jeremy D. Miller

    The post in question was removed.

  • DawlinLi

    the original link to the “post” is bad, can you fix it?