We're big fans of communication at Riskalyze. It's even one of our core values! Communication is essential if your whole team is going to be on the same page and have a shared vision. It’s also a great way to improve quality and consistency across your codebase. Here are a few ways that we focus on good communication within our teams — and end up delivering a better experience for our users as a result.
If you've ever worked on a large and/or growing team, you know how important code reviews are. Even a quick glance at a pull request can be valuable for catching any glaring errors. But with intentional review and discussion — really, motivation beyond just trying not to ship bugs — thorough code reviews help team members develop a rapport with each other.
Code reviews aren't only about looking at code. They're a chance to learn how others approach their work, hear them explain their thought processes, and share knowledge across the team.
Those early in their career aren't the only ones who can benefit. Those with more experience get to practice communicating technical ideas in a way that someone less experienced can understand. This skill is often undervalued, but it can help foster a more empathetic and understanding culture across your teams.
Getting Early Feedback
We encourage everyone on our team to reach out for feedback early and often. Asking for feedback provides opportunities to get different perspectives and leverage experience from across your team. But what's the benefit of reaching out early?
It's often difficult to review completed code because of the time needed for a thorough review. It's also not fun to pick apart someone else’s hard work.
With so much time and effort already invested in a PR, it's often easier to think, "Is this good enough?" rather than, "Is this as good as it could be?"
Reaching out for feedback early allows for more focused discussions around possible improvements, edge cases, and the best way to think about the problem. If we're way off track, we can correct our course before wasting time going further down the wrong path — and we don't have the rushed feeling that comes from being at the end of a sprint or near some other critical deadline. We can have more honest and thorough discussions.
Like intentional code reviews, this is a practice with benefits beyond the project. Creating a culture where everyone feels comfortable discussing their work and asking for feedback contributes to better work across our teams.
Help From Tools
Language tools can also be very helpful for writing clearer code. Your environment will determine the tooling available to you, but here are a few categories of tools we've found very beneficial:
- Static type analysis allows us to explicitly define what data we expect to flow through our programs. It also helps prevent silly mistakes that arise when we deviate from that contract.
- Linting allows us to enforce certain style choices we've made as a team about how our we write our code. This consistency can make it easier to jump into a new project or review someone else's code.
- Automatic code formatting helps our code conform to our linting rules without much effort. Various IDE plugins allow formatting as we save changes. We've also configured Git hooks to format any new code that gets pushed to a remote repo.
- Tests are a fantastic way to communicate the behavior of our code. Unit, integration, and acceptance tests (and others) all work together to build confidence that the code works and will continue to work once deployed. When someone changes code in an unexpected way, a good test suite can tell you exactly what broke and why. Be sure to pick a test runner that's fast and simple to use. It should be easy to run your tests as often as possible, providing immediate feedback as changes occur.
We've seen huge benefits by investing in tools like TypeScript, TSLint, Prettier, and Jest across our frontend codebase. Of course, taking the time to choose tools that best suit your team can mean the difference between engineering productivity and outright pain, so invest a little time and get lots of input from across your team to find the tools that best fit your needs.
What We've Learned
These are some of the ways we leverage good communication to work more effectively across our Engineering teams at Riskalyze. Here are some things we've learned in the process:
- An engineer can write good code by themselves, but it usually gets better with some feedback from teammates. Make time for thorough code reviews.
- Create an environment where everyone feels comfortable asking for feedback at any stage of their work. A five minute chat to clarify something you're unsure about could save hours (or days) of going down the wrong path on your own.
- Define team-wide rules for things like code style and testing, and automate them if possible. Your team should be focusing on hard problems, not arguing over semicolons.
Prioritizing communication leads to better code and a better product, while improving the experience for your team and your customers.