Both in terms of actual project code, and infrastructure systems. Your comment made me laugh. 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. The first few chapters are easy to listen to, and the book is broken down into shorter sections. Well, we've seen the sheer volume of projects that have been started and abandoned by Google. Your comment brought up some unsavoury memories. The process may take months because candidates usually ask for time to prepare, and some latency once the offer is accepted (background check, etc). He said that Google will eventually fall. If you have alternatives that are similar enough, then it makes more sense to be picky about their hiring process. Said another way, Goldratt also explains how a process that outpaces the others works to slow down the system overall. The tools at Google are perfectly capable of diffing lines of arbitrary width. When 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. Since most of this is only discussed on a very high level, the paper is easy to read and gives an interesting glimpse into how things work at Google. The width limit is per language- some are longer than 80. privacy statement. You believe others are competent and will do the right thing, and youre OK with letting them drive when appropriate. One thing that struck me years (decades) ago was when I was working for a company as a programmer. Ive worked with a number of X-FANNGers, and interviewed at a couple places that were predominantly run by them. "The Three Pillars of Social Interaction Agree. To the point in your last sentence, a few years ago I worked at a software company where there was a prolific code writer who similarly tied up about ~2 SWEs cleaning up his messes. The PDF on the original link is down. Whether a code is more readable (for a human) should really not be decided by an arbitrary technical limit from 50 years ago. At the same time hed happy-glad you to death with blocking change requests. And some languages, believe it or not, don't even have readability. Maybe they wanted to keep it secret for this exact reason. Why would I put up with a multi month process when many of my alternatives are so much less stress? Slightly off topic, but happened this week. The fact is that the limit of 80 characters length is arbitrary. Otherwise, you find yourself digging a grave for yourself when the time comes to migrate from v1.4 to v1.7, and it becomes grunt work that nobody wants to take on. Yes. So now we are at the mercy of automated formatters that try to enforce an arbitrary constraint that is irrelevant with today's code editing/reviewing technologies. You signed in with another tab or window. Because Google earns more money by making those engineers optimize ads rather than maintaining systems with a fraction of the ROI. I think I am a better judge of my beliefs than you are. Let's take Google+. Sign in Diffing an excessively long line is uncomfortable in most tools. Nowadays I personally use FAANG as an alias to "tech company in which employment is synonymous with status in the tech community". 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.

