Tech fields have an inherent disuse for seniority. Beyond five years, no one gives an f how long you have worked with a given toolchain/language. It's the hunger games. Medicine, finance, law, accounting...rightly or wrongly respect decades of experience. Tech is Logan's Run. Plan accordingly.
Nah, take a look at the general listings for anything from embedded to .NET to the javascript library de jour. You'll see the magical 5 year number pop up across the board for a reason. I've never worked in the SFO/brospace. Strictly old-school, east coast, precambrian hardware environments. Rules still apply.
And this is why software today is in such a sad state. Managers think it would be great to have an army of young engineers who don't question and just do what they're told. But any leader surrounded by sycophants will eventually fail. Management often doesn't realize that they really need the senior engineer who has the experience and confidence to say "NO". Because that engineer is the one who will prevent the project from collapsing under the weight of scope creep and tech debt.
> Because that engineer is the one who will prevent the project from collapsing under the weight of scope creep and tech debt.
That's the shitty thing: there's enough work that doesn't cross the threshold that requires you to pay for technical debt. Otherwise, a lot more managers would be getting burned by it. There's no electric shock when they hit the wrong button. Even if it isn't a "big boom" moment where you can't deliver some huge new feature because of bad architecture and lose a lot of potential money, the little payments are written off to the younger generation to actually rebuild the thing because they have energy/time to burn.
There's not really a single threshold though. I think the shittier thing is that software is just an incredible market for lemons. Even us programmers ourselves don't really know how good we are, and there is no way to accurately compare all the problems we faced with the problems we avoided. So forget about non-technical management, they could be paying twice as much for someone who takes 10x as long to deliver a feature and never have the first hope of getting a clue. Or they could hire someone who is demonstrably fast but paints the whole system into a corner where the next critical business feature requires a complete rewrite.
Experience is no silver bullet, but it generally goes a lot further than non-technical tea-leaf-reading or junior dev shotgun programming.
its possible to be experienced and not say no you know? the opposite is also true... the trick really is not saying yes or no, but understanding what your boss really wants, and offering a realistic way forward to achieve that.
"Tech fields have an inherent disuse for seniority. Beyond five years, no one gives an f how long you have worked with a given toolchain/language."
For front-end work maybe, lower down the stack, five years might not be enough to handle the more important things like the corporate RDBMS. A few grey hairs to oversee the youngsters is quite the norm the closer you get to the real value and money of organisations.
Also embedded software, aerospace software, medical devices. Those job listings always ask for at least 5 years of experience, or 10 - and that's not for a senior position at all.
I work in embedded. Unless it's for some god-awful DOD job, they don't put a premium on experience beyond five years. Even then, they don't put that much of a value on anyone in the non-managerial ranks experience beyond 10 years.
Knowing a language or toolchain isn't all you need to be a good developer. Knowledge of how to build maintainable, secure, reliable, scalable and usable systems is something that you get with years of experience (and frequently comes from making mistakes).
True, but companies don't care about those things, really, even in the supposedly developer-centric Bay Area. Just browse through any jobs thread or board, even (especially) the "Who's Hiring" HN thread. You're going to see a lot of "We're looking for an X developer" or "we're looking for a developer with Y years of experience in Stack X." Employers, even supposedly knowledgeable tech centric ones, routinely think the learning curve for a new stack or language is so great that they just can't risk even screening someone without specific experience.
It's because most of the who's hiring on HN posts are small 2-3 people startups that desperately need a new programmer.. yesterday. They're not a team that can afford to bring someone up to speed, even if that person is amazing in programming other things. Which is really unfortunate.
It isn't just the new startups. Hiring managers believe that the best indication you know how to do what they need done is to have done it before. And their vision of "done it before" is unfortunately very narrow.
It's unfortunate and also a terrible business model. In those cases it's clear the business isn't mature or ready enough to actually hire human beings, in my opinion. Not that I'd agree with their conclusion about who they need to hire anyway. There isn't an experienced developer out there who can't pick up the frameworks and languages (exceptions exist of course, e.g. for quirky languages like brainfuck or paradigm shifts like procedural to functional) these CRUD-by-other-names shops use within a week, and if their business is that close to failure without developer help they can't afford to be picky.
A company that's a startup building an MVP for a consumer app might not care if its software ever works reliably, or will be maintainable in five years. But if you're a bank, or a big on-line retailer, or a company that sells enterprise software - a business where you or your customers push billions of dollars of business through a software system - you definitely do care.
> But if you're a bank, or a big on-line retailer, or a company that sells enterprise software - a business where you or your customers push billions of dollars of business through a software system - you definitely do care.
Funny, those companies have the least reliable, performant, and maintainable code.
Experience. The worst horrors I've seen have been in the finance sector. I'm currently working on one where the developers don't know transactions exist. And millions of dollars of transactions daily are coordinated by users emailing inline csv files.
I see the opposite more often. Younger people have stuff to do after work. It's the guy with a wife and 3 screaming kids that wants to work long hours.
I think both hold true. The young can do a good crunch week that the old can't because of responsibilities, the old will some times have home situations that allow them to put in more overtime consistently.
There is a younger streak in small VC startups, and an older streak in the larger AppFaceGooSoft streak of companies as people tend to realize that the EV tends to be better for the typical employee at the larger ones.
