Learning from Giants #45
An animated introduction to Multi-cursor edition, How to work with designers, and how Lyft moved their apps to Server-driven UI.
👋 Hi, this is Mathias with your weekly drop of the 1% best, most actionable, and timeless resources to grow as an engineering or product leader. Handpicked from the best authors and companies. Guaranteed 100% OpenAI-free content.
Did a friend send this to you? Subscribe to get these weekly drops directly in your inbox. Read the archive for even more great content. Also: I share these articles daily on LinkedIn.
Multi-cursor editing: an animated introduction
If there's something you can spot immediately during a screen-sharing programming interview, it's keyboard text navigation abilities.
I’ve observed that people mostly fall into three categories when navigating text:
Always uses the keyboard.
Mostly uses the keyboard.
Only uses left-right arrows.
But why should you care?
As a software engineer, you spend most of your time editing text. Some of it will be code, RFCs, or communication. Being quicker on the keyboard and resolving tricky edition challenges in seconds instead of hours can make a significant difference on your impact.
Ultimately, your learning path will take you to multi-cursor edition. A must-have in your toolkit.
📗 Alex Harri's Multi-cursor code editing: An animated introduction is a step-by-step, visual introduction to the multi-cursor edition techniques. This will change your life, especially if you're a type (3) engineer! Bookmark it and return to it whenever you have a similar situation.
How to work with designers
Designers are the most complex element of product teams.
While PMs and engineers can share a similar background and vision, designers speak another language.
"To speak the language of designers, stop talking about metrics and start talking about users."
How to work with designers?
Understand what designer type they are.
Visual design, interaction design, and product design are very different jobs. It's common for start-up designers to have to do all of it. Yet you should know what gives them energy and they excel at.
Know what designers care about can be far from what you care about.
Design critiques drive excellence. Make sure they have a counterpart. A challenging mate to iterate with.
Care about the details as much as they do.
"The most direct path to a designer’s heart is to care about the details. [...] Every single designer I know loves to work with engineers and PMs that value design"
📗 Julie Zhuo's How to work with designers is a rare article from an author who has been in product, engineering, and design over their career. It gives a framework for hiring, interacting with, and creating value with designers.
How Lyft moved their apps to Server-Driven UI
Lyft operates both a white-label mobility app and consumer apps. They also have acquired many similar players. Over time, migrating these use cases to their main code base became a major source of complexity debt.
"It may seem like we were adding accidental complexity to our product by releasing so many variations on similar flows, but this was necessary complexity."
"The combinatorial complexity of our client code was growing quickly."
So they started exploring options beyond large switch statements everywhere in their mobile code.
"At this point, we needed a better abstraction for mobile to build features on top of. We started to play with moving UI/UX configuration to the server."
The Lyft engineers started feeding more and more of the logic from the server rather than these large if/switch statements. But this moved the debt from frontend to backend, as their platform API endpoints became increasingly tied up with view logic.
"We proposed a new BFF (backend for frontend) microservice named lbsbff exclusively for the Lyft bikes & scooters experience to abstract away hardware and provider implementation details from the client."
This way, view logic could live in a separate backend server that would be an aggregation and translation layer between the business and mobile worlds.
📗 Alex Hartwell's The Journey to Server-Driven UI at Lyft Bikes and Scooters tells how the team got to that solution, the intermediate steps and struggles, and describes their current "Server-Driven UI" iteration. Thank you, Alex for sharing such details. That's what makes these articles valuable to the outside world.
💡 Overall, we can take away a few higher-level learnings from that article. First, when complexity rises, and boundaries get hazy, adding an abstraction layer can be helpful. Second, moving complexity from the frontend to the backend enabled faster iteration (especially for mobile), higher reliability, and flexibility.
Beware, though, Lyft has several hundred engineers and high complexity. That's probably not your case (yet).