Issue #378, 21st February 2020

This Week's Favorite


Gross Company Happiness
4 minutes read.

"Companies make this mistake all the time. They have a maniacal focus on revenue while neglecting things like happiness. Ultimately this causes people to leave (ironically detrimental to the revenue they care so much about)." -- Clearbit's attempt to define and measure their "Gross Company Happiness" is a wonderful framing for the employees, making sure they enjoy the process while (hopefully) achieving their goals. How would you define it in your company? How would a happy few years in your company look like?

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


Culture


Can You Fix This Small Bug? It Should Not Take Too Long.... 🤷🏻‍♂️
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.


How to Break the “senior Engineer” Career Ceiling
5 minutes read.

Figuring out how impact vs. output looks like in your role (in the team) is where you should start. Which systems are critical for the success of the team? Do you have the right talent to execute (if not, how do you help there?)? Which tools are missing to get the team more effective? Are you inspiring them and teaching them to make others around you 10% better? Do people want to stay in the team to be around you? Excellent read by Yan Cui, and I'd read twice his advice on "Why you wouldn’t want to become a principal engineer."

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


The Pizza Model for Happy and Productive Teams
5 minutes read.

Adi Oz with a simple model to understand where you should optimize when serving your team as their manager. Each one of us is looking for something else in the company, so we should try to figure that out (in 1:1s) and then see which type of work and victories would make our team happier and engage with the day to day. Never assume; Ask.

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


Developing in Production: Mindset & Tools
6 minutes read.

Will Sargent with a post that I think every company with more than 30 servers in production should have as part of their onboarding for software engineers. "Scale and complexity cannot be ignored, because that's where the edge cases happen. [...] There's a saying in medical school for new students: When you hear hoofprints, think of horses not zebras. But in a sufficiently complex system, zebras exist."

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


Peopleware


Everything I Know About Asymmetries, I Learned From Woody Harrelson. Most Importantly: Always Double Tap. (Thread)
3 minutes read.

Taylor Pearson always gets me to think. If you can limit your downside, take the time you need to do it. While this sounds obvious, not many people pause to think about how to do so. For example, if you're worried that you're not learning enough and thinking of leaving your company to chase a new adventure, think about it again. Changing a company often means starting over (building credibility and confidence with others), which is a huge risk. Maybe you can stay in your current company and define the downside there carefully, so you and your manager could work on limiting the downside ("not growing fast enough")?

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


Technical Debt Is Like a Tetris Game
4 minutes read.

The Tetris game is a good analogy (with your Product Managers) as you often need to prioritize which tech debt you need to solve at this moment: "if you manage to build a clean, compact structure, then it will be more manageable later in the game. [...] And when someone asks you do keep adding features to this piece of code, you can explain to them that it is like a Tetris game filled up to the top. Because of the badly handled debt in the past, you can’t make any new block fit in."

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


Inspiring Tweets


@dhh: The quickest way to ruin the productivity of a small company is to have it adopt the practices of a large company.

@QuinnyPig: Myth: Your AWS bill is a function of how many customers you have. Fact: Your AWS bill is a function of how many engineers you have.

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