Your Software Engineering Bible - Brought to You By Stars from Google

Titus Winters, Tom Manshreck and Hyrum Wright. Five stars - worth the journey just for knowing what's there.. It's available for free. My best bits below..

Protect Your Energy!

Take real vacations

A weekend is not a vacation. It takes at least three days to "forget" about your work; it takes at least a week to actually feel refreshed.

Make it trivial to disconnect

When you disconnect, leave your work laptop at the office. If you have work communications on your phone, remove them.

Take real weekends, too

Again, this recharge works only if you disconnect from work communications. Try truly signing out on Friday night, spend the weekend doing things you love, and then sign in again on Monday morning when you’re back in the office.

Take breaks during the day

Your brain operates in natural 90-minute cycles.5 Use the opportunity to get up and walk around the office, or spend 10 minutes walking outside. Tiny breaks like this are only tiny recharges, but they can make a tremendous difference in your stress levels and how you feel over the next two hours of work.

Give yourself permission to take a mental health day

Sometimes, for no reason, you just have a bad day. You might have slept well, eaten well, exercised—and yet you are still in a terrible mood anyway. If you’re a leader, this is an awful thing. Your bad mood sets the tone for everyone around you, and it can lead to terrible decisions (emails you shouldn’t have sent, overly harsh judgements, etc.). If you find yourself in this situation, just turn around and go home, declaring a sick day. Better to get nothing done that day than to do active damage.

One recurring theme throughout the book seems to be that you should invest in worthwhile things before you need them. So, important is more important than urgent :)

The Leader Manifesto

Always Be Deciding	Ambiguous problems have no magic answer; they’re all about finding the right trade-offs of the moment, and iterating.
Always Be Leaving (Delegating)	Your job, as a leader, is to build an organization that automatically solves a class of ambiguous problems—over time—without you needing to be present.
Always Be Scaling	Success generates more responsibility over time, and you must proactively manage the scaling of this work in order to protect your scarce resources of personal time, attention, and energy.

 

As every system administrator knows, it’s one thing to know in theory that you can recover from tape, and another to know in practice exactly how to do it and how much it will cost when it becomes necessary. Practice and expertise are great drivers of efficiency and reliability.

As noted in the Site Reliability Engineering (SRE) book, Google’s production system as a whole is among the most complex machines created by humankind. So, we have already written a book about the complexity of keeping that machine running at that scale.

Much of this book focuses on the complexity of scale of the organization that produces such a machine, and the processes that we use to keep that machine running over time. Consider again the concept of codebase sustainability: “Your organization’s codebase is sustainable when you are able to change all of the things that you ought to change, safely, and can do so for the life of your codebase.”

The Beyonce Rule

One of our favorite internal policies is a great enabler of infrastructure teams, pro‐ tecting their ability to make infrastructure changes safely. “If a product experiences outages or other problems as a result of infrastructure changes, but the issue wasn’t surfaced by tests in our Continuous Integration (CI) system, it is not the fault of the infrastructure change.” More colloquially, this is phrased as “If you liked it, you should have put a CI test on it,” which we call “The Beyoncé Rule.”13 From a scaling perspective, the Beyoncé Rule implies that complicated, one-off bespoke tests that aren’t triggered by our common CI system do not count. Without this, an engineer on an infrastructure team could conceivably need to track down every team with any affected code and ask them how to run their tests.

Ask Questions

If you take away only a single thing from this chapter, it is this: always be learning; always be asking questions.  

We tell Nooglers that ramping up can take around six months. 

The bad behavior of just a few individuals can make an entire team or community unwelcoming. In such an environment,  novices learn to take their questions elsewhere, and potential new experts stop trying and don’t have room to grow. In the worst cases, the group reduces to its most toxic members. It can be difficult to recover from this state.

Expertise and shared communication forums offer great value as an organization scales. As engineers discuss and answer questions in shared forums, knowledge tends to spread. New experts grow. If you have a hundred engineers writing Java, a single friendly and helpful Java expert willing to answer questions will soon produce a hundred engineers writing better Java code. Knowledge is viral, experts are carriers, and it pays to clear away the common stumbling blocks for your engineers.

Knowledge is In some ways the most important (though intangible) capital of a software engineering organization. and sharing of that knowledge is crucial for making an organization resilient and redundant in the face of change. A culture that promotes open and honest knowledge sharing distributes that knowledge efficiently across the organization and allows that organization to scale over time. In most cases, investments into easier knowledge sharing reap manyfold dividends over the life of a company.

Psychological safety is the foundation that fosters knowledge sharing  environment. 

Start small, ask questions and write things down. 

Make it easy for people to get help from experts and documentation systems (set up forums and good search utilities) references.

