Hi, I'm tef, I am available for hire, and I'm looking for remote work!
I'm currently looking for staff or principal level roles, ideally with a DBA or SRE-ish flavour, and preferrably as part of a small, product-focused, remote team. Although I live in the UK, I usually work in American timezones.
Previously, I've worked on large scale distributed systems, done on-call for almost a million databases, run coding workshops for children, along with less cool sounding work, like deleting log files, writing documentation, making tests deterministic, and helping teams run meetings to time.
After churning through several startups, I've lived through the growing pains of scaling out both a team and a product, and as a result, the highest impact work has usually been structural. Fighting for incremental change, removing pain points and obstacles, and trying to smooth out the process and tools so that everyone can iterate quickly within a project.
Even so, I still enjoy debugging the odd race condition or two.
I'm often found hacking away on Python, Bash, and SQL, but I've also worked on Go, Ruby, Java, and a variety of other tools and languages. I know a little too much about databases and replication for my own good, and I tend to work best somewhere behind an HTTP API and in front of a Posix API.
Although I usually work in automation, operations, or platform engineering roles, I'm more than happy to dive into the unknown, or more realistically, the undocumented.
If you aren't a third party recruiter, email me at tef@printf.net.
Write code that is easy to delete, not easy to extend, a rather short and contradictory blog post, talking about how engineering tradeoffs veer back and forth as a system grows in size.
Repeat yourself, do more than one thing, and rewrite everything, a follow up to the earlier post, examining how and where the usual rubrics fall down—often at scale—and why doing the opposite of what you've been told can pay off.
How do you cut a monolith in half?, talks about the pitfalls of publish-subscribe, and why you might not want to use it to glue your system together.
Write code that’s easy to delete, and easy to debug too, isn't so much about debugging, but how to approach writing code that makes debugging less painful. The secret is careful error handling, and thinking about recovery from the outset.
Scaling in the presence of errors—don’t ignore them, covers some of the gaps in the previous two posts, examining when 'fire-and-forget' becomes "fires and regrets".
The one good talk is called Programming is terrible, but it's really about the cultural and structural problems in our industry at large. I have no idea how an hour long talk has 1.6 million views on YouTube, but I guess it resonated with a few people.
It's hard to talk about the impact of my work, in many cases my biggest achievements have been preventing things from occurring, but that's how things work out in operations. As for more feature-dev work, I usually make other people go faster.
Building simple frameworks to handle cross-cutting concerns, introducing abstractions to remove obstacles, or even just documenting an API to speed up on-boarding. Simply put, I don't like throwing code over the wall, and my code is rarely an obstacle for future change—if anything, the work I do enables fast feature development.
All said and done, often the most impactful changes I've been responsible for aren't code or features. I push for structures that help teams focus on the work at hand.
I've worked on documentation, which enabled speedy onboarding along with lowering the cognitive overhead of maintenance. I've worked with people outside engineering to ensure we're delivering the features people want, in a way that actually works for them, over hitting abitrary criteria or chasing buzzwords. I've also regularly replaced spiralling ad-hoc meetings with living documents and templated agendas, a small change that helps people to run meetings to time.
Aside: A well run short meeting enables people to get on with their jobs, focus on what's important. A badly run meeting will drain everyone's morale, turning sprints into slumps.
In the end, I choose to measure my impact and speed as a developer by how much I can accelerate those around me. It's what I'm best at, too.
Hired to develop out a control plane for on-premises devices, mainly written in Go. Oversaw structural changes to the code, including building out a system for configuration managemnt, as well as reshaping the database to cope with new challenges. Oversaw procedural changes to the team, including pushing for living documents, templated agendas for meetings, and heavier automation of tooling.
Declared a 'secret manager' by several coworkers, the highest impact work was always social in nature. defusing conflicts, trying to prevent staff turnover, and unblocking high priority projects that had stalled.
Despite being hired to work on robustness and control plane development, due to the small size of the engineering team, a lot of the technical work revolved around feature development, often just removing roadblocks for future work.
I oversaw the migration of the product catalog from DynamoDB to Amazon Aurora. A small, internal product team, we oversaw an assortment of services cut out from the original monolith.
I handled the migration to Python 3 in my first month, before moving onto migrating off DynamoDB, without going offline. After that, my role moved towards supporting the other developers, along with a few other architectural changes to prepare for growth.
My lasting impact is a slew of tiny details: Choices that enabled zero downtime when the schema changed, pushing back on feature development which couldn't scale out, introducing data changes to allow for replication without guess work, and carefully documenting the remaining footguns that remained.
I was on call for almost a million customer databases. I worked on the in-house automation system for the database-as-a-service, during which time the team tripled in size. Along the way, I also handled support requests. I have explained the problems with page fragmentation in PostgreSQL more times than I can remember.
The most substantial piece of code I was responsible for allowed the rest of the team to charge forwards in releasing new features, as well as managing wide scale outages without tears. I also removed a lot of race conditions (more than I added, at least).
My lasting impact is probably: useful documentation, pushing the team to bring in juniors, and bringing just enough formality into the weekly meeting that it ran to time, every week.
I helped write educational materials for 9-11 year olds across the UK, some of which have been translated and used around the world. I got to teach children how to code at Bletchley park, work with other non-profits, and at one point I ended up dressed up as the Firefox mascot.
My lasting impact is that the course materials were published openly, rather than behind a registration barrier.
I got hired four months before a deadline and re-wrote 50% of the product to hit it (a long story). I built a distributed headless browser in QtWebkit, Python, and a lot of boilerplate. It replaced an earlier system using an unmaintained GTK+ port of Webkit and SQS.
While there, I implemented a reference library for the ISO WARC standard, and it's still used occasionally by the Internet Archive today.
My lasting impact was introducing dependency injection, allowing client specific code to be kept away from shared libraries. They had a lot of client specific code.
Mid-level, entry level roles
2009-2011, Cloudsoft: A Cloud Services startup. Java. OSGi.
2008-2009, Skyscanner: Replacing a JScript/VB6/XSLT driven web scraping process with python. Still in use today, but the real impact was being able to write code without editing production systems.
2007, Securetest: Penetration testing (i.e nmap-to-powerpoint), working on PCI et al compliance, and standard vulnerability testing.