I help develop and operate a service that makes a hefty sum by doing all those things you deride, implementation-wise. It all works quite well - well enough that if routing patching causes any customer-visible disruption, you're in for extensive analysis, paperwork, and perhaps ritual abasement before an angry VP.

Yes, yes, there are many technical problems involved with consuming "eventual consistency". In the 20th century these problems were seen as blocking, and anyway just buy a bigger DB server. But the 20th century was along time ago, and while there's still a need for a transactional store, most problems can be solved without one, given sufficient thought - and at sufficient scale, it's really worth figuring out how.

Not that safe patching is incompatible with SQL, of course. In my last job we routinely pushed patches to farms of many thousands of SQL servers, and again if there was any disruption visible to the mid-tier, important people would become seriously angry about that, and we didn't use fancy servers, beyond RAID controllers (and even that concession I abhorred). It's always safe for a single server to fail, or be rebooted for maintenance, and if two servers holding your primary copies of the same data should fail, you better have taken serious, well-reviewed steps in planning to limit the number of DBs affected and the minutes of data lost and the minutes until you're back up.

And even that, which was a nice system, feels outdated now that Amazon went and announced this, which productizes the modern SQL DB and wraps it up in a pretty bow. /jealous

SAP? SQL? Party like it's 1999! For me, having it matter whether any given server suddenly fails would be a career limiting move. We push-restart patches to services every week or two, and if that affects a customer in any way TSHTF.

"Quark nuggets" are ordinary?

Well, I guess that would be technically correct (the best kind of correct!) if true, since 85% of matter is whatever dark matter is. Our matter is the weird stuff.

It can't be "ordinary baryonic matter": we know it doesn't interact with photons even at extreme energy densities, and we also know it doesn't move at or near the speed of light. Both are clear from the CMBR data.

Large companies often require multiple levels of approvals, often from teams in multiple time zones, before you can even get on with the business of coding. A couple years back I had a project where getting the approval took 6 weeks, and the code took one day (yes, I left that company not long after).

Indeed. But junior developers, almost by definition, aren't good at this. Most large software actually corps have this firmly in their interview process: give the candidate ambiguous requirements, and see whether he asks clarifying questions or just jumps in and codes some arbitrary take on the problem. It's a good way to assess the senior-ness of a candidate.

Practically, "how big of a design/project can you own" is the best measure of a developer. A senior dev drags projects across the finish line despite all the obstacles created by the company being stupid. A junior dev can follow clear requirements, but gets stuck and needs help at every ambiguity (or worse, doesn't get stuck and just solves some arbitrary problem).

And I'm certainly not a manager. Tried that once - my ability to anticipate people problems before they happened were sorely lacking. But managers should be focused on the people first, and the technology only enough to tell when a developer is BSing (or just wrong) about the difficulty of some task. Making decisions about how to staff competing projects so that the best work gets done, morale stays high, and devs grow their skill set - that's hard work. Preventing personality clashes, recruiting, firing people who aren't making the cut, that's all hard work. That why there are senior devs - to provide technical leadership so that the managers can get on with the people leadership.

Yup, very strong programmers certainly exist, but "10x" the code is not the reason they're strong. It's a pet peeve of mine, because writing that code generator instead of the 10x model classes looks like you're doing less work, to naive managers.

I know you were talking about people, but that line made me laugh - imagine saying that about code in this century.

Nope, I'm just saying that banging out lots of code is really important for your first promotion, after that it's still good, but becomes less important as you advance. "10x" is just a silly name for a talent agency.

Rock Star == Prima Donna == show off glory hound. You need a new word for what you're talking about. Legendary maybe isn't it either, unless there's a Prose Edda of coder adventures I haven't read yet. What you describe is what, without title inflation, gets called a Principal Engineer or Fellow. Most big companies treasure them, and they certainly don't need agents.

Have you ever worked for a big software company? That's not the job of management at all. It's the essence of engineering: improving the performance of a complex system (a system of made of programmers), or alternatively, to invent the stuff that really matters. That's why the tech track exists, and that's how you get paid the same as those senior managers.

The whole point is: your productivity as a coder is just nice, but there are more important skills for senior developers to focus on: skills that scale with team size.

I've work with multiple people like that throughout my career. I've done fun tricks myself like fixing a bug in a production system that couldn't be rebooted by just editing the contents of memory, quickly debugged software we didn't have the source code for by stepping through the object, debugged complex systems from hex dumps of memory (just a print-out and a mark-1 eyeball for tools). None of that really holds a candle to not having the bugs in production in the first place, which in turn is far less important than building the product the customer actually wants, instead of what they ask for.

The better you are, the more likely it is someone less good will have to maintain your code, debug your clever multi-threaded tricks without your insight, answer customer calls asking "why is it doing this" and so on. You can only do so much yourself - how good are you at making your team more productive? How much can you teach? How well do you test and document? How good are you at working with that team 12 timezones away that your whole project depends on? How good are you at spotting the 3 candidates in a sea of dozens of interviews that are as good as you, and making sure they get hired?

Banging out code is an important part of the job, to be sure, and is probably all that matters for a junior dev. But the more senior you are, the more it matters how well your skills scale with team size.

I suspect you're a self-proclaimed "rock star" who's convinced he's God's gift to programming, but hasn't worked on a team of equally-smart people, or who doesn't understand the reality of large projects.

Ability to bang out lots of code is the right way to measure a junior developer, but is not the essence of productivity. Two guys drive from NYC to LA - one at 10 MPH, one at 100 MPH. Who get there first? Well, it's important to know which one is headed in the right direction, and which one drives into the ocean, and is either of them so careless they're unlikely to make it there alive in the first place.

If your job skill is "given a clear design with unambiguous requirements and success criteria, I can bang out that code very fast," well, that's great for a junior dev. If you write well-tested, debugable, supportable, maintainable, secure, scalable code given ambiguous requirements, great, that's a successful mid-career dev. If you can fix everything wrong process-wise with your 100-dev organization so that everyone can work twice as fast, well, you're 10x as productive as the guy who sits in a corner and bangs out 10x the code, aren't you? If you can invent a product that solves a problem that everyone has, but no one else thought there was a solution to, well, the guy banging out code isn't even on the same scale.

Was about to post the same: worked with a programmer once who was in a reasonably successful second-tier rock band (they were big enough in Japan to tour there each year with their vacation time).

It's a network effect - you hire where you can find lots of skilled workers, and the worker move to where companies are hiring. Silly Valley is the largest hub, but on the West Coast there a fair pool of jobs in LA associated with Hollywood, and a large and fast-growing pool in Seattle where MS and Amazon are headquartered, and many other large companies have offices to mine that talent pool.

No, I really won't. Cheapskate organizations don't hire senior devs in the first place: only managers are paid well. Mature software shops, on the other hand, value devs on the technical track highly - they're harder to hire than managers. Especially once you get past the equivalent of first-level managers: Principle Engineers (or whatever you call the equivalent to a second-level manager) are golden. Middle management comes and goes with every re-org, but those few guys who work as engineers at that level certainly don't need agents - I know my company has an entire team of recruiters that do nothing but look for those guys.