Greetings! I am a software developer by trade, I am interested in system design and analysis for a variety of domains, and I love games. I studied economics and operations research in school.
Most of this blog is about software development.
My Values as a Software Developer
Software development is a people activity. As a person, you have emotions, and those emotions are central to your daily experience of life. You also have values – beliefs about the world. Your values and your ability to express them determine your emotional experience as a software developer. Software development is full of decisions. Those decisions have trade-offs. When you choose those trade-offs according to your values, it brings you joy. When you don’t, you struggle with internal turmoil due to a values conflict between your values and the system’s values. It takes time to learn software patterns and practices that enable you to build your values into your software. I want to share my values and some of the patterns and I practices I have found helpful for expressing them.
Uncertainty is pervasive
Technologies change, requirements change, teams change. We have limited knowledge and we’re bad at estimating. We need practices that help us cope with an uncertain future.
Clear Ownership
People have different values. Different values lead to different choices. Different choices lead to conflict. Clear rules about who owns what, where the boundaries between authority are, and about how to make shared decisions will reduce those conflicts. Good fences make good neighbors.
The User is king
Software development is a people activity. You are building software for people. Every decision you make should reflect that. You need to maximize the time you spend solving business problems, and minimize the time you spend solving technology problems.
Precision
Software is a model. You are modeling problems and algorithms for solving them. You are modeling business domains and their processes. Ambiguous descriptions and instructions lead to messy outcomes. People interpret the ambiguity differently, and end up misusing the system. The more precisely you model your systems, the less ambiguity that will crop up, the better the outcomes will be.
Control
It’s your system. If it breaks, you need to fix it. If it needs to go faster, you need to speed it up. If it’s misbehaving, you need to know what it’s doing. You need to understand it. You need the ability to manipulate its behavior.