Software Lead Weekly

The Ultimate Guide to First-Principles Thinking
5 minutes read.

This is such a beautiful guide into First Principles thinking. Use it as a map to delve into an area or two you find interesting now as it offers books, posts, and videos worth learning from. Go back to it when you want to explore a different area or to go deeper. You can spend 5 minutes to skim around for topics and content and find yourself 3h later looking for more.

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

When to Create.
1 minutes read.

My humble effort to help you start the weekend with a smile on your face, even in this difficult time. Good thing today is Friday, so I created this email.

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

Building Great Engineering Teams
7 minutes read.

Paulo Andre interviewed Gergely Orosz to get some tips on engineering management. "So we'd estimate impact on everything and then just stack-rank it. This, by the way, doesn't necessarily have to be dollars. With tech debt work, engineers often say we should refactor this API, for example. Well, what's the impact? " -- if you want to increase your impact as an IC, always think about this question when coming up with new suggestions. Talk with people around you to see how they'd measure it.

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

The Management Flywheel
5 minutes read.

"When you find yourself in a rut, remember that you don’t have to solve the root cause of everything wrong with the team as a first act. Start with the little problems. Give the team some small wins, clarity, and focus. Make their job a little bit easier, and help them work a little bit faster. Build up speed on the flywheel" -- Camille Fournier with helpful advice for managers who want to build initial momentum to get people engaged.

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

A Primer on Engineering Delivery Metrics
7 minutes read.

Juan Pablo Buriticá will get you to think about the metric you want to measure for your engineering team, and how to communicate the value the team will gain from it. Measuring build time, merge time, and number of successful deployments can help you improve the pipeline and make it more predictable. I'd look for measurements that will build trust with upper management as well. For each company, it might be a bit different. Ask others for feedback on what they'll consider as good indications for a highly performant engineering team.

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

A Few Rules
4 minutes read.

Morgan Housel with excellent rules for life. "Tell people what they want to hear, and you can be wrong indefinitely without penalty." -- this is such a powerful rule for leaders. It's so easy to try to please everyone.

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

A Better Code Review
7 minutes read.

I'm fortunate to work with Gilad Peleg and see his work in action, and I love his approach and mindset for Code Reviews. I look at CR as a way to understand "what did you try to achieve with this change?" and discuss that. What was considered? Is it the right place to make the change? If this change breaks, how will we know? If someone new will need to maintain this change, is it clear enough to follow?

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

@ctrlshifti: maybe when talking about tech debt and spaghetti code, the blame shouldn't be on the engineers who write it but rather the economic systems that incentivize short term profit and alienate us from the value of our own labor.

@TaylorPearsonMe: It's effectively impossible to evaluate and improve team performance without some sort of written principals and procedures. Without them, discussions devolve into talking past one another because of a lack of shared context about the actual measuring stick being used.