Ask For Advice, Not Permission
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 while asking for advice creates advocates for your idea but doesn't saddle them with responsibility.
featured in #469
6 Tiny Wording Tweaks To Level Up Your Communication As A Software Engineer
tl;dr: (1) Use “Would you be open to” instead of “Can you” when you want to seem less commanding but still lead to a “yes.” (2) Add “because” to your reasoning or request to strengthen it. (3) Use “can we” instead of “can you” to be more collaborative, particularly in code reviews. (4) Use “What do you think” to assert a suggestion but still leave it open for discussion. (5) Use “It seems like” when the conversation is at a stalemate and you want to call it out directly. Many times this breaks the stalemate. (6) Change the order of your “but” to negate the part you actually want to negate.
featured in #469
Take Your Time Making Decisions
tl;dr: "I taught myself how to breathe slower. How to slow things down. How to not answer somebody instantaneously… You can always move slower. The world will basically wait for you if you’re deciding something consequential. And you can always say, ‘I’d like to think about that a little bit.’ So the only reason to feel panicked is if you’re panicking yourself, and that’s your fault. You don’t have to do that. You can take your time, you can weigh things. It’s very infrequently that the timing has to be instantaneous."
featured in #468
7 Books That Changed Me The Most As A Software Engineer
tl;dr: "Books are one of the best ways to grow as a software engineer. They give you actionable takeaways based on decades of knowledge and experience.” Jordan organizes his book recommendations into the following 7 categories: (1) Writing & communication. (2) Software design. (3) Challenging conversations. (4) Relationships. (5) Engineering soft skills. (6) Productivity. (7) Engineering Management.
featured in #467
The 100 Best Bits Of Advice From 10 Years Of First Round Review
tl;dr: "End every meeting or conversation with the feeling and optimism you’d like to have at the start of your next conversation with the person. If you envision running into this person again and how you want that to go, it’ll undoubtedly influence how you navigate a present conversation — usually for the better. Chris Fralic on how to become insanely well-connected."
featured in #466
A Guide To Public Speaking For Software Engineers
tl;dr: Jordan discusses: (1) How to improve your body language, wording, and tonality. (2) How to create a presentation structure that keeps people listening to you. These concepts can be applied to in-person & remote tech talks, demos, technical direction presentations, leading meetings and interviews.
featured in #464
7 Types Of Difficult Coworkers And How To Deal With Them
tl;dr: Jordan interviews Raviraj Achar - who has been a tech lead at Meta for 5 years - about how he manages difficult co-workers. The following are the first 3 archetypes discussed: (1) Risk-Averse: The Habitual Defender: They want to avoid risk at all costs and don’t want the system to break. (2) Risk-Taker: The Trailblazer. The opposite of the prior archetype. This person often feels the risk is justified or they will propose ideas without scoping out the risk. (3) The Stealthy Critic: They will have opinions but save them for the last minute before something is ready to ship. Or they will comment on your design doc and leave things in an ambiguous state.
featured in #462