TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: A question about mentoring a junior developer

36 点作者 Desafinado2 个月前
So this is the scenario: I develop a SQL object which is being used by an application developer in an app I haven&#x27;t seen before. The developer is a junior and it&#x27;s clear that they have a poor understanding of the use cases they&#x27;re dealing with, and likely haven&#x27;t adequately tested their changes. This developer isn&#x27;t on my team and isn&#x27;t someone I&#x27;m directly responsible for mentoring. The application carries almost no risk if the developer breaks it, we can just revert our changes and no harm done.<p>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?<p>This isn&#x27;t a critical question for me I&#x27;m just curious to get a few takes on it. It&#x27;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)

24 条评论

RadiozRadioz2 个月前
Think about it from their perspective.<p>Imagine you&#x27;re new to a codebase, you&#x27;re struggling to make it work. Unbeknownst to you, you&#x27;re about to cause a production outage. Someone more senior at the company, the domain expert in the new thing you&#x27;re using, notices you&#x27;re struggling and decides to sit there, let you flounder and break production. It might not be a big outage, but you&#x27;d feel pretty bad and unsupported by your team.<p>You can see something bad about to happen, your instinct shouldn&#x27;t be to do nothing to teach the person a lesson. You owe them the professional courtesy of offering a guiding hand.
评论 #43218650 未加载
评论 #43241878 未加载
评论 #43240643 未加载
yarekt2 个月前
“Hi, I see you’re using &lt;SQL Object&gt;, I can give you some background information on it and help you get more productive with it”<p>For anything you&#x2F;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)<p>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.<p>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?”
solardev2 个月前
Why does it have to be either &quot;say nothing and let them break production&quot; OR &quot;suddenly I have an apprentice&quot;... can&#x27;t it just be a simple comment in the PR, as a peer developer?<p>&quot;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&quot;.<p>I&#x27;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?<p>It doesn&#x27;t mean I&#x27;m mentoring them or vice versa, and it&#x27;s not a power play. It&#x27;s just normal review in the line of normal work, peer to peer. It&#x27;s fine that you&#x27;re more experienced. We all start somewhere, and at some point, he&#x27;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&#x27;t see the problem.<p>Is there some context I&#x27;m missing?
评论 #43238499 未加载
lmeyerov2 个月前
There are times to do cross-cutting interventions, but this doesn&#x27;t meet the &quot;the CEO would be annoyed&quot; test<p>Instead, email and recommendation they review with their mentor and ask who else should be cc&#x27;d<p>This and similar approaches would:<p>- gives them a hint + permission to gain informed mentoring on their team<p>- if their team refuses, reveals to them an &quot;oh no&quot;, and documents it for the company<p>- 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.<p>- no effort<p>If the situation repeats, privately escalate to your manager and make their problem because... their job is to shield you from such politics
jasdi2 个月前
I would help them out without thinking too much about it. Its like helping a kid cross the road till they can do it themselves.
gus_massa2 个月前
A unfriendly version in al old post by Joel Spolsky <a href="https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2001&#x2F;12&#x2F;25&#x2F;getting-things-done-when-youre-only-a-grunt&#x2F;#:~:text=Strategy%204%20Neutralize%20The%20Bozos" rel="nofollow">https:&#x2F;&#x2F;www.joelonsoftware.com&#x2F;2001&#x2F;12&#x2F;25&#x2F;getting-things-don...</a><p>A friendly version is try to help to agree informal rules, for example &quot;<i>add at least three test cases in each change</i>&quot;.<p>Do you have a test suit for the app? Is it an UI app or a CLI app?
antithesis-nl2 个月前
Mentoring really only works if the junior person actively seeks out a trusted colleague, ideally in the context of a formal program (with clear guidance on expectations and such).<p>What you have here, basically, is a customer abusing an API. This is extremely common: mental models of systems differ greatly, and &#x27;getting things to work from my side&#x27; will always take precedence over &#x27;making sure I&#x27;m not missing an alternate understanding of the bigger picture&#x27;.<p>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 &quot;a SQL object&quot;, but still), just deprecate and&#x2F;or hide such functionality completely, or add convenience functions that automatically do the right thing, and promote those.<p>If you do decide to reach out, make sure you very clearly describe the issues you&#x27;ve observed in a strictly technical way (&#x27;Hi, I noticed you&#x27;re creating lots of Customer objects, which is really expensive since there are manual checks by various departments involved with that later on&#x27;) and clearly outline solutions (&#x27;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&#x27;).<p>And be mentally prepared for not getting any response, them turning things around and responding that <i>you</i> are the one who&#x27;s wrong, or even them running to their manager telling them <i>you&#x27;re</i> 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...
system22 个月前
Why is this considered &quot;mentoring&quot;? From what I read, you see an employee screwing up something and you have a chance to help your company before things go out of hand. Not everything you do at work should be considered mentoring. You can correct other&#x27;s mistakes or warn them before they cause damage. If the person wants a mentor or a senior to help them, they will ask.
bloomingkales2 个月前
You could ask them for help with a problem to break the ice. Something you don&#x27;t really need, that way you flatten the egos (just in case) and tacitly show that communication channels are always open, even for the smallest things.
austin-cheney2 个月前
Both. Give them an educational walkthrough of the system and concerned processes. Then let them know they can break things because you have showed them how to revert the damage.<p>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.
adonese2 个月前
In a somewhat big org with expanding in hiring. I myself am quite new (~ 6 months), and we have many teams working on a monorepo. It helps a lot when you spend 10 mins with a new joiner and just explain to them the overall process(s) and the exact issue: hey I noticed that the pipeline is failing perhaps you didn&#x27;t install a tool locally etc let me get this chance to get to know you while we go over this issue.
figassis2 个月前
Let them work for a bit to get their brain juices flowing, then point out the issues in their code review. If they need more help encourage them to discuss with you personally. Never knowingly let bugs go into production.
wruza2 个月前
In my experience, you want to advise, but not insist or work as a reminder. Tell everything not more than once-ish from &quot;if I was you&quot; perspective and whatever they pick up, the rest will be wolves.
jbs7892 个月前
I think it depends on the relationship with the junior. If you do have a level of trust, this wouldn&#x27;t be a question. If you don&#x27;t have a level of trust, then is there a way to build it quickly, so you can help them get to the right answer while they feel good about it.
iExploder2 个月前
I would take action, as to what extend I would give advice &#x2F; mentor depends on the person and the situation.<p>But almost definitely I would not sit idly by.
muzani2 个月前
Ask them if they want feedback. If they&#x27;re not ready for it or if they don&#x27;t trust you, it&#x27;s usually hurtful more than helpful.<p>That conversation alone should give you a good hint of what to do next.
therealfiona2 个月前
You help them out. They aren&#x27;t on your team, but you&#x27;re both on the larger team of your employer. You mentor them the same way you would someone on your team.
tbrownaw2 个月前
It sounds like there are bigger problems, especially if it wouldn&#x27;t be enough to just say &quot;hey, don&#x27;t forget to test for &lt;&lt;thing&gt;&gt;&quot;.
spike0212 个月前
it’s not uncommon for engineering orgs to have mentorship programs where mentor and mentee aren’t even on the same team.<p>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.<p>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.
DeepSeaTortoise2 个月前
Unless the junior reaches out to you, don&#x27;t keep those instructing him out of the loop.<p>A short mail mentioning what you intent and asking for permission is enough
giantg22 个月前
The root of the problem are the use cases. Why is there a poor understanding - poor requirements, poor documentation, etc?
rubenvanwyk2 个月前
Agree with others that helping a junior != mentoring. Mentoring is a bit of a strong word in this context.
brudgers2 个月前
Because good mentoring is an intimate relationship, talking with the junior developer is the thing to do.<p>Mentoring is not training.<p>It is a commitment to long term interest in their career development.<p>It is big picture, not test procedures.<p>Good luck.
Apofis2 个月前
Dude, your job is to mentor, so you mentor. You work for a company, and the whole company is also your team.