Services

Architecture

Early in a project, there are countless decisions to make from a technology standpoint: programming languages, frameworks, cloud platforms, tools, etc. There are a lot of reasonable choices here: no such thing as a perfect choice or a "one size fits all" answer. I determine architecture by looking at the problem being solved, the scale that it needs to work at, and the team building it. These factors steer what choices are made. I like to interview whoever is acting as product manager to get a better sense of what is being built. I look at the skills and knowledge of the current development team. I'll consider multiple options and then make a case for why I feel one is the better option. I'll give a high-level view of the system and how the different pieces work together. All of this goes into a document that the team and I can use to build the desired system. Going through this process ensures that we are in agreement early on in the project and have similar expectations.

API Design

A software system that lives in complete isolation is uncommon today. Everything is connected to each other and APIs form the contract between these different systems. API design is a special discipline because it involves juggling a number of competing concerns: an API should be performant but performance shouldn't get in the way of usability, APIs must be well-defined and rigid but also change over time as the needs change, APIs need to be secure but also be easy to use, APIs need to be straightforward to implement on both the consuming and producing side… the list goes on and on. Having designed a handful of APIs, I have firsthand experience trying to balance all of those concerns and can help avoid some pitfalls that I and others have experienced. I've found that the best designs are elegantly simple without being limiting.

Implementation

I bring nearly 2 decades of programming experience to projects: I'm fluent in a number of programming languages and techniques. I'm not limited to just the technologies that I know either: it's easy and common for me to pick up a new language or framework and be productive and knowledgeable quickly. I can build parts of the system and prefer to be responsible for prototypes and the minimum viable product. I spend at least 50-70% of my time as an individual contributor in my current projects.

Refactoring

I really enjoy figuring out how to evolve an existing system to do new things. Often, this means making changes to the system that restructure it in a way that the new feature becomes easy/trivial to implement. Many lessons learned are encoded in an existing system, so it is often valuable to keep around as opposed to scrapping it and starting over. Sometimes it makes sense to put new functionality in a new system rather than adding it to the existing one, with an event-driven architecture built around the existing system. There are lots of possibilities and I strive to explore those before committing to a ground-up rewrite.

Testing

Testing is critical to keeping a software system working correctly while making changes to it. Almost no system is done on the day that v1.0 ships, so testing is a vital part of the software development lifecycle. My early career was spent focused on testing software systems with automated tests. I'm good at seeing the system both as a whole and individual pieces so that testing can be done at the appropriate layer: unit, functional, integration, or end-to-end. I've done a lot of test planning and have both written tests as well as guided other engineers to write tests for their new features.

Custom Tools

One of my favorite areas to contribute is tooling: both for developers and for customers. It's often that there is some friction between the system and what certain users are trying to do with it. Tools can extend the functionality of the system or integrate with it in new ways. This can reduce the amount of time that it takes to do a task. I like to look at what the team is already doing and see if there are opportunities to automate that.

Technical Management

I love working side-by-side with other developers to help them accomplish their tasks and grow their knowledge. I can set technical objectives for them and guide them towards success. I hold technical 1:1s to review progress and see if there are insights that will help unblock their work. While I can speak to technical aspects of working with other developers (such as expectations around code review), I'm not the best person to help resolve interpersonal issues, review one's performance, or help make the most of benefits. These are topics best served in a people manager role and I'm happy to assist on purely on the technical side.

Code Review

A strong engineering practice is to have a team member review code that another team member is writing. This shares knowledge about what is being built, helps spot bugs early, and can identify future performance or architectural limitations. A reviewer can have a strong influence on the success of a project and can guide junior or newer developers towards good outcomes. Reviews can also be a source of contention, nitpicking, and stalled progress. I can guide this process so that reviews are valuable, informative, productive, and hopefully fun. A lot of my philosophy here is influenced by my time at Google where I participated in hundreds of code reviews where I was both author and reviewer. I've adapted that to smaller organizations, where code review is equally important.

DevOps

Running software in production today is more and more being handled by developers, as opposed to a dedicated team of system administrators. Developer-led Operations or "DevOps" requires knowing cloud platforms, operating systems, networking, software packaging and deployment, security, monitoring, logging, and more. This is a focus area of mine. I've worked in this capacity several times in startups. I was able to observe Site Reliability Engineering at Google and see how to bring engineering techniques into operations. I've gone as into the weeds as running a 14 machine Kubernetes cluster on bare metal for a home lab. I have a strong understanding of Google Cloud Platform as a prior engineer there.

Product Management

Good product management is a difficult skill to come by because it involves communicating and understanding both customers (who can be vague, hard to read, and uncertain) and the technical team (who are working with highly nuanced and jargon-heavy technologies). Although I haven't worked in this role directly, I have been around a few skilled product managers and have also seen plenty of ways could be done better on teams with weak product management. Particularly for early stage projects, I'm happy to fill this role by planning work items, researching customers, prioritizing features, estimating timelines, communicating product launches, etc.