Software Lead Weekly Software Lead Weekly

How We Make Decisions at Coinbase
8 minutes read.

Brian Armstrong shares the framework they're using at Coinbase to make decisions. You should print "What does good decision making look like?" and hang it on the wall in your meetings room. Setting the rules, the owner of the decision and holding people accountable for "disagree & commit" are all critical for a healthy organization.

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

Developer: "Here's Some Water." QA: ...
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.

Team Reviews
4 minutes read.

"It’s easy for managers to fall into the trap of exception handling: spending a ton of attention on the biggest stars or the biggest problems on our teams. That leaves so many people without the attention and support they need. A team review forces you to consider and talk over everyone’s work, how that work is changing over time, and what you can be doing as a manager to ensure each person is either succeeding or leaving." -- Marc Hedlund with a helpful framework Managers of Managers can use to hold Managers in the organization accountable for the people they serve.

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

Foot-Candles: The Different Paths to Tech
4 minutes read.

"Being a self-guided programmer means I go through the same mental cycle again and again. I’m always comparing myself to traditional CS grads. I’m always worried I’m missing something. I’m always worried I’m not enough." -- as a self-guided programmer myself, Alice Goldfuss words are so powerful as the Imposter Syndrome is always there. We all took a different path, and that's okay. It's not better or worse; it's ours.

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

Interviewing for Potential: A Guide to Discover Potential, Trajectory and Performance
6 minutes read.

I highly recommend writing down Brent Baisley's "Potential Questions" and use it next time you're interviewing someone. Hiring for potential is a powerful filter when hiring juniors - they don't have to come from great universities, just have a learning framework to guide them and the hunger to keep pushing forward. I usually tend to ask: "How would you learn [something they care about]?", waiting for the obvious "Well, I Google it up and read a few tutorials/videos." Then, I ask "How do you know it's any good? How can you trust the author?" -- Their answer here shows their ability to criticize what they learn, and go deeper than most will.

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

If You Are a Manager of Engineers, All This Should Come *Before* You Mess With Code: (Thread)
3 minutes read.

Erica Joy with a tweet that I think is spot on, leading to an interesting thread. What do you think Engineering Managers should do before they find themselves writing code? Discuss that at work, I'm sure there is a good opportunity here to learn a few things and hear different opinions.

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

Just-In-Case vs. Just-In-Time Learning
6 minutes read.

"The art of knowing how to learn is a muscle you can build." -- applying just-in-case learning can also help you reason from first principles. This is a powerful advice by Osman Ahmed Osman: "One advice I’ve found really valuable is that when learning something new, always think about what problems could this help me solve now and in the future? That way, when you do see that problem in real life, a little flag goes up in your brain that says: "oh, I know what I can use to solve that problem." One way to reframe that question is what problems was this tool/pattern developed to solve in the first place? If someone invested time in building a tool or thinking through a pattern, learning that tool or pattern without understanding the problem they were trying to solve is actually missing the forest for the trees. You’ll forget the trees anyway, but you’ll probably come across a lot of forests."

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

Delegate Outcomes, Not Activities.
4 minutes read.

"When you delegate the outcomes and not the activities, you help employees not just execute for the task at hand, but equip them for every future task after that. You’re giving true ownership to your team." -- I like the focus on a clear and explicit outcome, rather than focusing on the tactics. Claire Lew with a short and powerful tip when delegating responsibility to someone else on your team.

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

@stavvers: One of the best things about the GDPR is now every time a stakeholder at works asks me to do something I don't really feel like doing, I can go "um, I'm not sure if it's GDPR compliant, do you know?" and they'll give up and die before figuring it out.

@allspaw: Reminder that it takes just as much effort (time, money, staff, etc.) to build the wrong thing as it does the right thing. Problem discovery is under appreciated as a practice in software engineering, especially when compared to problem solving.