5 ms·

Software Engineering at Google

93 points by whack 5y ago

ChrisArchitect 5y ago
author's title is misleading - maybe include the words "the book" or quotes around Software Engineering at Google...
- mrits 5y ago
  That makes a lot more sense. I was trying to figure out how you take the time to write an entire book but then throw together a short blog full of grammar mistakes to promote it.
  - dentemple 5y ago
    It's easy--just be a software engineer at Google /s
- jsnell 5y ago
  Or put the title of the book in quotes?
- Swizec 5y ago
  Or read the first and second paragraph? > When I first picked up Software Engineering at Google I thought it was another one of those FAANG books full of lessons that make no sense at human scale. I was surprised, the lessons apply to teams as small as 5. > This is a "good shit stays" recap. The lessons that stick with you a few weeks after reading.
  - ChrisArchitect 5y ago
    no man, address it before that - it's misleading implying you actually were doing Software Engineering at Google
- 908B64B197 5y ago
  It looks like a cheap attempt at gaming NH to get clicks. Else the author would simply state where he works (surely just as good as Google). I'd be curious to hear from a real Google engineer.
hitekker 5y ago
Starts with a misleading title, goes into content-free blogspam, and ends with a desperate salesman pitch for their services. To top it off, the article randomly throws in "I love and appreciate you [a random visitor to his website] for who you are :heart:" Unseemly and oily.
- Zababa 5y ago
  > To top it off, the article randomly throws in "I love and appreciate you for who you are :heart:" I find these statements really weird when they're made by total strangers. They strike me as shallow.
gabereiser 5y ago
What I learned reading “Software Engineering at Google”
mikepurvis 5y ago
"... stubs and mocks are bad. Your tests are only as good as your mocks. They hide the true behavior of your system, drift away from reality, and take a lot of effort to maintain." I've often felt guilty for leaning toward broader-scope integration tests, but I've long felt this too— that they're less effort to write and maintain and are much better value in terms of actually catching issues. Not that unit tests don't have their place, but they're best for mostly-pure functions or classes where you're intentionally trying to cover a bunch of branches or corner cases.
- jamesgreenleaf 5y ago
  I've felt the same way - as though not being able to shoehorn everything into pure unit tests somehow means that I'm not doing testing right. In most cases though, what we really care about is verifying the full functionality of an app. Maybe integration & e2e tests should be considered as the primary form of testing, with unit tests applying only in the specific cases where they make sense, like you mentioned. Maybe the ulimate form of testing is something along the lines of Netflix's chaos monkey (now apparently an entire "simian army" suite of tools). Continuously test the real application, live in production, where it's not allowed to fail.
  - mekane8 5y ago
    I believe pretty strongly in the "testing pyramid" - that you should have a broad base of unit tests, with fewer integration tests and even fewer e2e tests. Source (also from Google): https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html https://testing.googleblog.com/2015/04/just-say-no-to-more-e... I think good unit test coverage is essential for good maintenance, but you can't cover _everything_ with unit tests. You definitely need integration and e2e tests to ensure bigger picture correctness. I have found that value one gets out of the different kinds of tests as you proceed up the pyramid get higher the closer to release you are, and are most valuable post release. During development they become obsolete too quickly due to changes in how things work. But locking in an already-released version to avoid regressions is great.
    - 5y ago
gumby 5y ago
Rather light on content. Repeats a common error: > QA takes a few hours or days to ensure everything works together as expected. Quality Assurance starts at the front of the process: what do we do to ensure (i.e. how do we accomplish) that product does what it says, as reliably as we can reasonably make it? This could include processes like design reviews, code reviews, writing tests, coding conventions, even business processes. Quality Control is a process of running tests and identifying things that don't do what they are supposed to (or weren't done as they were supposed to be, e.g. pushing straight to production). As I was told years ago, and took to heart: "you can't test quality into your product." This doesn't mean "don't test", it means quality comes from the start, and tests identify failures.
oxfordmale 5y ago
>>That's engineering considering the long-term effects of your code. Both direct and indirect. No that is over engineering, and in violation of YAGNI (you ain't going to need it) an KISS (keep it simple stupid) principles. A lot of code my teams develops gets thrown away over time, as it is either no longer needed or replaced with an off the shelf tool. It is really hard to predict what code will survive AND becomes a performance bottleneck. There is no point optimising prematurely. It is often best to tackle the problem when it occurs.
- Spartan-S63 5y ago
  I agree in an ideal world where it's easy to get time to prioritize optimizing something (whether it's performance tuning or refactoring). Even in the most mature organizations, getting that time to do non value-producing work is challenging and so seemingly premature optimization is a pragmatic tradeoff.
