We organize biweekly talks about various technical subjects. And while these are fun to do, I'm not entirely sure that this approach will scale as the company grows.
How do other lead engineers help their team grow their skills?
Thanks!
NOTE: None of the above should be done if the employers free time, except from the Coursera classes ofc which the company will have to pay if the team member agrees. A team needs to have at least some time per month spent in personal development, where you need to combine what everyone in the team likes with what is useful to the company/team. All the above needs to be decided on a team level, but as a leader you can drive the discussion.
We need to update our deployment pipeline and you have never worked with AWS before? Go for it!
Once they do, you can always do a bit of pair programming, but nothing really helps you grow more than the hands-on experience.
- not everyone needs the same leveling up, and it’s not always technical. I coach one of my junior dev on improving his code, another one in being more confident of her skills. My lead dev is solid on code but doesn’t always take into account the business perspective (i.e. in which context the code will be used, how often, etc)
- my main method of coaching is to ask a lot of questions. How do you plan to implement this feature? Why this way? What’ll happen when <edge case>? Why did you choose this architecture? Have you thought of <situation that’ll result in a bug with the current implementation>? Whenever possible, I don’t say how it should be done but try to bring them around to figuring it themselves. It’s not (always) leading questions, either. I’m not cross-interrogating them, just trying to understand what they did and why
- closely related to above, I let them make their own mistakes. Rather than try to convince someone that their approach won’t work (if the round of questions isn’t enough to clarify this), I let them go ahead. They either figure out on their own that they made a mistake (and then they’re open to discussing alternative solutions), or when the code has become complex enough I ask them to demonstrate a few corner cases. When those fail, sometimes hilariously, we can go back to the design phase. I try to balance how long to let them flounder between “long enough that they learn something” and “not so long that they bear a grudge for being played”
- refactoring their own code (for junior devs). I ask them to come back to a piece of code they wrote mostly on their own, a few months after they’ve worked on it (e.g. something they did as an intern, or one of their first projects). Can you figure out what your code is doing? Hmm, guess some comments and clear method names would come in handy now! How would you do things differently in hindsight? How would you reorganize your code? Once the code is refactored, a before/after comparison to highlight how much better the new code is.
- I’ll sometimes point someone to books or articles and ask them to read it, when I want to make a specific point. E.g. I asked a dev who wrote some very stateful js (lots of methods without a return value would would manipulate global variables in weird ways) to read Learn You a Haskell for Great Good to get him to think about side-effects and how to avoid them when possible.
- I haven’t done this yet, but I thought about a team code advent where everyone would solve the same problem in the same language, and we would compare solutions. This implies setting out some time each day for everyone in the team to work on the problem, so needs a little bit of planning and finding the right time.
I realize that most of these ideas are time consuming, both for me and for the developer. It would be much faster to just tell them how things should be done (at least how I want them to be done), or to point out the mistakes as I see them unfold. But I believe that teaching a man to fish is a much better long-term solution than giving him a fish every day.