How many books do you read a year?

The Story of the DelightRoom Dev Group (Book) Study

According to the 2023 National Reading Survey published by the Ministry of Culture, Sports and Tourism, the overall reading rate among adults was just 43.0%. That means only 4 out of 10 people read books. Literally, only 4 out of 10 people read what we call "books." The overall reading rate represents the percentage of people who have read at least one book in a year.

In the DelightRoom engineering group, we hold an Engineering Day once a month. We read a selected book (mostly engineering books), summarize designated chapters, and share our thoughts. Although the premise is to finish the book, members sometimes participate after reading only a part of it. DelightRoom engineers read at least one book every month. We're reading nearly three times the national average.

What kinds of books do we read?

Our first book was <The Art of Readable Code> (published in Korea as "Readable Code is Good Code"). It was the middle of summer. The study time was 8 AM. "Readable code is good code" is both the title and the core message of the book. It argues that code is written for engineers to read, not just computers, so it must be easy to understand. Code should be written in a way that minimizes the time it takes for someone else to understand it, and writing readable code leads to well-structured architecture and testable code. It advises prioritizing readability whenever things feel ambiguous. Developing with this mindset is said to make you a better engineer.

Beyond that, it explores various topics like how to write good comments, criteria for identifying useless comments, variable readability, refactoring, and testing—all helping us figure out how to write readable code.

After the study, we leave ratings for the book. Leaving ratings helps us decide what kind of book to read next.

The Dev Group study has been going on for seven months now. The books we've read together are as follows.

In "The Programmer's Brain," we explore various ways to improve an engineer's productivity by borrowing insights from neuroscience. We also read "The Psychology of Computer Programming," which covers the psychological aspects of programming. Additionally, we read "Software Engineering at Google," "Team Topologies," Kent Beck's "Tidy First?," and a book on programmer passion.

I'd like to briefly share some of the notes summarized by our members.

"Software Engineering at Google" Chapter 2: How to Work Well on Teams

(Summarized by Saeroi)

People aren't perfect. That's why humans are often described as something closer to a "collection of intermittent bugs."

The core of this chapter: "Software development is a team endeavor." For a team to succeed, we must align our behaviors with the core principles of humility, respect, and trust.

How do software engineers around us typically behave?

I want to hide my code

Insecurity. People are afraid of having others see and judge their work-in-progress.

The myth of the genius

Many people instinctively look for idols. Linus (created Linux), Guido van Rossum (created Python), Bill Gates (founder of MS), Steve Jobs (founder of Apple)—it's true that they all started things, but their greatest achievement was massively growing their communities or teams.

However, most engineers instinctively need heroes to inspire them and want to be seen as geniuses themselves. They value their own abilities more than teamwork.

The genius myth is just another example revealing our inner insecurities. Many programmers are reluctant to share a project they just started out of fear that if their peers see their mistakes, they'll realize they aren't a genius.

Hiding is harmful

If you work entirely alone, you unnecessarily increase the risk of failure and shortchange your own growth potential.

Share early to get feedback quickly and improve. Sharing early increases your bus factor.

Bus factor: The number of teammates who would have to be hit by a bus (and incapacitated) for a project to be doomed.

The bottom line: don't hide

"Working alone" is inherently riskier than "working together." Even if you're afraid someone will steal your ideas or think you're not smart, you should be far more worried about the possibility of wasting your precious time on the wrong things.

It's all about the team

The lone craftsman is rare. Even if they exist, they don't achieve transcendent feats alone.

Great teams make good use of superstars, while simultaneously delivering results greater than the sum of their individual members' outputs.

If teamwork is the best path to building great software, how do you build a great team? How do you find one?

The three pillars of social skills:

Humility: You and your code are not the center of the universe. You don't know everything, and you aren't perfect. A humble person is open to learning.

Respect: You genuinely care about the colleagues you work with. You treat them kindly and appreciate their abilities and accomplishments.

Trust: You believe your colleagues are competent and will do the right thing. It's okay to let them set their own direction when necessary.

Blameless post-mortem culture

Post-mortem: A retrospective process that looks back at what went right and what went wrong.

The key is learning from mistakes.

Wrapping up

People who read the same book develop a strange sense of solidarity. When we needed to converse or make decisions, the books we had read often came up as topics. Because we read the books together, introducing a methodology from them didn't require long explanations. The insights gained from a single book become a driving force that leads to new challenges, going beyond the simple accumulation of knowledge. The solidarity formed by reading and discussing together serves as a stepping stone for even greater progress for all of us. I hope that the individual growth achieved through reading leads to the development of not just the individuals, but the entire team and organization.