Reflections on leading my first major project
& how we actually learn -- it's not deliberate practice.
This is a bit different. Let’s quickly discuss changes to the newsletter before we jump into the good stuff.
First of all — the newsletter has moved to Substack! Tinyletter has been giving me issues with spam, replies not going through, and more. Substack seems to be a more reliable platform.
Second, the format. This is going to be more of a roundup newsletter. I’ll be linking to my own blog posts as well as some of the best stuff I’ve read recently. I’m not trying to overwhelm you with links, so this will be very curated.
I hope this new format goes well. As always, I’m open to feedback.
In case you weren’t aware, I work on the Booking & User team at OpenTable. That means we do the front-end development for the increasingly complicated checkout process when you book a reservation on the site. If you’ve ever used OpenTable, you’ve definitely seen my work.
Our team is very large (~10 engineers) and uses a pod model to work on multiple initiatives at once. We elect Project Leads to work on coordinating between back-end, design, product, etc.., make tickets, and to unblock the rest of the pod team.
I was recently put in charge of my first major project, which I’m not sure I’m allowed to disclose publicly since it’s still running behind an A/B test. Let’s just say it’s a huge fundamental change to the user flow and will easily affect tens of millions of users within the next few months.
I’ve been wanting to document more thoughts about my work and the processes my team has decided on. So, what better opportunity is there than the first time I’ve led a project?
There were so many unforeseen challenges throughout these past few months. Ultimately, it was a successful launch and I’m really proud of the work I did, but hopefully you’ll learn from some of my mistakes and maybe even some of my good choices as well.
After the glow of a promotion and being heads down on a huge project for the past 2 months, I just started processing my growth actions that I want to track moving forward.
As always, it’s easy to fall into the convenient trap that some book or some trick will be the key to unlocking the next level. If I read one more blog post about code katas, I’m going to quit the internet.
Instead, I suggest reading a practitioner’s take on how to learn. I’m a huge advocate of tacit knowledge, and a lot of the goals for my writing involve trying to impart some of the hard-to-summarize insights that I gained from tacit knowledge.
If you’re deep in the pop-psych scene and read all the Malcolm Gladwell books, consider actually trying their ideas out and seeing how they work in complex environments like programming. I’ve found that the best way to build expertise is to just pay attention in a challenging environment with quick feedback loops.
🔥 Hot take of the month: 🔥 I’m tired of being sold ebooks from engineers with less than 5 years of experience — just because they reached a specific title or they have a lot of followers on Twitter. Titles are important, but they’re so subjective to each company that trying to generalize that knowledge for money makes you a con artist.
If anyone thinks that my advice from having reached 5500 Twitter followers / 1000 newsletter subscribers & getting a promotion within a year and a half of joining a company is worth a $30 ebook, please just donate that money instead.
As always, thank you for reading! I hope this was helpful to you. If not, let me know. You can always reply to this email directly to reach me.