Helping developers with “No Bugs Project”

I’ve just finished the smooth reading of the book “No Bugs, No Stress - Your Step by Step Guide to Creating Life-Changing Software Without Destroying Your Life” and besides the really long name it has just a few pages, containing an amazing assemble of hints telling how to become a better developer.

Before start talking about the book itself, I would like to thanks its author Rafael Chinelato Del Nero, whose has dedicated his free time to present some techniques that are surely helping developers all around the globe. Along with the book, Rafael has the No Bugs Project that you can check, follow and share at https://nobugsproject.com/ (you can get the book for free at the same site by the way 😊).

Photo by David Iskander on Unsplash

Step by Step

The book has four steps and I’d like to write about each one of them, as well as its subtopics. The first step is about best practices and it explores how it’s important to make your code clear and readable, although not just for you! A good way of doing this is taking care of the names that you use in your packages, classes, methods, and variables. Good names matter!

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." Martin Fowler

In this same step, he talks about encapsulation to avoid repeated code, and code review with your workmates that result in an exchange of experiences, helping everyone grow as a developer and person.

Another point that is noteworthy, although I wouldn’t say that is related to best practices, is about IDE Shortcuts. Knowing the IDE’s shortcuts can improve the speed that you code up to 3x.

Understanding the Business

In the second step Del Nero talks about the Business Rule. Understanding how the organization operates is the most important thing to know before start coding. Not just understand the parts but everything as a whole.

To learn and have a full comprehension of the business, the author lists some points that can help us in this journey. Studying queries and APIs are two of them, becoming aware of the database tables will help significantly, and will also avoid the use of unnecessary joins. The API, in its turn, sometimes isn’t the most readable thing, but sometimes you can learn a set of business rules, just reading the code. And the most important: Never stop your search for knowledge.

Photo by Charles Deluvio 🇵🇭🇨🇦 on Unsplash

Imagine if all the business’ knowledge was centered on the more experienced developers’ mind. Imagine if those developers had to stop what they were doing to explain tons of business rules for every new developer that is hired. That would spend time and consequently money. A simple solution is a Wiki! With a Wiki, everyone can check, learn and create new pages about the business rules.

Test, test and test

I’m going to skip step 3 for a while and talk about the step 4: Test your software. In this chapter, the author talks about the importance of having a meaningful test during the development process. Unitary tests are good, but they don’t test if the business rules are being respected and followed, so try to put yourself in the user’s shoes. Use the system as a user, develop tests that test your logic and how it communicates with the system as a whole. Are all the business rules being adhered to? If yes, you did it properly!

I’ve left the step 3 to talk last because it is a point that discusses an uncomfortable theme for some developers: Soft Skills. Despite being a ninja with machines it’s a common sense that we have a lack of empathy and most of the time don’t know how to interact with humans.

They tried to give me a short deadline, and I said: No, no, no

Rafael highlights at this step that we have to work on improving ours Soft Skills and learn that we have to say NO sometimes. Short deadlines can cause loads of stress, poor code quality and therefore an increase of bugs. For our own health and for the company’s reputation, we have to be able to justify our denying and avoid those situations.

Another memorable part is about using a development methodology, breaking up tasks and identifying complexes points. Del Nero suggests that we group up with our team to identify the complexity of the tasks, and if one of it is too vast, we ought to break it up in smaller tasks.

Once we have a specific and clear task, we should classify its complexity, discussing it with our colleagues. I’d say that this discussion would help significantly the developer that get this task to implement, and also would help in providing the estimated time, granting in this way a better and viable deadline.

Hope you have enjoyed the reading and If you have liked what I wrote, you definitely should start following the No Bugs Project. There are loads of contents to explore and new stuff every week, I also strongly recommend following Rafael Chinelato Del Nero on LinkedIn and Youtube, once he is always posting tips and news about the project.