My question is: in this scenario what would you do, and why? Do I take the extra step and walk them through the entire testing process pre-emptively, or do I let them own their change and potentially experience the pain of breaking production?
This isn't a critical question for me I'm just curious to get a few takes on it. It's really a question of letting a developer pick up experience the hard way vs not throwing them to the wolves (which can lead to worse outcomes long-term)
Imagine you're new to a codebase, you're struggling to make it work. Unbeknownst to you, you're about to cause a production outage. Someone more senior at the company, the domain expert in the new thing you're using, notices you're struggling and decides to sit there, let you flounder and break production. It might not be a big outage, but you'd feel pretty bad and unsupported by your team.
You can see something bad about to happen, your instinct shouldn't be to do nothing to teach the person a lesson. You owe them the professional courtesy of offering a guiding hand.
For anything you/team create that is used by someone else, you have a responsibility in making sure it can be used effectively. There’s no excuse to drop a cryptic magic solution in the code base when you know no one else will understand it (not that you have done, just example)
At first its hands on help, after you know what people need to get working with it, pop the common things into a doc and point people at it when they ask for help. adjust doc if insufficient.
lastly always ask people you’re mentoring what their preferred way of learning is: some people learn by being shown and explained, some by guided “doing”, some by solitary exploration. Ask them how best you can support them. (some really Juniors won’t even know this, you may have to let them introspect about this first). it’s as simple as “before we get into this, how do you like to learn?”
"Hey, I think this will break if XXX happens (provide an example if you can). Can you please take a look before merging? Let me know if you need help".
I'd say that to any colleague (and hope they would to me) if I found a bug during code review, regardless of their team. I mean, it honestly sounds pretty routine and is the whole point of code review, no?
It doesn't mean I'm mentoring them or vice versa, and it's not a power play. It's just normal review in the line of normal work, peer to peer. It's fine that you're more experienced. We all start somewhere, and at some point, he'll be more experienced than you about some particular part of the code base, but your careful eye and constructive feedback is still valuable regardless. I don't see the problem.
Is there some context I'm missing?
Instead, email and recommendation they review with their mentor and ask who else should be cc'd
This and similar approaches would:
- gives them a hint + permission to gain informed mentoring on their team
- if their team refuses, reveals to them an "oh no", and documents it for the company
- keeps you unburdened. you only have so many mentoring hours before it flips to priority inversion, and your hours are likely more valuable to the company mentoring staff closer to you, e.g., inheriting your own code.
- no effort
If the situation repeats, privately escalate to your manager and make their problem because... their job is to shield you from such politics
A friendly version is try to help to agree informal rules, for example "add at least three test cases in each change".
Do you have a test suit for the app? Is it an UI app or a CLI app?
What you have here, basically, is a customer abusing an API. This is extremely common: mental models of systems differ greatly, and 'getting things to work from my side' will always take precedence over 'making sure I'm not missing an alternate understanding of the bigger picture'.
But one, possibly easy, thing you can do, is make the API more abuse-resistant. Add rate limits on expensive operations that should only be used seldomly (which may be hard in the case of "a SQL object", but still), just deprecate and/or hide such functionality completely, or add convenience functions that automatically do the right thing, and promote those.
If you do decide to reach out, make sure you very clearly describe the issues you've observed in a strictly technical way ('Hi, I noticed you're creating lots of Customer objects, which is really expensive since there are manual checks by various departments involved with that later on') and clearly outline solutions ('What you might want to do instead is only create Branch objects, which are basically what you want anyway and much cheaper and bore performant').
And be mentally prepared for not getting any response, them turning things around and responding that you are the one who's wrong, or even them running to their manager telling them you're impeding their progress by having way-too-hard-to-use systems. And just shrug that off, after briefly considering whether they may have a point, and making things better, for everyone, just in case they do...
The goal is to boost both their confidence and independence. The stretch goal is to reduce risks and not have to get other people, including yourself, involved in future efforts.
But almost definitely I would not sit idly by.
That conversation alone should give you a good hint of what to do next.
now i’m not suggesting you turn this into a full-time thing but it wouldn’t necessarily be too unusual for you to spend an hour call with this person to help them along a bit.
if they seem like they’ve got a good head on their shoulders you could even turn it into a regular cadence even just for career advice or something. could be monthly, quarterly, etc.
A short mail mentioning what you intent and asking for permission is enough
Mentoring is not training.
It is a commitment to long term interest in their career development.
It is big picture, not test procedures.
Good luck.