I’m a pragmatic, thoughtful, and empathetic software engineer.
Overview
My engineering experience is building software systems in service of business needs. I enjoy the process of identifying the right tradeoff points between the problem space and the architecture, so that the system meets the needs of its customers, and is authored, operated, maintained, and extended in a sustainable manner.
A large part of my technical experience is in backend engineering, owning and operating large scale distributed systems for data filtering and delivery systems, building API platforms, and the various services “underneath the water” to support those products.
Values
I value:
- working with groups who have a diverse set of lived experiences.
- working in high trust teams, with kind and motivated people.
- working thoughtfully and sustainably: slow is steady, steady is fast.
Team
While the main output of a team is production software (be that in operating services, or shipping libraries), the goal of a team is to build and maintain the processes that produce that software consistently and sustainably. To that end I find it most helpful to think of Software Engineering as a team sport. For me that means trusting that my team mates are motivated by good intent, are open to learning and sharing feedback, and that we all are pulling in the same direction.
It also means optimizing processes for the team instead of an individual. For example, the team is happy to slow down short term to onboard a new member, or get them ready for on-call, because it means long term the team will be more productive and stable. Or the team is willing to standardize on a tool or workflow because it builds shared context, and makes things like pairing easier. I’m also a fan of pairing as a great way to share knowledge, build common empathy and context, and most importantly share or learn things that you wouldn’t plan on doing otherwise (e.g. “oh wow, wait how did you make the IDE do that?”).
Ownership
Software Engineering is more than just typing out code in a particular language. It is also about owning the operation (e.g. deployments or library releases, monitoring, on-call or support) and maintenance (e.g. bug fixes, small feedback tweaks) of the system, as well as having a stake in the longer term vision of the product or services the system is supporting.
Leadership
Leadership as an Engineering IC can look like a lot of different things. I enjoy balancing “leading from the front” activities like Tech or Team Lead, driving a project, building consensus around an idea or implementation, etc with “leading from the back” activities like supporting new TLs, pair programming, and informal & formal mentoring.
Architecture & Code
All things in Software Engineering are about tradeoffs. Architecture and code are never finished, and are always changing in response to a diverse & dynamic set of constraints and needs. I really like the concept of Innovation Tokens to help guide where it makes sense to invest your creativity and engineering in solving problems. I believe that when designing and implementing a system it is important to balance between over-fitting to the immediate problem at hand and making something so abstract it makes solving any problem more difficult in the short term.
Hiring and Interviewing
I could write a whole document just on this (and maybe someday I will), but in short: The goal of any interview process is to derive meaningful signal about a candidates ability to do the job. I believe the best way to get that signal is approaching the process with empathy & compassion for candidates, being rigorous about what specific signal actually is important (e.g does your team honestly have to write a lot of hash map implementations from scratch?), and being transparent with the candidate about what signal you are looking for. A good process should be set up in such a way to help the candidate succeed and give them every opportunity to demonstrate the signal you care about.