I’m coming out: I’m a terrible trainer. Or rather, I think I would need to devote all my time to it in order to do it well. Otherwise, I can only achieve poor results for the learner. That’s why I want to draw up some guidelines that you might find useful. The first rule is never falling in love with your study method.
All People Are Different
I know it’s trivial, but truly accepting that we are all different is not at all obvious. I’m probably neurodivergent and have suffered from this problem for years, but that doesn’t mean I haven’t behaved the same way towards others. What applies to me doesn’t necessarily apply to others.
This means that, even though I tend to be independent in my learning process, others may have different needs. I think I failed with the last colleague who joined my team, even though I wasn’t responsible for him, because I applied what would have worked for me. I don’t want to repeat myself.
I’m not a trainer by profession. I occasionally have to train new employees, but I have no formal training as an educator, so what I do is showing them how things work. And even that is wrong, because it should be done by a professional: being the son of a middle school teacher does not help.
Document All the Code You Write
Even if it seems silly, it must become a mantra: document all the code you write. The only reason you would not do so is if you have already resigned: it’s not professional, but I can understand why. In all other cases, you have no excuse and should consider it part of the job.
Neither project managers nor the sales department will like it, but writing documentation should be included in your estimates. You are a developer, and the quality of your work also depends on the quality of the documentation you produce. If you do it quickly and poorly, you are not a good developer.
Why would being a good developer have anything to do with onboarding a new colleague? Simple, if you’re not, everything will go wrong. You can’t teach someone else what you don’t do yourself. So, becoming a better professional helps you be a better teacher as well.
Set Clear Guidelines (and Follow Them)
Big companies already have their rules, or at least they should. This is not always the case, and problems may arise in the case of corporate mergers. For example, a new company in the group was using Mercurial. We’ve always used Git here, but in the past, they switched from Bitbucket to GitHub.
The merger was also an opportunity to review the tools used for CI/CD. Specifically, we moved from Lerna to GitHub Actions: the key, in my opinion, is to maintain a consistent ecosystem. It makes no sense to use tools that belong to different suites, often competing on the market.
Of course, this doesn’t just apply to DVCS. The choice between Amazon Web Services, Microsoft Azure, and Google Cloud Platform should also be consistent. To be completely honest, I would choose a business email provider with the same logic. I don’t see the point, for example, in having Microsoft Teams and using Zoom.
Provide Tools to Stay on Track
Many, if not all, development teams typically equip themselves with tools, such as IDE extensions, to normalize their code. Ours has never done that, and it’s something we’re trying to change, but it’s not that simple. Especially when team members come from different companies.
My boss has an IntelliJ IDEA license, while I use Visual Studio Code like most of my colleagues. The newest member, however, has a laptop with Ubuntu, and we’re on MacBooks with macOS. I still haven’t figured out what the next company computer setup will be, and that’s a bad thing.
However, when speaking of tools, I am referring rather to linters and extensions for more or less automatically producing inline documentation of the code. Here too, very often everyone uses what they prefer. I think this is also an area that needs improvement, because in the long run it can become a problem.
Transform Best Practices Into Imperatives
Last but not least, best practices shouldn’t just stay that way: they should become a must. We need to take everything that has proven positive, document it, and make it mandatory. There should be no room for “creativity” unless there is a discussion and a finding that an alternative is better.
It’s right to propose new ideas, but not when these involve a disadvantage. There is also the opposite problem, which is making the mistake of falling in love with what you think is right for you. You may be handling a situation poorly and not even realize it. You have to find the right balance.
It happened to me with vibe coding. I would never have wanted to adopt it in my company, but, within certain limits, it can be helpful. The important thing is not to make it the first solution to problems, because the risk is that productivity will worsen. I’ll let you know how it goes.
You won’t believe it, but where I work, people do things in Python that have already been done in JavaScript, and vice versa. It’s just a challenge to see who can do it better. But we are talking about product development teams that should not be antagonistic. I find it quite childish.
Top comments (0)