/Leadership

The 3 Motivational Forces Of Developers

- Ben Northrop tl;dr: “After 15 years in industry, I've come to realize that the most defining quality of a developer is his source of motivation. It undergirds all of his decisions and interactions. It predicts what kind of code he'll write, what technologies he'll prefer, and even how he'll succeed on a given assignment. And it's often quite easy to peg for any given developer after just a few days of working with him or her.” 

featured in #543

How to Write Great Tech Specs

- Nicola Ballotta tl;dr: Nicola covers: (1) What a tech specs document is, why it's important, and why it can sometimes be challenging to create one. (2) How to create outstanding tech specs. (3) A Notion system for creating tech specs. (4) Tips from both his own experience as well as the communities.

featured in #542

The 3 Motivational Forces Of Developers

- Ben Northrop tl;dr: “After 15 years in industry, I've come to realize that the most defining quality of a developer is his source of motivation. It undergirds all of his decisions and interactions. It predicts what kind of code he'll write, what technologies he'll prefer, and even how he'll succeed on a given assignment. And it's often quite easy to peg for any given developer after just a few days of working with him or her.” 

featured in #542

Ask For Advice, Not Permission

- Andrew Bosworth tl;dr: From the CTO at Meta: “One of the most common anti-patterns I see that can create conflict in an otherwise collaborative environment is people asking for permission instead of advice. This is such an insidious practice that it not only sounds reasonable, it actually sounds like the right thing to do: “Hey, I was thinking about doing X, would you be on board with that?”" Andrew argues that the problem with asking for permission is that you’re implicitly asking someone else to take some responsibility for your decision. Asking for advice creates advocates for your idea but doesn't saddle them with responsibility.

featured in #541

Humans >> Data

- Kent Beck tl;dr: Kent discusses his stance on measuring developer productivity: “Looking at numbers is one way to pay attention, but it’s a limited, biased, & temporary way. There is no perfectly balanced set of metrics that will “drive” better behavior. As soon as such a set is introduced, clever folks will begin to subvert the numbers to their own benefit, they aren’t trying to make things worse for their colleagues, users, & investors — that’s just how it works out.” He discusses the value of managing humans over data. 

featured in #540

It's In The Stories

- Thorsten Ball tl;dr: “Sometimes, I think that this is what it’s all about: stories. And that, maybe, leadership is the act of producing the right stories, the anecdotes that are repeated by those around you, that carry the message you want out there.” Thorsten shares some examples. 

featured in #540

How We Deleted 4195 Code Files In 9 Hours

- Anton Zaides tl;dr: “My manager suggested an interesting idea - let’s clean up our codebase! We’ll stage a competition with worthy prizes, and in a single day delete all those unused files we always dreamt of cleaning up. Behold - the Cleanathon!” Anton discusses the goals of a Cleanathon, statistics and what to consider when organizing the event.

featured in #540

Standardizing

tl;dr: “While some standardization is necessary, many managers and leaders standardize just for the heck of it. Standardizing things feels productive, like cleaning up a messy room, and is a go-to move for leaders when they don’t know exactly what to do next. Whether it’s for power or preference, many people believe “the same” is “the best.” And it’s not. Here we explore where to give your teams autonomy and where to require standards.” 

featured in #539

Navigating Ambiguity

- Will Larson tl;dr: “Navigating deeply ambiguous problems is the rarest skill in engineers, and doing it well is a rarity. It’s sufficiently rare that many executives can’t do it well either, although I do believe that all long-term successful executives find at least one toolkit for these kinds of problems.” Will shares his playbook and approach. 

featured in #539

Navigating Ambiguity

- Will Larson tl;dr: “Navigating deeply ambiguous problems is the rarest skill in engineers, and doing it well is a rarity. It’s sufficiently rare that many executives can’t do it well either, although I do believe that all long-term successful executives find at least one toolkit for these kinds of problems.” Will shares his playbook and approach. 

featured in #538