There are two types of software developers. Those who dig deep and those who don’t. The difference can be dramatic.
There was a time, back in college while learning to program, where I would try to fix things the easiest way. I was just trying to get things to work.
But that quickly went away. If I find myself debugging code, I have this drive to dig until I find the true root cause. This can have dramatic impacts with how I interact not only with code, but also with teams.
When you don’t know how to fix something, what do you do? Do you throw your arms up in the air and ask for help? When the problem is in another team’s codebase, do you just say, hey its not my problem? Or do you pick it apart, and try to isolate everything about that issue?
If you don’t take the path of deep investigation, you’re doing it wrong.
Don’t pass the buck
Often, people will tend to find a way to prove that something is not their fault. But this is the exact backwards attitude you should take. Assume its your fault.
Science the shit out of it
In Bob Martin’s newest book, Clean Architecture, he makes a statement about math and science. To paraphrase, he says that math works to prove things true (through proofs), and science works to prove things false. One of the great ways to treat software development is to adopt the scientific method. That is, form a hypothesis, and attempt to prove it false.
This is how you can treat ownership. Before passing work off to another team or person, do everything you can to attack the problem in every way. Make a hypothesis and test it until you are out of hypothesis.
Assume that it is in your locus of control to resolve the issue you are working on. Exhaust every opportunity before validating that you need assistance to resolve that.
Even the phrasing here is important. Once you determine you can’t resolve something on your own, work to resolve it with assistance. Don’t just make it someone else’s problem.
Asking good questions
That phrasing is the general key to the next step. If you truly cant resolve something without help, you need to know how to properly take the next action.
Too often I hear “X is broken, do you know how to fix it?” What good does that do for the person you’re trying to get help from? Remember, they are not really obligated to help you fix your problem.
First, make sure they have time for your request. You shouldn’t just expect them to give you their time, it is their most precious resource.
Collect your data, and present it. When I’m asking questions, I like to immediately present the problem, and then follow up with the background on it. I’ll be prepared to deliver a full background of all the hypothesis I tested, and the conclusions I arrived at.
This does two things for the other person. It shows the effort that you have put into the problem for the other person. Additionally, it relieves the other from having to retread your steps unknowingly.
Finally, don’t just dump it on them and hope to hear back. Work with them to resolve the issue. Assuming they have the key piece of knowledge that you didn’t, this is a perfect opportunity for cross pollination of knowledge.
A good corollary is to think about how not to ask questions. Your goal is to make it as easy as possible on the other person. Don’t ask a question by leading with a seemingly unrelated question. Almost everyone does this, be direct. Don’t make the other person peel off the onion layers to find out what you are trying to solve. Instead, lead with that. Don’t ask open ended questions, ask pointed questions, that show you put some effort into it. And don’t lead with your opinion. You’ll color the response and the answer you’ll get.
Make it easy on others
The main goal is just to make it easy on others. Not only are you unburdening your fellow coworkers, but you’re showing them the level of effort you’re willing to put in. What a good way to deliver value at the office.
The person who helps you in this way is also way more likely to do the same for you when the tables are turned. Maybe they’ll even learn this method from you.