bakuninsbart 5y ago
The body of the article gives some good tips for organizing and maintaining code, but it frames it in a way that would suggest these are the best practices, and that's it. The points given are just the tip of the iceberg taught in a typical Software Engineering 101 course in university. There's no reason to reference Google here, none of these points are original. SE is an academic field with 50 years of publishing, and while most of it is pretty stale today, it is weird to lead a discussion on it completely disregarding the body of knowledge we already have. The introduction is also weirdly phrased, as the process of SE doesn't start with writing code - that's putting the cart before the horse. SE starts with thinking about what you want to solve, and how you can and want to solve it. Coding should probably come after these processes.
- mtnygard 5y ago
  Bear in mind that the blog is about a specific book titled "Software Engineering at Google." It's not an attempt to survey all of SE, and that explains why it refers to Google... because the book is specifically about SE _at_ Google.
rexreed 5y ago
Google developers are often so lost in the weeds of shipping fast and optimizing for rapid releases that they frustrate users with rapid UI changes, deprecation of major functionality, and not building the things that people often want in favor of just shipping fast. That's part of the reason why this post doesn't talk at all about user requirements, needs definitions, or user stories or anything like that. If this is what is "Software Engineering at Google" then maybe this shouldn't be seen as "best practice". I have found the Google experience, as a user, to be decaying steadily over the past 5-6 years.
- mekane8 5y ago
  I wholeheartedly agree that the experience of being a Google customer / user has degraded significantly. I'm not sure the omission of the topics you mentioned can be corelated exactly to that degradation, but it's an interesting idea. My assumption is that all the changes do go through proper UX and user testing, but the reason for them is questionable. I certainly haven't asked for hardly any of the changes. I also assume that the book focuses on the purely technical side intentionally.
- ksec 5y ago
  Yes. Despite the "Move fast and break things" or rapid releases cycle being attributed to Facebook, it was Google who did it first and amplified by Mark Zuckerberg which becomes de facto standard in Silicon Valley and Tech industry worldwide. The cult of move fast and break things meant doing it the old fashioned way were wrong. For nearly 20 years, Twenty Years. It is sin that is even worst than IE stagnation. ( Well I say that because IE is now irrelevant. If IE is still here my rage would have been even worst. )
  - Silhouette 5y ago
    The cult of move fast and break things meant doing it the old fashioned way were wrong. The likes of Google and Facebook, as well as many startups inspired by them, have been an excellent demonstration of what commercial success looks like in a modern software business. In particular, they have (unfortunately, perhaps) demonstrated that quality really doesn't matter all that much in their target markets. In the early days, it turns out that users will forgive almost anything breaking if you have an attractive product. Later on, you can still break things often and almost completely ignore customer service as long as your lock-in effects are strong enough to keep most of your users anyway. Even if you do need higher quality standards in your market, the lean startup view is to build anything you can and ship your MVP as quickly as possible. If and when you find product-market fit then you can pay off your "debts", potentially including big changes like rewriting your whole application or firing groups of early customers, because by that time you have the money and resources and user base to do these things without it hurting your bottom line too much. Again, from a business point of view, this strategy makes a lot of sense if you're operating in markets where these rules apply. What I don't understand though is why so many people who are operating in markets where quality does matter seem to idolise big names like Facebook and Google and the people who work there. They have a high profile and they pay high salaries and their hiring processes are well known for being challenging, but I see little evidence that they effectively translate any of those apparent advantages into producing either better quality or more innovation than anyone else in the industry. If anything, given the enormous resources they have at their disposal, the opposite seems to be true.

