Ugly code is, for better or worse, the ubiquitous weed of the software engineering world.
It is an unsavory side effect of growth that often rears its head when engineers layer interdependencies and superfluous complexities in the interest of rapid development. Left untreated, these entanglements expand into digital kudzu that can hamstring future developments.
The “Weedwacker” for this pesky scourge is adaptability.
“Be a chameleon,” suggested StackHawk VP of Engineering Dan Hopkins. “Find prior art in the code base and try to mimic the style.”
Hopkins’ strategy requires a healthy dose of humility, a discerning eye for artful code and the drive to learn new tricks — qualities that most engineers have in-pocket by nature of their craft.
For forward-thinking coders in search of crisp coding techniques, the opportunity to adapt is often baked into engineering culture. For Elise Shaffer, a software engineer at Red Canary, this opportunity is most present in collaboration, which she sees as a vital stepping stone to beautiful coding practices.
“At Red Canary, engineers are encouraged to pair with each other,” Shaffer said. “Pair programming helps us leverage our teammates and their expertise to write the best code we can.”
As these engineers affirm in their clean-coding strategies, adaptability becomes a crucial landscaping tool. Built In Colorado sat down with Shaffer and Hopkins to find out more about how their respective companies aim to empower engineers to create pristine code through psychological safety, airtight best practices and open communication.
Red Canary is a self-described “security ally” that aims to enable organizations to make an impact without fear of cyber-attack. Elise Shaffer, a software engineer, often uses peer feedback as a litmus test for the clarity of her work. “If a teammate asks me how something works, I know that the code isn’t clear enough to tell its own story,” she said.
When it comes to writing clean code, what are some best practices you follow?
One of my favorite best practices is to focus on testing and test-driven development. I find that forcing myself to write the tests first gives me more clarity about what I’m building — and reassurance that my tests will catch problems in the future.
When a new feature requires that we change the architecture or the structure of the code, my tests help me do that without breaking existing functionality.
I also find that communication is super important with the team. I will often create pull requests well in advance of requesting an actual review so I can solicit early feedback about my approach.
On the other hand, what are some bad coding habits that you wish every developer would stop doing?
Engineers can sometimes lean too much toward fitting within existing design patterns. When we see code, our first instinct is to make the smallest change possible. But, if we have to make that change hundreds of times in a row, we can find that our code becomes indecipherable and difficult to maintain.
Engineers can sometimes lean too much toward fitting within existing design patterns.”
This is how we get unreadable, nested “if” statements. It’s important to ask: “Is this piece of code still clear with the change I’m adding? Will this be easy or hard to change in the future?”
These questions can help us spot problem areas in our code before they arise. Having good automated tests can help us make an appropriate change now in a safe manner.
My favorite quote about this is from Kent Beck. He said, “When you have to make a change, first make the change easy. Then, make the easy change.”
How does your team make clean code a priority?
One of our company values is “We deliver quality.” Delivering quality means we need to make clean code a priority. We use testing and code reviews to make sure that we have clean code.
We’ve recently put logging and error-handling standards in place. And our review process helps us get more perspectives on our changes. We schedule biweekly lunch-and-learns that let developers share their experience and expertise with the rest of the developer community at Red Canary.
StackHawk is a software-as-a-service (SaaS) startup that strives to empower engineers to easily find and fix application security bugs in CI/CD before they hit production. VP of Engineering Dan Hopkins is an advocate for leading by example. “Be courageous!” he said. “Put your code up early and often for your coworkers to review.”
When it comes to writing clean code, what are some best practices you follow?
Choose technologies with an opinion. Make sure your team has used them in the past and knows some of the pitfalls — creating a code base on something your team is learning is a great way to end up with many different ideas about how code should be written. Foster strong psychological safety on the team so they feel confident giving great code reviews.
If you’re not the most senior member of the team, ask around if a certain block of code is a good example of what you’re trying to do.
If you’re not the most senior member of the team, ask around”
Quick Tips for Clean Code
- Use plenty of test automation
- Invest heavily in tooling
- Utilize consistent frameworks and libraries across projects
- Centralized business object design
What are some bad coding habits that you wish every developer would stop doing?
Focusing on non-functional functional requirements, like “How hard is this for the rest of the team to adopt?”
Also, undervaluing working code that has been in production and is battle-tested is a common bad habit.
How does your team make clean code a priority?
We make sure that sprint time is devoted to refactoring and cleaning code. In addition, all work in code is reviewed. We have very stringent code design requirements that promote high modularity and composable code.
