Keep a Record

My memory makes for a poor database.

I was looking through my resume and saw some cool things I had totally forgot about.

About a decade ago there was a game studio called United Front Games.

It was the first job I had programming full-time.

In the games industry no less!

I don’t remember any of those things.

I believe I did those things- I’ve only ever been punished for lying or embellishing on resumes/interviews/etc.

I stick to skillfully telling the truth.

And I do remember my time there.

But, it’s going on nigh a decade since that first game-programming job.

The things that have stuck with me do not correlate with that list of accomplishments.

I was responsible for this tool/pipeline thing that built the game and made it available for daily playtests.

It was this C# windows desktop app thing- multithreaded for some reason- that connected a Perforce subversion tool to a MySQL database.

On build, the windows app triggered an external C++ pipeline script.

Which would trigger a powershell script.

That would finally trigger a headless Unity3D build of the game.

All of it multithreaded for some reason.

From that moment I’ve never had anxiety about writing bad code.

I have hella angst about good software design though.

Funny how formative moments shape our career.

I figured out how that particular soup worked, improved and cleaned some of that mess up.

And being exposed to every damned language set me on a polyglottal path.

I’m pretty sure all that is captured in the point:

The other things I remember about that job:

Reducing 20 minute build times to 5~.

I wish I remembered the particulars, because those kind of improvements are bigly.

Think about it, 15 minutes saved for each dev building the game?

That’s actually huge in terms of net productivity unlocked.

The thing about those kind of tasks is that usually its just a ton of cruft that no one has had bandwidth to look at.

Usually in an area that isn’t all that critical.

I do remember doing completing a similar task at another SaaS I worked for.

Each customers store would have its own database on account sign-up.

The SQL DB would be created, then the history of every schema update would be applied on top of it until the latest schema was reached.

This is fine, until you hit the point where schema updates start taking north of 2 minutes.

The fix is relatively easy here.

Just take a snapshot of an empty, up-to-date schema, and using that during store creation instead.

Have to build some kind of automation to do this with every release, of course, I ain’t about fixing the same problem twice.

But this is the kind of cruft that pays real dividends.

Saving time for devs is nice and all, especially in today’s world of DORA metrics.

But saving time for customers? The ROI for those kind of optimizations rival new features.

Here’s the thing, as you progress in your career, you’re gonna forget the awesome things your past self accomplished.

Your memory makes for a bad database.

Do yourself a favor and list those accomplishments in a better database.

Honestly, LinkedIn actually provides some value here.

It’s literally just a list of the high-points throughout your career.

I would’ve remember even less about my time at UFG if I didn’t have that blurb I wrote a decade ago.

I’ve heard of people who keep a Victory doc in Google Drive or whatever.

Whenever they have a win, they put it in the the victory doc.

It’s easy to forget those little wins- some of which can be a big deal.

Personally, I’ve gone a bit hardcore this year in terms of keeping a record.

This is a Time Tracking database in Notion I use to record everything I’m doing:

It’s a bit much for most people, but it’s helped keep myself accountable and productive.

Since I’m unemployed, I have to keep myself working.

By keeping a record, I keep working, I stay sane.

So keep a record.

It’s one of those things that can pay real dividends.