Description:

Code readability is one of those best practices that are difficult to sell. Even if experienced developers understand its value, it is not easy to convince everyone of its importance. For instance, there are no leetcode-like initiatives for clean code. You’re not likely to see job posts which emphasize readable code (or even have it in the “good to have” section). So it becomes difficult to convince novices to start investing in the readability of their code. On the other hand, it is also not always easy to justify to managers and business stakeholders why a developer would take more time to make their code more readable. After all, it’s not like readable code delivers more features, or is necessarily less buggy. Like all other best practices, code readability is something we all aspire towards, but few of us would prioritize it over deliverables.

There are some axioms of code and it’s maintenance that we all hold sacred. The greats of our discipline - people like Fred Brooks and Uncle Bob, for instance - have written entire books about these axioms. We also know a few things about knowledge workers and their productivity. But despite our best intentions, even the best of us often run afoul of these “laws”. Consequently, we, as programmers, are often faced with a difficult choice:

Do we double down on best practices and guard them like zealots, or do we embrace the chaos that is inherent in software engineering and make our peace with it?

To most of us, this is hardly a difficult choice. But there are no atheists in foxholes. As deadlines knock our front doors, idealism and best practices have quietly escaped through the bathroom window. We have all been in situations where we have merged smelly code because the bugfix was overdue, where we have put off refactoring a module because it would block other developers, who have only just figured out how to use it. It’s common to abandon a well-meaning process in a crisis. The choice between what is right and what is easy becomes more and more difficult. Fortunatey for Pythonistas - it's not so bad.

In this talk, I’ll show with data why readable code is one of the most effective levers of overall code health. The talk essentially shows:

• that code readability implies modularity, which in turn implies testability, and has the highest impact on overall code health.
• how good programmers communicate their intent
• that everything you code is someone’s API
• how LoC is the most important metric of code health - less is better.

Through this discussion, we will distill the insights into a process for writing and maintaining readable code, and how to make this process easy to adopt and teach.

Prerequisites:

• Elementary knowledge of any programming language - as long as you know what variables, functions, classes and modules are, you'll enjoy this talk.
• Some experience of working in teams of any size - as long as you've worked with at least one other programmers, you'll enjoy this talk.
• If you've had to talk about your code in natural language - either in emails to clients or managers, or to your collaborators in git commit messages - you'll enjoy this talk.

Content URLs:

Here's the blog-post which inspired this talk: https://jaidevd.com/posts/code-readability-process/

Speaker Info:

I'm Jaidev. I'm a full-stack data scientist based in New Delhi. I currently work as Director of Technology at Gramener. I focus on building data-driven applications and the tooling around ML systems. I also teach statistics, linear algebra and ML (with Python) at various places.

I'm more or less a permanent fixture at Pycon India. If you're a regular at FOSS events too, there's a good chance we've met :-)

Speaker Links:

• Talk at PyCon India 2016 - Continuous Integration for Data Scientists
• Talk at PyCon India 2019 - Natural Language Generation with Python
• Website: jaidevd.com
• Recordings of previous talks