/Culture

Engineering A Culture

- Bryan Cantrill tl;dr: Bryan, CTO at Oxide, discusses fostering a culture of "openness, curiosity, and communication,” sharing some implementation details: (1) Uniform compensation, even if it might not scale indefinitely. (2) We are writing intensive, but we still believe in spoken collaboration. (3) We have no formalized performance review process, but we believe in feedback. (4) We record every meeting, but not every conversation. (5) We have a remote work force, but we also have an office. (6) We are non-hierarchical, but we all ultimately report to our CEO. (7) We don’t use engineering metrics, but we all measure ourselves by our customers and their success. 

featured in #502

What It Was Like Working For GitLab

- Yorick Peterse tl;dr: Yorick suffered from burnout after leaving Gitlab in 2021 and recently found the energy to discuss what he’s learned: “(1) Scalability needs to be part of a company's culture. (2) Make teams more data and developer driven. (3) You can't determine what is "minimal viable" without data. (4) SaaS and self-hosting don't go well together. (5) More people doesn't equal better results. (6) I'm conflicted on the use of Ruby on Rails. (7) The time it takes to deploy code is vital to the success of an organization. (8) Location based salaries are discriminatory.”

featured in #488

Using Cultural Survey Data

- Will Larson tl;dr: Will focusses on reading and acting upon survey data from the perspective of an engineering leader. In this post he works through: (1) Reading survey results. (2) Taking action on survey data. (3) Whether to modify survey questions. (4) When to start and how frequently to run.

featured in #397

Why I Quit Google’s WebAssembly Team, And How It Made Me Sick

- Katelyn Gadd tl;dr: "This is a partial story of what went wrong with the process and how it permanently damaged me. My hope is that this story will help people recognize toxic cultures in their own workplaces, or help new hires have a better career at Google."

featured in #316

IBM's Asshole Test

tl;dr: "They called it the "group test"; around 8 of us were led to a room and asked to solve a puzzle together. Each of us was given an information pack, there was a white board, and a timer ticking down from 60 minutes."

featured in #314

The Workplace Perks Your Developers Actually Want

- Nicole Kow tl;dr: (1) Expanding care benefits for the young and elderly - "61% of companies are opting for more flexible childcare benefits." (2) Flexibility - "2 out of 3 workers still want a balance between complete flexibility and a predictable work schedule." (3) Focusing on mental health - "76% of respondents reporting at least one symptom of a mental health condition in 2021."

featured in #312

Dimensions Of Power

- Kent Beck tl;dr: At Kent's company Gusto, the engineering team switched from private to public engineering levels and, as part of the transition, Kent wanted to emphasize to senior engineers and managers that power should not be misused. Here is Kent's ways in which to exercise "power advantages" & experience power disadvantages.

featured in #307

The Scoop: Inside Fast’s Rapid Collapse

- Gergely Orosz tl;dr: "I am covering details from the vantage point of software engineers and engineering managers." Gergely covers how Fast able to hire engineers competing with the big tech companies, warning signs within the company as seen from an engineering perspective, the current situation within the company, and more.

featured in #307

How Google, Twitter, And Spotify Built A Culture Of Documentation

tl;dr: "Today we’ll look at how 3 high performance engineering companies handle their technical documentation" starting with Google and their g3docs system, which "made documentation radically simpler for engineers." It (1) presented one way to document things, removing decisions. (2) Hosted docs next to the code so engineers can stay in their IDE. (3) Automatically rendered docs into designed HTML pages on commits.

featured in #298

The Ritual Of The Deploy

- Vicki Boykis tl;dr: "Deploying is a ritual, one of my coworkers wrote recently. It’s a sacred place, a quiet place, and a dangerous place, where anything can happen. In deployment, the system is in a fragile state, and you are in a fragile state." Vicki points to a prod deploy as a common, ritualistic moment for engineers.

featured in #265