In the last year I transitioned from lone developer to project manager. In this role I find that I am called upon to make quite a few judgment calls both on the behavior and the architecture of the application.
I am fortunate to work with a great team who I respect and are far better developers than I am, so generally this goes pretty smoothly. But,
occasionally, either due to my own biases or experience, I find myself or other developers in disagreement with a recommendation of one of the team members.
I have a simple solution to this problem. I request that the developer put the recommendation in writing. I do this for the following reasons:
-
If the developer doesn't have the energy to codify his or her argument in writing, then it probably isn't that important of a decision and we can move onto the next problem. There are always more problems to solve.
-
Putting the request into words forces the developer to think through what is being proposed.
-
It is far more likely that a well written argument will sway me than a half thought out verbal discussion.
We use an iterative methodology and don't specify every program element. But there are cases where there is value in working out a problem in writing. It forces you to consider possibilities that a purely mental model might omit. If there is enough contention in a decision to actually cause a disagreement, it is a strong indication that the time spent working out the issue in writing will be a good investment. I also believe that being able to defend a recommendation or decision is a fundamental sign of maturity in a developer.
I try to hold myself to same standard. I recently caught myself in a discussion where I was arguing a point verbally in a way that was not fully formed. This left me feeling uncomfortable, and I forced myself to research the problem and present my option in a more educated way. Ultimately this puts the onus on the other party to define their position as well, and the end result is a more thoroughly considered solution.
Developers reading this may ask themselves, "Why do you insist that team members defend their positions rather than just trusting them? Don't you trust your own developers?"
I do trust them, but in the past I've worked on projects with multiple smart developers, of one I consider myself, who all had their own ideas about the "right" way to do things. Chaos resulted. It wasn't that any one developer made a wrong decision, but we all made different decisions, and in a large scale software project this is a recipe for disaster.
I consider one of my roles to be the arbitrator of chaos, which ultimately means that every developer is not going to get to do things the way they want. This is a professional software development environment, and unfortunately it requires that developers perform their tasks in a manner that is in agreement with the ground rules of the project. That is why I highly recommend that developers unleash their experimental desires in a side project, and I'm even willing to turn a blind eye if they spend a few hours in the office working on it. I can fairly say that my side projects made me a better developer.