/Career Advice

Biggest Productivity Killers In The Engineering Industry

- Gregor Ojstersek tl;dr: Perfectionism: (1) Progress is much more important than perfection, waiting for perfect moments causes more issues than actually doing it when it’s not. 95% is often good enough for the majority of cases. (2) Procrastination: focus on finishing the hardest task first thing in the morning. Other tasks become much easier to finish. (3) Context-switching: Timeboxing of tasks, sticking to one task until you finish it. Dividing time into meeting and maker time. 

featured in #474

What I Wish I Knew As A Mid-Level Engineer

- Ryan Peterman tl;dr: "Always think about the “why” behind your work and make sure it aligns with what matters most to your team and company. It is easy to get sidetracked by interesting work that isn’t impactful. The fastest career growth comes by finding work that aligns with both your interests and what matters most to the company. The best engineers can quickly tell what work is most impactful. Discussing project prioritization with your manager and tech lead is the fastest way to develop this skill."

featured in #472

Writing Is Thinking

- Andrew Bosworth tl;dr: Andrew gives us tips on writing, leading with: "I believe in this concept so completely that I’ll take the importance of writing a step further: I find it valuable to write even if only for my own benefit. Writing is a linear process that forces a tangle of loose connections in your brain through a narrow aperture exposing them to much greater scrutiny. In my experience, discussion expands the space of possibilities while writing reduces it to its most essential components."

featured in #471

Getting Better Feedback On Your Work

- James Cook tl;dr: James offers a simple technique on when to ask for feedback on a project: (1) When you’re 30% done with the project, ask your audience "are we on the right track?" Seek the following answers: if what you are doing makes sense, first impressions on the concept, if it meets relevant customer and business needs, suggestions for other people or teams to involve, etc… (2) When you're 90% done with the project, ask your audience: "is there anything we've missed?" In terms of input, seek: typos and shoddy grammar, jargon, complex, or excluding language, inappropriate tone and emotion, etc...

featured in #470

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 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

- Jordan Cutler 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

- Matt Rickard 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

How To Build Trust

- Jacob Kaplan-Moss tl;dr: "These are all going to be fairly high-level, just skimming the surface – I could probably write a full post for each point, but will keep them brief to avoid making this article into a book." Jacob elaborates on the following: (1) Act consistently. (2) Communicate clearly and transparently. (3) Be reliable. (4) Set and respect boundaries. (5) Use role power sparingly. (6) Give feedback. (7) Give credit, take blame. (8) Delegate effectively. (9) Sponsor and coach. (10) Respect confidentiality but be clear about limits. (11) Ask for permission to give feedback, suggestions. 

featured in #467

7 Books That Changed Me The Most As A Software Engineer

- Jordan Cutler 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

Traits I Value

- Andrew Bosworth tl;dr: 15 traits valued by the CTO at Meta: (1) Ownership: Valuing individuals who take full responsibility for their tasks, allowing others to trust that these tasks will be handled competently without constant oversight. (2) Rigor: Preferring team members who think thoroughly and exhaustively, understanding all alternatives, assumptions, and limitations to ensure well-informed decision-making. (3) Bias for Action: Appreciating those who recognize the cost of gathering information and the cost of delay, and who act decisively to maintain progress.

featured in #466