/Practical Tips

Words Are Hard - An Essay on Communicating With Non-Programmers

- Michael Bryan tl;dr: Communicating engineering to non-programmers can be an important part of the job and, often, programmers shy away. Michael explains strategies and techniques he uses. 

featured in #171

Goodbye, Clean Code

- Dan Abramov tl;dr: Developers strive for cleaner code. There's an inflection point when a developer starts writing code in abstraction, this feels like a "super power." Dan learnt this comes with its own trade-offs. "Clean code is not a goal."

featured in #169

Notes On Technical Writing

- Marcus Kazmierczak tl;dr: Marcus frequently writes documentation for Wordpress. Here, he guides us through some of his learnings, including the concept of Minimalist Instruction.

featured in #169

Database Design Standards

- Curtis Poe tl;dr: Curtis runs through some tips on database design - whether to go with camel case names or underscore_names, plural or singular tables, column naming, and more.

featured in #169

Tech Lead Expectations for Engineering Projects

- Gergely Orosz tl;dr: Framework of how Gergely manages his team at Uber including the initial team setup, how risks are managed, stakeholder communication and more.

featured in #166

Don't Use Booleans

- Steven Luu tl;dr: The overhead of enums is comparatively low and comes with several practical benefits.

featured in #166

A Comment Is An Invitation For Refactoring

- Gergely Orosz tl;dr: A comment is usually a sign that a piece of code needs refactoring. Greg wants us to ask "could I refactor the code to remove this comment?" The answer is typically yes. He highlights three common examples of comments.

featured in #164

Other People’s Messes

- Jessica Kerr tl;dr: We're comfortable writing messy code when it's just ourself who will see it. If you know others will at some point review it, it's best to clean it sooner rather than later.

featured in #148

For Cleaner Code, Write Ugly Code

- Jessica Kerr tl;dr: When prototyping code, make it ugly. Generally speaking, the number of iterations correlates more closely to success than the total time spent. This way, you are forced to go revisit your code, streamline and beautify it.

featured in #147

Claude Shannon: How A Genius Solves Problems (2018)

- Zat Rana tl;dr: Solving problems comes with the right thinking pattern. Often, we use a logical thought process. Shannon's approach changes the reference point of problems asking "what a bad solution looks like". All answers hold a truth and reference points break up unhelpful mental loops.

featured in #146