Ask HN: How do you help your team “level up”?

Personal growth is something you really have to do personally. In my team the developers are supposed to volunteer to work on stuff they have not worked with before.

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.

Secure a member budget for online classes (e.g. Coursera), conferences and books. Have them do presentations on various subjects related to their craft (new things they've learned, new frameworks), add standards (coding, testing, linters, etc.) to the team's workflow, send them to conferences and have them do presentations on what they learned and how could help the team grow, etc. Voice your concerns, ask them to participate. Remember that ppl have difference backgrounds and learn in many different ways.

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.

I help them by bringing forth best practices. What is the state the project should be in? How do you get it there? How is logging, metrics, alerting, ci/cd (roll out and role back), tracing, performance monitoring, system level testing, unit testing, etc. Is there application state that can be removed? Can code reviews be improved? Auto remediation on alerting? Techniques for better project management. Maybe there are new packages or libraries that the team should investigate. Give projects to team members that require them to grow a bit, including presenting knowledge gains to others. There are few teams and projects where that is all perfect.

A few thoughts, as a CTO with a small team:

- 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.

I think one of the most valuable things a team can do to grow each other’s skill is to practice good code review.