93 points by whack 5y ago

ChrisArchitect 5y ago

author's title is misleading - maybe include the words "the book" or quotes around Software Engineering at Google...

mrits 5y ago
That makes a lot more sense. I was trying to figure out how you take the time to write an entire book but then throw together a short blog full of grammar mistakes to promote it.
- dentemple 5y ago
  It's easy--just be a software engineer at Google /s
jsnell 5y ago
Or put the title of the book in quotes?
Swizec 5y ago
Or read the first and second paragraph? > When I first picked up Software Engineering at Google I thought it was another one of those FAANG books full of lessons that make no sense at human scale. I was surprised, the lessons apply to teams as small as 5. > This is a "good shit stays" recap. The lessons that stick with you a few weeks after reading.
- ChrisArchitect 5y ago
  no man, address it before that - it's misleading implying you actually were doing Software Engineering at Google
908B64B197 5y ago
It looks like a cheap attempt at gaming NH to get clicks. Else the author would simply state where he works (surely just as good as Google). I'd be curious to hear from a real Google engineer.

hitekker 5y ago

Starts with a misleading title, goes into content-free blogspam, and ends with a desperate salesman pitch for their services. To top it off, the article randomly throws in "I love and appreciate you [a random visitor to his website] for who you are :heart:" Unseemly and oily.

Zababa 5y ago
> To top it off, the article randomly throws in "I love and appreciate you for who you are :heart:" I find these statements really weird when they're made by total strangers. They strike me as shallow.

gabereiser 5y ago

What I learned reading “Software Engineering at Google”

mikepurvis 5y ago

"... stubs and mocks are bad. Your tests are only as good as your mocks. They hide the true behavior of your system, drift away from reality, and take a lot of effort to maintain." I've often felt guilty for leaning toward broader-scope integration tests, but I've long felt this too— that they're less effort to write and maintain and are much better value in terms of actually catching issues. Not that unit tests don't have their place, but they're best for mostly-pure functions or classes where you're intentionally trying to cover a bunch of branches or corner cases.

jamesgreenleaf 5y ago
I've felt the same way - as though not being able to shoehorn everything into pure unit tests somehow means that I'm not doing testing right. In most cases though, what we really care about is verifying the full functionality of an app. Maybe integration & e2e tests should be considered as the primary form of testing, with unit tests applying only in the specific cases where they make sense, like you mentioned. Maybe the ulimate form of testing is something along the lines of Netflix's chaos monkey (now apparently an entire "simian army" suite of tools). Continuously test the real application, live in production, where it's not allowed to fail.
- mekane8 5y ago
  I believe pretty strongly in the "testing pyramid" - that you should have a broad base of unit tests, with fewer integration tests and even fewer e2e tests. Source (also from Google): https://testing.googleblog.com/2015/04/just-say-no-to-more-end-to-end-tests.html https://testing.googleblog.com/2015/04/just-say-no-to-more-e... I think good unit test coverage is essential for good maintenance, but you can't cover _everything_ with unit tests. You definitely need integration and e2e tests to ensure bigger picture correctness. I have found that value one gets out of the different kinds of tests as you proceed up the pyramid get higher the closer to release you are, and are most valuable post release. During development they become obsolete too quickly due to changes in how things work. But locking in an already-released version to avoid regressions is great.
  - 5y ago

gumby 5y ago

Rather light on content. Repeats a common error: > QA takes a few hours or days to ensure everything works together as expected. Quality Assurance starts at the front of the process: what do we do to ensure (i.e. how do we accomplish) that product does what it says, as reliably as we can reasonably make it? This could include processes like design reviews, code reviews, writing tests, coding conventions, even business processes. Quality Control is a process of running tests and identifying things that don't do what they are supposed to (or weren't done as they were supposed to be, e.g. pushing straight to production). As I was told years ago, and took to heart: "you can't test quality into your product." This doesn't mean "don't test", it means quality comes from the start, and tests identify failures.

oxfordmale 5y ago

