Characterizing Software Developers By Perceptions Of Productivity
- Abi Noda tl;dr: “Developers are different in what they consider as a productive or unproductive workday; this study aimed to help leaders make sense of these differences.” The study found 6 types of developers and what they deemed as productive: (1) Social developers: feel productive when helping coworkers, collaborating and doing code reviews. (2) Lone developers: avoid disruptions such as noise, email, meetings, and code reviews. (3) Focused developers: feel most productive when they are working efficiently and concentrated on a single task at a time. (4) Balanced developers: less affected by disruptions. (5) Leading developers: more comfortable with meetings and emails. (6) Goal-oriented developers: productive when they complete or make progress on tasks.featured in #459
featured in #459
Networking As An Introvert CTO
- Vadim Kravcenko tl;dr: (1) You go to an event. (2) Approach person, say Hi, and introduce yourself. (3) Ask questions. (4) Listen carefully and share your experiences. Keep a look out for common ground. (5) Go to 3 if the conversation feels fresh; otherwise, continue. (6) End Gracefully. Go to 2 if you’re not tired; otherwise, continue. (7) Eat some food. Leave the event. (8) Follow up with everyone you liked via email. Vadim also shares his core principles: (a) Make others feel accepted. (b) Give first, then give some more i.e. don’t make networking transactional. (c) Don’t overthink it.featured in #459
featured in #458
Talking With Colleagues About Suffering
- Ed Batista tl;dr: Ed often talks to leaders who sense that a colleague is suffering and who would like to offer support to them but are unsure how to discuss the topic. He believes that leaders should find the courage to take the initiative. “This will be fraught, and it will feel risky, and sometimes you'll get it wrong. But you'll only improve your ability to sense the right time and to find the right language with practice. Extend the invitation, and don't be discouraged if it isn't accepted at first. Try again later. Don't insist — the other person has to feel in control — but by signaling your interest you make it easier for them to respond when they're ready.”featured in #457
(People On) Nice Teams Finish Last
tl;dr: Let’s assume you suggest an idea and you were wrong about it. Many companies will not clearly tell you that you were wrong, and why. Instead they’ll do one of the following: (1) Find a way for you to save face. Maybe they ask you to do more research and then later quietly deter you. (2) Soften feedback. (3) Make feedback sound like an apology and blame others - “I wish we could, but we just have so many features to build.” The problem with this ambiguity is that people walk away from meetings not understanding they were wrong. And if there’s any ambiguity, people will decide that they were right, and the organization is messed up.” Always be clear.featured in #457
10,000 Hours With Reid Hoffman: What I Learned
- Ben Casnocha tl;dr: (1) People are complicated and flawed. Root for their better angels. (2) The best way to get a busy person’s attention: Help them. (3) Keep it simple and move fast when conceiving strategies and making decisions. (4) Every weakness has a corresponding strength. (5) The values that actually shape a culture have both upside and downside. (6) Understand someone’s “alpha” tendencies and how that drives them. (7) Self-deception watch: even those who say they don’t need or want flattery, sometimes still need it. (8) Be clear on your specific level of engagement on a project. (9) Sketch three possible outcomes for a project: the likely upside, likely ‘regular’, and likely downside scenarios. (10) A key to making good partnerships great: Identify and emphasize any misaligned incentives.featured in #456
Characteristics Of Code Quality
- Abi Noda tl;dr: “Researchers found that readability and structure were the most commonly used defining properties for code quality. 82% of interviewees referred to either readability or structure, or both, when describing how they define code quality.” After that, the researchers discovered that comprehensibility, documentation and correctness followed. Abi reminds us that “code quality is a fundamentally human property” and not measured by quantitive metrics.featured in #455
How DoorDash Defines Great Engineering Management
tl;dr: Doordash discuss their three management pillars and how they map to management roles: (1) Business Outcome: how managers set direction and drive impact based on our strategic goals. (2) Team: how managers support individuals, build team culture and partner with other teams. (3) Engineering Excellence: the quality of our products and systems, how fast we can move, and how efficiently our systems use resources.featured in #454
The Power Of Soft Skills: Insights From Engineering Leaders
- Ben Ricker tl;dr: “The tactic I’ve found to be the biggest indicator of success is being comfortable saying, “I don’t know. You can’t know everything, and pretending to do so often leads to wasted time, poor expectation settings, and frustration from clients and team members. Pairing “I don’t know” with the ability to ask great questions will help gain trust from all sides of a project and set the tone of working collaboratively.”featured in #454