Casey Kolderup
About Me
Hi! I'm Casey Kolderup. I live in Portland, OR, USA. I'm a software developer, a music lover, and a fan of art that can fit a mystery or a puzzle into it. I like making things, writing, and trying out new restaurants. I have a deep love for the 1996 film Big Night, the Super Nintendo game Earthbound, and the songs of Jason Molina.
I'm also... looking for full-time work! (pulls a big lever labeled ACTIVATE HIRE ME MODE)
Hire Me
Since the mid-2000s I've been working as a software engineer. Most recently, I wrapped up a four-year stint as a Staff Engineer on Glitch, the platform where everyone built the web, at Fastly. Before that I got to work with great people at places like Discogs and Vox Media. I've helped build great products, led teams of engineers, built and maintained public and private APIs, and overall have been very lucky to work with people who made me want to:
- do quality work
- pull off fun tricks
- learn everything necessary for both
- speak up for what's right, and
- advocate for all of us to do all of that
My job title usually looks something like "full stack engineer" or "product engineer". My work experience tends toward the backend, especially around the API layer, but I like having the opportunity to keep up to speed (and be helpful) on some amount of frontend development and I appreciate the freedom/autonomy afforded by doing a little bit of infrastructure/ops work as well.
This next bit could maybe sound like some kind of hot air about what a good team player I am but hopefully by writing this disclaimer I'll make it clear that I actually believe this is the important part of what finds me work where I'll be happy and productive:
I like a good technical challenge but I'm of the opinion that the best work I do is the time spent collaborating with product managers, designers, user researchers, and other engineers to make sure we all actually understand the work that we're doing. I think this step, and then rigorously working through a process that translates that understanding into useful changes, is a solid path to good work. Trying to take shortcuts or avoiding the work of understanding is the most common path to high-churn, high-incident, discouraging work.
I hope there's always some amount of coding in my job but the times that I have found the most success I have had a lot of other responsibilities that, in my mind, have to come first: communicating, writing, arguing (respectfully!), presenting, thinking about team structure and processes, and building community among teammates and across teams within a business or partnership. I think if you sacrifice these things, the output of the coding work will either suffer or be limited in its impact.