/Career Advice

Navigating Ambiguity

- Will Larson tl;dr: “Navigating deeply ambiguous problems is the rarest skill in engineers, and doing it well is a rarity. It’s sufficiently rare that many executives can’t do it well either, although I do believe that all long-term successful executives find at least one toolkit for these kinds of problems.” Will shares his playbook and approach here. 

featured in #482


The “Errors” That Mean You’re Doing It Right

- Jason Cohen tl;dr: The following “errors” are the natural by-product of good decisions and a necessary side-effect of success, and celebrated as such. The first 5 are: (1) Re-adding features/bugs you removed from the backlog. (2) Pivoting a strategy just after creating it. (3) Refactoring infrastructure after growing 10x. (4) Adding words because messaging was too terse. (5) Adding back features you removed. 

featured in #482


Demystifying Project Estimation

- Nicola Ballotta Jordan Cutler 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. 

featured in #481


Almost Everyone I’ve Met Would Be Well-Served Thinking More About What To Focus On

- Henrik Karlsson tl;dr: Henrik discusses the concepts of “Exploring” and “Exploiting” to help find focus. When you “Explore”, you look for what makes you feel alive. When you “Exploit”, you trip everything but your top 1-3 priorities. Breaking inaccurate mental models is critical, and can happen in two ways: “(1) Find people who understand things better than you and read what they have to say. Read with the intention of answering your questions. If you can’t find the answers, email them. (2) Perform experiments. State your assumptions and find ways to test if they are false. Most of the time, the slot machine of an experiment yields nothing. But that’s ok. A few will rearrange the world around you."

featured in #478


Legacy Seam

- Martin Fowler tl;dr: "When working with a legacy system it is valuable to identify and create seams: places where we can alter the behavior of the system without editing source code. Once we've found a seam, we can use it to break dependencies to simplify testing, insert probes to gain observability, and redirect program flow to new modules as part of legacy displacement." Martin shows practical examples of how to approach this.  

featured in #478


2024 Guide To Goals For Software Engineers

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

featured in #477


What I Wish Someone Had Told Me

- Sam Altman tl;dr: 17 short, guiding statements including: (1) Optimism, obsession, self-belief, raw horsepower and personal connections are how things get started. (2) Cohesive teams, the right combination of calmness and urgency, and unreasonable commitment are how things get finished. Long-term orientation is in short supply; try not to worry about what people think in the short term, which will get easier over time. (3) It is easier for a team to do a hard thing that really matters than to do an easy thing that doesn’t really matter; audacious ideas motivate people.Nicola covers: (1) What a Tech Specs Document is, why it's important, and why it can sometimes be challenging to create one. (2) How to create outstanding Tech Specs. (3) A Notion system for creating Tech Specs. (4) Tips from both his own experience and the community.

featured in #476


Look Back To Leap Ahead: 7 Questions For Your End of Year Reflection

tl;dr: A wide-ranging retro to set yourself up for success in the new year: (1) Evaluating projects to quit earlier. (2) Revamping regular meetings. (3) Using time wisely. (4) Alignment with manager’s goals. (5) Receiving and giving impactful feedback. (6) Changes in job role. (7) Readiness for career advancement. 

featured in #475


Advice For New Software Devs Who've Read All Those Other Advice Essays

- Hillel Wayne tl;dr: “13 bits of advice for early-career programmers. Some of it is contradictory”: (1) Behind every best practice is a horror story. If you don't understand a best practice, look for the horror story that inspired it. It might make the best practice make sense. (2) Carefully think about any advice and evaluate how it applies to your situation. There is very little about software that's been scientifically studied, and most of the research is inconclusive. (3) Every tool has some form of hidden depth, from your programming language to git to JIRA. You don’t have to become an expert in every single one, but consider spending 5-10 minutes learning a bit more about what it can do.

featured in #475


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