Posts

I find myself constnatly referencing great books, blog posts, and podcasts, then sending them one-off. Here’s a list of my favorites. Engineering System Design for Recommendations and Search - fantastic overview of core retrieval to ranking steps of modern pre-LLM recommendation and search systems. I directly used ideas from this at Amazon to improve homepage recommendations. Author recently followed up with Improving Recommendation Systems & Search in the Age of LLMs Patterns for Building LLM-based Systems & Products - similar to above, with a focus on LLM systems. Directly used learning here for Shopping Guides. Author summarized all LLM lessons in the much broader What We’ve Learned From A Year of Building with LLMs Microservices - parody video spoofing microservices architecture that is too real. Worth rewatching anytime you think “we’ll just make this a microservice” The Missing README - canonical book to give to new software engineers. Covers core concepts of using git, testing, doing code reviews, safe deployment and more. How Big Tech Runs Tech Projects and the Curious Absence of Scrum - specific methodologies don’t matter, autonomous engineering teams create a plan and execute, with product focused on strategy of what to build, not delivery. Migrations Done Well: Typical Migration Approaches - multipart guide to successfully architecting, planning, and executing a migration. Leadership ...

People are familiar with the prisoner’s dilemma in game theory. This is a setup where two accomplices are caught at the same time. Police separate them and give each an offer: to defect on their accomplice - meaning blame them, or to stay quiet. If you both stay quiet, the police have nothing on you except petty crime, and you’ll go to jail for 3 months. If you both defect, they’ll have proof on both of you, and you’ll both go to jail for 1 years. But if one defects and the other stays quiet, the one who defected will walk away with no jail time, while the one who stayed quiet will get 3 years. See game theory ‘payout’ matrix below. ...

Economics has a concept of the market for lemons about information asymmetry. In a market like used cars the seller has more information about the quality than the buyers. In these markets, the price converges to the average price, essentially making all lemons (bad cars) too expensive, but all normal cars too cheap (at least for the seller) as the market prices on expected value. The canonical approach to increase efficiency is to add various 3rd party inspections for quality or to have the seller provide some warranties or guarantees on quality. ...

Continuing my exploration of llm assistance in coding, I decided to try to fully build an app end to end only via vibe-coding in natural language, no actual code. I did this mostly through the composer feature in cursor. I had a lot of fun! In particular, it collapsed the time I took from idea to working app from ~20 hours to ~2 hours. You can check out the app I built here: Why are stocks up? which is a question friends have asked me for years (don’t worry, I also have whyarestocksdown.com). ...

I host this blog on AWS with S3 and cloudfront. It’s built using Hugo a fun open-source static site generator. I picked this setup originally after reading reddit threads recommending various static site generators, like this one. It was an excuse to learn some new tech, but I also wanted to pick something that was simple to learn and easy to deploy. For the past few months I’ve been using Cursor for my side projects. It completely changes the experience of writing code. Instead of the OODA loop of googling, reading docs, writing code, testing, reading reddit, checking stackoverflow, googling again, you ask an AI. You live in the IDE. And you notice that Cursor, using LLMs, is much better at writing code in popular languages and frameworks. I assume this is because the models are trained on open-source code and documentation, and the more that exists the better the LLMs are. ...

Updating this post after 2.5 years at Amazon to add more more learning… Original post from September 2022. Here is the most important lesson I learned in each year of work thus far. 2011: Software Engineer –> Designing a Data Warehouse is a technical and usability challenge. Ideal to have a single very wide table at lowest level of granularity (view or physical depending on database). Everyone messes up joins. Avoid duplicates. Pick descriptive and long column names. 2012: Solutions Engineer –> Cohort analyses are extremely helpful in understanding your customers (e.g new/loss/gain/churn over time). When in high-SKU domains (e.g eCommerce) product affinity analysis is also extremely valuable. 2013: Sr Solutions Engineer & first management role –> Engineering leadership must be done from the front. Communicate consistently and clearly explain priorities. If the team is staying up all night for a release, you are too. Hold yourself to the standards you hold the team to. Get coaching and learn. Listened to Manager-Tools Podcast and learned “When you tell a group of people something 7 times half will say they hear it once” 2014: Technology needs its own multi-year vision. Company, product and/or customer driven roadmap is not enough. Focusing on a core customer goal (High Availability for our largest client) led us to a multi-year delay in a more long-term important technology requirement for our business (native AWS). 2015: Director –> $500million acquisition! I led product demos + technology due diligence with prospective buyers. Before the deal closes there is a multi-year investments in relationships, clear narrative, consistent performance against prior commitments, demonstration of deep bench, and enthusiasm of all the principals. 2016: When something is working let it rip! I served as engineering + product leader for a segment of our business that hit $10m ARR in 18 months from launch. With just 3 engineers (and ~5 GTM folks!). We did this with extreme focus on customer needs, good early architecture decisions, and a very cohesive and strong team. Once growth hit this inflection point we should have invested dramatically more to define category and deepen moat against incumbents who had more distribution. We grew business to ~$25m ARR but it could have been $100m+. 2017: VP –> Recognition is the ultimate incentive. Money is a critical form of recognition (especially in a competitive market!) but in the end most people strive for status and recognition. Culture is defined by recogition and created with thoughtful org structure and operating cadence. Critical when balancing mission vs functional teams, creating career ladders, deciding compensation, and in creating org rituals. 2018: SVP –> The faster you need to execute the fewer objectives you must have. Narrow and prioritize. Then cut again. Dramatically increase expectations of quality and speed while dramatically decreasing number of projects and ‘decision makers’ 2019: Sr PM at Slack –> Small companies have drama, big companies have politics. Understand the coalitions and competing goals. With many Type A people getting things done requires (1) willingness to heads down make decisions and ‘ask for forgiveness’ or (2) building coalitions for your cause. Know which strategy to employ in which circumstance. 2020: Brands matter. A brand is the expectations and emotions people associate with something. McDonald’s brand is so strong because it is consistent. Work to clearly communicate consistent expectations of your project/team to stakeholders (and follow through!) 2021: Proximo –> Stated vs Revealed preferences are very different. Social desirability bias is real. Potential users unintentionally lie during user interviews to (1) be nice to you and your ideas, and (2) showcase the best aspirations they have for themselves. Be careful to suss out true challenges and avoid solutioning too quickly. 2022: Proximo –> People respect tough decisions that are made with clarity. Customers, employees, investors all understood decision to shut down Proximo. I also strived to take care of people - getting the team great jobs, returning remaining capital to investors, and helping customers find alternative solutions. 2023: Amazon Sr Software Engineer –> After 10 years in management joined Amazon as a Sr IC writing code again. Reminder that you can just do stuff, even for big companies. Keep finger to pulse on technology, took external idea from papers/blogs, built working prototype, and proposed new personalization system that ultimately improved CTR for homepage recommendations. 2024: Amazon Software Development Manager –> Back into management, this time leading AI Shopping Guides from prototype to public marketing launch. Learned how to build high quality accurate products using LLMs, manage the scrutiny of high profile projects, build 0 to 1 teams in a big company and, mostly, move very very fast.

Transitioning from startup to larger companies can be a huge shift in mindset. I made the shift from a 250 person startup (I had worked at from 30 → 250) acquired for $500m to Slack in 2018. Slack was then a pre-IPO company with 1200 employees (grew to 2000 in 18 months). I struggled! It was significantly different and harder than I expected. In personal conversation with startup friends transitioning to larger companies I’ve given advice on how to handle this better than I did. I decided to type it up for re-use. Like most advice this is a form of nostalgia so YMMV. ...