We're drinking something today.

Oh, yeah, it's good.

Do you like my hat?

I thought it would be appropriate for this episode.

There's this pretty interesting article I found online documenting the software engineering practices at Google.

And this is fantastic because a lot of this stuff I wanted to share with you guys I found out that it was actually available already online.

Published by a staff software engineer.

It is about the software engineering practices at Google.

If you saw my other video, why left, Go, go When I was there, they've been using a lot of really amazing technologies.

And I would say that the engineering practice and coach or a Google is one of the top that I've seen.

Not the very top.

I would say that startups still probably come in ahead in terms of coach quality cleanly in this things like that.

But in terms of high quality engineering at scale across thousands of engineers, I would say that Google is doing very well.

I thought I would highlight some of the key points in this document.

This video, by the way, is sponsored by brilliant oryx slash tech lead Check him out for high quality education of videos on science, math, technology algorithms, computer science officers of interesting topics that you can use to educate yourself or a loved one and get yourself set up for success.

The first part is talking about the source repositories.

How Google's code is stored in a single repositories E.

And it makes the cut very simple and clean to pull into.

And you can start editing any piece of code that you want.

And it's all a single repositories, so you don't have to worry about checking out multiple different repositories.

If you make a single change to a shared library across thousands of different projects, you immediately be able to figure out how that change is going to affect all the other projects.

If there's going to be any errors, compilation issues anything like that, and when you make a change, all of the tests will run to.

So it's just that you get immediate feedback on whether that is working or not.

There's over two billion lines of source code across nine million files and 40,000 commits per work days, so you can just imagine that it is a large amount of code.

The culture is such that anyone this encouraged to go in there and fix anything that they see, even if it's not necessarily in the project they own, which sometimes it will happen, like some of the code I might be working on, maybe actually owned by another team.

But I will still go in there and take a look and think about.

Hey, if I could make a two line fixed, maybe thou really help boost my own productivity.

Allow me to ship a certain feature faster, and I would just go propose that fix.

Almost all development occurs at the head of the repositories, not on branches were just true because you learn over time that you don't want to submit code that you don't know if it's going to work.

It's only production code, and if you think that it may not work or it's just a test code, something that you're trying out, you don't really want commit that where at least you want, submit that under a certain experiment.

But it's really about minimizing that month code that you submit because there's already way too much, and if it's not production code, then people don't really want that in the repositories.

Whatever you submit would be shipped to production.

It is on the head, the latest branch.

Other made.

The systems are running tests frequently.

Whenever you submit coat, there will be pre submit checks, which will block your code if it doesn't pass it and test.

And for slower test.

They're called post emit tests, and they would just check the code a synchronously after you have submitted, there's code ownership as well to help manage this larger structure of files.

Each code the directory has a certain set of owners, and their approval is needed to be able to submit code in.

That is one way to keep both quality high is that it's not like anybody can approve coat.

They're still going to be a few people who are designated owners who understand the code best, and they're the only ones to back and allow code to be committed to a certain area.

Google uses a build system known as blades, and I believe that last year they shipped the open source version of this call.

The basil blaze specifies how programs are supposed to be built using very simple build rules.

It's kind of like a make flow, but the interesting thing about this is it can be used across any language.

Almost you can use it to build c++ APs, IOS, APS.

Andrew adapts Web APS.

Even search of scripts is very customizable, and you can specify it Dependencies to.

And then the build system will figure out which dependencies need to be built first, how to cash them and then reuse those cash versions for other bills.

This makes incremental bills fast.

Pretty nice is, um, and if you want, you can check out Basil for the open source version if you want to use it in your own projects.

Continuing on the author mentions that Google has excellent Web based code review tools, and that's true.

You know code review is a big part of the job of a software engineer is something that you don't really do so much when you're in college or smaller companies.

But as again to larger companies, you find that love your time is spent reviewing coat common theon, certain lines going back and forth between discussions.

Other companies have similar technology like fabricator built by facility, But the one Google uses its their own proprietary one, and it's quite nice then.

We also have buck tracking and mentions here that Google uses a buck tracking system known as Bug a Nizer.

It's for tracking bugs, feature requests, customer issues, processes.

The interesting thing I would say is this is allowed this offers developed in the House.

It can be well integrated with all the other tools, like with the code review tour, you can link it to the bug tracking toe programming languages.

This is an interesting one.

You can see that there's five officially approved programming languages at Google.