>>That's engineering considering the long-term effects of your code. Both direct and indirect. No that is over engineering, and in violation of YAGNI (you ain't going to need it) an KISS (keep it simple stupid) principles. A lot of code my teams develops gets thrown away over time, as it is either no longer needed or replaced with an off the shelf tool. It is really hard to predict what code will survive AND becomes a performance bottleneck. There is no point optimising prematurely. It is often best to tackle the problem when it occurs.

Spartan-S63 5y ago
I agree in an ideal world where it's easy to get time to prioritize optimizing something (whether it's performance tuning or refactoring). Even in the most mature organizations, getting that time to do non value-producing work is challenging and so seemingly premature optimization is a pragmatic tradeoff.

bakuninsbart 5y ago

The body of the article gives some good tips for organizing and maintaining code, but it frames it in a way that would suggest these are the best practices, and that's it. The points given are just the tip of the iceberg taught in a typical Software Engineering 101 course in university. There's no reason to reference Google here, none of these points are original. SE is an academic field with 50 years of publishing, and while most of it is pretty stale today, it is weird to lead a discussion on it completely disregarding the body of knowledge we already have. The introduction is also weirdly phrased, as the process of SE doesn't start with writing code - that's putting the cart before the horse. SE starts with thinking about what you want to solve, and how you can and want to solve it. Coding should probably come after these processes.

mtnygard 5y ago
Bear in mind that the blog is about a specific book titled "Software Engineering at Google." It's not an attempt to survey all of SE, and that explains why it refers to Google... because the book is specifically about SE _at_ Google.

rexreed 5y ago

Google developers are often so lost in the weeds of shipping fast and optimizing for rapid releases that they frustrate users with rapid UI changes, deprecation of major functionality, and not building the things that people often want in favor of just shipping fast. That's part of the reason why this post doesn't talk at all about user requirements, needs definitions, or user stories or anything like that. If this is what is "Software Engineering at Google" then maybe this shouldn't be seen as "best practice". I have found the Google experience, as a user, to be decaying steadily over the past 5-6 years.

mekane8 5y ago
I wholeheartedly agree that the experience of being a Google customer / user has degraded significantly. I'm not sure the omission of the topics you mentioned can be corelated exactly to that degradation, but it's an interesting idea. My assumption is that all the changes do go through proper UX and user testing, but the reason for them is questionable. I certainly haven't asked for hardly any of the changes. I also assume that the book focuses on the purely technical side intentionally.
ksec 5y ago
Yes. Despite the "Move fast and break things" or rapid releases cycle being attributed to Facebook, it was Google who did it first and amplified by Mark Zuckerberg which becomes de facto standard in Silicon Valley and Tech industry worldwide. The cult of move fast and break things meant doing it the old fashioned way were wrong. For nearly 20 years, Twenty Years. It is sin that is even worst than IE stagnation. ( Well I say that because IE is now irrelevant. If IE is still here my rage would have been even worst. )
- Silhouette 5y ago
  The cult of move fast and break things meant doing it the old fashioned way were wrong. The likes of Google and Facebook, as well as many startups inspired by them, have been an excellent demonstration of what commercial success looks like in a modern software business. In particular, they have (unfortunately, perhaps) demonstrated that quality really doesn't matter all that much in their target markets. In the early days, it turns out that users will forgive almost anything breaking if you have an attractive product. Later on, you can still break things often and almost completely ignore customer service as long as your lock-in effects are strong enough to keep most of your users anyway. Even if you do need higher quality standards in your market, the lean startup view is to build anything you can and ship your MVP as quickly as possible. If and when you find product-market fit then you can pay off your "debts", potentially including big changes like rewriting your whole application or firing groups of early customers, because by that time you have the money and resources and user base to do these things without it hurting your bottom line too much. Again, from a business point of view, this strategy makes a lot of sense if you're operating in markets where these rules apply. What I don't understand though is why so many people who are operating in markets where quality does matter seem to idolise big names like Facebook and Google and the people who work there. They have a high profile and they pay high salaries and their hiring processes are well known for being challenging, but I see little evidence that they effectively translate any of those apparent advantages into producing either better quality or more innovation than anyone else in the industry. If anything, given the enormous resources they have at their disposal, the opposite seems to be true.