Keeping Your Code Clean
Food distribution is a key part of the foodservice ecosystem worldwide, and Sysco wants to reimagine the ecosystem with data-driven insights, as well as customer and market intelligence.
When it comes to clean code, the engineering team takes on the same innovative mindset to stay on the cutting edge. “When you are given the time to engineer a solution properly, strive to put the system in a better place than when you started,” advised Jonathan Black, software architect.
When it comes to writing clean code, what are some best practices you follow, and why?
I’d be remiss if I didn’t mention the seminal Clean Code by Robert C. Martin up front, and a related quote: “The purpose of a good architecture is to delay decisions. Why? Because when you delay a decision, you have more information when it comes time to make it.”
I regularly cite the principle of least astonishment. Write code to be read by other engineers, and not just your compiler. Even when you have a clever implementation for something, maybe save it for the The International Obfuscated C Code Contest if it means requiring a few paragraphs of comments to explain it.
I also build to the interface, and not to a concrete implementation. At the code level this helps with decoupling, law of demeter and Dependency Injection. At an architectural level, this means designing your services in the style of Hexagonal or Clean Architecture.
It helps to have a mature approach to testing as well. A quick look through your test suite should give a new engineer a good grasp of what the code base is meant to do, and can double as a documentation of requirements when done well.
On the other hand, what are some bad coding habits that you wish every developer would stop doing, and why?
Don’t be so quiet when it comes to decisions you don’t agree with. Amazon includes this in their leadership principles as “Have backbone; disagree and commit.” Decisions that affect your code and the way you write it should be able to withstand some scrutiny, and if done early enough can also save your organization time and money.
Also, stop making the easy change to fix a bug without thinking about the larger design. Or as Kent Beck puts it: “For each desired change, make the change easy, then make the easy change.” Sometimes you have to get a quick win, or maybe you have an incident that you need to resolve — this advice is not for those moments. When you are given the time to engineer a solution properly, strive to put the system in a better place than when you started.
“Stop making the easy change to fix a bug without thinking about the larger design.”
How does your team make clean code a priority? What are the benefits of this approach to software development?
Sysco LABS aligns well with best practices here: unit tests to certify locally and on the build server how your changes have affected the code base, integrated linting for maintaining a good baseline level of code quality and a review process. Though these are standard across the industry, they are still worth mentioning as they provide a foundation to further build your standard of quality.
Something that Sysco does that I don’t see as often is a focus on professional development for upskilling on new tools and technologies when they are onboarded into the system. Some teams have even introduced knowledge sharing sessions to show off new things they have learned or brought back from conferences.
I believe this helps drive a collaborative, outcomes focused culture where we can learn from each other, the industry and our own system to help define the future of foodservice and supply chain.
Want to join the team at Sysco LABS?