/Career Advice

Questions For A New Leader

- Ed Batista tl;dr: A set of questions to guide these initial conversations, relevant for a new leader in any situation: (1) What are the things you are hoping I don't change? (2) What are the things you secretly hope I do change? (3) What are the good things about this organization we should build on? (4) If you were me, what would you do first? (5) Why isn't the organization doing better? And more.

featured in #368

The World Is Run By People No Smarter Than You

tl;dr: "My overwhelming lesson from the past few weeks is that even these heroes of tech are just mortals as well who make very very dumb mistakes. And if they can make those mistakes, so can you." The author elaborates on this viewpoint amongst recent examples.

featured in #368

Get Straight To The Point

- James Stanier tl;dr: "In a world of continual context-switching and distraction, if you’re able to make it as easy as possible for others to understand what you want, what the next steps are, and whether or not you have a strong preference, then you’ll find that your interactions are far, far better." James digs into this with examples and the following framework: (1) Make it clear up front what you want. (2) Make the next steps obvious. (3) If you have a recommendation, say it up front.

featured in #364

7 Estimation Anti-Patterns

- Willem-Jan Ageling tl;dr: (1) Estimates because “we have to.” (2) Neglecting different estimation opinions. (3) One estimator to rule them all. (4) Estimating takes forever. (5) Estimates need to be “correct.” (6) Estimates are turned into commitments. (7) Others do the estimation.

featured in #364

How To Build Software like an SRE

- Brandon Willett tl;dr: "My goal here isn’t “what is 100% the most reliability-oriented way we can build things”, it’s more like “what is the 80% of reliability we can get for 20% of the effort while still enabling devs to go fast“, which gets you ultimately a system that looks pretty different. But it’s a line worth walking – if you do it well, working with production is fun, instead of miserably-safe or frighteningly-dangerous."

featured in #363

When Life Gives You Lemons, Write Better Error Messages

- Jenni Nadler tl;dr: Jenni covers what makes both good and bad error messages. For bad error messages, she gives cites: inappropriate tone, technical jargon, passing the blame and generic messages that have no reason. Good messages say what happened and why, provide reassurance, are empathetic, help the user fix the issues if possible and provide a "way out" e.g. a contact number.

featured in #361

Know Your Carrying Capacity

- Mac Chaffee tl;dr: "I like to think of the collection of things that someone can reasonably maintain as their "carrying capacity", to borrow the ecology term. If you take on more than your carrying capacity, something has to die. With modern software being so garbage, I think one big reason is that there are too many software professionals out there who don't know their carrying capacity."

featured in #359

Mike Acton’s Expectations Of Professional Software Engineers

- Adam Johnson tl;dr: "Games industry veteran rattles off a sample of 50 things he expects of developers he works with:" (1) Can articulate precisely the problem trying to be solved. (2) Someone else can articulate the problem trying to be solved. (3) Can articulate why the problem is important to solve. (4) Can articulate how much my problem is worth solving. (5) Have a Plan B in case the solution to my current problem doesn’t work. And More. 

featured in #358

So You're Using A Weird Language

- Pablo Meier tl;dr: "I realized I have some experience with the statement "I'm gonna write a program using a weird language," I thought I'd write a few narratives and strategies:" (1) Tolerance for weird errors. (2) Look for the forums, ask questions. (3) More than "typing source" — build the workflow, a project. And more. 

featured in #357

From Development To Real Users: How To Create A Web Performance Story

- Vinicius Dallacqua tl;dr: "Some of the most common questions asked when it comes to work with performance are, How do you convince stakeholders that improving the performance of your project is actually worth the investment? How can you prove that the work is necessary to begin with? Or prove that you have shipped improvements? And what is the impact of certain changes on users in different scenarios?"

featured in #355