My Technical Approach
A mind map of things that I focus on at work
Most of these are either particular interests I have or areas where folks have told me I do well. This is an expression of my professional personality and interest and not a normative statement about what your approach should be. I made it as a self reflection, but maybe you'll find it interesting too.
I am sure it is incomplete.
Reflection
I am surprised to see how much I value maintainability and supporting my teammates. I guess a lot of my architecture preferences come from a desire to build "livable systems" where it is easy to work. There is a humanitarian and capitalist aspect to this -- humanitarian in that I want me and my coworkers to have a good time at work, and capitalist because we make more money if we're not wasting time messing around with systems that are expensive to change.
As a technologist, I'd like to solve hard technical problems. I'm good at solving hard technical problems. I invest in learning the skills I need to get access to those hard technical problems: refactoring and test design so I can expose legacy systems for change; project management and software development lifecycle concerns so I can isolate a well-scoped, customer-meaningful, business-valuable aspect of the problem to address; collaboration and communication because the hardest problems exceed the capacity of one human mind, and I'd like to join forces with my peers to tackle extra tricky problems.
This has left me with an unusual skillset, because often problem solvers invest in more direct aspects of problem solving. Instead, I focus on communication, collaboration, software development lifecycle, project management, and testing strategy. It's unusual but not nonsense -- I've optimized for having the skills that grant me access to the types of problems that I enjoy solving.
Written 2023-06