The Outward Mindset in Software Engineering: Lessons from a Testing Rule

I just started reading a book called The Outward Mindset by the Arbinger Institute. After the first 2 chapters, I found myself reflecting on an experience I had as a software engineer.

So, a little over a decade into my journey as a software engineer, I got into one peculiar team. A senior member of the team told me the team had an agreement that said, "All code should be tested." To uphold this agreement, they created a mandatory sub-task—write test—for every product backlog item. The goal was simple: ensure every team member could make future changes without introducing unwanted behaviours (bugs). But to my surprise, some merge (pull) requests without tests were still getting approved and merged into the codebase despite the agreement.

The Illusion of Agreement: When a Testing Rule Falls Apart

One day, I was reviewing a merge request after a couple of weeks of working as a new team member. I uncovered that some parts of the code were not unit-tested. Therefore, I highlighted the issue of missing unit tests in a comment.

However, the senior engineer who told me about the team agreement jumped into the discussion, saying unit tests were unnecessary. The person argued that the software behaviour test (which uses Cucumber) had verified the code's functionality. We even had a meeting to discuss whether or not unit testing those codes was necessary. In that online meeting, that engineer pulled up an image of the testing pyramid, saying, "According to this principle, if an integration test has covered the code, a unit test is unnecessary. Trust me, the integration test will tell us if there is a bug in the code."

Though the statement was an incorrect interpretation of the testing pyramid and integration test, it is not the highlight of this article. Ultimately, the meeting ended with voting not to unit test the code in question, which was fair because the agreement only mentioned that all code should be tested without being specific about the unit or integration test.

Weeks later, I encountered another issue. While reviewing another merge request, I noticed a newly added function had zero test coverage—neither unit nor integration tests. Therefore, I remarked: "Missing tests for this function." Which I believed was self-explanatory.

The author's response, however, "Ah, yes, it's a new function, but it's practically a copy of an existing function. The only addition is a publication time check, which doesn't warrant a test." I brought the discussion to the team. However, the merge request author persuaded other engineers to vote not to write tests for the new function, which was against the team agreement.

The Checklist Trap: Following Rules Without The Right Mindset

That second encounter, where convenience trumped principle, vividly illustrates the core point of 'The Outward Mindset': the real issue wasn't a lack of rules but a lack of the right mindset. The team wished to ensure their software behaved correctly, which is why they had a rule about writing tests. But without a mindset prioritising long-term quality, the rule became a mere checklist item—easily bypassed when inconvenient.

I've seen similar situations in other areas of software development. In one case, SQL commands that consistently produced errors were approved and deployed to production. Before reading the Outward Mindset book, I believed that such a situation would not have occurred if the team had a definition of done stating, "[code] should function and work according to the acceptance criteria without producing errors." But now I am doubting the effectiveness of the definition of done without a mindset change.

The Outward Mindset in Software Engineering

I haven't finished reading The Outward Mindset yet, but it has already reshaped how I think about software engineering principles and team dynamics.

By the way, I want to thank Aleksandra van den Heuvel , my former manager, who explained the developer vs tester mindset in software engineering. She said I was fortunate to have a tester mindset while developing software. I was flattered at that time, but her words reminded me of my studies about mindsets.

Mindset isn't just an abstract concept—it directly influences how teams collaborate, how decisions are made, and, ultimately, how quality is maintained. As I continue reading, I'm eager to explore how shifting to an outward mindset can lead to better engineering practices, stronger teams, and more consistent outcomes.