/Career Advice

Engineers Who Won’t Commit Force Bad Decisions

- Sean Goedecke tl;dr: “Some engineers think it’s a virtue to remain non-committal in technical discussions. Should our team build a new feature in an event-driven or synchronous way? Well, it depends: there are many strong technical reasons on each side, so it’s better to keep an open mind and not come down on either side. This strategy is fine when you’re a junior engineer, but at some point you’ll be the person in the room with the most context (or technical skill, or institutional power). At that point, you need to take a position, whether you feel particularly confident or not.”

featured in #590

The Economics Of Being A Founding Engineer

- Daksh Gupta tl;dr: “The economics of being a founding engineer are peculiar. You're essentially taking a pay cut and accepting illiquid equity in exchange for a lottery ticket - but it's a lottery ticket where you get to thoroughly inspect the odds beforehand. While most founding engineers will end up with worthless equity, the ones who choose wisely and join the right startup at the right time can see returns that are simply impossible to achieve as an employee at a public company. It's a high-stakes game of calculated risk-taking, where thorough due diligence and strong conviction in your assessment can help tilt the odds in your favor.”

featured in #590

How Do You Spend Your Time?

- Marc Brooker tl;dr: “You thought you were productive, and getting a lot done, but they weren’t the things you, or your manager, thought were most valuable for your project and team. You’re busy, you’re productive, but it doesn’t feel right. It’s a problem I’ve faced before, which I think I’ve mostly solved for myself. Here’s some thoughts on what worked for me.”

featured in #589

Software Development Topics I've Changed My Mind On After 10 Years In The Industry

- Chris Kiehl tl;dr: Things I now believe, which past me would've squabbled with: (1) Simple is not given. It takes constant work. (2) There is no pride in managing or understanding complexity. (3) Typed languages are essential on teams with mixed experience levels. (4) Java is a great language because it's boring. (5) REPLs are not useful design tools (though, they are useful exploratory tools). And more. 

featured in #588

Five Coding Hats

- Patrick Dubroy tl;dr: The article presents five different approaches to coding, symbolized as "hats": (1) Captain’s Hat: methodical, by-the-book. (2) Scrappy Hat: minimal, straight to the point. (3) MacGyver Hat: results-focused, quick-and-dirty. (4) Chef’s Hat: focused on presentation, aesthetics. (5) Teacher’s Hat: emphasizing clarity, communication. Patrick argues there's no single "right way" to code; instead, different situations call for different approaches.

featured in #588

Picking Your Battles When You Are Hyper-rational

- Wes Kao tl;dr: “When you notice a small mistake or miscommunication, your urge might be to correct your colleague—because you are technically right. But this can derail the main point and cause a distraction. I have to remind myself: Keep the bigger picture in mind. I want to share an example of how this can creep into your work, with email drafts I almost sent vs what I actually sent.”

featured in #587

Working Fast And Slow

- Sean Goedecke tl;dr: “Some engineers work very consistently, putting in the same hours every day and getting out the same amount of work. I don’t. Some days I only have a few hours of focused work in me, while on other days I feel like I can go on almost indefinitely. I used to feel like this was a problem - that I was either overworking or slacking off - but now I lean into it. Instead of trying to push harder on slack days and pull back on focus days, I accept that I’ll be much more productive on some days than others. There are serious advantages to this working style.”

featured in #586

Working Fast And Slow

- Sean Goedecke tl;dr: “Some engineers work very consistently, putting in the same hours every day and getting out the same amount of work. I don’t. Some days I only have a few hours of focused work in me, while on other days I feel like I can go on almost indefinitely. I used to feel like this was a problem - that I was either overworking or slacking off - but now I lean into it. Instead of trying to push harder on slack days and pull back on focus days, I accept that I’ll be much more productive on some days than others. There are serious advantages to this working style.”

featured in #585

Protecting Your Time From Predators In Large Tech Companies

- Sean Goedecke tl;dr: “If you’re a competent software engineer at a large tech company, your time is in very high demand. Lots of people will want you to do things1. You should be very selective about how you handle these requests, and definitely avoid saying yes to everyone.”

featured in #584

Do Hard Things

- Nikunj Kothari tl;dr: “Getting good at these hard things doesn't make life easier—it makes you responsible for harder problems. But that's the point. Everyone faces difficult decisions. The difference is those who built this muscle early get to choose which hard problems they want to solve. Everyone else takes whatever hard problems life hands them. Start before life gets complex—before each new responsibility makes every risk feel heavier.”

featured in #584