The Pragmatic Engineer Test: 12 Questions On Engineering Culture
- Gergely Orosz tl;dr: "12 questions to get a sense of what a tech company is like to work at, based on things most job postings do not mention:" (1) Are code reviews and testing both part of the everyday development process? (2) Do you follow an internal open-source model, where any engineer can access and contribute to most other codebases - with appropriate code ownership in place?featured in #261
featured in #260
My Team Is Going In Circles, Help!
- Lara Hogan tl;dr: Assuming that outcomes are documented, clear, measurable and visible to all, lead the team through an exercise to generate a responsibilities document together. Lara illustrates this here. You're listing roles in the team and their responsibilities. If the team continues to feel stuck, coaching them using "truly curious open questions," while drafting a list of what folks need.featured in #260
The Value Of In-house Expertise
- Dan Luu tl;dr: "Twitter has a kernel team!?" Everyone is surprised to learn this but, as Dan explains: "a company Twitter's size is going to regularly run into kernel issues... without a kernel team or the equivalent, the company will muddle through the issues, running into unnecessary problems as well as taking an unnecessarily long time to mitigate incidents."featured in #260
How New Managers Fail Individual Contributors
- Camille Fournier tl;dr: (1) Doing all technical design work yourself. (2) Doing all the project management yourself. (3) Neglecting to give feedback on non-technical issues. (4) "Hoarding information" i.e. not providing business context to your team or distilling and communicating it effectively. (5) Focusing too much on your personal output and not the team's output.featured in #259
The Developer's Guide to Directory Sync / SCIM
tl;dr: SCIM is a popular protocol for user lifecycle management - i.e. making sure that users are added and removed from an app with the right permissions. Should you do just-in-time provisioning or sync to a directory. Let's dig into the details.featured in #259
featured in #259
What I Learnt Becoming A Tech Lead
- Tom Gamon tl;dr: (1) Don’t write code on the critical path i.e. where you're the blocker to deploy. (2) Defending your calendar. (3) It’s not necessary to be in every conversation. (4) You don’t have to be the most experienced engineer in the team, and more.featured in #259
The Case For Slacking Off At Work
- Jacob Singh tl;dr: Managers fear under utilizing resources so they orchestrate processes to put all engineers to work, simultaneously. In practice, this creates issues as projects invariably don't go to plan and resources cannot be reallocated easily. Jacob recommends a slacklog - "a backlog of things which can happen, but don't need to happen." These are ideas generated by the eng team, easily transferable between members, which can be added to the process to create resource flexibility.featured in #258
Don't Assume Consensus In The Absence of Objection
- Candost Dagdeviren tl;dr: We've all been in meetings discussing a challenge with one vocal engineer, who is opinionated and likes to share ideas. It's wrong to assume that, because no one objects, consensus has been reached or that one engineer's decisions are correct. "In some cultures, people won't speak up unless someone passes them the ball and mentions their names explicitly."featured in #258