Clean code isn’t just a nice thing to have or a luxury in software projects; it’s a necessity.

If we want our project to successfully deliver features constantly at a steady and predictable pace, then having a good and maintainable code base is a must.

The true nature of clean code rely on the fact that other practitioners should be
able to read and maintain the code.

Read the book Clean Code in Python, Second Edition, to know all about idiomatic Python, see the difference between good and bad code, and identify traits of good code and good architecture.

There is no sole or strict definition of clean code. Moreover, there is probably no way of formally measuring clean code, so you cannot run a tool on a repository that will tell you how good, bad, or maintainable that code is. Sure, you can run tools such as checkers, linters, static analyzers, and so on, and those tools are of much help. They are necessary, but not sufficient. Clean code is not something a machine or script can recognize (so far) but rather something that professionals can decide.

The interview in detail:

1. To what extent can the inability to write efficient code harm/affect an organization/software? 

In my experience, inefficient code can be so dangerous as to paralyze entire projects. I’ve seen services that needed to be re-written because of how unmaintainable they were. At some point, it became impossible to keep on making changes to that API, and the issues kept piling up, so it needed to be replaced by a brand-new system. 

On another occasion, there was an application we knew had problems because of the way it was written, and its instability was causing frustration in customers, which permeated into the company. The buggy nature of the application wasn’t separate from the way it was written, rather it was the consequence. Customers were complaining about quality, and this shows up to which degree technical debt can harm an organization. I’ve seen this pattern several times, when the company must make the hard decision of stopping the release of new features to fix errors in the software. 

2. What should developers keep in mind while starting out with legacy systems? 

First to identify the degree of technical debt accrued. There are good software projects that have been designed correctly and their technical debt is relatively low (perhaps it’s just about updating some libraries to newer versions or moving parts of the code towards new features that weren’t available at the time it was originally written). 

In the event of having a lot of technical debt, it’s important to understand what’s the most critical part that needs to be fixed. There’s certainly a part in the code, a module, or a functionality that’s responsible for most of the complaints from customers, and that’s what needs to be refactored more urgently. 

It’s critical in this sense to do a proper analysis and have a plan about the improvements to make in the code, rather than jump straight to the code and start refactoring. This will help give a clearer idea of what needs to be changed, and the degree of the refactor needed. Meaning, if we’ll be fixing the code, or the situation requires a full rewrite. Generally, completely rewritten the application should be a last-resort kind of decision, although there are some obvious cases (for example, if the application was written with Python 2, then it’s clear that all the code will need to be changed). 

3. What are the future advancements that you anticipate in Python? 

It’s hard to know for sure what will happen with Python in years to come, but it’s interesting to see that in a similar way Python took inspiration and features from other languages, it’s now inspiring modern languages as well, but it also catches up with new features and programming models. Such was the case of all the improvements made for asynchronous programming, incorporated into the standard library. 

I believe the asynchronous programming capabilities will continue to be enhanced in future releases. 

I have also noticed some improvements towards trying to make Python more efficient, whether this means having a more lightweight interpreter by reducing the number of packages in the standard library, to try to solve the GIL problem. These are the kind of improvements I’m more hopeful to see. 

4. What are some of the popular myths around writing clean code?  

Perhaps the most common misconception is that clean code is about formatting code, or maybe even about PEP-8. In fact, relating technical debt only to code issues is another popular myth. Technical debt, is also about technology, being caught up with dependencies. 

Being able to update your dependencies quickly in case there’s a security issue, it’s also a concern related to technical debt, and therefore to clean code. Things like the speed of iteration, how fast and frequently deployments can be made, the adaptability of the architecture, play an important role in the success of the project. 

5. Tell us about your book, Clean Code in Python, Second Edition. What trajectory does your book follow to help its readers develop maintainable and efficient code? 

The first chapter starts with an introduction to the importance of having a well-structured code base, presenting a framework for the chapters to come. This is supported by tools, and recommendations on how to setup a project for success, considering automated tools that will help us format the code, and setting up a pipeline to effectively deploy our code with good quality gates (controls, tests, different stages). 

Then, the book introduces some Python-specific concepts, making strong emphasis on the particularities of Python’s syntax, and a more succinct way of writing code, taking advantage of the features the language has to offer. 

There are some chapters that revisit general design ideas from software engineering, like object-oriented design and design patterns. From that point, the chapter will explore topics of software engineering in terms of how they can be implemented in Python, using the particularities of the language itself. 

The idea of the book is to provide readers with the tools and concepts for them to understand what clean code means beyond any definitions given. It’s a pragmatic book; oriented towards a practitioner’s audience, so it makes special focus on how to get things done in an effective way, which often means accepting tradeoffs. 

6. Does your book provide hands-on scenarios to practice the techniques it teaches?

Absolutely! The book has a very pragmatic, hands-on approach. As each idea is introduced, it’s followed by examples that demonstrate how that implementation would work. Moreover, I’ve put special effort into making the examples as realistic as possible. Considering that the examples need to showcase an idea irrespective of superfluous details (that is, leaving out everything that’s not relevant to the explanation being made, and isolating the problem at hand), they’re still real-world scenarios, pieces of code any reader can relate to their daily job. There’re no made-up examples like Fibonacci-series or things anyone wouldn’t normally find on real code. Extrapolating from the examples, readers can use the code as reference to solve their problems. 

To practice more, there’s a Github repository where all the code from the book lies, and it’s constantly updated. There’s also a Docker image for the entire setup of the book, with the environment already configured, that readers can use to test the code, and learn by modifying it.