hey tech lead here and welcome back to
another episode we are 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 or
the online published by a staff software
engineer it is about the software
engineering practices at Google if you
saw my other video why I left Google
when I was there they've been using a
lot of really amazing technologies and I
would say that the engineering practice
and culture at 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 code quality
cleanliness things like that but in
terms of high quality engineering at
scale across thousands of engineers I
would say that Google is doing it very
well I thought I would highlight some of
the key points in this document this
video by the way is sponsored by
brilliant org slash tech lead check em
out for a high-quality educational
videos on science math technology
algorithms computer science all sorts 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
repository how Google's code is stored
in a single repository and it makes the
code 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
repository 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'll 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 such 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 forty thousand commits per
work days so you can just imagine that
it is a large amount of code the culture
is such that anyone is encouraged to go
in there and fix anything that they
even if it's not necessarily in the
project they own which sometimes will
happen like some of the code that I
might be working on may be actually
owned by another team but I will still
go in there and take a look at and think
about hey if I can make a two line fix
maybe that will really help boost my own
productivity allow me to ship a certain
feature faster and I would just go
propose that fix almost uh development
occurs at the head of the repository not
on branches we're 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 now you don't really want
to commit that or at least you want to
submit that under a certain experiment
but it's really about minimizing the
amount of 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 repository
whatever you submit would be shipped to
production it is on the head the latest
branch automated systems are running
tests frequently whenever you submit
code there will be pre submit checks
which will block your code if it doesn't
pass certain tests and for slower tests
they're called post submit tests and
they would just check the code
asynchronously after you have submitted
there is 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 code quality high is
that it's not like anybody can approve
code 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 in the allow code to
be committed to a certain area google
uses a build system known as blades and
i believe that last year they ship the
open-source version of this called the
basil blade specifies how programs are
supposed to be built using very simple
build rules it's kind of like a make
file but the interesting thing about
this is it can be used across any
language almost you can use it to build
C++ apps iOS apps Android apps web apps
even searching scripts it's very
customizable and you can specify it
dependencies too and then the build
system will figure out which
dependencies need to be built first how
to cache them and then reuse those cache
versions for other builds this makes
incremental
fast it's pretty nice system 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 it's something that you don't
really do so much when you're in college
or smaller companies but as you get into
larger companies you find that love your
time is spent reviewing code commenting
on certain lines going back and forth
between discussions other companies have
similar technology like fabricator built
by facility but the one Google uses it's
their own proprietary one and it's quite
nice then we also have bug tracking and
it mentions here that Google uses a bug
tracking system known as buggin Iser
it's for tracking bugs feature requests
customer issues processes the
interesting thing I would say is that
since a lot of the software is developed
in-house it can be well integrated with
all the other tools like with the code
review tool you can link it to the bug
tracking tool programming languages this
is an interesting one you can see that
there's five officially approved
programming languages at Google they
mentioned C++ Java Python go or
JavaScript now I know that they also use
Objective C at least for iOS development
but these are the main ones and there
are also Google style guides and
readability to readability is a training
process in which somebody learns a style
guide front to back and anytime that
code is going to be submitted in one of
these languages it needs the approval of
somebody with readability and this
person with readability doesn't
necessarily need to be part of your
product team or know what feature 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 too 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 code quality high the whole code
base becomes garbage when everybody is
coding the way they want there's no
consistency they also mentioned protocol
buffers which is a way to serialize and
deserialize data across these core five
languages and each language supports
protocol buffer support a lot of times
you need to pass data from one program
to another program and you know there's
so many different ways to pass data you
can use XML you can use Jason there's so
many different ways and it can become
just a total mess and over time people
just say well why don't they just
standardize this method into a highly
efficient binary object known as
protocol buffers and that's what this is
and it just makes it very easy to
communicate data between many different
services that could be written in a
whole different number of languages
we've got debugging and profiling tools
they mentioned that if there's a crash
the server will 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 crashlytics
which was created and then bought by
Twitter and then turns out it was later
bought by Google as well so check out
crashlytics if you're interested in that
type of technology for reporting crashes
launch 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
launch and then have that checked off by
every single team and then there are
post mortems where anytime there's some
significant crash or outage of services
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
file on any one 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 bedroom 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 a cultural way of thinking not
necessarily the best I know a lot of
companies like for example Netflix may
disagree with the idea of having a lot
of process but yeah that's at least the
way they do it the famous 20% time they
have it where engineers are encouraged
to spend 20% of their time working on
anything
that they like I know I had to use my
20% time take initiative on some
framework some idea that may be
interesting later made it to production
we can take a look at the people
management they've got a few rows
engineering manager or software engineer
research scientist those are probably
like the ph d--'s set reliability
engineers who are the developer
operations they keep the systems online
mostly deal with Linux internals then
you've got product manager and program
manager I don't care 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 how highly
encouraged one interesting system that
they talk about here is the pure bonus
or kudos where twice your employees can
give a pure bonus amounts to like a
hundred dollar 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 out of 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 paper is an interesting
read for anyone who wanted to peek into
seen how software engineering is done at
Google lastly if watching my videos
isn't enough for you and you want to
spur yourself daily then check out
brilliant orgs new daily problems
feature where each day they published
several problems that provide 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 applying them you can
explore the concepts in great detail or
if you're confused any more guidance
then you can join the community and
discussing the problems there are
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 org slash tech lead
and finish your day a little smarter the
first 200 will get 20% off premium
subscriptions now do for me if you liked
the video give the like and subscribe
and I'll see you next time bye