Confidence in the code and systems is one of the most important aspects in a software team, but often underestimated or set aside for more “valuable priorities”. It’s that significant that, in my last roles, improving the team’s confidence has been a big part of what I’ve done. Why? Because a fearful team can’t be at its best, nor can it be nimble, healthy, or adaptable.

Fear is not an ideal driving force. It causes avoidance behaviours, pushes us to get away, creates a vicious cycle and erodes the developer's spirit and self-confidence. The vicious cycle will only make the feedback loop longer, reinforcing the behaviours:

• Fewer and bigger releases

• Long-lived branches

• Release freezes (don’t deploy on Fridays)

• More gates

• More manual testing

With a longer feedback loop, there will be delayed discovery of defects, high rework, lack of visibility… The team can’t sense and respond fast enough, there’s a big delay between action and consequence.

What if we could get near instant feedback on everything we do? We could discover if something goes wrong as we’re building it, if a bug appears as soon as the code goes live or if we’re not aligned in our understanding of the work, and adapt. We might sense that our solution won’t solve the customer’s opportunity before starting to build it, or that we need to change direction without having invested lots of money and time. With near instant feedback, we could refactor bravely, and make deploying at any time safer.

What if we could, when things go wrong—and they will—, know about it as soon as they happen, investigate with ease, have means to recover? No matter how great our process and code is, failure will always be an option, and fear of incidents will appear if we don’t embrace the possibility of failure and be ready for it.

From an engineering perspective, we want to build guard rails and shorten the feedback loop, which reduces fear, increasing safety.

In the past years, I’ve focused a lot on two areas: observability and testing.

Adding observability (nowadays known as observability 2.0) is a game changer, as it allows the team to see what’s going on under the hood of the system and understand it, shining light to a previously dark universe. Specially in these times of microservices and ever complex systems, observability is a must; otherwise you can’t really understand what’s going on. When the team makes instrumenting the code as they build it a habit, and starts seeing the value of it and how they can get fast feedback—as the code is built and all the way to production—, safety improves.

In terms of testing, from my experience, many teams don’t test much, if at all, and when they do, they have trouble writing tests that are reliable, fast and more importantly, that give them good confidence.

It’s not that the team doesn’t actively want to test, there are challenges that make it difficult to do so. One of them is the lack of knowledge and practice, and creating spaces to learn and get better together is paramount, even if it’s not “officially sanctioned”—being that the default in many places is to never encourage learning. Pairing or mobbing on a new test or a refactor and going through it together can be quite useful, as well as making things explicit and organising internal workshops, or having learning time.

Encouraging the team to test or improve the way they do it is a gateway drug to quality and safety. You can’t have Continuous Delivery without continuous testing.

Testing

When improving the testing experience and testing in general, there are two main aspects I’m looking for: confidence and friction.

Friction

Friction refers to how easy or difficult it is to write and run tests. The lower the friction, the higher the probability of developers actually testing. Plenty of us have experienced a situation when writing a test is an obstacle race, having to jump through hoops to come up with something decent. The easiest path is to do the wrong thing, or to skip the test altogether.

When dealing with friction, I want to create a pit of success, a clear path that allows developers to write good tests by default:

While there are numerous things that can reduce friction that we can tackle, the number one cause is often the system itself. In that case, making the system more testable over time by continuously refactoring and improving the architecture is a priority.

Low-hanging fruits can simply be things like updating libraries to the latest version possible, migrating to modern tooling that encourages better practices or simplifies areas like mocking, adding linting to tests to catch common mistakes… For example, in the front-end, migrating from enzyme to testing-library, and using Mock Service Worker to improve the mocking experience, while relatively simple, can reduce friction and make testing better for developers.

An example of reducing friction is simplifying async state management. Lots of complexity in the front-end comes from state management and, in particular, dealing with server state. Fetching, pagination, rendering based on state (loading, error…), optimistic updates, cache, etc. If we’re not careful and venture to build those features from scratch, we might end up in a world of pain. Using solutions like TanStack Query, Apollo or similar for async state management can simplify the developer’s life.

This is it for this week, in the next newsletter, I’ll cover how to improve confidence.

Interesting links

• Sam Altman Is Full Of Shit (Edward Zitron)

• No Web Without Women. “A collection of innovations by women in the fields of computer science and technology.”

• On Surveys (Erika Hall). Most surveys are an excuse to avoid talking to a real person, the easy way out. Moreover, plenty of surveys are just bad. Use them with caution.