About Me

Systems Thinking

First, I tend to be a systems thinker. There is a lot of value in reductionism. It's how I learn any brand new topic. When I first learned programming, I did so by breaking everything down into its smallest pieces and learning the individual parts. That helped me to use more complex features later down the line.

However, that method did not help me continue to learn new languages and concepts. What helped was systems thinking. I learn by finding relationships between things that I've learned in the past. It helps to think about the larger system. How does anything new I come across relate to what I already know?

When I code new features, I tend to approach them from the context of the entire system. How is this going to interact with the rest of the application? What are the possible unintended consequences of committing the first, and simplest solution? Is there a design or architecture that can ensure the safety, long-term stability, and usability of my code? The goal is large changes in behavior with few unintended consequences.

Change vs Consequence graph

This is done by thinking about the potential for code reuse and understanding the code that makes up the system. Rather than typing out a literal translation of requirements.


I love standardization in languages, and I understand their value. The clearest example is SQL, standardized under ISO/IEC 9075-1:2016. Or the JavaScript standards of ECMA International. These standardizations allow frameworks to build on top of something very stable with the best support. They also allow for the scenario of knowing SQL and JavaScript and easily being able to jump into MySQL or React. No matter the JS framework or DBMS, knowing and keeping up with the foundation, and standardized languages, means having a solid base level of knowledge to always come back to. It also means having the ability to create your own solutions, even frameworks, without having a dependency on fickle third parties.

And of course, knowledge of standards is something to layer new knowledge on top of as a frame of reference.

Putting a focus on standardized languages rather than frameworks ensures the long-term stability of our own marketability. (Frameworks come and go.) It also allows you to employ the Rule of least power. By not overvaluing frameworks it's hard not to notice their sometimes overly complex solutions whose abstractions can be harder to use, and slower in performance than what it's trying to abstract. This is often due to those foundation languages expanding or updating themselves so as to make their replacements unnecessary. (Such as jQuery and Axios.)

This does not mean I am against the use of frameworks. The use of frameworks allows you to build far more, far faster, with far fewer headaches. I used Next.js and Sanity to build this site. Both are frameworks that take advantage of React, which builds on top of JavaScript.

My point is only to remain aware of the most base level, standardized languages, their updates, their philosophy, and how to use them. Because often, the tools we take for granted are not doing us any favors.


Stoicism can mean different things to different people. What I take from it is the idea that I don't need to react to things that are out of my control. Sometimes having an emotional reaction to things out of our control can mean validation. If Person A has a lack of panic in a serious situation, Person B may think Person A is not taking the situation seriously. In fact, I think Person A has the correct mindset. Accept the situation, and do what you can. You can not control what has already happened.

You absolutely can take steps to prevent problems in the future. But that comes after. And usually with a reality check.

I try to be stoic as much as I can. I try to focus on what I can change, and not worry about what I can't. Although I can't say I'm perfectly consistent with it.


I learn by association. Just as I mentioned in the systems thinking section. I try to understand base concepts and keep them in my pocket for any language or framework. "I want to use a mixin, how do I do that in PHP? Oh, it's called a Trait."

I try to have a broad range of knowledge across a lot of languages and frameworks. This is why my home page displays a random list of technologies I've worked with. If I talk about the disadvantage of your personal favorite, I say that in reference to all the others I've worked with. It's not an insult. If I talk about the advantage of something, it's most likely not an argument, it's a statement.

Wanting to branch out and learn as much as possible has been a point of confusion for others in understanding 'who I am'. My homepage randomly lists technologies I've touched. The randomness is very much on purpose. Because I don't want to be considered an X developer, I want to be considered a developer. This is a difficult concept for people to get around who have dedicated themselves to the expertise of a particular language or particular tool.

While I respect the ability to fully dedicate yourself to a niche, my interpretation of 'niche' is 'development'. Not 'x development'. It's simply a matter of personal preference and thinking. Not better than, or worse than, just personal to me.

I love learning. I love tracking down the best courses on learning. My recommended courses page is a page, not a blog post. Because it is an important, permanent fixture of this site and who I am. Always a plan to learn something new. Always looking to create relationships between what I have learned and what I haven't. Not choose a favorite to stick to, but understanding programming as a whole.