Increasing engineering productivity with Albert

Young, Scrappy, and Hungry is Typedream’s podcast where our founders talk about the product, stuff they’ve learned along the way, the founder mindset, and things they think about as immigrant startup founders in Silicon Valley.

Spotify: https://open.spotify.com/episode/33YA2yv08WOJKQvGgT4nu4?si=cd71b01ad99a4556

Apple Podcasts: https://podcasts.apple.com/us/podcast/increasing-engineering-productivity/id1678220914?i=1000605116710

Full Transcript

It's currently 03:00 a.m. here. Michelle has been asking for a podcast episode from me for the past week. Thank you, Michelle, for being such a pain in the ass. Anyways, I think there are plenty of product-related stuff out there, just like Putri’s and Michelle's podcast. So go check them out if you haven't. But not really enough technical stuff for startups. Or maybe I'm just not reading enough. I don't know. But yeah. My name is Albert. I am one of the co-founders here at Typedream. On this episode, I'll talk about my experience in increasing engineering productivity.

So Tydedream was built around two years ago, maybe three. I'm not sure. The MVP was built in around a month or two, I think it was incredible work by Putri. The MVP was working quite well. There were, of course, a lot of bugs, but that should be expected. But when I started to contribute to the code base, it took me a while to be able to contribute anything significant. I was only able to fix bugs for weeks until I can ship features. Sure, there was zero documentation, but that's how most startups are. Documentation works better when there's more than one person reading it. Yeah.

So one of the biggest challenges in engineering is to break down large, complex tasks into smaller, more manageable tasks. I think our mistake with the MVP is that we coupled a lot of these tasks together so that it becomes so big that one line of change can affect some other thing that doesn't really seem to be related at all. This is bad because in order to contribute something meaningful, we need to understand a big portion of the system. The code base essentially has a really high barrier of entry to contribute.

So what's the solution? I don't know. But here's a part of the solution that had worked for us. First, we keep it stupid simple. We don't refactor code unless we absolutely need to. Why? I think we can agree that every time we make a change, we don't like looking at all the references of the functions that we changed. This should also help build MVPs faster. Just copy and paste. The code base will be huge, but hey, who cares? More lines of contribution, am I right?

Second, we identified the core of our product, make strong abstractions around it, and modify it if absolutely need to. So for us, this means separating the code where you edit websites and the code where you show the websites. This helps break the code base into smaller, more manageable pieces.

Third, feature flags. If you're a startup, chances are you're going to experiment a lot. We created a simple file that keeps track of our feature flags. Be careful though. We had too many feature flags at one point, and it was getting pretty confusing. Make sure to clean these regularly.

These things help me and my team become more productive. Hopefully, this helps. Let us know if this series is helpful to you or anyone so that we can make more of it. All right. Cheers.