As If Sand Were Stone…

8 min readMar 1, 2022

— A blog on my learning of the book “Software Engineering at Google”

Part 1

I have a habit of reading the book from preface which many skip or ignore thinking it to be non-essential. I with my writer hat know well and very well that;

Preface is in concert encapsulates the essence of whole book and important milestones the readers would encounter in this voyage.

A good writer makes sure that it spends enough time in writing and editing the preface to make it as perfect as it humanely can to make the reader well aware of the context and texts to expect in the the first and the last part of the book, as it precedes the narration itself and serves as the explanation of the it’s point of view and the answer to the comments.

One can only commiserate with those readers who don’t perturb themselves and read the preface providently.

This book’s preface starts by asking a question asking a vital question which has various meaning so in my opinion it’s an apt question to start with and set the premise of the whole landscape clear right from word go.

The question author poses is;

What precisely do we mean by “software engineering” ?

Photo by RepentAnd SeekChristJesus on Unsplash

The author doesn’t answer this pertinent and important question and goes on to the further inquisition asking two more questions.

What distinguishes “software engineering” from “programming” or “computer science” ?
And
Why would Google have a unique perspective to add to the corpus of previous software engineering literature written over the past 50 years?

Many a times we relate “software engineering“ to “programming” in a synonymous and identical fashion, but are they same or different. This is one of the myth author busts in the second paragraph of the preface.

He says and I quote;

The terms “programming” and “software engineering” have been used
interchangeably for quite some time in our industry, although each term has a
different emphasis and different implications. University students tend to
study computer science and get jobs writing code as “programmers.”

“Software engineering,” however, sounds more serious, as if it implies the application of some theoretical knowledge to build something real and precise.

Mechanical engineers, civil engineers, aeronautical engineers, and
those in other engineering disciplines all practice engineering.
They all work in the real world and use the application of their theoretical knowledge to create something real. Software engineers also create “something real,” though it is less tangible than the things other engineers create.

To answer the second question;

Why would Google have a unique perspective to add to the corpus of previous software engineering literature written over the past 50 years ?

The author gives following reasoning which in my opinion one could hardly contest;

Unlike those more established engineering professions, current software
engineering theory or practice is not nearly as rigorous. Aeronautical
engineers must follow rigid guidelines and practices, because errors in their
calculations can cause real damage;

Programming, on the whole, has traditionally not followed such rigorous practices. But, as software becomes more integrated into our lives, we must adopt and rely on more rigorous engineering methods.

So with this reasoning which is beautifully put in preface, one can expect that readers are going to get a bit more than they already know and it also creates a question what they do at current organisation is different from what Google does.

It’s with this curiosity I picked this book as I have been programming and doing software engineering for more than two decades now and in each organisation I have worked has elaborate engineering practices at place and I had the curiosity and a scepticism too and the purpose why I read it cover to cover to answer another question of mine;

Can I pick something new and unique which can help me becoming a better programmer and software engineer.

As I concluded after finishing this book, I can clearly enumerate the way Google has embedded following key constituents in their engineering practices.

Culture
Process
Tools

Now all these are nothing new as each organisation tries to encapsulate such philosophies while building engineering culture.

But as I read and also elucidated by author in very beginning that the methods and techniques described in this book are not to be taken as sermons and I consider them as very good practices which one can attempt to apply at individual level at least to make one a better programmer and software engineer.

However there is a lot to learn from this book and It would be virtually impossible for me to cover every aspect the book covered and the learning I got while reading this book, so I will attempt to summarise my thoughts in the form of TL;DRs as this book also does at the end of each chapter.

There are 26 chapters in this book so even with TL;DRs It would be just impractical to cover all the learning hence I will be covering this in series of blogs on this topic and this is the first part of that series.

Thesis

Chapter 1 : Software Engineering

TL;DR

“Software engineering” adds an extra dimension to “Programming”, programming is all about writing a code, and software engineering extends it by making it an art which needs to be cared , preserved and maintained to keep that art alive and flourishing till it completes it’s defined purpose and life span.
Care and Love one has to show for a critical and long-lived piece of code has to be much more and refined than a trivial and short-lived code.
Hyrum’s Law: with a sufficient number of users of an API, it does not
matter what you promise in the contract: all observable behaviours of
your system will be depended on by somebody.
Repeated tasks should be scalable in terms of human input and there should be right policies to achieve desired scalability (at least linear)
Be proactive and be careful about boiled-frog problems.
Don’t do anything because you hear “Because I said so”.
Don’t do few things on somebody’s whim and fancies, every action you do should be data driven.

Culture

Chapter 2: How to Work Well on Teams

Three Pillars;

Pillar 1: Humility
You are not the centre of the universe (or your code!). You’re neither
omniscient nor infallible. You’re open to self-improvement.

Pillar 2: Respect
You genuinely care about others you work with. You treat them kindly
and appreciate their abilities and accomplishments.

Pillar 3: Trust
You genuinely care about others you work with. You treat them kindly
and appreciate their abilities and accomplishments.

TL;DR

There is a trade-off of working in isolation and it’s important to understand it well.
Communication is key to avoid conflicts, a lack of communication creates distrust and right and timely communication can go in long way in building the right culture and mutual trust within team.
Understanding the team and organisation style is key to the success and culture fitment is mandatory to be successful.

Chapter 3: Knowledge Sharing

TL;DR

It’s important to focus on to ensure “Psychological Safety” for fostering knowledge sharing environment within team and organisation.
Take one step at a time , write questions and write things which needs to be done as clearly as possible to leave nothing to imagination or suspicion.
Encourage and reward those who take time to learn to broaden their perspective and eager to teach to others within team and organisation.
No silver bullet strategy in knowledge sharing, keep innovating and keep the new thoughts flowing don’t create hurdles for innovation.

Chapter 4: Engineering for Equity

TL;DR

Engineering bias is the default
Diversity is necessary to design properly for a comprehensive user
base.
Inclusivity is critical in team to make it trult supportive environment of innovation and creativity.
Product velocity is not the number of lines of code or features delivered . velocity must be evaluated against providing a product that is
truly useful to all users. It’s better to slow down than to release a
product that might cause harm to some users.

Chapter 5: How to Lead a Team

TL;DR

Don’t “manage” in the traditional sense; focus on leadership, influence,
and serving your team.
Delegate where possible, don’t DIY (Do It Yourself).
Pay particular attention to the focus, direction, and velocity of your
team.

This is first part of this blog series there are 21 more chapters to be covered which I will cover in subsequent blogs, so stay tuned if you like.

Nothing is built on stone; All is built on sand, but we must build as if the sand were stone. — Jorge Luis Borges

Credit: Gaurav Madaan YouTube Channel

About Me:

My name is Santosh Akhilesh, I’m a Computer Science Engineer; I love to and attempt to write about; Humans and Philosophy, Poets and Poems, Artists and Arts and Humans and Computers; all together, all intermingled, all united as an unison like a Beethoven Symphony.