tl;dr:“In my experience, it is at least the case that when programmers become trial-by-fire managers, they realize they don’t know how to do their jobs. Technical leadership — tech lead roles, principal eng roles, and even the dreaded “player-coach” role—those sneak up on people. A lot of times there’s still programming involved, so folks feel prepared. Their experience has exposed them to technical decisions and it got them promoted, so the way they do it is probably fine. Right?” Chelsea discusses 3 pitfalls she commonly sees.
tl;dr:“In my experience, it is at least the case that when programmers become trial-by-fire managers, they realize they don’t know how to do their jobs. Technical leadership — tech lead roles, principal eng roles, and even the dreaded “player-coach” role—those sneak up on people. A lot of times there’s still programming involved, so folks feel prepared. Their experience has exposed them to technical decisions and it got them promoted, so the way they do it is probably fine. Right?” Chelsea discusses 3 pitfalls she commonly sees.
tl;dr:“It’s how human programmers, increasingly, add value. Figure out why the code we already have isn’t doing the thing, or is doing the weird thing, and how to bring the code more into line with the things we want it to do. Chelsea argues that this “conveniently comprises most of the job these days: read code. Analyze it. Understand it. Repair it.”
tl;dr:The concept of a user "pigeonholes us into ideas that mislead our product direction and corrupt our technical choices." Chelsea notes three fundamental issues with the term "user:" (1) It doesn't describe how someone uses the product - reading, listening, playing, etc... (2) It implies addiction or manipulation (3) Inevitably screws the data model. Chelsea highlight this with examples.