Software Lead Weekly Software Lead Weekly

Aging Code
6 minutes read.

Vadim Kravcenko's framing of "Aging Code" and comparing it to Old Money> New Money (don't spend what you just earned) is powerful: "Why should you consider aging your code? Because the longer your code has been around, survived different cataclysms (read: business pivots), and evolved, the more robust it is. The team that has built it before you had time to debug, to optimize, to improve — the code has accumulated years worth of bugfixes that are in places you cant even imagine." -- The last section on "Asking the hard questions" can provide a good baseline for your team to consider where and why you should refactor the code and what would be the benefit of it.

Read it later via Instapaper.
Share it via Twitter or email.

Me When It’s Still Way Too Early but the Kids Start Screaming for Me to Get Up
1 minutes read.

My humble effort to help you start the weekend with a smile on your face.

Read it later via Instapaper.
Share it via Twitter or email.

The Silent Killer of Your Operating Practice: Fear
14 minutes read.

Amanda Schwartz Ramirez shares excellent advice on how to level up your executive team to push it further: "But at a fast-growing company, it's very easy to become hyper-focused on your piece of the puzzle, rather than how the constellation of pieces fit together. This is why team-building exercises, like ropes courses and escape rooms, are a favorite on leadership team offsite agendas: to remind you that you’ll accomplish much more together, versus going about it alone."

Read it later via Instapaper.
Share it via Twitter or email.

Shreyas Doshi: Better Teams, Better Products (Video)
89 minutes read.

When Shane Parrish (of The Knowledge Project) and Shreyas Doshi (one of the best product leader thinkers) meet for an interview, I know there will be so much value to receive.

Read it later via Instapaper.
Share it via Twitter or email.

Your Customers Hate MVPs. Make a SLC Instead.
6 minutes read.

"Simple, Lovable and Complete (SLC). We pronounce it "Slick." As in: "What’s the ‘Slick’ version of your idea?" [...] With SLC, the outcomes are better and your options for next steps are better. If it fails, that’s OK; it’s a failed experiment. Both SLCs and MVPs will sometimes produce that result because the whole point is to experiment. But if a SLC succeeds, you’ve already delivered real value to customers and you have multiple futures available to you, none of which are urgent. You could build a v2, and because you’re already generating value, you have more time to decide what that should look like." -- Slick (SLC) is a healthier way to treat your customers while ensuring you can build a sustainable business.

Read it later via Instapaper.
Share it via Twitter or email.

1 Trick to Finish Your Next Talk in Style
3 minutes read.

Never ending the talk with Q&A is a brilliant advice I never considered: "As you approach the end of your talk, say, "Okay, I am going to take a few questions before I make my conclusion." This lets the audience know that you are not quite finished, keeps the Q&A shorter, and allows you to finish in a way that the audience knows it’s over. When they know it’s over they will applaud in unison. In leaving them with your main takeaways as a summary, you are also more likely to be remembered."

Read it later via Instapaper.
Share it via Twitter or email.

What Is One Belief or Strategy You Have Adopted That Has Made Your Life Easier? (Thread)
3 minutes read.

I love the answers in this thread, for example "Telling my time where to go instead of wondering where it went (planning). I don’t wing it. I plan it." I'm not sure yet what I'd answer to this question, thinking of maybe "Crafting habits and working on ideas I'd be proud to do for decades, not years."

Read it later via Instapaper.
Share it via Twitter or email.

My Approach to Coding Interviews: Optimize for Iteration
13 minutes read.

"Optimizing for Iteration also means to write code in a way that allows you to switch out parts easily as new constraints come in. My general advice to keep code flexible is to not hard-code constants, to use many small, well-named functions and to keep code DRY. Keeping functions small makes it easier to verify just by reading that a function does what it’s supposed to do. If constrainst change, it’s often a matter of augmenting or replacing a single function, without having to touch any of the other parts. Another nice side-effect is that a good function name is basically docmentation and helps the interviewer understand what you are doing." -- Surma's approach to focus on "make it work, make it right, make it fast" while asking the interviewer what he should optimize for (e.g. accuracy? performance? accessibility?) is a healthy and mature approach that most interviewers will appreciate.

Read it later via Instapaper.
Share it via Twitter or email.

@ShaanVP: Companies die a death by thousand group decisions

@gdb: debugging is the art of increasingly understanding the divergence between what you thought you want and what you actually want