Software Lead Weekly Software Lead Weekly

The Maker of Things
5 minutes read.

Wonderful writing by Michael Lopp, on the great story behind Brooklyn Bridge. "We are defined by what we build" resonates so well with me, as I've seen too many people doing what's easy - destroying ideas and achievements, criticizing for the sake of self-glorification or afraid of taking a minimal risk that might hurt their personal "brand" they made up in their mind. I've seen too few trying to build. We sure do need more of those. Leaving a better world behind us is a legacy worth living for.

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

Tech Life as Graphs
2 minutes read.

My humble effort to help you start the weekend with a smile on your face. "Do your css rules are working" is so funny it should be on a t-shirt.

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

How Facebook Tries to Prevent Office Politics
5 minutes read.

Great tips on things you should do to reduce politics in your organization. One of the key elements I truly agree with is "Make escalation "legal"" as I find it to reduce a closed mind, where you say to yourself "I don't want my CTO or product manager to talk directly with my teammates or vice versa, they should go through me". If you hire people with good intention and work together on building trust, you should actually motivate people to talk directly with whoever is most relevant. The second you become defensive, you're already losing in this game of organizational politics.

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

Finding Time to Become a Better Developer
7 minutes read.

Share this article with your engineers, it's golden. I wanted to pick a few favorites, but I was afraid to copy&paste the entire article. Now, do what I believe is right and ask them to capture 2-3 hours (weekly) in their calendar for deliberate learning - each week can be dedicated to a specific topic. Yes, it should absolutely be on the company's "expense". It will manifest in happier employees, who get things done faster over time.

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

Notes From the Field: Summarizing Dozens of Meetings With M&A Teams
3 minutes read.

I try to share with my teammates (all software engineers) as much as I can about our business: basic dynamics behind VC investments and what it means to our startup, how SaaS companies metrics should look like at growth and pretty much anything else I believe could provide them a richer context. I believe that the more context they will have, the better decisions they'll make on their own during their day to day tasks. This post has a lot of interesting observations behind startup acquisitions that I felt fall under this category.

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

Bad Habit #4: Fix Other People’s Mistakes
5 minutes read.

Important read by Marcus Blankenship, pointing at a bad habit almost every new Engineering Manager. This is something I did in my first year as a manager. It took me a full year to understand how risky this path is, and how much damage it can cause to my relationship with others, not to mention the long hours I pulled off. If you know someone who just became a manager for the first time, be a good friend and share it with them.

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

How I Interview
5 minutes read.

It's always interesting to read and learn from different people on how they interview. Randall Koutnik's "Common interview antipatterns" are practices I myself try to avoid as well, as they tend to measure the wrong things and can hardly predict the candidate's success assuming they'll be hired. This is of course based on my own experience only, but asking yourself "is there any correlation between this question and the candidate's success on our team?" for each question you're using is already a great step forward.

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

@mipsytipsy: name your db nodes after GoT characters, to remind yourself you shouldn't give a shit when they die. #lifehacks

@jessitron: gitmire (n): when you have no idea how your repo got into this state, and even less how to get it out. :-(