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.