tl;dr:Jordan discusses his terminal setup and shares daily commands across the following categories: (1) Terminal app, shell, and plugin manager. (2) Theming. (3) Best terminal plugins. (4) Aliases and history config. (5) Command line utilities to install.
tl;dr:(1) Bring solutions, not problems. Focus on showing how you are there to support the team that needs the help. (2) Clean code isn’t the end goal. Collaborating effectively with your team is more important. (3) Team outcomes are greater than individual outcomes. What you spend your time on should be directly correlated with what will bring impact for the team. (4) Adapt to your manager. Understand how to adapt to your manager’s style and goals to see the best collective outcomes. (5) Influence isn’t about wording. Focus on building relationships with a foundation of trust.
tl;dr:(1) Before the meeting: Figure out the outcome you want to achieve by the end of the meeting. Invite people based on that outcome. Send a message or tag in the channel about the meeting invite and the purpose. Add a meeting description so everyone knows what it’s about. Start the meeting description with, “The goal of this meeting is…” (2) During the meeting: Start the meeting off by reiterating the expected outcome and goal. Respectfully keep the meeting on track pointing to the goal. Make sure everyone feels heard throughout the discussion. (3) After the meeting: Document all important points. Post a summary of the points and action items along with dates and responsible individuals.
tl;dr:“Estimating a project or the latest feature you aim to deliver holds incredible value, not only for the business your team serves but also for you and your team. In fact, estimations bring clarity and alignment, which are crucial for delivering quickly and with minimal stress.” The article covers the purposes and challenges of estimation, and gives practical examples and tips.
tl;dr:“When deciding on goals, start with the end in mind. Think about the focus areas you need to grow in to get to your ideal state, then create goals for each focus area. To make sure you complete your goals, break down, break down, break down. Start with annual goals, then break them into quarterly goals, then for each quarterly goal, create action items for that quarter.” Jordan exemplifies 5 different types of goals and tells us to know which type we’re setting: (1) Objectives not 100% within our control e.g. be promoted to senior engineer. (2) Objectives 100% within our control e.g. exhibit the behaviors of a senior engineer. (3) Action-based checklists e.g. read 25 books this year. (4) Recurring patterns e.g. work out 3 times per week. (5) Feeling e.g. Feel more confident at public speaking.
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.