/Career Advice

Hard Things In Computer Science

- Nicolas Frankel tl;dr: Nicolas gives an explanation as to why for each: (1) Cache invalidation. (2) Naming things. (3) Dates, times and timezones. (4) Estimates. (5) Distributed systems.

featured in #329

How I Learned To Love Feedback Loops (And Make Better Products)

- Neil Kakkar tl;dr: "One common theme that stood out was how feedback loops between each stage lead to much better decisions. In this post, I want to talk about why these feedback loops are useful, and how to actively seek iterative gains from these loops."

featured in #328

Mental Model: Difficult Problems vs Hard Work

- Ben Congdon tl;dr: "In other words, Difficult Problems involve operating in a higher dimensional space than Hard Work. Strategies that can collapse the higher dimensional Difficult Problem into a lower dimensional form of Hard Work reduce the cognitive costs to solving the problem." Ben discusses his approach to balancing the two. 

featured in #328

Keep Your Experiments Separate

- Jessica Kerr tl;dr: "Add features one at a time — not as a series, but on alternate timelines. With version control, we have this superpower." Jessica believes this is a superior process for learning new frameworks, programming style, and more.

featured in #327

Career Checkup Template

tl;dr: (1) Fork this template. (2) If there are any sections that don’t resonate with you, remove or edit them. (3) Fill in the sections. Feel free to jump around to answer the parts that you have the most energy for. (4) Revisit a few days later: is there anything you want to change? (5) If possible, find peers to discuss each others checkups together. (6) Review a year from now.

featured in #326

The Fallacy Of Splitting Time

- Ben Northrop tl;dr: "There are two projects, both deemed important by the business, and both need a UI developer. Unfortunately, only one UI developer is available. Why not let the UI developer split time across both projects?" Ben explains why this doesn't work using the equation: Productive Time = Total Time - Overhead.

featured in #326

Advice For Engineering Managers Who Want To Climb The Ladder

- Charity Majors tl;dr: "We have been interviewing and hiring a pile of engineering directors at Honeycomb lately. In so doing, I’ve had some fascinating conversations with engineering managers who have been trying unsuccessfully to make the leap to director. Here is a roundup of some of the ideas and advice I shared with them."

featured in #325

Why, Oh Why Was This Added?

- Žiga Miklič tl;dr: "While not commenting event calls is usually not a big deal, it may be a problem in situations like mine where I had to go over many ambiguous use cases at once. This resulted in a lot of wasted time that could be otherwise avoided if the original author added a comment."

featured in #324

Start Test Names With “Should”

tl;dr: Reasons include: (1) It removes redundancy, because the function name should already be in the call stack. (2) It is falsifiable i.e. a person reviewing the test can decide to which degree the name agrees with the actual test. (3) Encourages testing one property of the function per test.

featured in #323

Master Your Questioning Skills

- Murat Demirbas tl;dr: Murat committed to asking "crazier" left-field questions in each post he wrote. After 70 posts, he learned that these: (1) Are useful as they took him out of "default mode." (2) Keep the brain more engaged. We tend to ask easier questions. Harder ones feel uncomfortable or seem impolite. (3) By calling them "MAD" questions, they give him the license to be more uninhibited. 

featured in #322