The world’s leading publication for data science, AI, and ML professionals.

Clean Code for Data Scientists

Part 3 - Teamwork

Part 3 – Teamwork

If you’re a Clean Code enthusiastic (and frankly, how can you not be?) and you work in a team, this is the place for you. When working in a team, each has his own notion of how to write code, his own ideas on what is clean code, and whether or not we need it (but you know the right answer, yes?).

When we’re part of a team, we usually share our projects, our repository, our helper functions, and tools. Also, we might use someone else’s code or deal with a bug in a team member’s code right on the day he’s called in sick. Meaning – we need to feel comfortable with all of our team’s code, not just our own. One of the best ways to help you understand your team’s code and feel comfortable with it is to make sure you all use the same language – clean code. Whether you’re a team leader or a team member, you can start the clean code revolution!

Spreading the clean code word

How do we make clean code part of our team’s core values? How do we create coding standards that make it in the long run?

1. Share the WHY

The first step, kind of like the first part of this blog series, is to make sure your teammates understand why it is so important to write clean code as data scientists. Many data scientists don’t come from computer science backgrounds (as am I, guilty as charged), so they might not be familiar with this topic or feel it’s unrelated to their work.

Understanding the motivation is crucial for writing clean code (and also, in general, as data scientists). If people don’t understand the why, not only will they have less motivation, but they will also not write the cleanest code. Writing clean code requires you to understand the logic behind it – for example, we write meaningful names to make our code readable and create accurate expectations when reading it. Without understanding the motivation, you can’t tell whether you wrote clean code or not.

2. Match your expectations

In real life, most of these efforts fail due to implementation difficulties. Either you or one of your team members have probably had a failed attempt at writing clean code as a team at least once.

One of the best ways to make sure these efforts will not be in vain is to set expectations. Make sure your team members and managers understand that it’s a lengthy process (months), it tends to have temporary regressions (around release dates for example), and it slows down the development in the short term. It’ll take time and patience until all team members are aligned and the code will slowly become better and better.

Only once everyone is aligned on the importance of the matter, and we set our expectations from the process, we can get to work.

3. Write down guidelines

Schedule a meeting with the team and write down your own team’s guidelines for writing code. As the ambassador of clean code, it is recommended that you’ll come prepared with suggestions. Then, go over these suggestions with your team, discuss, and decide which ones you want to adopt. A written, short, saved, shared document will make everyone committed to those guidelines, and enable them to go back and read them if they need a reminder. Plus, it’s a great document to add to your onboarding plan, when a new team member joins in the fun. Just make sure it’s not too long (no more than 5 pages), divided into meaning subjects, and written in bullets, so it won’t become hard to read.

4. Suggest a recurring coding session

You might find that this guideline meeting with your team was too short to squeeze in all of the clean code practices you had in mind. Or you might find that you want to discuss other day-to-day protocols, like working with Git, models versioning, working with notebooks, etc. This is why I recommend turning that meeting into a recurring one. It doesn’t have to be once a week, it can be once every other week or once a month. But having a place to discuss code protocols is a great gift you can grant your team. If you happen to run out of topics (unrealistic, I know), you can always grab a piece of old, messy code and refactor it together as a team. You’d be surprised how fun it is and it can bring up further issues to discuss.

5. Code reviews

Another very common way to ensure your team is writing the neatest, cleanest code, is with code reviews. Check each other’s code, make sure it follows the guidelines you had in mind and discuss any mismatches. This process is crucial to make sure you’re all still aligned. Those code reviews could also lead to:

  • Updating the guidelines document if needed
  • Discussing frequent mistakes in one of your recurrent code sessions

Not every piece of code you write needs to go through the code review process (depending on your team’s policy, of course). If you feel, as a team, that code reviews take up too much of your time, you may choose to do code review only for the more crucial parts of your codebase, and not every time you update it. Instead of having a mandatory, burdening process, it’s better to perform fewer code reviews and make them meaningful (actually learn from them).

By the way, if you want to make sure your code is really clean and readable, it’s recommended to just send it to your colleague (using pull request or any other method you wish), without any prior conversation. Don’t tell them where to look, what your code does, what part you wish to improve – let them be the judge of that. It’ll make your code review more objective and will serve its purpose – to check whether your code is readable for anyone, anytime.

6. Pair programming

"Pair programming is a development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently". (Wikipedia)

While pair programming might seem highly time-consuming at first sight (as two team members work on a single task), it is also a great way to enhance your coding skills. When you code with a colleague at your side, they constantly bring up issues you have not thought of and enrich your clean code way of thought. Try to incorporate pair programming in your work processes every once in a while, you won’t regret it.

To sum up, if clean code is important for you, you should aim to make it a daily habit in your team. Explain the importance, determine guidelines, try to schedule a recurring meeting and make sure you’re having enough code reviews as a team. If you have more ideas, please share them with me, and let me know how it works for your team. Good luck!


Related Articles