/Career Advice

My Approach To Building Large Technical Projects

- Mitchell Hashimoto tl;dr: “I've learned that when I break down my large tasks in chunks that result in seeing tangible forward progress, I tend to finish my work and retain my excitement throughout the project. People are all motivated and driven in different ways, so this may not work for you, but as a broad generalization I've not found an engineer who doesn't get excited by a good demo. And the goal is to always give yourself a good demo.”

featured in #591

To Avoid Being Replaced By LLMs, Do What They Can't

- Sean Goedecke tl;dr: “It’s a strange time to be a software engineer. Large language models are very good at writing code and rapidly getting better. Multiple multi-billion dollar attempts are currently being made to develop a pure-AI software engineer. The rough strategy - put a reasoning model in a loop with tools - is well-known and (in my view) seems likely to work. What should we software engineers do to prepare for what’s coming down the line?”

featured in #591

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