27 ms·
Software Engineering at Google (2020) [pdf]
- google234123 4y agoIs the first chapter explaining why all lines must be less than 80 characters in width and all parameters and conditional statements must be automatically formatted in the most compact way possible - damn readability.
- Rebelgecko 4y agoThe width limit is per language- some are longer than 80. And some languages, believe it or not, don't even have readability
- google234123 4y agoSorry, i didn’t mean to use that word to mean that. Was just talking about how it’s easier to read parameters and long conditional statements that are split over separate lines.
- jppittma 4y agoNo languages have readability on GoB. You don’t know what you’ve got until it’s gone.
- maskedinvader 4y agodo we really have to limit 80 chars now? don't we all have bigger monitors and wider screens to accommodate 120 perhaps?
- dmitriid 4y agoOn a wider screen you will probably have several code windows/panes side by side. So, back to 80 characters :)
- nickjj 4y agoYep. If you run 2560x1440 at its native resolution you can fit (4) side by side code windows at 80 characters with a very readable font size. Having 120 character lines only lets you have 2 (3 will cut off the last one by a decent amount). Being able to comfortably open 4 files side by side is like having access to a completely new world compared to 2. You can often fit the entire context of what you're working on in one visible space. I use 80 characters for mainly this reason and it's also no extra time spent when using languages like Python because Black will auto-format it for you, it comes down to running 1 command and letting the machine do all of the work.
- helge9210 4y agoWith 80 chars you could fit three windows with code side by side on standard screen or four on ultra wide.
- LudwigNagasena 4y agoDon’t we all have IDEs that enumerate lines and allow wrapping?
- okamiueru 4y agoNot sure what you mean. Soft wrapping?
- omegalulw 4y agoOther than the reasons already posted, I find it much easier to read code with 80 char line limits vs longer. For me it's like the benefit of reading an article in columnar format - going down vertically just feels more comfortable.
- ignoramous 4y agoWhile it might be true that 120 chars are ideal for screens [0], the consensus is an optimal line length is roughly 50 to 75 chars. [1] [0] https://www.viget.com/articles/the-line-length-misconception/ https://www.viget.com/articles/the-line-length-misconception... [1] http://webtypography.net/2.1.2 http://webtypography.net/2.1.2
- kozd 4y agoThat seems to apply for blocks of text. I don't know that the same would hold true for code.
- shakezula 4y agoWhat is code if not blocks of text
- tpush 4y agoA tree of nodes.
- shakezula 4y agoAnd we model sentences the same way
- cjg 4y agoOften significantly more indented.
- YokoZar 4y agoSentences feel different from lines of code. "One statement doing one thing per line of code" seems a reasonable idea but "one sentence per line of text" seems a bit absurd.
- kitsune_ 4y agoYeah but line formatting usually includes white space indentation in the calculation of the line length, I don't know whether you can 1:1 translate findings from normal text paragraphs like that. With linted code the actual relevant length might only be 20 characters, maybe we need some smarter linters.
- corford 4y agoEven Linus seems comfortable with 100 these days: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bdc48fa11e46f867ea4d75fa59ee87a7f48be144 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... On my team we've settled for either 100 or 120 depending on language.
- nicogg88 4y agoWhen you take into account IDE stuff like file tree on the left, plugins on the right, or the split view when looking at a file diff, more than 80 char is too much even on a large monitor in my opinion.
- BeetleB 4y agoI almost always have multiple files open side by side. Lines longer than 100 characters start wrapping which really hurts readability.
- whatever1 4y agoWhy is this a thing in languages that are not Fortran 77? Why not a 1000 character long line? If I want the editor to overflow it below or show me a scrollbar should be my choice.
- nine_k 4y agoDiffing an excessively long line is uncomfortable in most tools. A crash dump mentioning the 1000-character line leaves you thinking where in that line the error has happened. The actual limit should be the complexity of one lihe, something like the number of AST nodes in it. But our tools which go back all the way to mechanical teletypes and punched cards are firmly line-oriented. This allows them to be language-agnostic.
- thfuran 4y agoI think it's reasonable to have restrictions on both. Regardless of complexity, long lines make it hard to view side by side diffs on your screen.
- dudeman13 4y ago>Why not a 1000 character long line? I work in a codebase where a previous dude constantly did this. I do not find those lines amusing. Whenever I'm un-fucking his stuff one of the first things to do is expand his infinite lines into usually 5-50 lines because visualizing and reasoning about 50 lines of code crammed into one requires someone who is totally a way, way better programmer than me. I don't need to git blame to know when the code was written by that guy.
- compiler-guy 4y agoIn a personal project that makes a lot of sense (and in a personal project you have your choice), but once you are in a corporate or open source project of more than just a couple of people, code is read far more often than it is written, and by many more people than the original author. In those circumstances, it makes sense to optimize for readability to everyone rather than the author’s personal preferences. One can easily argue that Google’s style isn’t optimal, but it’s harder to argue that a personal preferences free for all is optimal.
- iliketrains 4y agoHaving worked at Google for many years, 80 char line limit was easily the biggest frustration with coding. Because of that, I was forced to write less readable code, shorten variable and function names, omit some comments, fight with formatter and linter, spend extra time aligning things, etc. For example, Python requires extra effort to brake lines, often adding extra parentheses or doing other unnecessary tricks. Lambda does not fit on the rest of the line? Too bad, define an extra function, because liner won't let you submit a lambda that spans more than one line... Now, I am so happy with 120 char limit while still being able to fit two columns on one screen.
- foota 4y agoLine splitting in python is miserable, all the other languages are much easier for it.
- bjackman 4y agoFWIW, a counterpoint: I work in C++ (80) and Go (no line length limit) at Google and I barely even think about it. I just write code however feels natural and then run 'hg fix' before sending for review. I would definitely not impose 80 if it were my choice but it really doesn't bother me when clang-format is set up as nicely as it is. Probably Python should switch to the Go model, since auto-splitting python lines sounds tricky.
- bpicolo 4y agoBlack’s model for Python is great. It has a default limit of 88 but will go over that up to 10% if the formatting makes more sense that way.
- bob1029 4y agoWhat is with these draconian rules of having any limit at all? There are tons of edge cases where allowing a 100k line of text would totally make sense to most developers. Are the tools at Google and elsewhere unable to diff code if a line exceeds some arbitrary width?
- 4y ago
- spockz 4y agoI think we need some contextual line width limits. When splitting a function/method definition over multiple lines, I like to align the parameters. Now if there is a short line limit this will force us to left align the parameters instead. This has the consequences that there is less visual, spatial, distinction between method definition and their code, resulting in a big hodgepodge of characters. If we have contextual limits, we can make method headers arbitrarily long while keeping the body within a tight limit. Or allow a longer line when defining a lambda in python as another comment laments.
- 4ad 4y ago> When splitting a function/method definition over multiple lines, I like to align the parameters. Please don't do this. It's horrible for us who use proportional fonts. In fact I would go as far as arguing that "artificial" line breaks are always bad. They aren't really more readable, quite the opposite usually, and most importantly they break diff. I like short lines, and it's a good ideal to strive for. 98.5% of my code fits in 80 columns, but if I need a longer line, don't artificially make it worse in the pursue of some arbitrary rule.
- unicornmama 4y agoThis style was written for C++ developers who work author on terminals. It shouldn’t be taken seriously outside that context.
- shric 4y agoThe nice thing about books about how Google does X (SRE, SWE, etc.) is you can adopt the good/relevant parts however you see fit and ignore the stuff that either only applies to Google scale or makes no sense.
- bigcat123 4y agoWell, for people who are ridiculing the absurdity, note that it's software engineering at Google, not software engineering. One's peculiarities are another absurdity. Reserve judgement, and try to understand the rationale.
- TheFragenTaken 4y ago"For most Google projects, we must assume that they will live indefinitely" on page 6 made me chuckle.
- nine_k 4y agoIndefinitely, not endlessly. You cannot predict the date when your project is going to be sunsetted: it may be in 6 month, or may be well past your retirement.
- izacus 4y agoWhat's that software engineering truth? All the "temporary" code ends up running in production for decades? :D
- WJW 4y agoI think GP was thinking more of https://killedbygoogle.com/ https://killedbygoogle.com/, Google is somewhat infamous for killing off well-liked projects if they are not successful enough.
- izacus 4y agoYeah, I think we're all aware of this tired old joke by now.
- captaincaveman 4y agoSo google wants to kill off the tired old joke now huh!
- deleted 4y ago[deleted]
- aaomidi 4y agoDon't try to emulate google. Seriously. It's how you're going to kill your company if you do. Google is not an efficient or fast company. You need to be efficient and fast to deal with the momentum google has. If you interview people from FAANG and you see they are going to want to recreate their company within yours, don't hire them. They're going to ruin team dynamics. And seriously, make sure these people aren't assholes. With some companies in particular you need to really be an asshole to survive. Weeding out assholes is far more important for most smaller companies than technical expertise. Heck for most people you probably don't need a separate technical interview. Just, honestly whatever google does do the opposite. From hiring to project management to planning to software development.
- anon2020dot00 4y agoAgree with the other commentator that this is an unconstructive message. Replace Google in the message with Apple/Netflix/Microsoft and it will read exactly the same since it has no specifics except "don't do what x company is doing" with no particular reasoning behind it.
- elromulous 4y agoThis is not a very constructive comment. It doesn't mention any specifics, then it jumps into assuming that Google / FAANG have more assholes? Disclaimer: I'm a swe at alphabet.
- bartread 4y ago> This is not a very constructive comment. I think there's some substance. I've personally experienced examples where teams have looked at Google or other FAANGs, cargo-culted in practices - or at least their understanding of the practices - and then things have not gone well. With that being said, it's not to say that there's nothing to be learned from FAANGs: you can learn plenty but you need to be choosy in the application of that knowledge. The wider point is that I've observed a trend in industry - stronger at some companies than others - of applying solutions, trendy or otherwise, without a clear understanding and articulation of the problem being solved and the value of solving that problem to the business. That being said, I don't think it's fair to generalise that one has to be an asshole to survive at one of these companies - which is certainly implied by GP's choice of phrasing. I now know quite a few people who've worked at FAANGs for varying periods of time, and none of them are assholes. There are no doubt assholes at FAANG but I've seen no evidence that they're any more concentrated than in the general population.
- vinay_ys 4y agoThe book itself is a bit abstract and generalised (on purpose I suppose). People who have worked within Google vs not will think differently on how they can apply it in practice in their own company/team. Many of the practices that work very well at Google don't work as well elsewhere primarily due to bootstrapping problems. Google's developmental practice are built on top of so many layers of highly complex and large tech-infra capabilities that don't exist outside. The process/culture practices also have cyclic dependencies with those infra capabilities. Interestingly, so many things that are quite easy everywhere else aren't so easy to do at Google. Software engineering within Google is painless in many of the usual sense of pains seen outside Google, but it has its own pains – some quite painful pains.
- rsanek 4y agoWas it purposeful to make this comment also highly abstract? Not meaning this as snark just found it a funny juxtaposition.
- heavenlyblue 4y agoYeah, I kind of understand what that comment is saying but also feel like it can be interpreted in so many different actual ways that it's practically useless.
- willis936 4y agoIt's a good CYA legal insurance policy.
- deleted 4y ago[deleted]
- webo 4y agoOne simple example was that I couldn’t install dependencies from public registries such npmjs (npm) or pypi (pip). It took an approval process for an internal team to review and clone packages onto Google’s internal registry. On the other hand, things like deployment and monitoring were so trivial and magic. This was circa 2015.
- classsic009f 4y ago
- posharma 4y ago600 pages? Wow! Will be great to have the best practices summarized somewhere.
- lstamour 4y agoFYI, this is also available as an audiobook from "Upfront Books". The first few chapters are easy to listen to, and the book is broken down into shorter sections. When it gets into talking about syntax formatting rules, it's a bit un-listenable. Some chapters have a lot of advice in them, others, like the chapter on inclusivity, have less specific, actionable advice. (What do I mean? Well, you could start talking about user research or scientific UX studies to get feedback beyond groupthink at the company, but that chapter on inclusivity didn't mention it.) But besides the unevenness, it's a book that does add value, I think, to general conversations on software development. And it's a rare technical book that's also available as an audiobook, so that helped it stand out for me. I couldn't find a canonical publisher link, so here's a few ways to get the audiobook, instead: https://www.oreilly.com/videos/software-engineering-at/1492082791/ https://www.oreilly.com/videos/software-engineering-at/14920... or https://play.google.com/store/audiobooks/details/Software_Engineering_at_Google_Lessons_Learned_fro?id=AQAAAEA8Dk5OYM&hl=en_CA&gl=US https://play.google.com/store/audiobooks/details/Software_En... or https://www.audible.ca/pd/Software-Engineering-at-Google-Audiobook/B08VLF73BV https://www.audible.ca/pd/Software-Engineering-at-Google-Aud... or https://books.apple.com/us/audiobook/software-engineering-at-google-lessons-learned-from/id1552319795 https://books.apple.com/us/audiobook/software-engineering-at... or https://www.kobo.com/ca/en/audiobook/software-engineering-at-google-lessons-learned-from-programming-over-time https://www.kobo.com/ca/en/audiobook/software-engineering-at...
- karmasimida 4y agoRead during a long flight. I like the testing part very much, it is pretty inspiring
- nomilk 4y agoI haven't read this, but for those who have, what did you find counter intuitive or surprising?
- osigurdson 4y agoCode reviews are an interesting topic since there is so much variability on the part of the reviewer. One could spend hours reviewing a change only to respond with "Looks good to me" after finally concluding that there is no better way, do a cursory code style level review with the same response or spend the same amount of time as the original author completely re-writing the code.
- UncleMeat 4y agoBecause Google owns their own code review tool, they can collect data to distinguish these sorts of cases.
- deleted 4y ago[deleted]
- golondon 4y agoI skimmed through it but still didn't see any part describing how is the local dev env is? Let's say that you work on a service that does something for ad serving, how do you write code for that and test it? I understand unit tests and e2e tests are used but what I'm referring is just simple opening web browser, navigating to the localhost:3000/foo/bar/something and seeing if it's ok, I found this as much faster feedback loop while writing code in addition to the tests. Can anyone from Google share that?
- Jensson 4y agoBasically every service has already been packed full with so many things that an instance can barely fit on a server, you wont be able to run that monstrosity locally. Which is why they started doing "micro services", out of necessity since when each binary gets over a few gigabytes you don't got many other options. their micro services still takes gigabytes, but it let them continue adding more code. But each of those depends on hundreds of other micro services. And those microservices are of course properly secured so you wont be able to talk to production servers from your development machine.
- jeffbee 4y agoAre there a lot of binaries "over a few gigabytes"? On x86_64 you can only have 32-bit offsets for relative jumps. How would you build and link something that large?
- Jensson 4y agoI worked on search, it might be different in other areas. But yeah, the fact that you can't link it etc was a huge problem that we had to think about.
- SemanticStrengh 4y agoWow can you reveal a few things about the internals of google search? Any secret-sauce/revolutionar algorithm? How does it compare to Lucene?
- erwincoumans 4y agoI find this part on page 35 very important: "The Three Pillars of Social Interaction So, if teamwork is the best route to producing great software, how does one build (or find) a great team? [...] They’re the foundation on which all healthy interaction and collaboration are based: 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.
- alexashka 4y agoThey forgot Pillar 0 - not everyone's going to get along, let people choose teammates until they find ones that fit. Once they do, pillars 1, 2 and 3 no longer need to exist. If you need to tell people to be nice, you're doing it wrong. You're not their mother and these are not kids to be talked down to and told how to behave.
- daok 4y ago>let people choose teammates until they find ones that fit. Good way to get a very echo room of single way of thinking with strong bias. But I agree that it is way faster without the friction of different point of views.
- deleted 4y ago[deleted]
- ctvo 4y agoGoogle is the only company I'm aware of where the engineers constantly publish popular books about their engineering practices. Apple, Amazon / AWS, MSFT, etc. have all done impressive things in their space at various points, but seem to lack the mixture of personalities / culture / reputation where "Engineering at Apple" isn't quite the hit that SRE at Google [1] or this book may be. 1 - https://www.amazon.com/Site-Reliability-Engineering-Production-Systems/dp/149192912X https://www.amazon.com/Site-Reliability-Engineering-Producti... Edit: If you're at Apple and happen to work in hardware, I would pay good money to read about the process and war stories.
- jrvarela56 4y agoMaybe a bit lighter than what you meant but entertaining: Creative Selection by Ken Kocienda (https://www.amazon.com/-/es/Ken-Kocienda-ebook/dp/B079DVT6VP https://www.amazon.com/-/es/Ken-Kocienda-ebook/dp/B079DVT6VP). One anecdote I enjoyed was how Steve Jobs said the guiding principle for Safari was that it had to load pages faster than any other existing browser so the engs made a benchmark with top 100/1k sites part of the CI to enforce the principle: diffs that slowed-down the browser could not be merged.
- dilyevsky 4y agoOther companies usually publish books on management
- inoffensivename 4y agoI've maintained some pretty big libraries inside Google at one time or another in the last 16 years. I believe our system is bad for both sides (library maintainers and users). Here are some of my frustrations: * the One Version Rule means that library authors can't change a library "upstream": your changes must work now or they can't get in. This sets the bar for landing changes very high, so development moves at a snail's pace. The version control and build system we have makes it difficult to work inside a branch, so collaboration on experimental/new things between engineers is difficult. * users can create any test they wish that exercises their integration with your library. They can depend on things you never promised (Hyrum's law, addressed in the book). Each of these tests becomes a promise you, the library maintainer, make to that user: we will never break that test, no matter how weird it is. This is another huge burden on library maintainers. * the One Version Rule means that, as a user, I can't just pin my dependence on some software to version X. For example, if I depend on Bigtable Client, just give me version 1.4. I don't need the meager performance improvements in version 1.5, because I don't want to risk breaking my project. This means every roll-up release you make, every sync to HEAD you do, risks bringing in some bug in the bleeding-edge version of literally everything you depend on.
- mucle6 4y ago>The version control and build system we have makes it difficult to work inside a branch nit: use fig
- danpalmer 4y agoNot sure how much we should discuss in a public forum, but while you may be technically correct, I don't think this is the right solution here. Long-running shared Git branches are a useful tool for large scale changes and integrations. They're not ideal in small teams, but unavoidable at some level and useful if done well. Fig isn't doing that.
- inoffensivename 4y agoI use fig, it doesn't solve the problem I'm talking about.
- b20000 4y ago404
- jenny91 4y agohttps://raw.githubusercontent.com/abseil/abseil.github.io/cd13b21daa6ec74155548241241693198c1b1264/resources/swe_at_google.2.pdf https://raw.githubusercontent.com/abseil/abseil.github.io/cd...
- Nzen 4y agoIn the last three hours [0], they removed it from their git repository, and replaced it with separate html pages [1]. [0] https://github.com/abseil/abseil.github.io/commit/a69a63ec3f79a96d096025115347f1e37f2ebd37 https://github.com/abseil/abseil.github.io/commit/a69a63ec3f... [1] https://abseil.io/resources/swe-book/html/toc.html https://abseil.io/resources/swe-book/html/toc.html
- b20000 4y agodon’t be evil
- ahahahahah 4y agoDid you really just insinuate that replacing a pdf with an html version of the same thing is evil? I guess I shouldn't be that surprised on hn.
- b20000 4y agoi prefer to err on the side of caution
- blacksoil 4y agoThe PDF on the original link is down. Does anybody mind to re-upload it? Thanks :)
- mertysn 4y agoIt's available on the wayback machine [1] 1: https://web.archive.org/web/20220329143949/https://abseil.io/resources/swe_at_google.2.pdf https://web.archive.org/web/20220329143949/https://abseil.io...
- einpoklum 4y agoAt this link, it says: "File not found". Try: https://abseil.io/resources/swe-book https://abseil.io/resources/swe-book or more directly: https://abseil.io/resources/swe-book/html/toc.html https://abseil.io/resources/swe-book/html/toc.html