Best practices for coding in ML/DS -  Techniques to construct your project

Mher Khachatryan

1

About Me

• BS in Physics, MS in ML
• Ongoing PhD
• Experience in Data Science, CV, Gen AI Engineering,
• Senior Software Engineer @ 10Web, Researcher @ ICRANet,
• Ex-Krisp, Ex-Metric

Define your problem

​

One time code for tiny problem

​

Project with long lifecycle

​

3

Define your problem

​

One time code for tiny problem

​

Project with long lifecycle

​

4

If you want to be efficient in the long run, you gotta be slow

5

6

What does poor design/code lead to?

• You and your coworkers don't understand how your method works. 

7

What does poor design/code lead to?

• You and your coworkers don't understand how your method works. 

8

What does poor design/code lead to?

• You spent more time on debugging than problem-solving. 

9

What does poor design/code lead to?

• Onboarding new member is painful for him/her.

10

What does poor design/code lead to?

• Developing new features, improving model becomes harder/expensive

11

Developing new features becomes harder/expensive

​

12

Developing new features becomes harder/expensive

​

13

What does poor design/code lead to?

• Experimenting with new models become slower

14

What does poor design/code lead to?

• You lose track how your model worked fine.

15

Don't Panic! ��There is a solution

16

Write code for humans

• Don’t have variables named `x`, `var1`, `foo`
• Have short enough but self-explanatory variable names
• Generally variable names do not take any memory*

*In Python they take but negligibly small

17

18

Write code for humans

• Try to explain your code without comments
• Put comments only where necessary 

​

19

Write code for humans

• Write docstrings
• Type checking via various IDEs. 
• Explaining your code in detail.
• For future, automatically build project documentation
• Different style for Python

20

Write docstrings

​

21

Write docstrings

​

• Auto documentation from docstring https://www.mkdocs.org/

22

Jupyter Notebook is evil

23

24

Use IDEs

PyCharm CE, Free

• Type checking 
• Autocomplete 
• Realtime linting
• Refactoring
• Debugger
• VC
• Terminal, Python Console

PyCharm Pro, Paid

• Everything on CE
• Jupyter notebook
• Database tools
• Remote development
• Scientific view

​

​

25

Use IDEs

VS Code

• Type checking 
• Autocomplete 
• Realtime linting
• Refactoring
• Better Debugger then in PyCharm
• VC
• Terminal, Python Console
• Remote development
• In-app tensorboard

DataSpell

• Everything on PyCharm Pro
• Better Jupyter notebook support, remote local
• Remote development
• R console
• Scientific view
• You can divide .py file to cell-by-cell running parts like in notebooks.

​

​

26

Use Version control

• To have backward-compatibility 
• Write long, understandable commit message
• Commit as soon as you make important change
• Use gitflow, or other convenience
• Don't commit on master

​

27

Make your experiment reproducible

28

Make your experiment reproducible

• Fix seeds/randomness
• Fix versions, have setup.py or requirements.txt 
• Have one input file for parameters/configs (yaml, json, .py of constants)

​

29

30

Logging/Debugging

• Be proactive, use logging/debugging
• Do not use prints
• Use python logging module
• Log your model results, intermediate steps, metadata.
• Some cool tools
• https://aimstack.io/
• https://neptune.ai/  (for jupyter notebook funs)
• https://wandb.ai/site
• https://mlflow.org/

Choose your weapon 

31

Use principles

• Have software design
• Use modules and functions for one purpose only (Single Responsibility Principle) 
• Don’t repeat yourself (DrY)
• Follow guidelines (PEP8 or yours)
• Avoid creating tech debt as much as possible
• Read about design patterns
• Read Clean Architecture

​

32

33

Think iterative

34

Define your problem

​

One time code for tiny problem

​

Project with long lifecycle

​

35

Thank you!

​

Q&A

36