featured in #546
Algorithms We Develop Software By
- Grant Slatton tl;dr: “I recently had a conversation with a distinguished tech CEO and engineer. I loved hearing his description of a software development methodology he's occasionally used, and it got me thinking about other heuristics and generalizations.” Grant discusses tactics to develop software effectively.featured in #544
Derisking 12 Common Workplace Scenarios
- Wes Kao tl;dr: Wes covers simple ways to derisk the following workplace scenarios:(1) Sharing an idea your colleagues might find controversial. (2) Giving constructive feedback to a direct report. (3) Testing your offer. (4) You made a mistake and need to tell your customer. (5) Troubleshooting a technical issue. (6) Giving feedback to a peer. And more.featured in #543
Algorithms We Develop Software By
- Grant Slatton tl;dr: “I recently had a conversation with a distinguished tech CEO and engineer. I loved hearing his description of a software development methodology he's occasionally used, and it got me thinking about other heuristics and generalizations.” Grant discusses tactics to develop software effectively.featured in #543
Practices Of Reliable Software Design
- Christoffer Stjernlöf tl;dr: Christoffer discusses the following: (1) Use off-the-shelf. (2) Cost and reliability over features. (3) Idea to production quickly. (4) Simple data structures. (5) Reserve resources early. (6) Set maximums. (7) Make testing easy. (8) Embed performance counters.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
How To Identify And Reduce Risk In Your Daily Work
- Wes Kao tl;dr: Two simple questions to ask yourself: (1) What’s most likely to go wrong? (2) What can I do to prevent this from happening? Wes also covers principles to help derisk work: (A) Embrace a healthy sense of paranoia. (B) Pattern match to remember what happened in similar situations. (C) If you foresee a misunderstanding, speak up and clarify. (D) Risk isn’t binary, it’s on a spectrum.featured in #541
How To Say "No" And Win Back Your Time As A Software Engineer
- Jordan Cutler tl;dr: Jordan discusses the four practical approaches to saying No, along with practical examples and phrases to use: (1) The Direct Approach. (2) The Redirect Approach. (3) Change Their Perspective Approach. (4) Stonewall Approach.featured in #541
You Should Make A New Programming Language
- Nicole Tietz-Sokolskaya tl;dr: “You use a programming language as a tool of thought even when you're away from the keyboard. This makes it ripe for learning. You will learn a lot if you make a new programming language.” Notably, you will learn about grammar, language design, parsing and runtime execution. Nicole shares a couple of easy ways to get started.featured in #541
Make Things Simpler Than Possible
- Arthur O’Dwyer tl;dr: Donald Knuth presents a particular system in a specific way. “He first presents an oversimplified version of the system — so oversimplified that it is, in fact, incorrect — to give the student the general gist of the system. Seeing a consistent general plan up front, even though it errs in some particulars helps the student understand the final version.”featured in #541