How Engineering Teams at 4 Chicago Companies Prioritize Clean Code
Some of the world’s most ancient languages and writing systems have yet to be deciphered, leaving scholars to search for additional artifacts and information that could yield breakthroughs.
These languages have yet to be unlocked for various reasons: insufficient text length, scarcity of bilingual artifacts for comparative analysis, a lack of historical or cultural context for accurate translations of characters or passages, and so on.
At this point, the relationship between archaic symbols etched in stone long ago and modern coding languages typed on a computer may seem unclear. However, software engineers can look to such artifacts to better understand the importance of prioritizing clean code: Code that only makes sense in the original coder’s mind creates headaches for future developers and — unlike indecipherable ancient languages — won’t be seen as something deserving of the time, energy and resources needed to be understood.
“One best practice I follow is to ask myself: if a new developer joined the company a year from now, would this code I’m writing make sense to them? Or would it take a lot of time and effort for them to figure out how it works?” explained Madelyn Nelson, senior platform software engineer at Sprout Social. “While no best practice can 100 percent guarantee future usability, keeping the future developer in mind is at the heart of clean code.”
For Eric Cormack, senior developer at Milyli, pairing accurate naming conventions with clean, concise code is key for future readability. In tandem, these recommendations result in code that “can read similarly to spoken language – and that’s as ‘plain’ as it can get in my experience,” said Cormack.
Built In Chicago to software engineering leaders at Chicago-based companies Getty Images, Sprout Social, Milyli and Medtelligent to better understand how their teams prioritize clean code and what common bad habits coders should avoid.
More than 30,000 leading brands rely on Sprout Social’s all-in-one social media management platform to gain data-driven insights into their marketing and create deeper connections with their audiences.
When writing clean code, what are some best practices you follow?
A core motif of writing clean code is considering how a future developer would perceive your code. Would it take a lot of time and effort for them to figure out how it works? Five years from now, if an entirely different team owns this codebase, would the service I’m architecting now be easily extendable for their use case? Or would the work they intend to do require a complete refactor or even a rewrite?
While no best practice can 100 percent guarantee future usability, keeping the future developer in mind is at the heart of clean code. Also, choosing one style guide for your team or organization is a great example of low-hanging fruit. It’s relatively easy to implement, and the amount of headaches prevented is massive.
On the other hand, what bad coding habits do you wish every developer would stop doing?
There are some situations where churning out code as quickly as possible is appropriate: production outages, the first customer at a startup needs a bug fix and so on. However, those situations are few and far between. In most cases, it’s better to dedicate an extra hour or two to cleanliness than to slap on a band-aid solution and create tech debt.
Another bad habit is using inside jokes as naming strategies. Inside jokes can be a fun way to bond with teammates, but they are ineffective for naming variables, classes, services and other tech entities. For example, it may be tempting to name a new service you’re working on after a funny conversation your team had at lunch that day, but inside jokes fade over time. Several years in the future, it’s unlikely that more than a handful of people at the company will remember the name’s origin and how, if at all, the name relates to the entity’s purpose. Instead, use clear, descriptive names. Use the name as an opportunity to explain to the future user what this entity is and does. It may feel less fun in the moment, but it will save teams a lot of time and energy in the long run.
In most cases, it’s better to dedicate an extra hour or two to cleanliness than to slap on a band-aid solution and create tech debt.”
How does your team make clean code a priority? What are the benefits of this approach to software development?
Regular code quality meetings make a world of difference regarding the cleanliness of a codebase. By frequently discussing code quality on some set cadence — say, weekly or biweekly — teams can keep cleanliness top of mind, regardless of the current project or other initiatives. Regular sync meetings also set the stage for accountability. It’s easy to lose track of tech debt work if you only discuss it quarterly, but it’s much fresher in everyone’s minds if teams create tickets, share progress and reflect on learnings every sprint.
Additionally, it can be tempting to think of messy code as someone else’s problem, especially if you’re new to a codebase. However, software development teams usually share ownership over their portion of a codebase, including cleanup efforts. If you notice something that could be improved with a couple of hours of work, then take that on immediately as part of your current work. If a cleanup effort would require more than a couple of hours, create a tech debt ticket and talk to your project manager about prioritizing that work for an upcoming sprint. That way, you can maintain momentum in feature work while also cleaning up smaller pieces as you go.
Getty Images has served as a preeminent visual content creator and marketplace for more than 25 years, providing users access to powerful, current images that connect with their audiences and tell an engaging story.
When writing clean code, what are some best practices you follow?
Code readability is one of the most important aspects of writing clean code. Have function and variable names favor readability over conciseness and communicate the intent as clearly as possible. It’s also important to be consistent with naming conventions and patterns and leave the code cleaner than you found it.
On the other hand, what bad coding habits do you wish every developer would stop doing?
I wish that developers would avoid unnecessary comments that state the obvious. Instead, developers should write unit tests, keep classes small and, most importantly, stay focused on one thing.
Having a robust peer review process allows stronger developers to share and reinforce best practices.”
How does your team make clean code a priority? What are the benefits of this approach to software development?
With our team at Getty Images, peer review requests are submitted using a merge request template that has general guidelines and reminders. A robust peer review process allows stronger developers to share and reinforce best practices and, hopefully, is a learning opportunity for newer developers.
Healthtech company Medtelligent is on a mission to address the challenges facing senior living communities. Medtelligent’s ALIS (Assisted Living Intelligent Solutions) platform was launched in 2009 to help facilities manage routine care for residents and identify solutions to common issues.
When writing clean code, what are some best practices you follow?
What makes code look clean? It’s subjective depending on the pet peeves of the peers performing the code reviews. For us, we consider the code clean when it’s indistinguishable from the developers who wrote it. We achieve this feat by adhering to coding standards and conventions that we have maintained through learned standards and conventions from the community. As new developers join the team, our standards and conventions grow through open dialogue and demonstrations.
We also ensure our code is self-documented. It probably requires refactoring if you need to put comments around code to explain what it’s doing. Naming conventions are very important because they allow the developers to convey intent for classes, methods and variables.
Minimizing nesting also makes for clean code. Code will be much easier to interpret for the runtime if it’s easy to interpret with our eyes. Multiple levels of nesting make it difficult to follow the logic, so we highly recommend exiting fast and abstracting code into separate atomic methods to keep the orchestration logic clean.
On the other hand, what bad coding habits do you wish every developer would stop doing?
God classes and methods are the worst! When a class has no singular purpose, it is just as hard to maintain as the god developer who wrote it. Just like the class it’s in, a method should have a singular purpose and be just a few lines of code. You shouldn’t have to scroll to read a method from start to finish.
Instantiating dependencies is another habit we strictly regulate. Every application framework either has built-in Dependency Inject (DI) support or open-source DI packages in every language readily available to use with your application. When dependencies are manually instrumented in dependent code and not injected, it is impossible to cover that code with tests. Having dependencies on concrete implementations rather than abstractions is a related bad habit that makes test coverage very difficult due to being unable to mock the dependencies.
Creating classes without following layout conventions set forth is another bad habit we strictly enforce. Each class should be familiar in its makeup, so it’s easier to find code when examining a class.
Code reviews and pair programming are the most effective way to regulate clean code.”
How does your team make clean code a priority? What are the benefits of this approach to software development?
Code reviews and pair programming are the most effective way to regulate clean code. Delineation of why the rules for clean code is critical, and these engagements allow for that dialogue to take place. Code reviews are especially useful for junior developers as a medium to highlight and learn from mistakes. Pair programming allows for actively demoing the benefits of writing clean code as it provides a real-time commentary and application of clean code principles. The result can serve as a good model for junior developers to follow.
Integrated development environments (IDE) like JetBrains Rider or the JetBrains Resharper plugin for Visual Studio are also very effective tools to configure and enforce clean code rules. The squiggly lines that show around code when it doesn’t adhere to the rules are like having a peer pair program with the developer. It even has it automatically apply the necessary changes that comply.
Milyli builds software that helps legal professionals tackle tackle the complex challenges that arise while gathering digital evidence. Users can cut costs, boost efficiency and more securely manage sensitive information tasks through the company’s applications.
When writing clean code, what are some best practices you follow?
“Keep blocks of code small — and smaller than that even.” If a stretch of code spans more than a couple of lines when it could be a single unit of work, tie that block to its function and give it a good name. When blocks are written in as few lines as possible, you establish legibility which will help reduce future effort — whether it’s a colleague reading the code or you’re updating logic five months down the road.
Secondly, with today’s IDEs, having a descriptive, longer name on members is not a hassle. I name functions and variables following the rule of “as much as necessary, but as little as possible.” A good name will be precise enough to let the reader know what a variable holds or what a method does so that they can confirm logic easily and not need to retrace steps. When paired with my first recommendation, “clean code” can read similarly to spoken language – and that’s as “plain” as it can get in my experience.
On the other hand, what bad coding habits do you wish every developer would stop doing?
Developers should never stop asking questions – even of themselves. If you can’t understand what the code is saying during a review, ask about it or ask for help. If a choice seems incorrect, asking is the quickest way to an answer and potentially learn something new. It’s not that you shouldn’t immerse yourself in the code of a project. But hoping you’ll “figure it out” yourself can lead to faulty assumptions about someone else’s coding choices.
I also think it is crucial never to skip your final pass. People are always ready to move on from a challenging problem but shouldn’t do so prematurely. After tests are passed, it’s tempting to move on, but it’s the absolute best time to edit your code, clean it up and make it easier to maintain. It’s best to do this while your familiarity with the code is fresh in your mind, even if it’s not your favorite thing to contemplate further at the time.
The lodestar for Milyli’s clean code is to seek an effective process through repeatable action.”
How does your team make clean code a priority? What are the benefits of this approach to software development?
The lodestar for Milyli’s clean code is to seek an effective process through repeatable action informed by open discussion and thorough coding practices. Our pull requests are the most accessible place to keep our code clean as a team. There is the first run of accurate world legibility testing. If a reviewer has difficulty comprehending what’s going on, they’ll have to ask clarifying questions — sometimes pushing The Socratic Method to its limit.
Still, culturally we love diving into big questions. By refactoring, we answer those questions in the code and prevent later headaches. We also make sure our newest teammates are familiar with “Uncle Bob’s” Clean Code and feel invited to contribute new ideas or approaches that align to delivering effective, succinct coding in our products.
