Very early in my programming career, I was very dogmatic. I learned one way to do things and that was THE right way and anyone who didn’t do it that way was doing it wrong. I really wasn’t afraid to tell people that either. Obviously starting with “Your doing it all wrong!” wasn’t a great strategy for winning people over to my way of doing things. Luckily I was capable of learning.
What really helped me with all this was being very curious. I tried very hard to understand why people made the decisions they did. What were the constraints they were working with? What requirement was I missing or not seeing? Why is what was obvious to me, not obvious to them?
I realized that in my right/wrong way analysis, I was discounting all of the context and circumstances that caused people to do things in a different way. In many cases, the decisions they made did not match what I would have done simply because I didn’t have all the information they did. When I was patient and let them explain, I often found that given their particular circumstances, the decision that I had questioned was actually quite reasonable.
In the cases where I still disagreed with the decision, understanding their thought process quickly made me realize that it wasn’t malice, laziness, or incompetence that caused them to make these decisions that seemed like poor decisions to me, but rather it was simply lack of knowledge and skill. I backed into the retrospective prime directive: “Always assume everyone is doing the best that they can with the knowledge and skills that they have.”
In those situations where after gathering more information, I still thought there was a better way to do things, there was one question that always seemed to help: How is that working for you? That question seems to cut through all the subjectivity of “Well that is not how I would do it.” It gets right to the core of the matter. Is what they are doing working for them? If so, then why would they change? and why would I even bother to try to persuade them to do something different?
If the answer is: “No. It is not working very well.”, then we have a starting point for a conversation. In that case, it is not me barging in with my better way, but them realizing on their own that change is needed. No one likes change, but it is a much easier pill to swallow when it is your idea. At that point, they are much more receptive when I tell them there might be a better way.
Now there is a caveat to this. Sometimes when I ask people “Is this working for you?”, they say yes. Now there may be situations where they say yes, yet I can clearly see that there is a better way. At that point, I need to trigger their imagination. I need to start asking what if? What if you could cut your software delivery time in half? What if you didn’t spend so much time chasing bugs? What if you could have multiple developers working in parallel? I need to try to help them see that even if things appear to be working, that they could be better.
You may have some processes that are not producing the results that you want. Or you may have some areas that are technically working, but you feel that you could do better in those areas. If so let’s schedule a call to talk about a better way to write software.