I’ve recently been cranking on improvements to this site and a personal blog with Claude Code, and boy howdy, developing with AI is fun. I write this as a followup to my last post about building with AI. Once again, I can’t promise any brilliant tips or tricks, and once again, this will be laughable 6-12 months from now when the state of the art has changed once again.

In July, I joined two of my cousins and two of their friends on a 500-mile ride from Target Field in Minneapolis to Wrigley Field in Chicago over the course of a week. Cousin B had just left a job after 16+ years and was doing a 2026 bike tour frenzy, so why not ride to Chicago to see the Twins play the Cubs? On a personal note, my cousins’ mother (my aunt) died of colon cancer 20 years ago, and all five of us had been impacted by cancer in a meaningful way, so we decided to make the trip a fundraiser for cancer research.

In my advisory work, a common question I get from leaders goes something like, “how do I get my engineering team to care about [customers, shipping faster, quality]?” Their team is chasing the latest AI tool from Hacker News, polishing a low-value refactor, or holding an unstated quality bar that slips a deadline, and everyone is frustrated.

As much as I enjoy writing software, I generally won’t unless I have a particular problem to solve, even if it’s a manufactured and silly problem to solve. I’ve been itching to try out this newfangled way of working with AI development tooling, and I finally found a complex problem to try it out!

Of course, you can’t spell Matt Spitz without AI.

From April to June this year, I rode my bicycle across the United States, from Washington DC to the Oregon coast. The ride was solo and unsupported, meaning that I rode by myself and carried everything I needed on my bicycle. It was an incredible adventure and one I’ll never forget.

Earlier this month, I rode from Crescent City to San Francisco. Together with my 2009 ride from San Francisco to Los Angeles, I’ve now cycled almost the entire California coast.

I like to frame employee retention as tent stakes. When pitching a tent, one hammers tent stakes into the ground to keep the tent from blowing away in a brisk gust of wind. Similarly, in one’s employment, there are specific reasons, articulated or not, why someone sticks with a company. When reorgs, strategy shifts, and market downturns start ripping up some of the tent stakes, as long as someone has enough remaining in the ground, the tent doesn’t blow away.

It’s been about a decade since I’d relaunched this site on Jekyll, and the poor thing needed a visual refresh. The site was too text heavy, and the CSS was hacky and forced. I just rewrote tgifunk.com and kept up the momentum to redesign mattspitz.me. I’m still not a web developer, but I like to think that the code and the design are much cleaner than they were.

I spent a lot of time at the West Portal library branch growing up, and when I went inside a few months ago for old time’s sake, the man behind the desk offered me a San Francisco Public Library Explorer Map. The map of San Francisco has a little gray circle for each of the city’s 27 libraries, at which one can pick up a unique sticker for that library. I’m currently unemployed and love silly challenges, so I decided to collect each sticker by bicycle.

Every few years, I update a document that lists my values, my modus operandi, and a few fun facts.

Product engineering – developing software that meets a customer need – is a skill that is developed rather than taught. When deployed effectively, strong product engineers have extraordinary leverage, crossing crossfunctional boundaries and getting (a lot of) stuff done.

I recently presented an introduction to retrospectives at Vanta as a tool for teams to use in a hypergrowth environment. The presentation was well-received, so I’ve converted it into a post in it’s interesting to others, too!

I’ve had a few major inflection points in my career as a manager. Previously, I’ve written about managing without domain expertise. Recently, I’ve had an opportunity to reflect on another: management beyond relationships.

Many people I’ve met professionally are ambitious and crave feedback to accelerate their growth. Unfortunately, these people are often frustrated by expecting and not getting feedback from their manager.

This is an evolution of a prior post about remote work. Many are working remotely now, thanks to COVID-19. I’m assuming this will be more of A Thing™ going forward and decided to refresh my thoughts.

An important part of a manager’s job is to develop the capabilities of those in her reporting chain to deliver more impact to the business in the long run. This requires understanding the career aspirations of her teammates so she can stretch them in ways that are motivating.

At the risk of stating the obvious, being an engineering manager (EM) and an individual contributor (IC) are different jobs. An IC is responsible for developing high-quality software that serves customers’ needs. An EM is responsible for ensuring that the company’s resources are leveraged effectively to achieve its goals. Managers concern themselves with ensuring that their team’s processes are effective, that people are in high-impact roles, and that those in their reporting structure are growing to deliver more impact in the future.

