Helping the Team

Perhaps you have experienced the struggles of on-boarding new developers into an already large team in the middle of a project. Everybody who comes wants to have a say in how things are done, no matter how late in the process they get involved. Here is a litany of the types of commentary that I hear in this situation:

Brogrammer

  • On my last project we used <insert product, pattern, or practice> and it worked great. We should certainly use that here.
  • We don’t need <insert pattern, product, or practice> its too <insert adjective>.
  • Why don’t you just <insert suggestion>.
  • The code-base is in a bad state because <cite example>.

Each of these commentaries were delivered, without necessarily an understanding of the choices that were made by the team to get to this point, nor with a full understanding of the work remaining. I sincerely believe that each developer made the comments in a spirit of trying to help the team. I also believe that each of these comments reflects the developer trying to construct a “familiar” environment where he knows how to deliver value.

Here are the problems with this:

 

  • Commentary rarely reflects a problem statement before offering a solution.
  • Commentary rarely exposes the cost (in effort and risk) of adopting the solution.
  • Commentator may or may not have the experience or skill to lead the team through the adoption of the solution.
  • Commentator may or may not have thought through the solution to the ultimate conclusion – to determine whether it is feasible, valuable, or reasonable within the context of the project.

I attribute these commentaries to each developer’s on-boarding process, and their process of “mourning” the familiarity of their last engagement, while also trying to understand the current environment.

So by way of honoring the desire of new developer resources to actually help, I offer the following advice:

1) If the code base gives you a skin rash, be a “boy scout programmer”, and leave the campsite better than you found it. Find ways to improve the existing application incrementally, without the necessity of a major reworking of any aspect of the code. Those that are able to help in small things are often given a chance to help with bigger things.

2) Before you suggest any solution, make sure you have clearly articulated the problem that you are solving. If you are going to articulate a problem, make sure you express it in terms of some bad outcome that will certainly happen unless your solution is implemented. You may be proposing a solution to a problem that others have already solved differently, or you may be solving a problem that nobody else believes exists. The outcome that is so horrible in your mind, may be perfectly acceptable within the context of this application.

3) Take the time to study and truly understand the requirements and the business cases supported by the application. Understand the architecture and the team that is already on the ground. Understand what has already been tried and rejected because of constraints of technology and requirements. Understand the organizational and environmental constraints. Compare your solution to the context, and see if it still holds water.

4) Put your hands to keyboard and deliver some working software capabilities (stories, features, etc) and earn some credibility with the team. After you have helped them crank out some code and you are perceived as part of the solution, then they might listen to your ideas about improving the code base.

Remember, no application is perfect, and those who have worked their fingers to the nub getting this far, may not really appreciate the brilliance of your ideas, until you prove that you are a solid, productive, collaborative member of the team.

No Comments

Leave a Reply