How good engineers write bad code at big companies

>I have not worked for a FAANG, so maybe things are different there, but I don't suspect so

it is quite a bit different at FAANG. I've workded for small companies, huge companies that aren't software/FAANG, and now FAANG, and it's definitely better here.

The floor is very high for talent and just an overall ability to get stuff done. Google certainly doesn't have a monopoly on genius coders, i've met brilliant folks at all different size companies.

It is very good at making sure the caliber of the average engineer is quite high. Code quality is shockingly good across teams and codebases. I said good, not amazing, there are definitely differences in teams and I can cherry pick projects outside of google that had better code than some at google.

But the consistency of it being decent is very high.

I'm also dubious of your claim that compensation doesn't attract better talent. In my 25+ years of coding, it's a pretty damn strong correlation. The people who leave google to go to even higher paying places like the top hedge funds or Anthropic are not the most 'average' caliber talent, it's usualy the better folks.

> The problem I observe is the universal one: management doesn't care about good code, it cares about results. It's generally too hard for ANYONE to tell what's going on in a codebase unless you're experienced with it. Management can't evaluate the value of maintenance work, so it doesn't value it.

I think this is a very telling statement, but perhaps not in the way you intended. I would agree that management only cares about results, but I would posit that maybe that's a good thing. If you don't have ground-truth knowledge of a problem, you must rely on either the word of someone who does, or metrics that can be used as a yardstick.

When all a manager has to go on is someone's word, it can be really hard for them to gauge the depth, severity, and impact of the problem being expressed to them— and without any metrics, they have no way of tracking progress on resolution. In a modern codebase, you could spend YEARS on improving maintainability and still not "finish". The key (that I've found, personally) in this situation is to give the manager some form of metric to describe the problem. If you can establish a number to measure what you're advocating for, and quantify the consequences of not doing it into actual business impact, I've talked managers into taking my suggestion more often than not.

1. In Silicon Valley, people are not bounded by non-compete clauses and can come and go at will. So fungibility is a top priority for any tech company. The only way to do that is to make sure expertise is shared across the team and not monopolized by one or a few old-timers.

2. Eng teams that have mostly old-timers tend to get stale and slow in changes. This is bad for products that need rapid evolution or new ideas to break status quo. New engineers have way more incentives to make changes to prove themselves and collect credits, while old-timers tend to play safe and stay on the side of stability.

3. Bad coders, not new coders, write bad code.

I've been at big companies for 12 out of the last 20 years, never a FAANG, just "average" big companies. The rest of the time I've spent at startups and medium-sized companies, and sometimes a startup-in-a-big-company.

I have met maybe 5 good engineers in my whole career. The size of the company did not matter. The reason is, the only thing that exists in our world today that can make you a good tech engineer, is yourself.

When you hear the word "engineer", you might imagine a professional who has done studies, passed exams, has certificates, maybe even apprenticed. They know a specific body of knowledge (which is maintained by some organization), they're held liable for their work. They are masters of their domain and they don't step outside of it.

But not if they're in tech! Then an 'engineer' can be a high school graduate or a PhD. Both can make the same amount of money, and have the same lack of real-world experience and job skills. They will both regularly apply technology they've never been trained on, never learning more than the least possible information to get a proof of concept working (and then that immediately becomes a production service). There's often no record of the decisions they made, no formal design process, no architectural review, no standards listed, no testing required, no risk analysis performed, no security/safety/reliability checklist performed. And they often are dealing directly with PII, with absolutely no thought to how to manage it. And they often have far more access than they should have, leak critical credentials everywhere, don't manage the software supply chain properly, don't even pin versions or even test rollbacks, etc. I have seen all of this at every single company I've worked for.

In any other 'engineering' profession, this would be illegal. Hell, it's sometimes illegal just to change a breaker in a subpanel in your home without pulling a permit, because doing it wrong has consequences. Think of all the times your personal financial records, health records, sensitive data, social security numbers, etc, have been leaked, just in the last year or two. 9 times out of 10 those happened because nobody cared enough to prevent it. But these things shouldn't be optional. There should be some kind of mandatory thing in place to force people to ensure this doesn't happen. And some kind of mandatory minimum requirements about what people know, what they're allowed to work with, and how. None of that applies in tech, yet we still call it engineering.

There's quite a bit of cope involved in this discussion, right? As in "I didn't get hired but at least I, a noble artisan, am not compromising my beautiful style"?