Posts

If you’re using React to build a web app or a React Native mobile application, chances are your app has a handful of initialization tasks: things that always need to happen before the main application mounts and runs. Some examples of these responsibilities include: Loading previously-saved settings. Creating global-ish objects, like a single shared API_CLIENT instance. Deciding whether the user is logged in, and fetching their current profile if so. Checking whether there is a newer version of the application available. For this type of work, there’s a handy pattern I always end up using, which leverages React Context Providers to streamline things. I call it the “bootloader pattern” because it reminds me of what low-level hardware bootloaders do to start up real machines, but that’s just my cute name for it. ...

If you are the technical co-founder or early engineering lead at a startup, and you want to talk about your microservices, hand-rolled CI/CD, in-house monitoring stack, or any other unique part of your stack, I will say: Cool. Let’s riff. Take me deep, I’m ready. But there’s something I’m likely to tell you in return, something I’ll probably insist you’re overlooking and need to internalize as soon as possible: Your technology stack is not the product. ...

When an impulse hits you that it’s time to move on, what do you do? Your next impulse might be to suppress and put off the feeling. If you’re naturally given to fighting and “making it work”, the thought of leaving may be so unpleasant and unwanted that it’s all around just easier to kick it away for another day. Yet delaying the right decision has its costs. I probably don’t need to tell you that staying in a bad situation will often negatively affect one’s creativity, growth, and even mental health. And at the very least, it will delay reaching your future potential. ...

When building at a startup, sometimes you envision an ideal solution first, making it hard to see anything else. “Do the low-tech thing first” is the rebuttal to this. It’s a simple team value that challenges the sneaky and wasteful instinct to over-engineer, over-analyze, over-anything-but-ship. Primarily, the expression means: give yourself permission to be simple and unsophisticated, when doing so works, and when the fancier option isn’t obviously justified right now. ...

Plenty of tech companies tout a cultural value of “fail fast”: Accept that you will make mistakes; make those mistakes as promptly as you can; and learn from them so that you don’t make them again. It’s a liberating concept and great value. But to truly succeed at a “fail fast” culture, it’s not sufficient to simply sit back and appreciate this value. You must also identify, and then root out, the causes of slow failure. ...

As a people manager or team lead, you are juggling multiple responsibilities. Two responsibilities that probably come with the territory, week in and week out, are: Prioritizing your time well. Creating visibility for your boss, peers, and team. Of managers I’ve mentored and supervised, most had an innate understanding that they must prioritize their time. But very few arrived with a system for creating visibility1, or even thought about that as a necessary function. ...

During the growth of a tech startup, the founding technical leader will likely make an important change to their organization: They will hire or promote someone to be the VP of Engineering, and redefine their own role and duties as CTO in the process. When I went through this process, although I sought and received plenty of advice, I didn’t find a perfect playbook for this change. This post is no exception, but collects and summarizes some of the key aspects of the change that helped me. ...