Hey, I just found your LinkedIn Profile and noticed that we studied at the same university - even the same degree! I've send you a request on LinkedIn, so maybe we could connect and have a chat?
Thanks for sharing this with us. This advice (change from being a shooting star to helping others to improve) seems to be in contrast to the article. Or am I missing something?
Thank god for this article. I'm a new tech lead with 1 person in my team. This person is even from a different country, new to the industry and not that advanced in his programming skills. I noticed everything this article describes.
Although everything gets better day by day, week by week, it is still difficult and I sometimes even have the feeling "damn, do I really want to be a tech lead?"
There are hundred ways that you would have written any piece of code differently than your mentee. And if you correct all of them you will both be unhappy and unproductive. There are truly amazing coders who code differently than you or I. Focus on issues that materially affect the application(correctness, reliability, performance, security, reliability, maintainability - less important than the other) and give clear explanation of why you're making the critique and how it affects the application.
Also remember you're a team, and he wants the application to be awesome too. Approach critiques with "here's a way we can make the application faster" as opposed to "you wrote slow code".
Document every critique you make to create a code guidelines document. This will help anyone else who joins the teams, and will make your critiques feel less arbitrary, and help them remember and be able to lookup your critiques.
Make sure you have a standup every day to watch over their progress and code.
It's really easy to focus too much on getting your own work done and slack off as a tech lead or mentor. Always prioritize your mentee's work over your own. Don't start your work until you've set him up for success for the next few days. (code reviews, making sure he has work lined up and understands what he needs to accomplish and how he needs to accomplish it)
Maintain a positive attitude, remember to compliment them, err on the side of over complimenting than under complimenting.
Don't be afraid to ask for their advice or for them to do research.
Expect the quality to not be up to what it would be if you wrote it. Try to plan for this by increasing QA time, testing, and spending more time reviewing the parts of the applications where correctness is the most important. Also make sure to do performance testing in case he did something boneheaded.
Over communicate. Explain the why's of everything. There are 100 tech leads who under communicate for every tech lead who over-communicates. So chances are your team will run better if you communicate more.
>Over communicate. Explain the why's of everything.
I would like to second this, if your schedule allows it. Attempting to make sense of a large codebase (that likely has much domain-specific and even historical reasoning within) when you are inexperienced and/or new to the domain can be a much better experience if the information flows as freely as possible from the expert to the new person.
a junior-senior combination works well with pair programming.
i suspect your problem is that you can't yet judge what your junior is capable of, so you assign him tasks and then find out he is struggling with a task, or doing it wrong, and then you have to spend time correcting or teaching.
in pair programming these activities go hand in hand. you tackle a problem together. at first you take the lead, but ask the junior how he would solve it.
initially you drive (type the code) and he observes. once he has seen you code for a while, you can let him drive. as you work together you slowly learn about his abilities, and when tasks come up that you feel confident he can do by himself, then let him, while you bugger off to deal with your email.
depending on the nature of your work, you may need to spend some time doing managerial stuff that your junior can't help you with, or you have to attend meetings. (although for meetings about the code you write i'd take the junior along)
with only one person in your team i do hope though you get at least 50% of your time to code yourself, which you can use for pair programming. the other time your junior will spend on tasks on his own or learning something that you'll need next.
Junior-senior pair programming is different from managing one report, though the line is quite blurry. When I had a solo report it felt much more like a junior-senior pairing than being a manager (especially as it was their first eng job, and teaching them the basics was most of what I did).
Ultimately as a manager you're also evaluating their work and are in a position to decide things like if their employment continues, if they get promotions/raises, etc; that is what makes it distinct. Feedback in a junior-senior pairing is much more purely about helping them grow.
Dang though. 50% of your time to code... I'm an IC (as much as I want to be an EM) and that sounds really nice. I regularly have whole days where I don't get to code (in part because, as a potential future EM, I'm expected to mentor; I have 7 regular 1-1s, for instance).
how many people are you mentoring? obviously if it's more than one then you won't have as much time to code. i was thinking of the simple case where a team of two people is responsible for a single project. if one of them is the project manager, the other a coder, then the pm should not need all day to manage. unless of course they are at the kind of company that wastes everyones time with meetings and whatnot that prevents anyone from getting actual work done.
this is amazing advice. I figured this out the hard way as the manager just last week. Was initially apprehensive as I haven't done much pair programming before, but it was incredibly productive and my report loved it
not with a single report. the overhead is maddening. much better to have 2..3..4 where you can put them to plan/discuss/evolve solutions while you just update and evolve checklists. debrief daily, use their work. be consistent, write your own daily summaries for upstream. going from 1 to 4 should ~double the time you need while making you much more productive/deliver more comprehensive skills & results at the same time. make sure you get paid for keeping things on track while doing your usual! p.s./edit: four is a great size. 2x5 is the most i'd want to do. coordinate with hr but stay out of it.
OP here - glad that you enjoyed it, thanks for reading!
One thing I'll mention is that management is hard and largely a learned skill. I think of it like playing a sport. Some people are better than others due to innate ability, but everyone can improve with practice.
We've written / will write more on these sorts of topics if you're looking for more tips. Best of luck!
Hey, are there already some tutorials / books for Phoenix 1.3? I found this [1], but it will be released in late december 2017. Any ideas / recommendations for the Phoenix 1.3? Folder structure and models (schemas) got changed quite a bit.
Have a great day!