Software Lead Weekly Software Lead Weekly

Normalization of Deviance
12 minutes read.

"But where things are going well, as in the small company with the light-touch CEO mentioned above, almost no one has any idea why things work. It's magic.[...] But it's not magic. It's hard work that very few people understand." -- Dan Luu's post is so wonderful, even the footnotes are insightful. Dealing with the natural entropy in the company by continually rethinking and iterating on the processes and the talent structure can take you a long way. The first step though, is finding good workshops or a coach for teaching employees how to conduct emotionally uncomfortable conversations. There is no improvement if there is no reflection and open discussion.

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

These Captchas Are Getting Harder
1 minutes read.

My humble effort to help you start the weekend with a smile on your face. Snipers and Captcha, what can go wrong?

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

Unlearning Toxic Behaviors in a Code Review Culture
11 minutes read.

Sandya Sankarram with a post that you should share within the engineering organization. It will increase empathy and provide a few more tools for those who want to give feedback but not sure how to do it well. I'd expect Senior Engineers to act according to Sandya's tips, and provide feedback to others if they see a toxic behavior. The impact on the team's morale and ability to work together is at stake.

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

The Paradox of Scale: Netflix Couldn’t Build Netflix
4 minutes read.

"But if we shift our perspective and look, not at where they are today, but at how they got started and the way that they move, there’s a beautiful release." -- Who can you learn from that is 6-12 months ahead of where you're standing now? What would you ask them? Which building blocks they built that enabled them to provide value at scale (turning into a complex system)?

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

How to Build a PaaS for 1500 Engineers
12 minutes read.

Every team that is building a system for internal customers should read this post. It provides useful guidelines for where you should focus on, and how to communicate your value: "[...] by providing these metrics, we facilitate a conversation between tech and business, between cost and profit centres. And precisely because we measure the productivity of teams, we can also measure in what degree our job delivers on our mission: support teams to deliver at their best."

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

On Drafting an Engineering Strategy
6 minutes read.

Mathias Meyer provides a method you can leverage for creating a strategy for engineering teams. I'd read the section on "Gathering Perspectives and Input" multiple times, as this can prevent costly irreversible decisions.

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

Building Trust — With People and Software
8 minutes read.

Tal Joffe uses the analogy of building trust in our ability to maintain and develop code by using tests to building trust with people by using 1:1s: "If we remember that our goal in testing is to be able to trust our code and not to achieve 100% coverage, for instance, we would make sure our tests are descriptive and focus on expected behavior and not on the implementation details. Similarly, our goal in 1:1s is to build a relationship between us and our directs so we can trust them and they can trust us and not getting updates on project status, for instance."

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

@samkottler: No amount of process will ensure the right work is getting done.

@davidbrunelle: A lot of folks who work in technology believe that logic, alone, is sufficient to change minds or sell an idea. In a perfect world maybe a solid argument *should* be sufficient. But in reality, you also need to make people care.