That doesn't explain the useless engineering theater that these companies engage in, like code review and "readability", that drastically reduce IC velocity. If FAANG supposedly "only" hires the "best and brightest", then why are they so untrusting of their contributions?
I mean, I've never worked in a team that large. A big part of that is because I can't imagine asking someone else's permission to write code. If a company can get so big that they can't trust their developers to release code, maybe that company is just too big?
Companies like Google are a joke. All the Cap'n Crunch you can eat, but do your job and write some code and get it into production? Can't have that!
EDIT: the largest company I ever worked at only had about 300,000 employees.
I had a long response typed out to an up thread comment, then remembered the rule "don't feed the trolls". I did get a chuckle afterwards when I read their username, it certainly is apt.
Edit: oh God, I looked at his linked personal site and this isn't a parody account. I really hope this guy is drinking or something, he claims to have worked in VR/AR. Claiming that none of his coworkers in 20 years have been able to understand linear algebra, while working in that field?
For the most part you don't really need to understand linear algebra for most things -- engineers past have done a great job on abstracting interesting math problems away in everything.
If you're not constantly working with linear algebra, you're going to get rusty fast. Mind you, he seems like he writes a matrix multiplication with goto based loops every time, so he can make sure that he keeps knowing linear algebra, and to prevent the business he's working at from getting anything done because he doesn't like their ethics
I think he's probably above average in technical skills and below average in human skills. In that context it makes sense he doesn't like being told by others how to write code. I can imagine it can be frustrating if unqualified people review my code and make irrelevant comments, but usually if you're that good, why are you working with morons anyway?
I’ve seen this pattern a few times in my now long career. Above average Engineer with missing (social skills/theory/cs degree) ends up only getting experience at companies with sub par developers.
Sub par developers parrot industry recommendations such as code reviews or microservices, and Above Average anti-social dude asks why and gets a dumb answer, and out-engineers all the idiots trying to mimic industry best practices.
Now Above Average engineer’s ego expands even more. Not only is he smarter than everyone else, all these best practices are dumb too.
Look at all these people needing code reviews or unit tests, they still can’t ship. Those people doing it at Meta and Amazon must be dumb too.” They think.
The thing is, their arrogance and/or disdain for (whatever) endures they only get hired at companies where this cycle repeats.
It is not a “brag” to say none of the developers you’ve ever worked with don’t understand linear algebra, it means you only work with morons. Being the king of morons isn’t a thing to be proud of…
Some people just hate rethinking their views even if the other person is competent. I know people like that, smart and right about a lot of things, but can't admit that they are wrong ever. I can imagine code reviews being torture to such people.
What does any of this have to do with you thinking code reviews are worthless and slows down velocity? A whole reply of strawman arguments while tossing in the word 'milquetoast' doesn't make it intelligent.
As others have pointed out: code reviews exist for many complex projects even outside of these big companies. Code reviews existed before these companies.
I strongly agree that by and large we waste 99% of the compute resources available to us on useless abstractions.
However, this is an orthogonal issue to not reviewing code. To contrast, if we push code to production _before_ review, then production is much more likely to be full of bugs, and we force people to go looking for them afterwards. I've worked in this kind of environment, and the amount of wasted resources (both compute and engineering time) is staggering. Somebody's pet project ends up taking way more compute than anybody would have deemed acceptable and we have exactly the overhead and waste you are referring to.
Better, lower overhead abstractions require buy-in, and this means it needs to work for other people than the person who wrote them. At some point it needs review and discussion, otherwise it will just be a continual edit war between competing parties.
> useless engineering theater that these companies engage in, like code review and "readability",
Oh boy.
Sure, if you're small, working on your own or at an early startup, you can get away with ignoring code quality and just hack away to rapidly do amazing things. As soon as someone else is going to have to change something about that unreadable code, you're going to wish it had been written with a bit more readability.
Moving fast is great for a quick PoC, but if you're going to take that straight into production, you'll see tech debt pile up fast.
Although with large companies, there's also the fact that large companies are just intrinsically slow. I've had plenty of projects where I moved faster than the company could deal with. But also some where some people greatly appreciated the speed at which we could pivot and respond to their needs. But that speed was always built on a basis of readable, maintainable code. And every time we had to deliver something too fast, we followed it up with a period of refactoring to clean up the tech debt, so the next time we needed to, we'd be able to be fast again.
Code reviews are not about "getting permission to code"; yes, they are a form of quality control, but they're also a way to share knowledge among a team, so that if you decide to quit suddenly, your coworkers can make sense of your code.
If I were to be in an environment where there are multiple developers who can understand even the basic mathematics of geometry and linear algebra too do what I do (that's a tall order. It hasn't happened once in 20 years that I've worked in a company that has had even one other developer that knew anything beyond basic algebra), why would they spend their time telling me how to do my job, rather than just doing their job? If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it?
It's kind how my children argue over basic things like bedtime. They insist it's only "fair" if one of them turns off the light and the other closes the door. And if the light is already off when they enter the room, then the door closer is going to get pissy and turn the light on to make his brother get up out of bed and turn it off.
It's a meaningless exercise developed to give the illusion of control.
I struggle to believe that your coworkers don't understand the basics of LinAlg and geometry. It seems much more likely that you write code which is hard to parse, can't be explained, and your concept of maintenance is rewriting it from scratch because you don't understand it a year later either.
Writing code that other people understand is an independent skill from solving the particular problem at hand. If your colleagues don't understand your code, either you need different colleagues, or you can't write understandable code.
>> Writing code that other people understand is an independent skill
> It's also the main skill of a developer. Code is for people.
If there are any people reading this starting out in their career, i can't stress how important this is. Being able to write beautiful code and being able to explain it to your peers and see them take off with it and do amazing things is the single most important skill as a software engineer IMO. I would put it above any algorithm riddle, esoteric language feature, tool expertise, or anything else.
Why would you expect for code review to catch all errors? That's a false dichotomy. Code review is expected to catch some errors.
Why code reviewer wouldn't fix errors himself? Well, that's an interesting question for sure. One reason, I guess, is that it current way encourages people to avoid doing mistakes over and over again. If code reviewer would have to fix error himself, that would not encourage person writing the code to avoid issues in the future and that would discourage person doing code review to find any issues. But, I guess, in a very trusted environment that definitely could work.
> If I got something wrong in my code, A) how did the process guarantee that it will be caught? B) why wouldn't whoever found the problem just fix it?
well.. fair point. Code review guarantees nothing, if there is an issue found there's going to be delay to fix it as it rolls back through the process. I hate "process" as much as anyone else but I learned during COVID its importance. I implemented a vaccine system for a state government with a team starting at 3 and growing to over 100 in about 8 weeks. It was the hardest thing i ever did and "process" saved my ass and kept CNN off my front lawn a few times. It also was a real thorn in my side when i needed to get things done. Process vs getting-shit-done is a balance and it's rarely perfect.
I mean, I've never worked in a team that large. A big part of that is because I can't imagine asking someone else's permission to write code. If a company can get so big that they can't trust their developers to release code, maybe that company is just too big?
Companies like Google are a joke. All the Cap'n Crunch you can eat, but do your job and write some code and get it into production? Can't have that!
EDIT: the largest company I ever worked at only had about 300,000 employees.