I had been working in New York City for just over a year when I sat down at one of my favorite cafes in my neighborhood to write a personal journal entry. I gave it the title “On the crossroads between goal-oriented and process-oriented” and I wrote down stream-of-consciousness reflections on my life, career, and how I wanted to do things differently.

It was October 2015, and I had finished grad school and moved to NYC to work full-time as a Software Developer in a fin-tech company. I was having what I have come to see as the seminal quarter-life crisis many folks go through when they finish their formal years of education. I had been chasing goals all my life up until then, and now I had the luxury and privilege of deciding whether I should set another goal or do things radically different than what I had done so far. Goal-oriented versus Process-oriented, I called it.

One of the most transformative pieces of wisdom I’ve gotten in my career is Titus Winters’s ToTW #122 on test dataflow clarity. The Tip of the Week (ToTW) series offers advice focused on C++. Like Testing on the Toilet, which offers advice and best practices for software engineering at Google generally, it has become a fixture within the engineering culture, frequently cited in code reviews.

If you haven’t already, check out ToTW #122: Test Fixtures, Clarity, and Dataflow now—I’ll wait.

For many, Reactive programming seems like a conceptually elegant approach that falls apart the moment you try to do any serious programming. When adding essential error handling, refreshable state, etc. into an application, many folks see their codebases move further from the promise of clean, elegant reactive transforms.

It doesn’t have to be this way. While I’ve argued before for cleaner display of refreshable data by using AsyncPipe adopting better patterns for data refresh, this advice on its own does not provide an end-to-end pattern of displaying data from the moment it is loading all the way to error handling and refresh.

There’s a little-known pattern in software architecture that deserves more attention. Data-Oriented Architecture was first described by Rajive Joshi in a 2007 whitepaper at RTI, and again in 2017 by Christian Vorhemus and Erich Schikuta at the University of Vienna in this iiWAS paper. DOA is an inversion of the traditional dichotomy between a monolithic binary and data store (monolithic architecture) on the one hand, and small, distributed, independent binaries each with their own data stores (microservices, and service-oriented architecture) on the other. In data-oriented architecture, a monolithic data store is the sole source of state in the system, which is being acted on by loosely-coupled, stateless microservices.

I was lucky that my former employer also fell upon this unusual architectural choice. It was a reminder that things can be done differently. Data-oriented architecture isn’t a silver bullet by any means; it has its own unique set of costs and benefits. What I did find, though, is that a lot of large companies and ecosystems are stuck at exactly the type of bottleneck that data-oriented architecture is meant to resolve.

The conventional wisdom of the software engineering community is that striving to 100% test coverage is a fool’s errand. It won’t necessarily help you catch all bugs, and it might lead you down questionable paths when writing your code.

My recent attempts at 100% test coverage showed me the answer is much more subtle. At times I was tempted to make questionable code changes just for the sake of coverage. In some of those times, I did succumb. Yet, I found that often, there is an enlightened way to both cover a branch and make the code better for it. Blind 100% coverage can cause us to make unacceptable compromises. If we constrain ourselves with only making the codebase better, however, then thinking about 100% coverage can change the way we think about a codebase. The story of my 100% test coverage attempt is a story of both the good and the bad.