When I’m running a team, I like to pass along the links from the dozen or so newsletters and feeds I follow for a few reasons: (1) encouraging growth on the team is important for everyone’s growth, (2) stoking conversation about shared interests, (3) I tend to have a lot of opinions about the things I see and few outlets.

So am I providing you a curated list of links from other curated lists? Yes. Will they appeal to you? Maybe! Over my 7+ years of running teams, I’ve collected a lot of interests in many (mostly frontend) technologies. Feel free to pay attention to whatever you’d like. I don’t have a comment section so, I guess, come find me if you want to talk to me about it?

πŸ€– Android

  • Android Studio drives me nuts with the memory situations and how it grinds everything to a halt. Shahinoor Shahin has some tips for the next time you’re waiting an hour for it to spin up a virtual Pixel or compile your code. ProAndroidDev
  • Core Web Vitals on Web were both the standards I’ve always wanted and video game I like to play when building internet applications. Though Android Vitals Metrics may not be the same thing, there are similarities in that (1) Google decided, (2) they have concrete metrics for performance, and (3) Google says they reserve the right to change what the important metrics are at any time. Fun! Android Developers Blog
  • Always love engineers admitting mistakes and broadcasting how they learned from it for posterity. Mess up. Fix it. Document it. Youtube: Phillip Lackner

🍎 iOS

  • Some of the most interesting conversations I’ve had recently about iOS architecture isn’t really isolated to iOS. It’s about how to use guardrails and automation to shift hearts and minds to improve architecture (wired: using libraries and subapps to organize verticals, tired: pitching all your work into a monolithic void). Just telling people to do it isn’t enough. You need enforcement with system-level and human-agnostic authority. SwiftLint? Maybe. Harmonize may offer something more robust (Stelios Frantzeskakis explains). ITNEXT
  • Lots of neat little tweaks for Swift including some improvements for testing and concurrency. Paul Hudson runs through them with examples. Hacking with Swift

πŸ•ΈοΈ Web

  • React gets the RC for React Compiler (auto-optimizes and -memoizes the heck out of the stuff you forgot to) and experimental features in <ViewTransition> (let React hold your hand through the startTransition API), and <Activity> (“lets you hide and show parts of the UI”). This is basically React leadership reminding that React is at least a little opinionated as a framework and they’re begging you to stop re-rendering everything all the time. React Compiler RC , ViewTransition and Activity
  • I remember being in Italy the first time and seeing the split flap boards with train times and thinking, “Wow, how old timey! Italians love keeping around old stuff!” Generalizations aside, I love that split flap boards are still around and the thought exercise of having something give the illusion of spinning like this is neat. Jhey goes deep on how this one was built. Craft of UI , Codepen

β˜•οΈ Java/Kotlin Backends

  • πŸ¦—

πŸ—οΈ DevOps/Infrastructure

  • I love a deep dive and I learned a ton about the saga architectural pattern. Also includes an example implementation for NestJS, Kafka, and TypeScript. The New Stack

πŸ’Ό Product

  • If you’re just typing in a bunch of stuff into ChatGPT and editing the results, you’re barely scratching the surface of what is available to you. This is listed as an article about making “product management fun again” but this is probably good article for any 9-5ers. The diagram defining AI agents against the behaviors we associate with AI is enlightening. Lenny's Newsletter
  • This is directed at engineers but the relationship goes both ways. Product managers, what do you think of this list? Is this the kind of thing you’re seeing in your engineering partnerships? Pragmatic Engineer

🎨 Design/UI

  • I’m a sucker for micro-interactions and little details that make a software a little more delightful. How Emil Kowalski ends this article about elevating your animations encapsulates that: “Everyone’s software is good enough these days. The barriers to entry are low. To stand out, you need to make your product feel great.” Emil Kowalski

🦾 What We’ve Decided to Call AI

  • The news about how to use and who uses and why aren’t you using AI can feel like chaos. Web devs love a “State of” survey so here is data from 4,181 respondents about how the industry is using AI for developing web applications and beyond right now. The State of Web Dev AI 2025
  • Sychophancy and dark patterns in AI are getting some sun shone on them with the issues coming out of the OpenAI 4o model. Having AI tell you you’re great is a bubble that can be harshly popped when everything goes wrong. Sean Goedecke goes into some good detail here about the trouble with sycophancy. Find ways to tone down the “yes man” in your responses for your own sake. Sean Goedecke , OpenAI on 4o sycophancy
  • I’ve definitely noticed some of the early warning signs of skill atrophy even if I haven’t been using AI for very long, mostly in the realm of “I don’t remember the syntax immediately or don’t want to read the docs – figure this out for me.” Addy Osmani has some good tips to how to combat skill atrophy and use AI as a partner, not a surrogate. Elevate
  • Matheus Lima posits something interesting: the OG vibe coding (aka finding flow) is being interrupted by the new vibe coding (managing a chat agent to write boiler plate code for you). Kind of related to the skill atrophy above. Terrible Software
  • All the things that Claude integrates with now (Atlassian products, Asana, Zapier, Sentry, Cloudflare, etc) opens up a lot of possibilities. Anthropic
  • I have my own thoughts about this (see “AI Can Learn from the Foibles of Car Infrastructure”) but here’s an article about why even the most AI-adverse engineer should probably at least keep up. HACKREAD

πŸŒͺ️ Engineering and Team Management

  • Going through engineering manager interviews, I keep getting asked about how I measure success engineer and team success. This is the answer. Anil Dash

πŸ§‘πŸ½β€πŸ’» Technology and Other Stuff

  • As the pendulum continues to swing away from having embedded humans focusing on quality, the burden either falls on engineers or on non-engineering partners (i.e., Product and Design) to help catch UI differences. Datadog suggests using synthetic monitoring as smokes tests to help automate finding the simple stuff at least. Datadog
  • In my #OpenToWork lifestyle, I’ve been thinking a lot about my career and some of the things I might’ve done in order to help either climb a ladder or prepare myself for the future. Anthony Henao hit me in the gut with some of these points, particuarly the “Someone Will Guide You” myth which is something I expected because it’s what I do for people on my team. Worth a read and looking forward to the follow-up. The Utopian Engineering Society
  • Just like the earlier article about why engineers need to be at least cognizant of AI (even if they don’t want to be), I have a lot of thoughts about the pressure the CEO misunderstanding of AI puts on engineers when they don’t fully undertand the current state of AI. Anil Dash has always been erudite in describing these things and this is a good one to read, too. Anil Dash