You are being too pragmatic

Michelin is transforming to become a data driven company and a software driven company. In order to do this we need to transform the mindset of our teams to create best in class software. Software craftmanship is one of the goals of Michelin toward becoming a software driven company.

I have many books I like to read, mostly fiction. I don't usually like to read nonfiction books because honestly it doesn't hold my attention. This mindset shift in Michelin encouraged me to order and read "The Pragmatic Programmer" written by David Thomas and Andrew Hunt. From the preface I was hooked. I'm currently about halfway through the book but I thought I would share some of my favorite sections or tips out of the book.

Are you a pragmatic programmer?

1. You are an early adopter of technologies and techniques. You love learning about the newest language or software products on the market. You grasp technologies very quickly.
2. You are inquisitive. You ask a lot of questions. If John is working on a new piece of software are you peppering him with questions about how it works and wanting demos?
3. You are a critical thinker. Does someone tell you something can't be done? You need all the facts before you accept that statement.
4. You are realistic. You understand how long something really takes to do and you have a good feel for how difficult certain tasks are.
5. You are a jack of all trades. How many software languages and technologies are you familiar with? You know enough about them all to be dangerous.

I've been a programmer for more than 25 years so when I read those characteristics I thought "Yes, that is me. I'm a pragmatic programmer."

Tips for being pragmatic

Whether or not you want to be a better developer, architect, product architect or network engineer, I think most of the tips in this book will apply to many fields in IT. I'm only about halfway through the book and there are 100 tips in the book however I will give you a few I loved from the book so far.

This is a hot topic in Michelin IT right now. How do we get everyone in the teams to care about the products they deliver. I know that if I care about what I am doing then I am going to take my time, make the right decisions and deliver a better product.

The premise of this tip is that we all create technical debt in our software with grand plans to go back later to clean it up. We get busy and add more duplicate code or poorly written functions that occasionally crash the application. Technical debt grows until it is too difficult to clean up the code or sometimes add new features easily. Even if you implement something quickly for the business, plan to refactor the code to reduce that technical debt.

You have an idea that will reduce incident tickets by 20% to the help desk but the amount of work required would take up a lot of your time. What do you do? Do you implement the idea and spend lots of overtime to get it working or do you pretend it isn't important.

"We always do it this way." How many times have you heard that from colleagues? Pragmatic programmers must break the status quo and be a catalyst for change.

Software will never be perfect but we should all strive to make quality code and make it a requirement.

What is quality code? It is easily understood, simple, bug-free, documented and performant. This tip encouraged me to to read another book that I believe all programmers should read: "Clean Code" by Robert Martin. There are many examples in the book about how to write clean quality code.

Involve the users in the quality of the code you deliver. Perhaps the users would be okay with the rough look and feel of a new feature to get it delivered more quickly.

This is a new term for me but found it interesting in that it isn't taught in college. Orthogonality is a programming concept where changing one piece of code or third party software does not affect the other code. You've possibly heard another term used decoupled or independent.

Imagine if you want to change your database from SQL server to PostgreSQL, your code should not be affected by this change if you have followed the orthogonality concept.

It doesn't matter if the problem is your fault or someone else's. It is still your team's problem. When I work with my team, I always use the term "we". It implies that the team is not just "me" or "you" but "we" as a group. If I fail then we all fail. Fixing the problem will be a team effort.

Writing tests will take time and you will probably write more unit tests rather than actual code. Implement Test Driven Development where you write your unit tests before you write the code.

Test Driven Development is a process for developing unit tests before developing the code. It helps ensure that units tests are properly covering the feature you as the developer creates.

Our team struggles with this. Automate everything wherever possible. Automate builds, code scans, unit tests, regression tests, deployments, server restarts. Take those repetitive tasks out of the process.

I have left the best for last. Delight the users should always be the top priority. Deliver top quality code that solves a problem. Software developers deliver code however in essence we should solve problems.

In conclusion, there are many tips from this book that would be useful for any person or organization. I only highlighted a few that I found useful in my current role.