Developing complex software at scale almost always requires coordination across potentially many teams and functions. People are people, and every now and again, such coordination results in disagreement or conflict. For example, an engineer might disagree with the user experience proposed by a designer. Or, a team responsible for a key dependency for a project may not share the project owner’s prioritization of that dependency, risking the project’s timeline.

There’s a natural tension between quickness and quality in early-stage product development. The faster you build a product, the sooner you can get feedback and iterate towards what users want. If you move too quickly at first, you risk the maintainability of the code and can end up spending all of your development time fighting fires due to all the shortcuts you took.

A team’s culture is its most valuable asset, especially in a dynamic industry like tech. Values and traditions enable teammates to trust one another as they adapt to growth, looming competitors, and evolving strategies. Particularly for small teams, maintaining a high bar for culture is critical to its long-term success. Unfortunately, a “culture fit” interview usually amounts to taking someone out for lunch (or worse, beers) and seeing if they play nicely with the team.

My team has been investigating the impact of potential performance improvements on the web, and since I only code off-the-clock these days, I wanted to try my hand with some newer technologies, too.

Since I put my silly Turn Down For What in the Google Play Store last year, it’s been downloaded 92,000 times. Today, over 11,000 people have it currently installed on their phone. Ridiculous. I spent two hours on it, and now it’s all the rage in Spain and South America. The internet is a crazy place.

Sometimes, your job sucks, and it’s time to move on. Maybe you’re looking for something new and the company can’t provide it, or maybe something bad happened that’s the extra push you needed put in your notice. It happens. However, in finding something new, it’s important to differentiate leaving your current job from finding a new job.

Sometimes, when I interview someone, they’ll mention a favorite piece of technology (a common one these days is Go). Once they’ve discussed its merits, I ask them what they don’t like about it. Not being able to come up with a downside indicates a lack of experience.

In the last five years, I’ve been a founding member of three New York engineering offices for companies based in the Bay Area (Meebo, eBay, and now Dropbox). Along the way, I’ve learned some of what makes a remote office successful, and often, what doesn’t. The ideas I’ll share in this post come from firsthand experience and discussions with coworkers at headquarters and in remote offices around the world.

I’ve had a number of conversations with current students looking for their first job out of college, and I find myself sharing the same advice. These points are particularly applicable to new grads but are worth keeping in mind throughout one’s career. I’ve had these discussions in the context of tech and startups, but this advice isn’t necessarily specific to that industry.

In 2010, Mark Zuckerberg famously said that the key to success is to “move fast and break things.” From an external perspective, “moving fast” means shipping new features and products at a healthy cadence. Internally, an engineering organization moves fast when its engineers work on problems of value as efficiently as they’re able.

I’ve recently changed the way in which I handle passwords. Some folks have asked me about it, so I figured I’d share.

When I was in high school, Kazaa was everyone’s primary source of pirated music and viruses. I made a reasonable amount of money fixing virus-infected Windows XP machines for friends-of-friends. I’ve been proud to say that I hadn’t (to my knowledge) been affected by a virus. Sadly, my streak came to an end this week. And on my Linux desktop, no less!

One of the challenges of web development is figuring out how best to use the browser’s download cache. When you surf the ‘net, if anyone uses that term any more, webpages and images aren’t downloaded every time you access them. The browser saves that extra work, time, and bandwidth by caching resources – images, pages, scripts, and styles – it’s already downloaded. But what happens when you DO want the browser to download a new version? Say you updated an image and want to make sure that the user has the latest content. How do you instruct the browser to download the new version?

Tech companies will often include some sort of equity in their compensation packages. It’s an excellent way to motivate employees, as they’re literally invested in the success of the company. How that equity is distributed, though, can have a massive impact on incentives and team culture.

As of today, I’ve officially migrated this blog from Tumblr to Jekyll. Finally!

One of my favorite essays is The Rise of Worse is Better by Richard Gabriel, which describes the distinction between what he calls the “MIT approach” and the “New Jersey approach” with respect to software development.  In short, the MIT approach is about solving a problem correctly and completely from the start.  That is, every possible use case and functionality is carefully designed up front and the result is a beautiful, complete piece of software.  The New Jersey approach, which Gabriel describes the philosophy behind UNIX and C, is to build systems iteratively, perhaps at the expense of building the perfect solution.

