featured in #364
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
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
My Energy Is A Linear Function, Until It Isn't
- James Stanier tl;dr: Monday to Wednesday are high energy, productive days for James, but Thursday is an inflection point where he's tiring. James discusses how he's trying to rectify this: (1) Purposefully trying to work 10% slower. (2) Being stricter with notifications so there's less context switching. (3) Limiting checking messages to within working hours. (4) Deferring non-essential requests and tasks into the following week. (5) Pomodoro technique.featured in #354
The Hierarchy Is Bullshit (And Bad For Business)
- Charity Majors tl;dr: "It took two decades, an IPO and a vicious case of burnout before she allowed herself to admit how much she hated her work, and how desperately she envied (guess who??) the software engineers she worked alongside. Turns out, all she ever really wanted to do was write code every day. And now, to her dismay, it felt too late. Why did it take Molly so long to realize what made her happy? I personally blame the fucking hierarchy."featured in #354