/Career Advice

How To Understand Things

- Nabeel Qureshi tl;dr: “The smartest person I’ve ever known had a habit that, as a teenager, I found striking. After he’d prove a theorem, or solve a problem, he’d go back and continue thinking about the problem and try to figure out different proofs of the same thing. Sometimes he’d spend hours on a problem he’d already solved.” 

featured in #513

Who Pays You? And Why?

- Brian Kihoon Lee tl;dr: “I get asked for career advice from time to time. While each situation is different, a recurring theme is disempowerment - feeling like there’s nothing you can do to advance your career. To help diagnose, I like to ask two questions: Who pays you? And why? These two questions encourage you to leave the comfort zone of job descriptions and confront the reality of what it’ll take to get to the next level at your current job, or potentially a new job. I’ll explain how I think about these questions, and this hopefully helps you think through your own situation.”

featured in #512

My Favorite Teacher

- Thorsten Ball tl;dr: “He taught us that you can summarize anything, in whatever length you want. He could summarize the Cold War in two sentences. A new law around unemployment benefits and social security? Four sentences. Bismarck’s forced resignation and all the political maneuvering that proceeded it? Three. Whenever someone would fail to summarize something, he’d say: “you’re not thinking clearly.” Summarizing is thinking clearly.”

featured in #512

Cognitive Load In Software Development

- Artem Zakirullin tl;dr: “There are so many buzzwords and best practices out there, but let's focus on something more fundamental. What matters is the amount of confusion developers feel going through the code. Confusion costs time and money. Confusion is caused by high cognitive load. It's not a fancy imaginary concept, it can't be misleading - cognitive load is there, and we can feel it.” 

featured in #512

Cognitive Load In Software Development

- Artem Zakirullin tl;dr: “There are so many buzzwords and best practices out there, but let's focus on something more fundamental. What matters is the amount of confusion developers feel going through the code. Confusion costs time and money. Confusion is caused by high cognitive load. It's not a fancy imaginary concept, it can't be misleading - cognitive load is there, and we can feel it.” 

featured in #511

Software Friction

- Hillel Wayne tl;dr: Friction is everywhere in software development: bugs, security alerts, dependency upgrade breaks something, etc.. Hillel believes the way to mitigate this is (1) Smaller scopes and shorter iterations. (2) Giving teams more autonomy. (3) Building in redundancy. (4) Better upfront planning. (5) Automation (6) Experience. (7) Gaming exercises. (8) Checklists and runbooks. 

featured in #511

4 Software Design Principles I Learned The Hard Way

- Leonardo Creed tl;dr: “I recently built and designed a massive service that launched successfully last month. During the design and implementation process, I found that the following list of “rules” kept coming back up over and over in various scenarios.” Leonardo discusses: (1) Maintain one source of truth. (2) Yes, please repeat yourself. (3) Don’t overuse mocks. (4) Minimize mutable state.

featured in #511

4 Software Design Principles I Learned The Hard Way

- Leonardo Creed tl;dr: “I recently built and designed a massive service that launched successfully last month. During the design and implementation process, I found that the following list of “rules” kept coming back up over and over in various scenarios.” Leonardo discusses: (1) Maintain one source of truth. (2) Yes, please repeat yourself. (3) Don’t overuse mocks. (4) Minimize mutable state.

featured in #510

Good Ideas in Computer Science

- Daniel Hooper tl;dr: “By “universally considered good” I mean they aren’t debated. Ideas so widespread and effective that you might not even think of them as being invented. Each idea may not be suitable in all situations, but you won’t find a programmer that thinks you should never use them. I intentionally focus on ideas, not implementations. For example: Unix contains many good ideas, but is not on the list because it is an implementation.”

featured in #509

Measuring Personal Growth

- Chip Huyen tl;dr: Chip wondered how to measure personal growth: “I don’t want to use metrics like net worth or the number of followers, because that’s not what I live for. After talking with a lot of friends, I found three interesting metrics: rate of change, time to solve problems, and number of future options.

featured in #508