Software Engineering at Google (2020) [pdf]
abseil.io
abseil.io
* 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.
nit: use fig
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.
Even during my tenure at AWS inside Amazon, I have difficulty believing this would be useful; for example, at AWS, we'd separate services by tiers based on how close to the center they were inside the internal service graph. Running EC2/S3 or another tier 1 service? Yes, you're probably going to index on moving a bit slower to reduce operational risk than not. Running a new AWS service that is more of a "leaf node" than a center node? You can go ahead and move fairly quickly so long as you're obeying AWS best practices, which while somewhat hefty by startup standards are quite relaxed by other corporate standards.
What I wonder is whether this kind of heterogeneity would have been a better path for Google than what you describe. 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.
But, as you might be alluding to, perhaps the current approach doesn't even suit the needs of the company and is purely bad even for Google's specific problems -- in that case, is it simply there due to cultural cruft/legacy? I haven't worked at Google before, so it's hard for me to say something based on my experience with it.
Basically if you could pin lib versions everyone would be stuck on old versions for a long time, causing difficult debugging work for each user of the library. You'd then also have all sorts of diamond problems: what if you want newest absl but older bigtable client?
It's a difficult problem no matter which way you go.
Skip forward a few years and my projects are full of workarounds for years old Google bugs. It feels like fixing basic functionality just isn't a priority. Most of them are literally labeled "NOT A PRIORITY".
[0]: You can read Scrapy's docs, and the docs for most major Python libraries, from beginning to end and just "know" how to use it (https://docs.scrapy.org/_/downloads/en/latest/pdf/). With Google docs you have to piece together fragments of information connected by an complex web of "[barely] Related Topics".
If we had to maintain 6 past months of releases, we would never get anything done. Since breakages in our client library were our problem, getting a months-old bug means that we can just tell you to recompile rather than figuring out how to backport a fix for you.
Hyrum's Law considerations got really weird, especially when people take them too far. I think this is based on the kernel idea of "don't break userspace," but its practical implications are nuts. Hyrum's law has killed infrastructure projects that could have made things a lot better, and has resulted in crazy test-only behavior being the norm.
One person on an adjacent team loved taking behaviors as promises (and he also had a reputation as one of the most prolific coders at G). We had to clean up his messes every time he relied on unspecified behavior. I pushed back on his nonsense a few times, particularly when he used an explicitly banned combination of configuration options that we forgot to check-fail on, but always lost. 1.5 SWEs on our team were full-time cleaning up after him.
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. Not sure what to call this? Gatekeeping, control freak, PKI hacking, passive-aggressive, or maybe just being an asshole.
I think part of it is that programmers don't like to write a lot of documentation, but infrastructure services have very long lives and naturally build up a lot of documentation. If you write down a lot of promises, you also have documentation about what you don't promise. Unfortunately, the culture of G was that docs don't get updated and you promise all observable behavior.
Effective Zero Sum behaviors that management should avoid:
0) I can ship faster than all of my team mates if I nitpick their CRs and get mine quickly approved by our easier reviews.
1) I can make sure my CR reviews are always faster if I am the nitpicky a-hole on every other CR
2) I can ship faster if I don't add as many tests as my peers. I'll promise to add them in a later CR and forget about it.
3) I can ship faster if I write software that is difficult for others to work on.
4) I can seem like a smarter engineer than everyone else by using jargon and writing difficult to understand code.
5) I can convince management to look at my X,Y,Z productivity metrics, while the team remains ignorant. (Code Review iterations is a dangerous example of this)
Big thing is to recognize signs of zero sum behavior, and investigate if it's being done intentionally or unintentionally. Even if its intentional, it may simply be a bad reaction to the surrounding incentive model of the organization.
I think about Eli Goldratt's The Goal all the time.
Paraphrasing: A team (system) is only as fast as its slowest member (task); to speed up the team, focus on making the bottle neck faster.
Said another way, Goldratt also explains how a process that outpaces the others works to slow down the system overall. Local optimization leads to gloal inoptimization.
Pretty basic queue theory stuff. This aspect is aka Theory of Constraints.
Anyhoo. I don't buy most "10x programmer" tales. I just wonder who's on the receiving end of such awesomeness. And at what cost.
Can you explain what “happy-glad” means here please?
Just to pick on the last example, having customers with unreasonable tests _is_ a real problem. But letting clients pin down specific/older builds of their dependencies (your code) to deal with this doesn't solve the problem, just pushes it down the road, imo making things worse.
.. 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).
On the other hand, my users can pin versions, and we maintain a longer LTS window for those features. To this day, that LTS window has never been exercised because we end up having to build backwards compatibility into everything we do. The backwards compatibility promise also means our testing is extremely verbose.
This is not to disparage the people who built those systems, but there is only so much concrete you can put in a rocket ship.
I get the feeling you need to pin to v1.4 but ideally by being on the trunk head at all times, you force everyone (especially the library owners, and yourself, by writing tests around your wrapper) to do things properly such as having enough tests in place. 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.
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.
On the other hand, things like deployment and monitoring were so trivial and magic.
This was circa 2015.
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-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.
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.
"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.
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.
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.
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/14920... or https://play.google.com/store/audiobooks/details/Software_En... or https://www.audible.ca/pd/Software-Engineering-at-Google-Aud... or https://books.apple.com/us/audiobook/software-engineering-at... or https://www.kobo.com/ca/en/audiobook/software-engineering-at...
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?
Most developer's main targets are much, much smaller.
My project weighed in as a jar of about 350MB. At one point I had look inside and it was like 60% protobuf-generated code.
Another possibility is to install your program in production but under your own personal credentials. Every engineer has unlimited budget to do so, albeit with low priority.
Aside from the above, other practices vary but a team I was on had several dev environments in Borg (the cluster management system). One of which was just "dev" where anyone was welcome to release any service with a new build at any time. Another of which was "test" which also had basically no rules but existed for other teams to play with integrating with our services. The next of which was "experimental" where developers could release only an official release branch binary because it served a tiny amount of production traffic, "canary" which served a large amount of production traffic and required a 2-person signoff to release, and finally full production.
So basically developers had four different environments to just play with: their own workstations under their own authority, in prod, under their own authority, and dev/test in prod under team testing credentials.
1: https://cloud.google.com/docs/security/encryption-in-transit...
I like the testing part very much, it is pretty inspiring
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.
Disclaimer: I'm a swe at alphabet.
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.
These are companies that operate at the sort of scale where you harvest huge amounts of data about people and then use it to maximize your profit regardless of the impact on the people themselves. Those are asshole tactics, and people who think "I'll get paid a lot to work on that!" are probably skewed towards the asshole end of the spectrum of all humans.
I don't think it's a huge leap to believe FAANGs overrepresent the number of assholes they employ.
I also don't think that's necessarily a bad thing. As much as many of the staff are assholes, the companies make things a shitload of people want. There's some good in that. You can be an asshole, make a pile of money, and still be doing good work.
(Of course, if you're reading this and you work for a FAANG I don't mean ~you~. Although, if you're reading HN... )
The kids are getting their brains fried, and they don't even know it.
Slightly off topic, but happened this week. A Google employee commissioned my girlfriend on Reddit to draw two minions. Paid for the first one and then didn't for the second, it was literally $10 for someone that's making > 250k. It's also kinda funny that he paid with a PayPal account that's tied to his entire digital identity: github/linkedin/etc.
I'll definitely remember that the guy was from Google (ex-Amazon) and is/was an asshole.
This is a bigger problem with some companies.
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.
I’ve worked with a number of X-FANNGers, and interviewed at a couple places that were predominantly run by them. Your comment brought up some unsavoury memories.
When I research places to work now, if any of the main people are X-FANNG I politely decline the opportunity - it just saves everyone’s time.
It’s like when some people say “Silicon Valley” when they mean San Francisco or vice versa: from a distance they look like the same thing.
[1] https://www.fool.com/investing/2021/11/05/faang-is-dead-long...
While I wouldn't go to your extent just yet, I'm on the sample size of 2 large projects. Projects where ex-Googler's were in technical/team lead positions, and those two were the flakiest, bikesheddy and glacially moving of all projects I've worked on.
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. Both in terms of actual project code, and infrastructure systems.
Lots of personal questions about attitude, what you do in your spare time, how you feel about things that bordered on the illegal.
I was personally intimidated by the process and in the end they never even bothered to contacted me back.
I think if I see this again I will pass but unfortunately I was never told this chap was going to interview me until I was in the office shaking his bloody hand. Maybe they wanted to keep it secret for this exact reason.
Huh? That's absolutely false. FYI this dude wasn't just ex-google he was ex-facebook and ex-google (worked at both). He was a Product Manager and then I think some VP of something. He was like a VP at the the parent company of the company I was interviewing for.
FAANG stand for: "Facebook (now Meta), Amazon, Apple, Netflix, and Google (now Alphabet)".
Looking at the questions I suspect these came from facebook but were altered. I even asked the next interviewer (the one I was actually told I was being interviewed by) that I found the questions strange and he agreed and said that the guy was kind "out there".
Speaking of hiring, just yesterday I spoke with a Google recruiter but bowed out when he told me that the process takes months.
I can't think of any point in my career where I'd be willing to put up with a process that takes MONTHS. 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? My time is valuable, I won't spend months on an interview/hiring process. If anything, Google better spend that time telling me why I should work there, because I have plenty of alternative options.
So, if you copy their multi-month hiring process, I certainly won't be applying.
But then I'm just a curmudgeony old fart with a decaying brain. Google is for bright young things in their 20's.
Regarding cognitive decay: I like to think time is simply pruning the weak and lazy neurons. At least that's what my remaining grey matter is telling itself. Your comment made me laugh. Thanks.
[1] https://kevin.burke.dev/pdf/30_seconds_teacher_quality.pdf
I can't give citation, but someone was talking about an assessment unit in the army that tried to identify candidates to fast-track to more senior command positions. What they found was that there was no reliable way to determine such candidates. Unpromising candidates went on to great things, and the so-called promising ones didn't. The assessor wryly noted that despite the failure, enthusiasm for assessment didn't abate.
One thing that struck me years (decades) ago was when I was working for a company as a programmer. I happened to see the CVs of the candidates. On the basis of less than 15 minutes, I came to the conclusion that they were all likely to be as good as the other. There was perhaps one lemon in the group.
Some companies are very successful, and obviously employ bright people. There's a mindset of "manifest destiny", and of course a certain conceit.
I think that there was a talk at Google about how companies rise and fall. He said that Google will eventually fall. Nothing lasts forever. (Although I will say that a company like Microsoft has beaten a lot of history as to how long the edge can last). One Google employee raised a hand and asked how it could be prevented. You could tell it in their eyes and manner of speech that they thought that the sheer brilliance of their minds would prevent such a thing from happening. I can't remember what the response was, but I think it was along the lines of "you can't". Time and tide happen to all men.
I thought about this, and I did come to one interesting idea: spinoffs. Google may do better for their shareholders if they explored the idea of spinoffs. How so? Well, we've seen the sheer volume of projects that have been started and abandoned by Google. Presumably the logic behind this is that they'll encounter, by chance, another project that will propel them to the next level.
The idea is good, but there's a snag: Google is too successful. This leads them a lot of dilettantism. They try this, they try that, they try the other. Then they get bored, and go back to their ad revenues.
Let's take Google+. At one point, people speculated that it would usurp Facebook. 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. As we now know, Google+ disappeared and Facebook is still strong. Perhaps a better strategy would have been to spin off the Google+ division, retaining only a 20% stake. This has two effects: 1) it creates a smaller division with less diseconomies of scale, 2) the new division is pot-committed. Failure is not an option. Success is by no means guaranteed, of course, but success is more likely when there's a gun at your head.
I stayed at one company for 9 years and by 2008 at 34, I was the epitome of an “expert beginner”. I changed jobs four times between 2008 and 2016 and I was just your regular old enterprise “full stack developer”.
In 2016, I was the lead developer at a medium size non tech company and looking at where I wanted to be in four years after I my youngest (step)son graduated and we could move anywhere the money took us.
I looked around at the landscape and saw that my salary was going to plateau with one more job hop locally unless I became a manager. 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 something’s.
I kind of put the idea to the side and started working on the skills it would take to become a consultant (not a contractor doing staff augmentation who calls themselves a consultant).
Out of the blue, while I was a working as a de facto “cloud architect” at a startup in 2020, BigTech cloud provider recruiter sent me a message about a role in the consulting department. 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. But I do get to work remotely.
Curious to know what you were doing to make this happen. Did you have a guide?
They brought in two sets of consultants. One set that was suppose to know about AWS. But they ended up just treating AWS like an overpriced Colo and I didn’t know any better at the time and the other set who in hindsight were just following a cookie cutter script who were “helping” the business manage integrating a bunch of recent acquisitions.
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”.
I figured I could bring more to the table from a software engineering standpoint.
I changed jobs in 2018 where the then new CTO wanted to be “cloud native”. He was trying to build out an internal engineering department. He knew I had no hands on experience with AWS. But he liked my proposals.
Two years and a lot of projects later, I had the technical side down pat. It took me a couple of years at AWS to get good enough at the soft skills/customer interaction side.
My original plan was to get a job at one of the big consulting agencies to hone my craft. I got lucky to skip over that part.
Source: me, crammed leetcode.
It's as easy as saying like "I just got an offer from $competitor".
The process may take months because candidates usually ask for time to prepare, and some latency once the offer is accepted (background check, etc). If you are actively looking for a job, you are most likely already prepared.
That’s still terrible by industry standards. We lost many candidates because they did have competing offers and couldn’t sit on them for a month while the hiring committee waited until the next blood moon to gather.
I'm sure there are plenty of candidates giving up because they received a competing offer and wouldn't wait, but I think it's reasonable to expect a hiring process to take a month, even in small companies.
Edit: I also have anecdotal evidence of cases where an offer would be made withing 2-3 business days after the interviews at both Google a Facebook.
Yes. It’s fucking terrible. That pace isn’t acceptable for things with significantly more at stake (buying a house, getting married, donating an organ). Google just abused its position as a desirable place to work while I was there to take time to hire candidates.
Do you want to optimize to hire people who accept whatever offer comes first? 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?
Why would I put up with a multi month process when many of my alternatives are so much less stress? It just feels like Google doesn’t value my time.
Also, respecting the privacy of your customers and having a business model that does not depend on collecting data they may not want to be collected.
My main point stands though. Don't emulate google or your startup is going to fail.
This also otherwise rings a little hollow without specific things to backup the assertion. I think being direct forces us to have the real conversation.
https://abseil.io/resources/swe-book
or more directly:
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.
[0] https://www.viget.com/articles/the-line-length-misconception...
On my team we've settled for either 100 or 120 depending on language.
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.
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.
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.
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.
The other fact is that few devs craft their code to fit 80 characters. Instead they write code and let formatters do their thing. But automated formaters are doing a horrible job, aka if I write a line that is 81 characters long, they will massacre it to a set of unreadable lines with no proper aligning.
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.
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.
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.
Are the tools at Google and elsewhere unable to diff code if a line exceeds some arbitrary width?
Can you give one?
At the very least you can inspect your test data easily without having to extract it from base64-encoded strings.
Current approach may be working for your team, but I can totally see why a company which has a dedicated team working on build and testing infra, prefers a slightly more complex approach. It requires one-off investment in tooling which can be payed off very soon given enough people using it.
Of course you can embed binary files as base64, but have you thought if you should
You just have to convince your reviewer it makes sense in that particular case. The more obvious it is, the easier it will be.
Those in charge of the C++ style guide choose not to allow them without strong justification. In practice, you just convince your reviewer and move on. Most reviewers are reasonable, but edge cases a where it is needed are rare.
I don’t especially like it, but in terms of annoying style issues, it is very far down the list, especially when the tooling handles it all for you via auto formatting and whatnot.
There are much more compact languages than Python.
> Now, I am so happy with 120 char limit while still being able to fit two columns on one screen.
The standard width of a terminal is 80 characters; if you are writing 120-character-wide code then your lines will read very poorly on a terminal, or a window sized to a terminal.
Note too that to be readable text should not be too wide, which is why newspaper columns are narrower, and why websites normally try to have a fairly narrow text box. It turns out that 80 characters wide is a pretty good readability standard.
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.
p.s. even dot matrix printers support a 100 character mode.
EDIT: long lines only reduce readability for prose. Code is inherently easier to parse for the eye because it has a shape. Unless of course if you f--k up that shape with arbitrary line breaks.
I think I am a better judge of my beliefs than you are.
> No-one sizes their terminals to 80chars.
Mine open at 24×80, although to be honest I normally tile them instead. And I much prefer code formatted to be 80 chars wide, with functions that fit within a page or two of text.
Wouldn't you agree that largely depends on the code in question? Of course I also "prefer" shorter lines in general, but that relationship is somewhat linear: 81 is not infinitely worse than 80. If the function in question would be more readable with just 1-2 lines that happens to be 83 chars, wouldn't you opt for that over placing some arbitrary closing bracket on the next line? Whether a code is more readable (for a human) should really not be decided by an arbitrary technical limit from 50 years ago. We have code reviews for that.
btw, as far as I know the linux kernel has a _recommended_ 100 char maximum now.
Perfect person to ask this. What is behind the need to constantly abandon products/services in favor of new offerings that have a fraction of the functionality?
The upper leaders even talked about that. How Google was looking for "the next big thing", and every time it turned out to just be be more ads since nothing else they tried even came close to being as profitable.
We don't have an 80 character rule, but none of the other developers has come to me saying my code is hard to read.
The lambda problem is a language problem. If Python allowed multi-statement lambdas, you wouldn't have this frustration. When I used to do C++, most of my lambdas were multi-line - my coworkers found it easier to read.
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.
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.
[0] https://github.com/abseil/abseil.github.io/commit/a69a63ec3f...
1: https://web.archive.org/web/20220329143949/https://abseil.io...