Systems Thinking
We’ve all written nice, clean, and concise programs that worked well. We’ve shipped them to production and had them run in a stable fashion for months or even years, only suddenly to start experiencing problems when something in the environment changes. If you are like most of us, you conclude that this isn’t the fault of your code, but rather the fault of recent changes to the system. And you’d kind of be right, but the fact is that your code is the part that ended up breaking. If you’ve ever had this experience, then you are well aware that the way you look at your code in a development environment is vastly different than how you have to think about in production. In production, you are part of a larger ecosystem, a large part of which you don’t control. Compounding the problem for developers, to effectively write and debug most code, you really need to think of it in a linear fashion, with appropriate abstractions. However, at some point, the very thought processes that make you capable of writing the code, will hinder it from running well in production. You need to be able to shift in and out of both mindsets if your code is going to run at scale and be stable. Early in your development career, you can often get by with treating your code as if it lives in isolation. Not only is this a necessary stage of your growth, but at some point you are going to need to consider the broader ecosystem in which your code lives. The way you have to think at this scale is going to be different than what you had to do when you can focus on a single application component. However, it’s hugely valuable to your career to be able to think well in both modes. In the aftercast, we’ll discuss some ways that team leads and senior developers can help junior and mid-level developers become better at systems-level thinking. Links Join Us On Patreon Level Up Financial Planning Donate to Beej’s Mission Fund Memo: Put “BJ Burns” in Memo