v0

I feel like a kid again.
I feel giddy.

I’m grinning as I code and smiling as I sleep.
I’m having fun — and feeling free.

When I describe what I do, the most common word used in response is “grind.”
They ask “so are you on the grind?” as if I was on ketamine or Wegovy.

My answer is “well, kind of, yes, I do work a lot, but I don’t grind either.”
And to that, the crickets chirp.

My schedule is admittedly hard to adhere to.
As a first date kindly put it before, it is “psychotic.”
I do work hard, and also understand, that for most people that isn’t such a good thing.

Work is the shit-of-life that you have to put up with.
It’s what keeps you from going home, saps your time and your days, and stops you from doing the things you really enjoy.

So it’s strange to see someone who loves work and is unabashed about it too.
I don’t typically attempt to explain myself, being happy not being understood, but I’ll try for a bit today.

There is a joy in building things.
Building things is incredibly frustrating. You are presented with many choices and have to puzzle your way through each. You make certain decisions on premise of logic and others on principle. But bit-by-bit, you progress. You see your ruminations take shape, your ideas take form. That tech bet you took paid off, those hours you spent optimizing that function were worth it.

And then you see it.
You see what you built work end-to-end. It’s shitty, and you know its faults better than anyone, but you can’t help but be proud of it too. You know how it works — each and every interaction there, and while that doesn’t mean much to others, to you it does.

You built something.

This week, we got that feeling of glee.

A month ago, we set the date of January 31st to get end-to-end.
That habit precedes us from our time at Amazon, where a dogmatic and charismatic principal engineer taught us the importance of dates.

We take dates seriously.
As I was once rebuked, “if you say something and don’t deliver, your word becomes worthless.” But despite the fear around missing a date, we still set them and set them frequently.

Constraints bring about clarity and a date makes the abstract concrete.
It is far too easy to fluff around developer estimates and engage in political non-speak in planning meetings. But as soon as you set a date, as soon as you start looking at the code and thinking through what needs to built, everything moves.

We tend to set rather ambitious dates.
What was initially in-scope for January was the fully-working git server with authentication done properly and all core features implemented (i.e., file browser, grep, questions, bug reports, and pull requests).

We failed to achieve all that.
We had a number of setbacks: a bike accident, benign proximal positional vertigo, and food poisoning, and spent less time working than we would’ve liked. But realistically, even if we were fully healthy for the month of January, it is unlikely we would’ve succeeded.

Things are always more complicated than they seem.
When we say things like git server or file browser, we have some sense of the work that is entailed, but never have the full picture prior. You can argue that it’s a question of depth and that if we took enough time and rigor to plan things properly, we would be able to guess accurately, but at that point, what is it really that you’re doing?

Accepting uncertainty is inherent in development.
Building takes time — and the reason why isn’t because of calculable costs (especially nowadays), but because the process is a creative one.

It requires you to iterate repeatedly, think differently, and try until you succeed.
And often times, you simply don’t know until you do.

You don’t know what’s important about file browsers until you build one.
You don’t know what’s important about git servers until you build one.
You don’t know what’s important about issues until you build one.

So build.
Set dates, be ambitious, accept the unknown, and get after it.

To end on a tangent, there’s this notion of a “personal color” in modern Korean culture.

I suppose at its core, it’s some pseudo-scientific analysis of skin tone that tries to find the color that makes an individual look the best. Yours could be red, mine could be blue, who knows.

But I like the phrase as there’s no direct corollary I’m aware of.
It is a color, or more broadly, a thing, that makes an individual shine.

Dev tools is Mikkel’s personal color.
He’s always been quite prideful and perfectionist about his code. In many cases, that’s more impractical than not, but dev tools seems to be the space where that truly shines.

Between bouts of vertigo, he spent his days reading git source code out of this fear:

Anywho.
There is a long laundry list of to-dos that are assaulting me, but getting end-to-end feels good nonetheless. We’ll make a slightly more public link soon, but for now, enjoy a preview: gitdot.io/beta

Thank you
—baepaul.