When you submit code to Zindi at the end of a competition, do you ever think about what happens next? Your code gets reviewed by our team of data scientists, and if you’re one of our winners, that code goes to the people sponsoring the competition - often a big corporate. Even if you aren’t in the top three you might want to share your code, so the rest of the community can learn from your work.

At Zindi, we see a lot of submitted code. Some of our users have been writing and submitting code for years. But for others, this will be the first time they submit code to someone else to look at. That means submitting your code to Zindi can be a great way to learn good coding practice for your future projects for clients! You also need to think about how to present your findings to clients, be that a technical data science team or non-technical upper management.

We wanted to give you some insider info, so we talked to Amy Bray, Zindi’s data scientist in charge of code review. Here she shares her tips about how to present to clients, and how you can make sure the code you submit is well organised, easy to read and run, and ready to be passed on to a client.

How to present your code to clients

“There are two types of clients you might present your solutions to,” Amy says. “Management won’t want to see the code, they want to know if your solution is cheaper, better, or faster to run. In this case, don't give them the code; rather present the challenge, include a slide or a few sentences focusing on the features you used, and then talk about implementation and value to the business.”

“When you’re presenting to a data science team, you should still include all the above information, but add more technical depth about the methods you used.”

You will likely need to hand over your code to a technical team. That means you will need good commenting, sensible variable names throughout the code, and correct file structures. A comprehensive README file is also helpful as a primer for those not familiar with the code or the project, and remember to add a requirements file with your package versions.

Do’s and don’ts of good submission

Something that you might forget when focusing on winning a Zindi competition is that winning submissions on Zindi go to real clients! We have submitted your code to companies like Facebook, Uber, and InstaDeep.

“Submit your code like you're submitting straight to the client,” advises Amy. “And the client may not have a data science team, so your code needs to be easy to read and understand even by a non-technical audience. You aren't presenting to your peers!”

A key part of good coding is your documentation: “Good documentation isn't commenting every line of code you write, it's explaining the idea behind each block of code that you write.”

Amy also recommends you use sensible names for your functions, so that it is easier to follow your thinking. Good documentation doesn’t even require perfect English - presentation and logical thinking is something everyone can do.

Some other pieces of advice and common mistakes to avoid:

• Remember that someone else is going to read and run your code
• Follow a logical code structure: import all your packages and data at the top, followed by exploratory data analysis, then define your functions clearly and finish with your implementation.
• Don't print out your whole data frame.
• Trial and error is a natural part of the process of machine learning, but your final submission should not include those efforts.
• Keep a logbook to remember your parameters for each submission, to make sure you include correct parameters for your final code submission. Pen and paper is a great first logbook.
• Try rubber duck debugging your code. What if you had to explain your code and ideas to a duck, or a school child? Can you do that?
• When using deep learning models, organize your code and in your README file be sure to specify the version and environment you are using.

Ultimately, as a professional data scientist, you should always be building good coding habits, and always take pride in your code.

Where to look for good code examples

Amy says one of the best places to start learning good practices is by looking at other’s work. Fortunately, Zindi is full of great data scientists, many of whom have excellent coding habits and are willing to help! We’ve collected some great places to start:

• Zindi user Simonjhb’s 8th place solution in the Farm Pin challenge demonstrates excellent documentation (GitHub repo). Look at how he explains the problem, then each main idea he explains. Note the file names and code structure. Look at what packages he imports and where, look at how he imports and exports files and to where. See how he has used sensible variable names and structured his thoughts into code blocks. (find him on Medium)
• Zindi user Steveoni has excellent code structure and is easy to follow (GitHub)
• Zindi data scientist Johnowhitaker creates many of the starter notebooks for Zindi competitions, which are a great way to learn good coding practice (Johno’s GitHub). He also writes fantastic tutorials on his blog (Data Science Castnet)
• We post all of our competition starter notebooks on the Zindi GitHub page
• Zindi ambassador and experienced data scientist Davisy writes excellent tutorials on Medium (and find him on GitHub)
• Zindi ambassador Thierno is an experienced data scientist with excellent coding practice (GitHub)
• Have a look at Zindi’s discussion boards, especially after a competition closes. Many data scientists share their code there. It’s also a great place to ask for help. You can post your code there and ask for feedback. Everyone started somewhere and would be happy to share their insights, lessons and resources with you.