在毛象上刷到一条推荐这个reddit上关于junior dev求助的帖子:



❝When I hire a junior dev, I'm not looking so much for experience as aptitude. I know you are not going to be a full contributor immediately. I do not expect you to refactor the codebase your first week. I'm looking for someone who thinks the right way; I'm gonna teach you what you need to know.

The first few months are literally just training you on how our huge architecture and millions of lines of codebase works. You'll work with a variety of our senior devs and team leads on tasks that introduce to you our workflow. If the timing works out, we send you to a conference or two, usually with some strong suggestions on which panels to attend.

The fact that they're giving you training is a positive! Why would I invest time and money in training someone I didn't think had potential? So they obviously see something in you even if you don't entirely see it yourself.

The point is, we don't expect our junior devs to be full contributors until about six months in. We don't even count them into our sprint calculations until about month 4. It may be more than a year before they are fully confident in working on their own.

The other thing I try to do is give constant feedback to our juniors so they know where they stand. It sounds like this might be where the disconnect is for you. I was having a beer with one of our juniors at a conference a few years back and he opened up about how he thought he was so far behind and was thinking about quitting.

I was like, "Dude, you're doing fine, you're right where you're supposed to be." He looked like he was about to cry and the world fell off his shoulders. Since then I try to check on in juniors weekly or so just to reassure them that they're doing okay and/or provide feedback, although I will admit to being lax about this recently because I've been slammed. So maybe ask your peers for honest feedback.❞

❝Communicate. Ask questions. Restate things to make sure expectations are clear. When you realize something is wrong, give a status update. Your manager/lead/project manager will be much happier to hear, "this looks like it might take twice as much time" with a week to go rather than, "I only got halfway through this effort."

Set a time limit for how long you are willing to grind on a given problem before asking for help. This is something our organization just implemented per scrum team because even experienced developers often don't know when to ask for help.
These things can help you find a better solution you might be missing, or alert the entire team to a big problem they may be able to avoid. Even if nothing can be done to fix a 2x increase in dev time, at least people know.

Be kind. To yourself and others. We all have different experiences and strengths. People have wildly different feelings and reactions to asking for help, to being helped, to learning something, or to being corrected, so don't beat yourself up or berate others for not knowing something. Even things that seem like basics might be foreign to someone who transferred roles or doesn't work in a language as often.

Sometimes we just need a fresh perspective to get un-stuck. Sometimes there's some crucial knowledge we had no other way to acquire. Sometimes we make a mistake or an assumption. Nobody is perfect or infallible, so don't expect it from yourself or others.❞

Sign in to participate in the conversation
呜呜 w(> ʌ <)w

一个 泛ACGN 实例,讨论主题不限 ~