/Management

The Case For ‘Developer Experience’

- Jean Yang tl;dr: Developer Experience is the sum of how developers interface with their tools. Tools fall into 2 categories: (1) Abstraction tools make re-usable models e.g. APIs. (2) Complexity-exploring. Tech stacks are messy and becoming messier, and present an opportunity for "observability" tools beyond logging and tracing. Jean provides characteristics of a good tool, and advice for buyers and users.

featured in #252


What Makes A Good Changelog

- Herbert Lui Zeno Rocha tl;dr: Changelogs are a must for developer tooling. We explore 5 important aspects of a good changelog, from images to formatting, and how to customize your changelog to communicate effectively to your users.

featured in #252


How To Influence Without Authority

- Matthew Tse tl;dr: 3 ways to influence without authority at Atlassian: (1) The Psychologist: understand motivations and context of who you’re trying to influence & then work backwards to reach an outcome. (2) The Pitcher: Constantly explore and try different ways of framing ideas you want to influence. (3) The Activist: Create large movements by regularly sharing stories, perspectives and facts. Matthew guides us when and how to use each.

featured in #251


How To Build A Startup Security Team: Advice from Security Experts

tl;dr: The rise of security threats is a major problem, even for startups. But what can you realistically do to protect yourself with limited time & resources? In this post, we share advice from security experts on how to build a strong security team.

featured in #251


Closing Calls: Tell The Best Version Of The Truth

- Will Larson tl;dr: Most hiring funnels miss a closing call and the end of the hiring process. This is 2 steps: (1) Ask for the candidates concerns. (2) Answer them by telling the best version of the truth. "The artistry of the closing call is finding the most compelling path between their starting concerns and accepting your offer. Infrequently... you’ll come to realize that the role really doesn’t give the candidate what they’re looking for. It’s far better to realize now than after they’ve joined."

featured in #251


5 Properties Of A Healthy Software Product

- Dominik Braun tl;dr: (1) Reliable estimations, so that estimated effort is within ~15% of actual effort. (2) Orthogonality & cohesion - architecture can be changed independently without affecting each other, and architectural components are "loosely coupled." (3) Reproducibility, a build configuration is capable of producing a "deterministic and reproducible output." (4) Confident Deployments. (5) Teams organized to mirror architecture.

featured in #250


Uptime Monitoring Is Now Available In AppSignal

- Wes Oudshoorn tl;dr: Uptime monitoring is the first line of defense against downtime. Ping your apps every minute from 4 locations around the world and receive alerts when something is down. Now you'll know about downtime before your users do.

featured in #250


Software Deploys And Cognitive Biases

- Charity Majors tl;dr: There are real reasons for not deploying on Fridays, and there are others often cited driven by biases, such as: (1) “It is more dangerous to deploy than not to deploy” - prevention bias. (2) “It’s always riskier to do something than to not do something” - omission bias. (3) “Deploys are scary, so we need to slow down and be careful” - slow motion bias, and more.

featured in #250


Software Development Waste

- Greg Wilson tl;dr: "I've looked back at the end of every software project I've ever been on and thought, "If I'd known then what I know now, I'd have been done in half the time." A study followed eight projects, each over two and a half years and categorized the waste seen in development e.g. building the wrong feature or product, mismanaging backlog, and the causes for each type of waste.

featured in #249


A Guide To Writing A Robust Cross-Platform Implementation Plan

- Claire Katherine Lynch tl;dr: Tech Designs is a 2-step process to helps tackle the uncertainty of initiating a major new project. Step 1 is Shared Tech Design: when a cross-platform team collaborates to determine changes to the API, where the business logic lives, and a list of remaining open questions. Step 2: Client Tech Designs - when engineers consider how they’ll make the feature come to life within their area. Claire discusses both steps.

featured in #249