One of PostHog’s values is that everybody codes. That doesn’t mean everyone needs to be a developer, but we do encourage everyone to practice the basics of shipping, no matter their role. Even site updates require GitHub and some basic knowledge of coding, for example.

But, of course, you may know that already. I wrote about it a year ago, when I joined PostHog. Back then, my coding knowledge was limited to just a smattering of HTML.

Not anymore. PostHog is still unlikely to consider me a good candidate for an engineering role, but I’m much more confident with code. GitHub is no longer foreign ground and yesterday I juggled React, Javascript and HTML in a way which mostly worked!

In my previous post I wrote about the three principles that set me up for success, but now it’s time to reflect on what’s helped me succeed since.

Having unrealistic goals

In my last post I said it was important to set realistic limits and that’s true, at the start.

However, it’s also been important to follow less grounded ideas. One example is the ShuffleHog — an idea I had for a hackathon project which is essentially a shuffle button to help you discover new insights. I thought ShuffleHog was a fun idea, but nobody else latched on to it.

If I’d stuck to realistic limits, that would be the end of it. I can’t build a product feature on my own, can I?

It turns out that I can. Late last year I made a ShuffleHog prototype on Twitter, coded in Tracery. That lasted until Marius added the ability to make front-end apps in PostHog last week. 24 hours later, ShuffleHog now lives inside PostHog as a beta feature that can suggest random query ideas.

ShuffleHog still isn’t quite ready for other users to try yet, but who knows? Maybe I’ll keep following this dream.

(Keep) making mistakes

One thing that hasn’t changed over the last 12 months is the importance of making mistakes — and I should know. I make a lot of them.

The reason mistakes are so important is, I think, because coding isn’t a prescriptive discipline. There’s no single correct way to code or write, so it’s more valuable to know why something broke than how it ‘should’ be done.

Breaking things is a great way to learn about how to fix them. PostHog recently rebranded plugins to apps and, as part of that, we launched a new apps library. I broke a bunch of things while working on that project — but that's OK because I managed to fix most of them (with occasional help from Eli) and carried those lessons over to the ShuffleHog project.

Take it offline

Something I’ve loved about becoming more confident with code is that I’ve been able to follow this passion outside of work. This creates a feedback loop where I get even more excited about what I’m learning and what I’m able to do, so I bring that energy back into work…where I also learn and do more. It’s very satisfying.

The experience I’ve had with GitHub, for example, ended up being the catalyst for me to build my own arcade emulation machine at home because I now had the skills to fork and tweak certain repos. Likewise, spending time in the world of open-source software led to me playing around with a lot of Raspberry Pi sensors at home.

These may be small projects, but they’re a million miles away from where I was before PostHog — and I’m excited to see how much farther working with code will push me to go!

Enjoyed this? Subscribe to our newsletter to hear more from us twice a month!