Issue #364, 15th November 2019

This Week's Favorite


Team Composition
4 minutes read.

Richard Crowley with one of my all-time favorites, explaining why you need to think of teams and projects like sports teams or puzzles: "Even though pretty much any team can deliver results, suboptimal team composition is still a problem. It’s a problem when teams working on very straightforward projects take longer than necessary. It’s a problem when teams stacked with senior engineers are neither mentoring junior engineers nor taking moonshots. Most importantly, these problems are hard to notice because, again, everyone’s delivering results. But your competitor who composes their teams more thoughtfully is going to perpetually eat your lunch. They’ll get to market faster, they’ll innovate faster, and you’ll be left behind."

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


Culture


Meetings vs. Emails
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.


Starting an Engineering Management Book Club
6 minutes read.

"An engineering management book club is the best of both worlds. It allows members to build their first team while leveling up their management practice. I can’t recommend it enough." - Dan Na covers some helpful ideas for why and how to start a club book for engineering managers in your company.

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


MLOps, or DevOps for Machine Learning
5 minutes read.

This area of Machine Learning infrastructure and automation is new enough that I feel this post can provide good alignment in your organization. I see many Data Engineers moving towards this area, and learning the craft slowly over time. Increasing the speed of the pipeline can do wonders to the type and number of experimentation you can try out, very much like CD enabled better reaction to market needs and superior customer support. Both affects the bottom line of the buiness.

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


This 1997 Interview With Jeff Bezos on Why Amazon Started as an Online Book Seller After Considering 20 Other Product Categories (CDs Being 2nd Choice) Is a Master Class in Understanding of Competitive Advantage (Video)
3 minutes read.

What can you do now that couldn't happen before (or was extremely uncomfortable)? This short interview with Jeff Bezos made me think a lot about the products I've built and the ones I have in mind for side-projects and at my work.

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


Peopleware


How to Be A Good Software Engineer Mentor
4 minutes read.

Share Milecia McG's post with senior ICs in your organization to shed some light into "how good mentorship looks like." I'd add to Milecia's advice on "Let them finish their thoughts before you tell them the right way" to share the tradeoffs: pros & cons, risks they see, and how they'd mitigate that. As "consultants" we should focus on options and enrich the conversation.

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


Effective Learning for Software Engineers
8 minutes read.

In a world where information is endless, the ability to effectively consume information and apply it becomes a challenge. Vitaly Pushkar offers a helpful framework to apply (I'd use Spaced Repetition instead of a daily 10-15 minutes practice) when taking on a new subject. I think that learning in groups can add good peer pressure to push yourself further to learn, practice, and share your learnings within the group.

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


How to Make Good Code Reviews Better
7 minutes read.

I'm a big fan of everything Gergely Orosz (Engineering lead at Uber) writes. What can you take it from and make Code Reviews better in your team? What would you add to it? Which anti-patterns would you avoid?

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


Inspiring Tweets


@kenegozi: Microservices is an O(n) problem, where n is number of business teams in the organization.

@littleidea: Hot Take: enterprises struggling to deliver software would make more progress from having everyone involved contribute to an open source community for one week than from an infinite amount of agile coaching 🔥 🔥 🔥

- 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!