Consistency is Key

You are reading "Software, My Dream Job," a software engineering newsletter covering hands-on tips & insights from working in the software industry. If you like what you see here, click or tap "Subscribe" above.

Consistency is crucial in so many ways, and it's a critical trait to be successful, especially in software engineering. Being consistent creates an expectation with those around you of what'll happen given an assignment. It also yields results in various ways outside of work, from consistent diet producing desired weight loss to consistent exercise yielding desired muscle toning or gain.

What does consistency look like in software engineering? It could be broken down in a myriad of ways, but here are four broad areas we'll focus on:?

• Consistency in code review, both in the timeliness of reviewing other people's changes and in the value of the comments
• Consistency in communication with peers of any discipline, both in written and verbal form
• Consistency in your timeliness of delivery and accuracy of estimations
• Consistency in your organization, such that others can learn how best to work with you

Code Reviews

As a software engineer, the expectation is that one is consistently creating a fair amount of well-contained change requests/pull requests/code reviews. These should preferably be small, and the more coming out of you, the better. There is a balance here, though: in the quantity/quality tug & pull, we don't want to go too far into quantity at the expense of quality. Being consistent in one's approach to quality, and setting a high-quality bar, is an invaluable set of traits.?

In addition to writing code reviews, software engineers should be reading a lot of code too! An engineer should be reviewing code as quickly as possible while providing valuable comments, admittedly high expectations. Speed is needed to help the team's overall velocity of change, but thoroughness takes time and is where impactful commentary is found. These comments support the codebase (and therefore the reviewer, indirectly) and help improve the code author, a critical component of code reviews. The gold standard for software engineering code reviews is consistently providing feedback in a compassionate, constructive way. Doing so quickly and often leads to better outcomes for teams.

Communication

Verbal communication, whether 1:1 or in a group, in person, or over a call, is a critical skill in software engineering. Being consistent in one's verbal communication will help others understand you better, and by being aware enough to be consistent, we can then also start to learn and improve. Consistent verbal communication does not mean speaking in a monotone voice! It means being consistent in how you deliver your messages and gaining the trust of whomever you're speaking with. A side effect of poor consistency in verbal communication can be the "kid who cried wolf" effect, where someone who inconsistently describes situations in which help is needed eventually gets no more help at all.?

I've found that writing consistently helps me write more efficiently and is hopefully more understandable, especially as the corpus gets larger (while staying consistent with itself). To achieve this type of consistency, I've found that a consistent writing process is vital -- my process for drafting, reviewing, and editing needs to be consistent for the output to be consistent. I also use tools like Grammarly to help give another perspective; I view it as an editor who's not always right and take or reject suggestions as if they were redlines made by another person.

Delivery

Estimations in software engineering are challenging. There are often so many unknown unknowns; it's a guessing game at best. However, there are always pieces of work that can be described cleanly, for which you can communicate clear expectations of timing. This is where being consistent is critical. For example, if you have a task and say, "that'll be done by 4 pm", you should be consistent in actually following through with that commitment.?

For a large project, being consistent with the buffer you give for the fact there are always unknown unknowns you can't thoroughly plan for is essential. Furthermore, over time, I've tuned that buffer, which has helped me correctly estimate large projects while still sticking to a mantra of mine: "under-promise, over-deliver."

Organization?

By being organized consistently, others start to expect and even correctly predict some of your actions, which can end up helping the team and speed up knowledge finding. For example, through my organization of links, others can consistently find what they are looking for, which means I've shortcutted a question to another individual for that document. This shortcut was only possible by putting something in a specific place -- the "how it was organized" -- and repeatedly communicating to others what the organizational system was.

While abstract, these behaviors impact an organization's -- in the people sense -- ability to achieve its goals as fast as possible. Organizational consistency is yet another complex task for software engineers, although its benefit is not limited to software engineering environments. The hard part is that, ideally, the organizational structure and processes are consistently improving, too.

Conclusion

Why am I talking consistency? Well, you may have noticed this article is coming out on a Wednesday instead of the usual Friday. Is that because I'm trying something new, or am I simply scrambling since I missed my regular Friday date? While the former is a silver lining, the latter is the real reason. I had to maintain my publication consistency, or I could see this writing habit fizzling too quickly!

Consistency is something I find very important; it's where I have found a lot of my success. In addition to work, it's helpful in athletic endeavors, academics, and even in taking care of pets! Something to keep in mind is that there will always be lapses, just like this edition. The important thing is being honest with yourself and responding correctly to a lapse. For me, the response was to write an article still, just write it a bit late. I could have skipped, committing to writing next month's article right on time, but I knew it'd be too easy to let that slip too, and I'd hate to have missed two editions in a row. That's a pattern at that point.?

In some situations, though, staying consistent is a matter of skill, and failure should similarly not be taken lightly, but also not too deeply either. If the skill is new, failure is a way to learn and improve. If it's established, failure can be frustrating, but there are always factors at play that can cause something we're typically highly consistent with to be disrupted. By learning what there is to learn and moving on, we create a consistent approach for ourselves to keep for life.?