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