Issue #221, 17th February 2017

This Week's Favorite


How to Be an Effective Early Stage Employee. Hint: Be Helpful.
5 minutes read.

I've used the "Helpful Hierarchy" (well, I didn't call it like that though) Daniel Debow introduced here many times before, talking about it with my teammates who just started their career as Software Engineers. This is probably the best advice I can give others, as I know how much it helped me to push forward and make a difference in every company and role I did before. I think that you can replace “and I fixed it” with “I’d love to take X days, and get it fixed” unless the problem is really small (rarely the case).

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


Culture


Oh Cool, the Tests All Pass on the First Try
1 minutes read.

My humble effort to help you start the weekend with a smile on your face.

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


Hiring & Opportunity
4 minutes read.

Julia Evans shares a great post on what you need to do in order to attract great candidates to your team (and what even "great" means) -- The biggest challenge is explaining how someone fits your specific team, and how it's a mutual win for both sides. Julia is working for Stripe, a company with a great engineering brand. Still, hiring for her team means joining a specific team, tackling specific challenges. Can you explain why someone should join your team? Does it sound exciting? Can you make it specific to them?

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


Balancing Early and Later Project Risks
3 minutes read.

Bill Schneider shares how Senior Engineers can help balancing (/mitigating) risk by figuring out the current phase of the project. Senior Engineers have to understand the dynamics of the business, to grasp the entire Value Stream from idea to production, ending with revenues or growth impact. I'd pick Bill's definition of "type 2" as I believe most companies lost focus and momentum due to "type 1" mistakes.

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


Paint Drip People
2 minutes read.

"I was a big fan of the T model of skills, introduced by David Guest in 1991: know about a lot of things, be really good at one. The more I taught it, the more unhappy I got with the metaphor" -- the T model is an old one, something I've used when talking with others about career growth, but Kent Beck's Paint Drip metaphor is indeed a better one. Share it with your teammates, what is your metaphor for career growth? Why?

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


Peopleware


Make the Other Mistake
5 minutes read.

Please don't miss "The Fear Wall", I've seen too many times great engineers, kind and humble, holding back for too long. Mark Rabkin with an inspiring post and a new mental image you can use to boost your learning and growth.

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


Mental Frameworks for Making Decisions
5 minutes read.

Friends who know me well, heard me talking about Nathan Barry a lot! His advice on "dealing with team issues" is super important to follow. Be a helpful consultant rather than trying to fix everything your own. People have to build relationships with others, so don't resolve conflicts where there is an opportunity to build a stronger team.

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


The Root Cause Fallacy
3 minutes read.

"stop looking for a single root cause, and instead identify the system of conditions or dysfunctions that jointly caused the observed problem. This allows something constructive to come out of the postmortem, instead of inexorably bringing pressure to bear on a well-meaning person who will then be sacrificed to appease the false gods of reductionist blame-gaming." -- well written, read the all post as it provides a better approach than the "5 whys" so common today.

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


Inspiring Tweets


@BenNadel: “Write code that’s easy to delete, not easy to extend” … is one of the best pieces of programming advice I’ve ever read.

@Nick_Craver: I'LL SEE YOU IN GIT BLAME!

- Oren

P.S. Can you share this email? I'd love for more people to experiment and improve their company's culture.

Subscribe now & join our community!