At a systemic level, reward those who take the time to teach and broaden their expertise beyond just themselves, their team or their organization.

No silver bullet. Empowering a knowledge sharing culture requires a combination of strategies and those strategies need to change over time.

Another common motivation for hiding your work is the fear that another programmer might take your idea and run with it before you get around to working on it. By keeping it secret, you control the idea.

We know what you’re probably thinking now: so what? Shouldn’t people be allowed to work however they want?

Actually, no. In this case, we assert that you’re doing it wrong, and it is a big deal.

Here’s why.

Hiding Considered Harmful

If you spend all of your time working alone, you’re increasing the risk of unnecessary failure and cheating your potential for growth. Even though software development is deeply intellectual work that can require deep concentration and alone time, you must play that off against the value (and need!) for collaboration and review.

In the realm of programming, lone craftspeople are extremely rare—and even when they do exist. they don’t perform superhuman achievements in a vacuum; their world-changing accomplishment is almost always the result of a spark of inspiration followed by a heroic team effort.

A great team makes brilliant use of its superstars. but the whole is always greater than the sum of its parts. But creating a superstar team is fiendishly difficult. 

Software engineering is a team endeavor

This concept directly contradicts the inner Genius Programmer fantasy so many of us hold, but it’s not enough to be brilliant when you’re alone in your hacker's lair. You’re not going to change the world or.delight millions of computer users by hiding and preparing your secret invention. You need to work with other people. Share your vision. Divide the labor. Learn from others. Create a brilliant team.

