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
Communicate Design Tradeoffs Visually
- Tim Lyakhovetskiy tl;dr: “A goal of any written design or project proposal is to present and evaluate alternatives. However, documents that include multiple solutions can be difficult to read when the qualities of each solution are not clearly expressed. A common approach to simplifying proposals is to use “pros and cons” for each alternative, but this leads to biased writing since the pros and cons may be weighed differently depending on the reader’s priorities.” Tim shows us how to color code these tradeoffs to make it easier for readers to parse ideas.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
CSV Import Solutions: A Build Vs Buy Analysis
tl;dr: Users expect CSV import to just work, but building an importer isn’t easy. Flatfile surveyed companies to rank the effort required in order to build essential CSV import features such as parsing, validation, transformation, data I/O and security.featured in #458
Manage Your Capacity, Not Your Time
- James Stanier tl;dr: “If we’ve been lucky enough to work with leaders that manage their capacity well, then we may have been surprised that when we reach out with something urgent, they are able to respond quickly and effectively: perhaps they’ve offered to jump on a call straight away. This isn’t luck or anything to do with you. It’s just good capacity management on their part.” James discusses the importance of managers (1) Leaving space for the unexpected e.g. escalations, meetings, and other interruptions that will inevitably arise. (2) Understanding that capacity is a function of energy levels, and having the awareness to keep these in check. James shares a simple logging exercise to better understand this relationship between capacity and energy levels.featured in #457
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