The soothing thrum of a mantra, spoken or silently conjured, has the power to quiet the mind, dull distraction and soften stress.
In the traditional sense, a mantra is a mystical invocation rooted in the “om” of Vedic Sanksrit origin, but the term “mantra” has become synonymous with guiding principles that structure elements of secular life — from daily fitness rituals to intricate coding strategies.
A conversation with three New York software engineers revealed that each tech company employs its own mantras to manifest clean code. At Parsley Health, a reoccurring mantra is to “provide documentation,” said Senior Director of Engineering Yen Siegel. At Artium, Software Engineer Liz Johnson shared that tackling fixes right away is a guiding principle. Meanwhile, engineers at Spring Health believe an important refrain is to “leave the code better than you found it.”
Mantras possess the power to ground the complex and lofty process of creating crisp code. Built In New York connected with three leading tech companies to learn more about the coding edicts that refine their craft.
Spring Health strives to use clinically validated AI tech to deliver optimal care — including meditation, coaching, therapy and medication — to its members. “An overarching theme of bad coding is over-engineering,” Spring Health’s contributors told Built In New York. “These complicated solutions are often less flexible and can root codebase in outdated technology.”
When it comes to writing clean code, what are some best practices you follow?
In our practices, descriptive variable names and well-commented functions help developers to have a clear and concise view of the code. Good functions themselves should be self-documenting and clear. We generally aim to avoid side effects in our functions so that they are composable when implementing new behaviors or business requirements.
Test-driven development (TDD) is another practice to ensure the cleanest code is written. This development process allows us to think through the expected behavior of code and write the logic for it. It allows us to approach problems from the outside in.
Oftentimes, the initial plan for structuring code will improve as we begin the TDD process and begin to think through what the surface area and entry points will be for a given module.
When it comes to code maintenance, refactoring allows for re-evaluation of the codebase. Simplifying the logic when possible helps to produce a leaner and more efficient product. These practices often lead to readable and sustainable code.
On the other hand, what are some bad coding habits that you wish every developer would stop doing?
A few of the less desirable habits are having bloated functions or large pull requests (PRs) and over-engineering. Large functions will eventually be hard to understand and maintain. The logic can become quite complex and very hard to add to or refactor.
Like most companies, our code review process is invaluable to promoting good coding habits and helping correct some bad practices. When done right, they are a good learning experience for both the reviewers and the submitters. Reviewers should be able to understand the code changes without extensive knowledge of the new or modified functionality. Pull requests that have changes in multiple places can make it difficult to effectively review.
How does your team make clean code a priority?
Our goal as engineers at Spring Health is to create code that is quality and owned by all of us collectively. Often, the best code is not the fanciest solution, but the one that is the most understandable.
One rule we like to abide by is the “campground rule”: Leave the code better than you found it. It’s a good thing to internalize and helps us improve the quality of the codebase even as we are tackling new features.
One rule we like to abide by is the ‘campground rule’: Leave the code better than you found it.”
Pair programming is a big part of the culture at Spring Health. This process helps to get another set of eyes on a problem. It allows engineers with different levels of experience to learn from each other.
Automation and tooling are valuable and worthwhile investments that pay dividends down the road. All PRs go through automated linting, testing and security checks. This helps keep our code reviews focused on substance and behavior. No code updates can get to production unless it passes the rules we’ve all agreed on.
Parsley Health is a holistic medical practice designed to help women overcome chronic conditions. The healthtech company aims to analyze the whole picture of health, treat multiple health conditions at the same time and be a long-term health partner. While she subscribes to many best practices for clean coding, Senior Director of Engineering Yen Siegel shared that the guiding principle behind all coding at ParsleY Health is “maintaining standards and consistency.” She added: ”We document a well-defined set of standards and use automated tooling to maintain consistency.”
When it comes to writing clean code, what are some best practices you follow?
When it comes to clean code, we work to make it readable, simple and straightforward. Writing clean code is like writing a self-documented set of instructions that provides the reader a clear sense of what we are trying to accomplish.
Some Important Points to Consider
- Self-described functions or naming conventions play an important role in writing clean code.
- The method name should describe what it does, and the variable names should be the same.
- Strive to write short functions that only do one thing and avoid extensive nested conditions.
- Provide documentation and comments in the code so other developers also understand what the code is doing.
- Keep a consistent style and structure across similar project codebases.
On the other hand, what are some bad coding habits that you wish every developer would stop doing?
As engineers, we sometimes feel pressure with deadlines and compromise quality for speed. Many poor coding habits are driven by pressure to deliver the code quickly. Sometimes it is more expensive to fix a bug than it is to spend extra effort getting it done correctly in the first place.
Some Bad Habits to Avoid
- Compromising quality for speed: Well-managed code takes a little extra time but when rushing to get it done we make mistakes.
- Avoiding unit tests: A lack of unit testing creates more bugs and increases project risk.
- Fixing bugs without addressing the root cause: Fixing a bug without understanding the root cause can create a cascade of other problems.
- Ignoring security vulnerabilities: This could increase operational costs.
- Writing unorganized and unstructured code: Poor coding structure is difficult to maintain and makes onboarding new team members more difficult.
Understanding how schedules and project pressures drive bad coding habits is the first step to eliminating those habits.
As engineers, we sometimes feel pressure with deadlines and compromise quality for speed.”
How does your team make clean code a priority?
Our engineers are encouraged to collaborate and work together to strive for better coding standards.
Clean Code Tips
- Document well-defined coding principles and standards and incorporate them into the engineering onboarding process.
- Establish a technology forum for engineers to review architecture designs.
- Encourage engineers to actively participate in code reviews across project teams and use Github to enforce clean code merges to master.
- Encourage pair programming and mentorship.
- Internally organize technical bootcamps.
Providing the right environment and setting high engineering standards allows us to create high-quality products that reduce maintenance and operational costs over time.
Artium is driven by the goal of finding progressive ways to build software as small teams of passionate craftspeople. The consulting company helps its clients implement their own diverse culture and software development. Software Engineer Liz Johnson advocates for pair programming as a means of identifying blind spots in one’s code. “When someone calls out something that they are having a hard time understanding in your code, it’s worth pausing on that and thinking through why they may be having a hard time understanding,” she said.
When it comes to writing clean code, what are some best practices you follow?
There are a few obvious ones: Don’t repeat yourself. If you are going to repeat code everywhere, you will also have to change code everywhere. Get your tests to pass first, but refactor before you move on. The code cleanup step takes discipline because it is not a natural thing — we want to move fast.
TDD is a real helper in getting clean code out the door. Write code that is modular. If each piece has a single responsibility, and requirements change, you can swap out smaller pieces of code.
The one that I think gets overlooked is learning to write in the language that you’re working in. Take a little extra time to learn the nuances of the language. Usually, people have structured it in ways that allow you to write it cleanly, but those ways don’t necessarily apply to all languages. Learning the cleanest way to use the language that you’re in takes an extra step, but it’s worth it.
Learning the cleanest way to use the language that you’re in takes an extra step, but it’s worth it.”
On the other hand, what are some bad coding habits that you wish every developer would stop doing?
I think developers need to be much more careful about saying, “We will fix that later.” Try for a time-boxed amount of time to fix it right now. Spend 30 to 45 minutes, and you will be surprised at how many times what you are trying to do is not actually that big of a refactor.
If you get really stuck or realize it is as big as you thought, then at least you have tried something, you’re learning from it and you gave the code a chance to be better.
Developers often try to future-proof code. They will occasionally add over-complicated elements because they’re trying to build it for a future that may or may not happen. If you know something is coming down the line very soon, you can adjust for that. But you should write cleanly to the requirements that you have at the time. If you’ve written clean, modular code, it’s not going to be hard to adjust.
How does your team make clean code a priority?
Pair programming is a huge help in writing clean code. Someone is going to stop you from doing something that seems confusing before you even do it. Beyond that, it gets you in the habit of writing code for someone other than yourself. At some point, someone is going to look at your code, and they’re not going to have you there.
When you are writing code, you should have the awareness that this may make sense in your head, but it needs to make sense to someone else who does not have you there always to explain it to them.