They mentioned C plus plus Java, Pathankot or JavaScript.

Now I know that they also use objective see, at least for Iowa's development.

But these are the main ones, and there are also Google style guides and read ability to read ability is the training process in which somebody learns a style guide front to back, and any time that code is going to be submitted in one of these languages, it needs the approval of somebody with readability, and this prison with readability doesn't necessarily need to be part of your product team or know what future you're working on.

They're really looking at the way you use the language and just making sure that you're using the language properly in the correct way.

You're not doing anything to silly about it.

Some people like it.

Some people don't if the reviewers become too pedantic.

But I think it's pretty nice, actually, for keeping coach quality high.

The whole Kobe's becomes garbage.

When everybody is cutting the way they want, there's no consistency.

They also mentioned protocol buffers, which is a way to serialize and D serialized data across these core five languages, and each language supports protocol.

But for support.

A lot of times you need the past day that from one program to another program and you know there's so many different ways the past day that you could use XML.

You can use Jason.

There's so many different ways and it could become just a total mess and over time people just said, Well, why don't they just standardize this method into a highly efficient binary object known as practical buffers?

And that's what this is and it just makes it very easy to communicate day that between many different service is that could be written in the whole different number of languages We've got debugging and profiling and tools.

They mentioned that if there's a crash, the server with Dump the Stack trace and then there would be some Web interface for debugging, which is pretty nice.

I think that this type of software is probably very similar to Crash Lid IX, which was created and then bought by Twitter.

And then it turns out it was later bought by Google as well.

So check out Crash Olympics If you're interested in that type of technology for reporting crashes, large approval is another tool for coordinating launches across many teams.

Like if you need approval from, say, the legal team, privacy team, security team accessibility, other business requirements, then you can create this lunch and then have that checked off by every single team and then their postmortems, where any time there's a significant crash or outage of service is people like to write up a document explaining what happened and how that can be fixed or prevented in the future.

And it's mostly a blameless culture.

And I think that's interesting because the way Google operates.

It's almost like a system.

It's a process, and it's not really about the individual engineers who's at fault.

It's really about making a system and ensuring that the system is infallible, rather than pinning down the fall on anyone engineer and saying, Well, we're just gonna fire that guy You know who's to say that the next guy who comes in is going to be any better, or how's he going to ensure he's not gonna make that same mistake again?

That's where processes come in.

It's kind of, Ah, cultural way of thinking, not necessarily the best.

I know a lot of companies like, for example, of Netflix and may disagree with the idea of having a lot of process, but that's at least the way they do it.

The famous 20% time they have it were engineers are encouraged to spend 20% their time working on anything else that they like.

And then I had to use my 20% time taking initiative on some framework.

Some idea that I thought maybe interesting later made it to production.

We can take a look at the people management.

They've got few rows engineering manager, cell for engineer research scientist.

Those air probably like the PhDs set reliably.

The engineers who are that developer operations.

They keep the systems online, mostly deal with Lennox internals.

Then you've got product Mandarin program manager.

I don't hear that much about program managers, but project managers are quite interesting roles.

These are people who are like many CEOs of the product that they are responsible for shipping and managing.

The last part Talks about feedback House highly encouraged.

One interesting insistent that they talk about here is the pure bonus or kudos.

Twice a year, employees can give up your bonus amounts to like $100 cash reward or something like that, and it's just a thanks to anybody who they want to give it to.

I think it's nice to have a system to incentivize people a little bit more to go under their way.

Try a little bit harder to help you out without necessarily having people always going around fishing for tips, fishing for a few extra bucks whenever they're nice to you.

Anyway.

The papers an interesting read for anyone who wanted the peek into seeing how software engineering is done that Google lastly, If watching my videos isn't enough for you and you want to spur yourself daily, then check out Berlin dot org's new daily Problems feature where each day they published several problems that provides a quick and fascinating view into math, logic, science, engineering or computer science.

Each problem provides you with the context and framework that you need to tackle it so that you can learn their concepts by a plan that you're gonna explore the concepts in great detail.

Or, if you're confused anymore guidance.

You can join the community and discussing the problems there thought, provoking challenges that will lead you from curiosity to mastery one day at a time.

So what are you waiting for?

Go to Brilliant that orc slash tech lead and finish your day a little smarter.

The 1st 200 will get 20% off premium subscriptions.

Now do for me if you like the video, give the like and subscribe, and I'll see you next time.