I looked at what it would take to get into $BigTech as a software engineer and I was neither interested in grinding leetCode or even working as a software engineer at a large company with a bunch of 20 somethings. I think we need some contextual line width limits. .. and these problems are absolutely worth having in return for the simplicity of ~only having to support head (and, in some cases, like client LB policies, just a relatively short build horizon). 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. Then they get bored, and go back to their ad revenues. It doesn't mention any specifics, then it jumps into assuming that Google / FAANG have more assholes? You can be an asshole, make a pile of money, and still be doing good work. It hires people who had the time to cram leetcode. Interestingly, so many things that are quite easy everywhere else aren't so easy to do at Google. I feel that there are too few people at Google who will say "stop, that is going to create a problem in the future". With 80 chars you could fit three windows with code side by side on standard screen or four on ultra wide. I do not find those lines amusing. No languages have readability on GoB. My original plan was to get a job at one of the big consulting agencies to hone my craft. 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. [1]. Candidates are more inclined to wait for offers from tier-1 companies (e.g. I think you meant "pro forma" not "performa". Yeah, 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.

Skip forward a few years and my projects are full of workarounds for years old Google bugs. It's a difficult problem no matter which way you go. If Python allowed multi-statement lambdas, you wouldn't have this frustration. Youre open to self-improvement. I'm glad someone got a laugh, at least. Some evidence for this is a well-known study [1]. I've maintained some pretty big libraries inside Google at one time or another in the last 16 years. With some companies in particular you need to really be an asshole to survive. Either through a separate build step which embeds them into the test binary. One simple example was that I couldnt install dependencies from public registries such npmjs (npm) or pypi (pip). It's almost definitely confirmation bias. > working on the skills it would take to become a consultant. Effectively Yes. I think there's some substance. Don't emulate google or your startup is going to fail.

This makes it very easy to switch to other projects or languages, Google servers have libraries for debugging built-in, For example, if something crashes, one can change command-line flags in a web interface and run everything again, This greatly decreases how much conventional tools like gdb are used, Some teams have dedicated release engineers, but mostly this is done by regular software engineers, Releases are often done weekly or fortnightly, sometimes even daily, Regular releases keep engineers motivated and make it easier to change ideas based on user feedback, To deploy a release, dedicated release branches are used, First, the change is typically pushed to a, If everything works fine until here, a gradual roll-out to production is performed. Same here. Well, for people who are ridiculing the absurdity, note that it's software engineering at Google, not software engineering. It doesn't seem that unreasonable to me but moving to Google would be a big step up in my career. My observation has been the torrent-of-poo coder also demands quick (pro forma ~~performa~~) code reviews while nitpicking concern trolling other people's PRs. Paid for the first one and then didn't for the second, it was literally $10 for someone that's making > 250k. Code is inherently easier to parse for the eye because it has a shape. Google has automated tools for measuring test coverage. Isn't it worth waiting a couple weeks to get the right job that you will spend the next few years of your life at? I am not saying lines should be arbitrary long, but a 100-120 _soft_ limit would really not hurt anyone and would help code readability a LOT. Some people are very enthusiastic and well meaning and "productive" (high change count), but create a burden for their colleagues in their fervor to change things. >There are tons of edge cases where allowing a 100k line of text would totally make sense. At that point just run your dev service on borg using free quota. Gatekeeping, control freak, PKI hacking, passive-aggressive, or maybe just being an asshole. [0] https://github.com/abseil/abseil.github.io/commit/a69a63ec3f [1] https://abseil.io/resources/swe-book/html/toc.html. So there I was at 46 with my first job in $BigTech - making about what a 26 year old who was promoted to a mid level engineer was making. This paper gives a high-level overview of software engineering principles at Google. Why does it need to be in the same test file at all? If I want the editor to overflow it below or show me a scrollbar should be my choice. 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. Why Netflix and not Hulu, HBO, Disney? Engineers are encouraged to keep each individual change small. I just wonder who's on the receiving end of such awesomeness. It's hilarious! I would suggest "Fortune 500 Technology sector" but that captures a lot of companies that don't have an emphasis on software. Recruiter chat, recruiter screen, tech screen, take home, onsite, references, meet and greets, offer, waiting for other offers, negotiating offers, acceptance, and then finally waiting for the 2 weeks and the start date. Either I'm actively looking for work and want something ASAP, or I'm not actively looking, in which case why would I put myself through that? Inline base64 string in each unit test method containing the exact specimen was way more convenient. This could take a few days, Changes visible to users need approval from people from the respective core engineering team, There might be more approvals necessary, e.g.

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. There's a TLDR at the end of every chapter. The process/culture practices also have cyclic dependencies with those infra capabilities. It just feels like Google doesnt value my time. Name names. https://www.oreilly.com/videos/software-engineering-at/14920 https://play.google.com/store/audiobooks/details/Software_En https://www.audible.ca/pd/Software-Engineering-at-Google-Aud https://books.apple.com/us/audiobook/software-engineering-at https://www.kobo.com/ca/en/audiobook/software-engineering-at https://cloud.google.com/docs/security/encryption-in-transit https://www.fool.com/investing/2021/11/05/faang-is-dead-long https://kevin.burke.dev/pdf/30_seconds_teacher_quality.pdf. Did you really just insinuate that replacing a pdf with an html version of the same thing is evil? When I last interviewed every place gave me an offer within a week, and they would informally tell me I was getting one usually within 24 hours. Its fucking terrible. > They're going to ruin team dynamics. I find this part on page 35 very important: They forgot Pillar 0 - not everyone's going to get along, let people choose teammates until they find ones that fit. You just have to convince your reviewer it makes sense in that particular case. You dont know what youve got until its gone. Agree with the other commentator that this is an unconstructive message. 4) I can seem like a smarter engineer than everyone else by using jargon and writing difficult to understand code. That's kind of standard at big companies. It is a pain point, but relevant for legal liability and tracking security concerns, else you quickly have wild west where it's unclear what kind of problems affect which team and how. because of legal, privacy or security requirements, Google has an internal launch tool for tracking what reviews are still required, When there is a major problem in production systems, the people involved write a, This document describes what happened and how it could be avoided in the future, The focus is on the problem and how to fix it in the future, not on blaming people for it, A lot of software at Google is rewritten from time to time, This might seem like a waste of resources but it has some advantages, Knowledge about the system that is rewritten is transferred to new people, It ensures that code is written using modern technologies, Engineers can spend 20% of their time working on a side project, Makes it easy to experiment with different ideas, This also keeps engineers happy, which accounts for much more than 20% of productivity, Individuals and teams explicitly document their goals and ways to measure their progress, This is done at all levels of the company, Each objective is given a score between 0 (no progress) and 1 (completely done) at the end of each quarter, The desired average score is 0.65: Goals should be ambitious enough that they cannot all be completed, OKRs have no impact on performance evaluations or compensation, Works differently in various parts of the company, Sometimes top-down (management makes a plan), sometimes bottom-up (engineers decide), There are separate ladders for engineering and management, Research teams are embedded into product teams, New googlers go through introductionary classes called, Google supports studying at external institutions as well as taking online courses, Transferring to a different team inside the company is encouraged, Sometimes, SWEs also do 6-month rotations as SREs, Engineers can give each other peer bonuses, a small cash bonus for doing something above their actual work, For promotion, people have to nominate themselves or have to be nominated by their manager, The performance of managers is partly assesed by asking people in their team for feedback. NOT coding). (Code Review iterations is a dangerous example of this). At one point I had look inside and it was like 60% protobuf-generated code. They're going to ruin team dynamics. The build team made sure to remove any kind of timestamps from builds, All changes must be reviewed by at least one person, Code review discussions are automatically copied to a mailing list, Developers are encouraged to keep individual changes in individual code reviews small, All code in production must have unit tests, The review tool highlights files without corresponding tests, Integration, regression and load testing are also widely done, Some teams have individuals that are responsible for prioritizing and assigning bugs. In 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. No evidence that code of 80 characters length is more readable than code of 83 characters length. There was even an animated gif where a bus with the Google logo above it smashes into a car with the Facebook logo above it. > And I much prefer code formatted to be 80 chars wide, with functions that fit within a page or two of text. Lessons Learned from Programming Over Time. But besides the unevenness, it's a book that does add value, I think, to general conversations on software development. If a service needs to make RPCs (which is generally the case) that's not a problem because developer workstations are able to do so via ALTS[1]. Once I started belated learning about all the services that AWS had to offer developers and for DevOps, I knew I wanted to specialize in consulting in that area and set myself apart from the old school network folks who got one certification and called themselves cloud architects. Didn't see that video before. Is 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. They're not ideal in small teams, but unavoidable at some level and useful if done well. Well occasionally send you account related emails. Almost all development occurs at the head of the repository, not on branches. What is with these draconian rules of having any limit at all? Reserve judgement, and try to understand the rationale. Even at a small scale, it is beneficial to mirror every external dependency. He was a Perl programmer who was set loose on C# code. But yeah, the fact that you can't link it etc was a huge problem that we had to think about. A wholly unpleasant experience that felt a little like what happens to people when they get involved in a cult. > No-one sizes their terminals to 80chars.

My main point stands though. Or, is it the case that the sheer monolithic scale of search/ads at Google is such that it just wouldn't make sense, and that continuing to pile incremental resources into the monstrosity (and I mean this gently/positively) of search is what the company must do and so what the engineering culture must enable. Most reviewers are reasonable, but edge cases a where it is needed are rare. By clicking Sign up for GitHub, you agree to our terms of service and Because Google owns their own code review tool, they can collect data to distinguish these sorts of cases. Seriously. Presubmit Checks can be automatically enforced as part of the code review and commit process. 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. Have a question about this project? If we had to maintain 6 past months of releases, we would never get anything done. Was it purposeful to make this comment also highly abstract? I'm sure they're familiar with good sturdy systems from Google and wanted to replicate it within other organization they got hired into, but without high upfront investment to build a Google-like infrastructure (with assumingly Google internal-like tooling) the projects turned out into a mess of multiple very fragile scattered components. interviewmocks interviewmocks