Building Hoot showed Christina and I the ugly side of Android fragmentation. Hoot is currently running on over 1600 different device models on five different versions of the Android OS (>= 4.0), and it makes extensive use of the hardware: multiple cameras, the light sensor, and the orientation sensor. Unsurprisingly, given the number of different configurations, we’ve seen some weird behavior: crashes, incorrectly-rotated videos, and even videos recorded in sixplicate!

In the last few months, I’ve been building Hoot, a private video messaging app for Android, with my business partner Christina. Part of a video messaging app is hosting and serving – you guessed it – videos. Hoot’s videos are served off the filesystem by nginx on a shared media server, separate from our application servers that process Hoot’s API requests.

Hiring good engineers is really, really hard. These days, it’s a seller’s market, and a top candidate will almost certainly have a number of competing offers with all sorts of shiny perks. I’ve done some hiring in the past, and I’ve tricked some great companies into letting me work with them. For whatever reason, I’ve had a disproportionate number of conversations about hiring and being hired recently, and I figured I’d share some nuggets that have come up.

I ordered the new Project Sputnik laptop from Dell to replace my six-year-old MacBook. It’s basically the most-tricked-out version of the XPS 13, running Ubuntu 12.04 instead of Windows 8. I won’t get into why I dislike Apple’s OS, but I run Linux on my desktop and on any server machine I login to, and I enjoy a consistent experience. The most appealing part about Project Sputnik, as opposed to installing Linux on any ol’ Windows laptop (or a MacBook, for that matter), is that it includes a Dell-managed PPA for the hardware. In theory, this means that Dell is committed to making sure that the laptop’s hardware “just works”.

The phrase “application programming interface” (API) is officially quite generic. It encompasses interactions between software components as tight as data structures (e.g. C++’s standard template library) and as loose as structured queries over the Internet (e.g. GitHub, Yelp, Yahoo! Finance). A piece of code that exposes an API offers a contract with its clients: “if you interact with me in this particular way, I will perform these actions or return this data.”

I came home from Thanksgiving with a bloated stomach and few enormous files that I planned to back up on my home computer. These files were on the order of ~100s of GB and left me only about 30GB free on my laptop hard drive. And now, fair readers, I will share the harrowing tale of… The File That Wouldn’t Fit Twice. Using a couple of electronics tricks learned in ME210, I ended up with a pretty neat solution to transfer these huge files to my server.

My grandfather is an impressive man for a number of reasons, but one thing that continually amazes me is how curious he is. He’s a voracious learner, reads everything, and figures things out on his own. In general, computers are more difficult for grandparents. They constitute a paradigm shift in how we consume and produce information, and the more people are ingrained in traditional means of doing so (e.g. print, television, radio), the more difficult it is to start using computers.

I’m going to go out and say it. I love unit tests. Hopefully, by the end of this post, you will, too. I’m not going to cover the pros and cons of various frameworks in each language, the best way to mock out data dependencies, or even the secret to writing impeccable unit tests. There are enough resources, and I hope that you’re inspired to seek them out. In case you aren’t convinced that unit tests aren’t the best thing since sliced bread, I’ve brought my old friends from Office 97, the Screen Beans people, to help me.

Recommendations have been all the rage for the last couple of years now, and since I’ve been working for Hunch (now eBay), I’ve been thinking about why they’ve become necessary and the value good recommendations bring to the piles of content on the Internet.

Over the last few weeks at Hunch, we’ve switched our version control system from Subversion to git. I’m not an expert on git by any means, but, since I had more knowledge than most and an interest in making the switch, I ended up with the responsibility of getting us across the divide with as few showstoppers as possible. A number of development teams seem to be doing the switch these days, so I figured I’d share my experience and lessons learned to ease the transition for others.

For many years, particularly for web applications, the only real option was the ol’ RDBMS. Their primary query language, SQL, is possibly taught more than any other language. Recently, a number of alternatives to the traditional RDBMS, collectively termed NoSQL, have become rather popular. Boasting horizontal scalability and incredible speed, open-source databases like MongoDB, CouchDB, Cassandra, Riak, etc, have attracted much curiosity within the development community, and more projects are started with a NoSQL backend rather than a traditional RDBMS like MySQL.

Well, I’m back. And, much to my surprise, I made it to LA without any serious issues along the way! It was an amazing, amazing trip, but I wasn’t sure at all that I was going to be able to do it. My bike was relatively-untested, and before I got it, I hadn’t really gone on a ride over 40 miles long. Seven days and 470 miles later, I’ve done some of the best rides I’ve ever been on. Wow.