Software Lead Weekly Software Lead Weekly

Your Job Is Not to Write Code
4 minutes read.

A must read post for every software engineer and leader out there, on the explicit expectation of delivering value rather than code. That being said, I believe most of the time the fault is in setting the expectations right, where many leaders fail: "If you get hassled for writing less code, that’s a failure of management... We need to spend less time demanding that you write features and more time asking you to improve our product for our users. If we’re not doing that, I strongly suggest you ask us to."

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

When I Install a Software
1 minutes read.

As always, something to start the weekend with a huge smile on your face. Installing software in 2015. Happens every time.

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

Trouble With DevOps? Try TrekOps
3 minutes read.

Spent a lot of my childhood watching Start Trek and never thought of this one great observation: "Something that is really great about Star Trek, is that when a character notices something is amiss, and they are the only one to see it, the rest of the crew doesn’t just dismiss their concerns offhand." - do you treat your people the same? Does your teammates respect each other's opinion?

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

Lessons Learned From Scaling a Product Team
12 minutes read.

There is never one recipe to use when you scale a team, but it's always interesting to read how different companies approach it and the reasoning behind it. I'm going through something similar at my company, so I took from it many points on how to set clear accountability and re-thinking our approach to weekly or bi-weekly demos, to make sure people see what others built.

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

How Successful Remote Teams Evaluate Employees
8 minutes read.

It's always interesting to learn what you can take from remote teams even if your team is not distributed. Everything needs to be much more explicit working in a distributed company, thus the learning you can get by carefully paying attention to the downfalls. I specifically enjoyed "Look to the Team for Feedback" and "Provide Feedback Often" sections.

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

The Geek's Guide to Leading Teams
45 minutes read.

Great lecture by Patrick Kua you should watch if want to lead other software engineers at some point. Patrick is a great speaker, so my only advice is to grab some cup of tea or coffee and watch it. Share it both with current leaders and people who seek to reach that point in the near future.

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

A Few Traits of Successful Managers
3 minutes read.

Great observations from Cap Watkins (of Etsy) on some of the traits of successful managers. While all 3 points are spot on, my favorite is "Great managers do what they say they’ll do."

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

Technical Debt: Adding Math to the Metaphor
10 minutes read.

I'd send this post to every non-engineer employee who often do not understand the cost of Technical Debt - "By analogy with financial debt, it is economically sensible to incur technical debt when the expected cost of the obligations incurred is lower than the benefits gained by deferring the work.".

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

@jaykreps: Software is mostly human capital (in people's heads): losing the team is usually worse than losing the code.

@jadler: OH: "Software is eating the world, and it is shitting data."