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.
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.
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.
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.
tl;dr:Jordan delves into the following areas: (1) Git & terminal workflow. (2) Coding, notably tracing code down or up a stack, navigating between locations & typing. (3) Saving what you learnt in accessible ways. (4) Offloading ideas and tasks immediately so you don’t carry them in your thoughts. (5) Communicating through visuals. (6) Using a password manager. (7) Window management.
tl;dr:Insights from about topics like salary negotiation, promotions, 1-on-1s, and more for engineers. Takeaways include the importance of respectful and collaborative negotiation, aligning personal goals with company objectives, focusing on relationships and soft skills for promotions, and ensuring engineers control the agenda in 1-on-1 meetings. The article also touches on the challenges of middle management, and preferences for remote work and startup environments.
tl;dr:The first 2 are: (1) Git bisect: Run you through a binary search process between the “good commit” and the “bad commit” until it finds the commit the bug started happening. (2) “Binary search commenting”: Commenting out sections of the code and replacing it with a hardcoded value to narrow in on where the problem is.
tl;dr:(1) Write out all possible options. (2) Cross out what won’t work. (3) Write pros and cons, come up with a preference, and discuss with your team. If you’re still unsure, do any of the following: (a) Act as your end-user and critique each solution from that perspective. (b) Have 1:1 discussions with someone junior and more senior. (c) Consider how reversible the decision is, what the cost of each one being wrong is, and what room each one has for being extended in the future.