How to work with your tech team and sustain its growth
A philosophy I’ve internalized very early during my studies and carried on as a developer and manager in IT can be summarized in the following sentence: work as if your team was five times larger than its current size (even if you work alone).
What do I mean by that? Imagine your team of 3 people as consisting of the three of you now, the three of you next week, the three of you in one month, three months, and six months. Then think of how you would manage things; you now have 15 people to take care of. Let’s say you have a technical task that you’re looking at right now, and ask yourself the following questions.
- Is what I want to do today it a one-time thing? Or is it something you’ll have to do again in three months? Once a week? Can it be automated? How time-consuming would that be?
You should ask this question, because when you can automate it, you’re asking all those other team members (the you’s of the future) to take that burden of the manual work as well when you take the decision to post-pone the automation. You need to decide if automating today is a good investment to make time for the rest of your “future team” (DRY, don’t repeat yourself), or if the automation would take so long to implement that you would just burden your future team with buying you the time to do that and maintain your automation once it’s complete (just do it; today beats tomorrow!). My rule of thumb is that you shouldn’t repeat something more than twice.
- Is your code still readable if you don’t look at it long enough to forget about it?
Because the person you are today understands your code, but in the future, you’re a different person in a different mood. Maybe you feel like cutting corners today, but next month you’re looking at this code between two meetings and you only have an hour.
And who knows what you remember from last time you looked at that code, let alone one of your (actual) colleagues who hasn’t previously seen the code. Should you have better documentation? Re-factor it a bit before committing? These things can make a big difference. It’s ok to cut corners before a deadline on these things with a “purity” flavor on them, but past the deadline, the first thing to do would be to clean up after yourself, a bit like after an online exam at university; take a deep breath, grab a beer, have fun, get a good night sleep, and the next day, clean your desk. Same goes for your code.
- Could I delegate the task of adding a new feature on top of my code to someone else without talking to them about the existing code?
Maybe you wrote the code so well with your own style and notes that you understand, that you think your code is great. But what if next time this code has to be modified, you’re on vacation and you don’t wanna get a phone call from your colleague asking for help?
That’s why it’s important to have conventions on how to write code. If you write code in your own way independently of your colleagues, it’s really hard to work as a team. Nowadays it’s also possible to encode these conventions in linters and parsers, that when combined with git hooks, prevent any code not satisfying those conventions from ever being saved in the repository.
I hope this gives you some ideas about how to take a decision of doing that re-factoring you’ve been craving for so long, fixing that bug that you’ve been working around manually for a few weeks, or maybe stopping to work on automating that unit test seeder if you might as well scrap the whole feature. Feel free to share some stories in the comments!
At Polar Squad, we share a lot with that philosophy, but we call it DevOps; the principles behind DevOps impact everything a tech company does, from feature planning to infrastructure, including deployments, team organization, etc. My colleagues and I share ideas like the ones in this article on a regularly basis. Stay tuned for more content about tech!