tl;dr in tech by Joe Karlsson - Issue #31
tl;dr: “You start realizing that everything comes back to a relatively small number of principles, universally applicable.” Paulo’s 20 principles include:
1) Don’t fool yourself. Self-awareness is the foundation without which nothing else works.
2) Lead yourself first. Manage emotions, don’t suppress them.
tl;dr: “The compass is a popular metaphor for leadership - we value its steadfastness and reliability. The weathervane symbolizes bad leadership - we’re skeptical of leaders too easily swayed.” The most effective leaders integrate aspects of both so the question isn’t “what kind of leader should I be?” but “what kind of leadership is called for at this moment - and am I capable of summoning it?” Ed provides us with 30 questions to navigate this.
tl;dr: Gergely covers a timeline of events, cause of the outage, what customers are saying, the impact of the outage on Atlassian’s business, learnings from this outage, and more.
tl;dr: “My favourites of these that I use already are entr, ripgrep, git-delta, httpie, plocate, and jq.” Julia breaks this list into replacements for standard tools, new inventions, and less-new tools.
tl;dr: “I don’t need to burn any of my limited focus on something menial anymore. It matters even more when automating something I don’t know by heart, like my Zoom URL or my EIN. Then it takes focus to find it ;and then copy it over.”
tl;dr: “I hear the misconception that a server can only accept 65K connections or a server consumes a port for each accepted connection all the time.” Joseph wrote this article to dispel this myth from 3 angles.
tl;dr: Typical white-boarding interviews are suboptimal. A better method is to have “the candidate read existing code and talk about what it does and how it works.” Reading code is: 1) Probably 95% of what a developer does in their job. 2) Way more efficient than writing. 3) Puts the candidates at ease compared to writing code. The author shows us how to put this is into practice.
tl;dr: Ask yourself why you need documentation e.g. making better decisions across the org, helping people get the right information, making onboarding more self-service. “If we’re deciding whether to write something, we should ask whether writing it will help us with one of those objectives.” Paulo suggests pointing your team towards the “why” and also provides tips for maintaining the practice.