Consider this: how many pieces of widely used. successful software can you name that were truly written by a single person? (Some people might say “LaTeX,” but it's hardly “widely used," unless you consider the number of people writing scientific papers to be a statistically significant portion of all computer users!)

High-functioning teams are gold and the true key to success. You should be aiming for this experience however you can.

If teamwork is the best route to producing great software. how does one build (or find) a great team?

Pillar 1: Humility

You are not the center of the universe (nor is 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 believe others are competent and will do the right thing. and you’re OK with letting them drive when appropriate.’

At Google, “readability” refers to more than just code readability; it is a standardized, Google-wide mentorship process for disseminating programming language best practices. Readability covers a wide breadth of expertise, including but not limited to language idioms, code structure, API design, appropriate use of common libraries, documentation, and test coverage.

Readability started as a one-person effort. In Google’s early days, Craig Silverstein (employee ID #3) would sit down in person with every new hire and do a line-by-line “readability review” of their first major code commit. It was a nitpicky review that covered everything from ways the code could be improved to whitespace conventions. This gave Google’s codebase a uniform appearance but, more important, it taught best practices, highlighted what shared infrastructure was available, and showed new hires what it’s like to write code at Google.

Don't design for everyone. Design with everyone. Focus on users who are most impacted by bias and discrimination.

The goal is to make changes that push humanity forward without further disenfranchising the disadvantaged.

Google decided early on, however, that its software engineering managers should have an engineering background. This meant hiring experienced managers who used to be software engineers, or training software engineers to be managers.

Performance, productivity and happiness - what the manager is responsible for - of every person in his team, including tech lead, while ensuring that the needs of the business are still met by the product for which they are responsible.

There are. however. great reasons to consider becoming a TL or manager. First. it's a way to scale yourself. Even if you?re great at writing code, there?s still an upper limit to the amount of code you can write. Imagine how much code a team of great engineers could write under your leadership! Second. you might just be really good at it! many people who find themselves sucked into the leadership vacuum of a project discover that they're exceptionally skilled at providing the kind of guidance, help. and air cover a team or a company needs. Someone has to lead. so why not you?

Servant Leadership

There seems to be a sort of disease that strikes managers in which they forget about all the awful things their managers did to them and suddenly begin doing these same things to ?manage? the people that report to them. The symptoms of this disease include. but are by no means limited to, micromanaging. ignoring low performers. and hiring pushovers. Without prompt treatment, this disease can kill an entire team. The best advice I received when I first became a manager at Google was from Steve Vinter, an engineering director at the time. He said, "Above all, resist the urge to manage." One of the greatest urges of the newly minted manager is to actively "manage" their employees because that's what a manager does, right? This typically has disastrous consequences.

The cure for the "management" disease is a liberal application of "servant leadership." which is a nice way of saying the most important thing you can do as a leader is to serve your team. much like a butler or majordomo tends to the health and well-being of a household. As a servant leader, you should strive to create an atmosphere of humility, respect, and trust. This might mean removing bureaucratic obstacles that a team member can't remove by themselves, helping a team achieve consensus, or even buying dinner for the team when they're working late at the office. 

Antipattern: Hire Pushovers

If you’re a manager and you’re feeling insecure in your role (for whatever reason), one way to make sure no one questions your authority or threatens your job is to hire people you can push around. You can achieve this by hiring people who aren’t as smart or ambitious as you are, or just people who are more insecure than you. Even though this will cement your position as the team leader and decision maker, it will mean a lot more work for you. Your team won’t be able to make a move without you leading them like dogs on a leash. If you build a team of pushovers, you probably can’t take a vacation; the moment you leave the room, productivity comes to a screeching halt. But surely this is a small price to pay for feeling secure in your job, right?

Instead, you should strive to hire people who are smarter than you and can replace you. This can be difficult because these very same people will challenge you on a regular basis (in addition to letting you know when you make a mistake). These very same people will also consistently impress you and make great things happen.

Antipattern: Compromise the Hiring Bar

Steve Jobs once said: “A people hire other A people; B people hire C people.” It’s incredibly  easy to  fall  victim to this adage, and even more so when you’re trying to hire quickly.  A common approach I’ve seen outside of Google is that a team needs to hire 5 engineers, so it sifts through a pile of applications, interviews 40 or 50 people, and picks the best 5 candidates regardless of whether they meet the hiring bar.

This is one of the fastest ways to build a mediocre team.

Be a Zen Master

As a leader, your job is to inspire, but inspiration is a 24/7 job. Your visible attitude about absolutely everything - no matter how trivial - is unconsciously noticed and spreads infectiously to your team.

One of the early managers at Google, Bill Coughran, a VP of engineering, had truly mastered the ability to maintain calm at all times. No matter what blew up, no matter what crazy thing happened, no matter how big the firestorm, Bill would never panic. Most of the time he'd place one arm across his chest, rest his chin in his hand, and ask questions about the problem, usually to a completely panicked engineer. This had the effect of calming them and helping them to focus on solving the problem instead of running around like a chicken with its head cut off. Some of us used to joke that if someone came in and told Bill that 19 of the company's offices had been attacked by space aliens, Bill's response would be, "Any idea why they didn't make it an even 20?"

This brings us to another Zen management trick: asking questions. When a team member asks you for advice, it's usually pretty exciting because you?re finally getting the chance to fix something. That's exactly what you did for years before moving into a leadership position, so you usually go leaping into solution mode, but that is the last place you should be. The person asking for advice typically doesn't want you to solve their problem, but rather to help them solve it, and the easiest way to do this is to ask this person questions.

We strongly advise against using the compliment sandwich, not because we think you should be unnecessarily cruel or harsh, but because most people won't hear the critical message, which is that something needs to change. It's possible to employ respect here: be kind and empathetic when delivering constructive criticism without resorting to the compliment sandwich. In fact, kindness and empathy are critical if you want the recipient to hear the criticism and not immediately go on the defensive.

Delegate, but get your hands dirty

You can have a résumé and a list of achievements a mile long, but nothing lets a team know how skillful and dedicated (and humble) you are like jumping in and actually doing some hard work.

Seek to replace yourself

Unless you want to keep doing the exact same job for the rest of your career, seek to replace yourself. This starts, as we mentioned earlier, with the hiring process: if you want a member of your team to replace you, you need to hire people capable of replacing you, which we usually sum up by saying you need to “hire people smarter than you.”

Mastery in its basest form simply means that you need to give someone the opportunity to improve existing skills and learn new ones. Giving ample opportunities for mastery not only helps to motivate people, but also makes them better over time, which makes for stronger teams. An employee's skills are like the blade of a knife: you can spend tens of thousands of dollars to find people with the sharpest skills for your team, but if you use that knife for years without sharpening it, you will wind up with a dull knife that is inefficient, and in some cases useless. Google gives ample opportunities for engineers to learn new things and master their craft so as to keep them sharp, efficient, and effective.

A Story about trade-offs - the parable of the airplane by Lindsay Jones.

The Google Shell guide : https://google.github.io/styleguide/shellguide.html

Within Google, we process much more than one million search queries from developers within Code Search per day. For one million queries, an increase of just one second per search request corresponds to about 35 idle full-time engineers every day. In contrast, the search backend can be built and maintained with roughly a tenth of these engineers. This means that with about 100,000 queries per day (corresponding to less than 5,000 developers), just the one-second latency argument is something of a break-even point.

In reality, the productivity loss doesn’t simply increase linearly with latency. A UI is considered responsive if latencies are below 200 ms. But after just one second, the developer’s attention often begins to drift. If another 10 seconds pass, the developer is likely to switch context completely, which is generally recognized to have high productivity costs. The best way to keep a developer in the productive "flow" state is by targeting sub–200 ms end-to-end latency for all frequent operations and investing in the corresponding backends.

Thank you pirates at http://repository.itb-ad.ac.id/153/1/438.%20Software%20Engineering%20at%20Google.pdf for giving me a database I could search :)