Does this sound familiar?
I’m using this example in the book I’m writing, and want to see if this sounds familiar to you.
Ananya: “Marcus, which class should contain the method to check if we have new orders? I need to add it for the feature I’m working on today.”
Marcus: The OrderUpdate class would be good.
Ananya: Okay, I’ll do that.
<two days go by>
Marcus: Ananya, what’s the status of that feature?
Ananya: It was quite difficult to make it work in the OrderUpdate class. I had to rewrite big parts of the class, and other classes too. I should be done next week.
Marcus: Oh, that’s too bad. Was there class it would have fit better?
Ananya: I think the OrderStatus class would have been better, but I’m almost done with this approach. It’s fine – no worries.
Marcus: Oh, why didn’t you suggest the OrderStatus class?
Ananya: You said you wanted it in OrderUpdate. I assumed you had a reason.
Questions
What do you see happening here?
What’s your reaction to it?
How could it be prevented?
Let me know and I’ll share the responses to the list, so we’ll all learn together.
Best,
Marcus
You may also like...
Regardless of if the rest happened, the initial answer to the question is terrible. It doesn’t teach the coder anything and teaches them to simply ask you what to do whenever they have a question. I think there are two potential approaches here depending on how important this feature is and how important time vs. development is. Ideally, you wouldn’t answer the question, you would ask them another question to make them think about it. Still guiding them to the answer with follow-up questions, but forcing them to think about it and hopefully training them to be able to think it through and make a similar decision again down the road. If you don’t have time for that, at the very least the answer should be “my opinion is it should go in the OrderUpdate class, because [logical reasoning here]”. Even then you should be fostering an environment where your employees should feel comfortable challenging that suggestion and really thinking through your reasoning rather than tuning out once they hear OrderUpdate.
The next thing wrong with this is that two days went by, your employee made a lot of major changes to the structure of the code, and they waited until you asked for an update. That’s not how that should work. There should be open communication lines and if major changes are being made, she should at least be alerting you and other members of the team. It’s a fine line because some people can see that as asking permission and you need to not micro manage too much, but as a leader you need to foster an environment where your employee feels comfortable either dropping by or sending you an IM saying “hey this is a bit tougher of a change than I thought, I’m running into roadblocks x, y, and z, my eta is next week now instead of this week”.
And then finally, and this goes back to the first part, you need to foster an environment where people trust and respect your expertise, but realize you’re a human who can be wrong. A good leader is extremely humble and always asking more junior employees to suggest ideas to change the way things are done. Because often they’re the ones who are the least entrenched in the current system, and can see the forest rather than the trees. My current employer actually regularly swaps developers between projects in order to still maintain some expertise but also continually introducing fresh eyes to projects and the expectation is if you’re new your job is to not only learn the project but also think critically about some of the ways it could be improved.
Great analysis, Zach!