tl;dr in tech by Joe Karlsson - Issue #15
tl;dr: “It’s been a while since I was on the receiving end of a software engineering interview. But I still remember my favorite interview question. It was at [SingleStore] circa 2013… Since [SingleStore is] a database company, this is a database challenge.”
1) We’re not answering the user’s needs, notably around performance and accessibility.
2) We’re overusing JS: Both in our dependencies and in our own code.
tl;dr: “A good plan would result in strong execution and a successful outcome” but this approach failed Scott when managing larger projects. His advice: “make plans that bend and adapt with the changing world around you. I built a habit of forming rough, directional plans, testing them with small bets, and using quick production feedback to reorient myself and start the cycle again.”
tl;dr: Ankit shows us how to design the architecture for a global Tinder-like service where users can create profiles, view recommendations of other users in geographically nearby regions, like or dislike other recommended users, get notifications when matched and be able to move to a different location and still get recommendations of nearby users.
tl;dr: “You’ve probably seen web editors based on the idea of blocks. I’m typing this in WordPress, which has a little + button that brings up a long list of potential blocks that you can insert into this page.” Joel thought it would be cool if blocks were interchangeable and reusable across the web, and is creating the Block Protocol doing just that, discussed here.
1) There are enough “known knowns” in the project i.e. things you’re aware of and understand.
2) There are no more “known unknowns” i.e. things you’re aware of but don’t understand.
4) You stop learning new things.
5) Falling down the rabbit hole.
tl;dr: “I can’t count how many times I’ve heard programmers talking about writing some new piece of code to work around the behavior of some other code which they don’t want to change. You are a programmer - you are allowed to change code! In fact, it’s your job! Just change the code to do what you want! Fix the bug! Change the behavior! Add the feature!” Spenser illustrates this with common excuses people give.
tl;dr: “The biggest mistake I see engineers make is doing too much work on their own before looping in others.” This costs time and creates the risk of going down the wrong path. Managers can help:
1) Encourage engineers to show work as quickly as possible.
2) Help them decide what to show that provides meaningful feedback.
3) Encourage launching something end-to-end internally, quickly.
tl;dr: Ankit shows us how to design architecture similar to Uber’s: Riders are able to view available drivers in nearby locations, request rides from source to destination, notify nearby drivers of the ride and allow one of them to confirm the ride, show pickup ETA to customers when a ride is dispatched.