The purpose of this post is to explain how I like to Do Work and the principles underlying those decisions. This not meant to say that I consider the way I work to be the only correct one, nor that I am unwilling to try other ways of working. However - the impression that I would like readers to come away with is that the way I work is principled, considered, and intentional. If you’re a recruiter looking for something akin to a cover letter, this is about as close as it gets. I think a lot about why I do things the way that I do, and this post explains the internal logic of how I work.
I believe that the single most important thing for any work that I do is to ensure quality, and if we have to trade off quality for any reason (such as time or budget) to make this trade off loudly, with discussion and consent. I believe that as a developer of tools for other teams, it is my job to help them use my tools in a way that places quality at forefront of their priorities. Finally, I believe that competent and healthy teams prioritize quality, and healthy processes encourage and require quality as part of their acceptance criteria.
Of all my ways of working, I think that this is the one that is the hardest to compromise on, or adapt to a culture that behaves somewhat differently. For example, while I have no qualms about writing in the eye of the public workplace, I am also happy and productive if I need to do so in my own space. However - if I find a culture that doesn’t prioritize quality, I will feel drawn towards changing that culture accordingly.
It should be self-evident from this blog that I like to write. Writing is a form of expression (more on that later), but in the context of work it is also my favorite tool - when I write, I get to gather my thoughts, examine them, and see where the road leads. I do my best work when I have the time and space to document the problem we’re trying to solve, think through and explore alternatives, and identify the best course of action through discussion and consensus.
There’s a number of ways that this manifests - the first is that for any given project I will produce at least a few pages of design documentation. Aside from being a medium to gather my thoughts, I also find this kind of resource to be extremely useful later on to reference when trying to understand why I made a certain decision, or to figure out the next step when its not immediately apparent.
Finally - the value of writing is that I can converse with myself. When I write, I challenge myself to justify the claims that I make. Sometimes, I find that something I found to be intuitive is anything but; these things happen, and we’re better for it.
To me, the purpose of a tool is to help you bring something from your imagination into reality. Metaphorically, to the sculptor a chisel creates form out of a block of marble, right?
In the context of work, this means that I seek for myself (and to build for others) tools that are expressive. Tools should give you the freedom to do what you need to do - having to make compromises to work within the framework of the tool mean that it’s an imperfect tool. Sometimes these imperfections are tolerable - but sometimes these imperfections are meant to be fixed.
It is perhaps a fait-accompli that I feel the best tools in software to be the ones that are closest to the code, or are code itself. Indeed, I believe that writing your own code is a form of expression, and that everyone should be encouraged to do it. I believe that my coworkers should be not just comfortable, but excited, to use tools that are close to the code. And, I believe that comfort and familiarity with the command line is not only a good thing, but necessary to make effective use of tools that are good, which is to say close to the code.
Interfaces are the medium by which we express ourselves using tools. I believe that the best interface is transparent - when you approach it with velocity, it ceases to exist. Very often in software, we find ourselves writing an interface that mimics one or more other interfaces - I believe that we should write interfaces that acknowledge their transparency, or even embrace it. Hiding complexity behind interfaces is acceptable, but as a developer you must recognize that its a compromise.
Invariably, this belief that tools that are close to the code means that I do tend to prefer command line tools to GUI tools. While this is true, there are good GUI tools out there - I find that I enjoy GUI tools that have a dense interface and many exposed features (in other words, are transparent to their code).
Here are a few examples:
Here are some working beliefs of mine that I don’t have the time or energy to turn into a full section