[scarface74]

No this is not ageism. After a certain point, if you are an individual contributor, your value is not worth more than someone with less experience.

A developer with 10 years of varied experience can usually do just as well as someone with 20 years of experience. I also believe that the idea of the 10x developer while not a myth, is so rare it’s not worth trying to find for most companies.

I speak as someone in my mid 40s who has been at this professionally for 20+ years [1].

I’m debating whether I want to take the next step of consulting or just stay in development. I see my salary hitting a ceiling in the next two or three years and I think I am okay with that.

[1] well for all intents and purposes maybe 12 years. I stagnated for a few years and became an “expert beginner”.

[notacoward]

> your value is not worth more than someone with less experience.

I don't think such a general statement (even its direct inverse) can be true or even particularly useful. At a certain point you're playing the odds. We're dealing with X, what's the chance that someone has seen X before or can see a connection to something else? In those situations, 20 years of varied experience can be a lot more valuable than 10 years of varied experience, especially if the 20 includes areas or approaches that have been forgotten/ignored for most of the last 10. (You'd be surprised how often the ebb and flow of tech fashion produces such results.) Note that I said can. Whether that actually happens depends on the exact technology, what experts you already have, team size/cohesion, etc. "Is not" without qualification expresses a more absolute and certain opinion than is warranted.

[xfitm3]

Let's not forget the essence of why we get paid: you are paid because someone likes you. They like your work output, your social skills, or your status.

I'm not as hungry as a intern but I present well, and at the end of the day, thats why I get paid.

[mistermann]

"In order to be successful, one must project an image of success at all times."

– Buddy Kane, American Beauty

I doubt many people know this explicitly, but I think the necessary behavior is intuitive to lots of people. I suspect people "on (or near) the spectrum", which is far more common in tech circles, get their ass handed to them career wise many times because of this, because they are in some sense looking at a different version of reality than other people.

[bsder]

Don't confuse the current shitshow that is VC flippable social software garbage with actual competence.

I worked with people at IBM and DEC at the point probably just at the peak of their heyday when the average experience was about 15 years.

Oh ... my ... God.

I have never had that kind of interaction again. Being able to just call up and talk to the folks who designed FPU algorithms, x86 emulators that smoked (I think the FX!32 guys knew more about x86 than AMD), BDD analyzers that actually matched circuitry to descriptions (NP-hard problems--solved every day), debugged CPU failures by having 3 old guys light up cigars, put their feet up and think real hard ... I can go on and on.

Yes, those big, sclerotic companies had lots of deadwood. But, there was a 25% that was amazing.

About once every couple of years now I bump into someone genuinely as good. It's really rare now.

[kylel]

Do you know of any companies that nowadays with that type of culture?

[Nursie]

> A developer with 10 years of varied experience can usually do just as well as someone with 20 years of experience

As a developer with 20 years experience ... I'm a lot better at what I do than I was ten years ago. Better at seeing how it relates to the business I'm working with, more productive in ways that are not just LoC.

I'd be OK if I can sustain my current income... but I'd still like to take the step to being more of a consultant. I'm dancing on the edges of it now, between contractor and consultant.

[JamesBarney]

How much better? What are you doing now that you weren't doing 10 years ago that is a real game changer in terms of value?

As an architect/tech lead I'm much better than I was 5 years ago. I know how to manage engineering practices and when/how to apply them, better how to design a systems, and how to better manage relationships/politics so that I can leverage my experience into actual implementation and design.

But as an individual contributor I don't think I'm a whole lot more valuable unless it's in a domain I have deep experience in like real-time.

[Nursie]

> How much better?

That's very hard to say.

> What are you doing now that you weren't doing 10 years ago that is a real game changer in terms of value?

Technical leadership on teams of developers. Mentoring and enabling younger team members. Having more cogent ideas about tooling and delivery, having more well formed ideas about delivering the product my client needs, not prioritising doing things in technically interesting ways. Managing upwards/sideways when I encounter problems in product ownership and similar posts. Teasing out requirements where these are incomplete. A lot of things.

I'm also more confident in tackling larger problems, and understand more about the big picture, from kernel to front end.

Much of this is incremental, of course.

> But as an individual contributor I don't think I'm a whole lot more valuable unless it's in a domain I have deep experience in like real-time.

Are those things you mentioned not part of your individual contribution? They don't translate directly to LoC, but they likely to contribute directly to faster, simpler delivery of what the client needs.

[JamesBarney]

Yeah most of the things you've mentioned you've gotten better are the things I've noticed too. On smaller team that I run or am in a sr. position it seems to make a big difference. But on larger teams(100+) where I'm just plugged in as staff augmentation it makes a smaller difference.

Sometimes your job is just transforming fairly well articulated requirements into code and on these I notice I haven't gotten a lot better than I was 4-5 years ago.

[scarface74]

And that’s another line of reasoning I don’t believe.

I have a coworker who is probably 10 years younger than I am but has been working for the company for 7 years to my one, how could I better understand the business of the company than he does?

I worked for one company when I was 35 dealing with the complicated rules of the railroad industry. My manager was 28, but he was the founder of the company before it got acquired, built it from scratch and had 90% penetration in the particular market segment, how could I be more experience at how my code relates to the business - one he studied since he graduated from college?

[rpedela]

You can always find examples that counter the generalization but don't necessarily make the generalization false. In general, a 40 year old is going to be better than a 25 year old in understanding how software is applicable to business simply because they have more experience. They have been in more business meetings and seen how their software applies. Does that mean a 25 year old can't be better than a 40 year old at that? Of course not.

[scarface74]

It's not just one random counterexample. Knowing how code relates to a business has a lot more to do with how long you have been in that particular business or vertical than your general experience.

That 25 year old who was at the company since they started 3 years ago is going to know a lot more than that 40 year old who just came in yesterday.

Besides that, I did say 10+ years. The whole point is diminishing returns from experience.

[AnimalMuppet]

There's more to this than understanding the business.

With 20 years of experience, I didn't write the bugs I did 10 years earlier. I produced better architectures. I produced more readable code. I could tackle more complex problems. I could help my coworkers more.

[Nursie]

> I have a coworker who is probably 10 years younger than I am but has been working for the company for 7 years to my one, how could I better understand the business of the company than he does?

You probably don't understand the specific business domain better. That's not the claim. But you may better/faster understand the clients you have and how to meet their needs, how to interpret their requirements, spot the gaps in what they're asking for, etc

[scarface74]

My next resume

Summary

- Expert at solving XYProblems

[edmundsauto]

One explanation could be that having more experience in a wide variety of fields brings perspective that someone steeped deeply in the business, but with very little external breadth, has.

Not that I necessarily think that's true. Personally, I have yet to be convinced that it's possible to systematically measure developer productivity, making all of these comparisons pretty worthless except as "dorm room at 2am" type conversations.

[jerf]

"I also believe that the idea of the 10x developer while not a myth, is so rare it’s not worth trying to find for most companies"

The problem with the 10x myth is that it assumes a single dimension of productivity, and that no-one is ever negative so there's some sort of sensible, positive "minimum" to talk about.

Senior developer leads a team of three other medium-experience developer, and completes the project in six months. Junior developer leads a team of 5 other even more junior developers, after six months they've got nearly nothing, so we pull in another 4 semi-skilled developers and 2 contractors who are drowned under the mess and don't know what to do, and six months later, the project is cancelled entirely.

How many times better is the senior developer?

There's nothing even remotely skewed about those numbers, either. Both are totally realistic. And yes, senior engineer can fail, and junior engineer could succeed. (Although the range of projects where a junior can succeed and a senior can fail assuming adequate initial knowledgebase for both is fairly narrow; generally if you find one, you've probably got a strawmanned "senior" engineer who isn't actually senior but just a collection of stereotypes in your head.)

If you're still offended:

A generally senior software engineer who knows nothing about the domain and his team of three develop furiously for a year and eventually deliver the first iteration of what was asked for, with another year to go on the project to finish it. A generally software junior engineer who is deeply familiar with the problem domain listens to the customer's problem and after a day's thought realizes what they really need is a very different, but also much simpler, solution, which they deliver in two weeks by themselves. How many more times valuable is the latter?

(I've actually advised someone like that in the construction industry. They were switching into a programming career in their 40s. I said, look, there's no realistic chance you're going to outprogram me in a really academic, isolated sense of the term. But you've got contacts, the ability to pass the shit test with other people in your industry which I and/or generic software engineer have no chance of, and a deep understanding of the problem domain. Don't worry about trying to outprogram a 20-years-experienced software engineer, take advantage of the facts that you know what your customers really need, and... you're there! and I (standing in for generic software engineers) am not! Life's about playing what you're dealt, but people are generally dealt more cards than they realize, I think. Not necessarily better cards, but they have more cards than they think.)

I tend to agree there isn't a such thing as an engineer who is 10x more productive than another, in the sense that they will do the same thing as that other engineer, just 10 times faster. The key comes from doing things differently, most of the time.

There's other differences as well, such as being aware of the pitfalls. I recently got myself put in charge of a billing system, and as a senior engineer, I at least have the good sense to be suitably terrified, for instance. "Move fast and break things" has its place, but "careful, paranoid engineering" does too. Almost by definition, your really junior employees don't really know how to do the latter. (They'll often be able to cargo cult it, which can be a start, but they won't really understand it.)

[scarface74]

My statement was referring specifically to an "individual contributor" and I said as much in the original post. If you are a team lead, by definition you aren't just an "individual contributor" and you're also not the "10x developer". Your increased effectiveness is because you have a team under you and you are a "force multiplier".

but "careful, paranoid engineering" does too. Almost by definition, your really junior employees don't really know how to do the latter. (They'll often be able to cargo cult it, which can be a start, but they won't really understand it.)

I also specifically said the difference between someone with 10 years of experience and someone with 20 years experience. If you have 10 years of experience -- you hopefully aren't a "really junior employee".

[jbay808]

I've worked with a 10x developer. He wasn't a team lead because he wasn't interested in being a team lead and also probably wouldn't have been nearly as good at it as the person who was.

But man, was he ever transformative. Not only in terms of handling the most technically challenging tasks and solving the black-magic challenges that nobody else wanted to touch, knowing the C standard like the back of his hand, and getting things done quickly to a high standard of quality. He also was a force multiplier, because he would help others debug their problems when they got stuck and get them back on their feet and productive again, give advice for how to best handle various edge cases, and designed and maintained our tooling. He was a mentor to junior members of the team, and the team lead would ask his input and advice for how long things might take, what risks he could see causing delays, etc.

You can't plan around having someone like that but they make a world of difference if you're lucky enough to work alongside one.

[blueboo]

Likewise. To have someone with immaculate technical judgment means you potentially have a custodian that keeps an entire multi-team codebase on track.

[jerf]

My apologies, that's a fair defense.

I suppose I so deeply agreed with you I went total mental blindspot on the idea that someone could be a 20 years skilled software engineer and not be (technically, if not necessarily managerially) leading at least a small technical team. I'm not going to delete my post because I think it still has interesting stuff in it, but I do apologize for my tone of disagreement.

[ljm]

On that basis I’d consider the junior to actually be more senior, as understanding the need of the user and building that is vital to the role. A senior engineer who churns out code without taking that step to understand the domain and build the right thing is not, in my estimation, senior at all.

Bashing at something until it finally works is, to me, something we do as beginners when we’re still in the mindset of solving every problem with code.

[jshowa3]

You'd be very surprised then at how fast some people at companies bang out code with very little understanding of the problem, get it done fast, and look like heroes because it works. They then build up an expectation of getting things done fast because "time is money" and end up with a garbled mess of spaghetti code that functions.

Most senior developers that I know are so good at the above that very little communication is required about even the problem. So in reality, they end up sacrificing the team and becoming one man armies.

This goes on until retirement, and then a junior replaces them because they're cheaper and they're stuck with trying to learn a huge ball of code on their own, because teams became obsolete and documentation was an after-thought, that could have been done with a bit more effort on the senior developer to get out of their box and actually impart knowledge.

However, there is the opposite end of the spectrum where they write great code and could do everything themselves while still knowing crap about the problem domain. At that point though, does the PD really matter? Most people , including customers, just accept code results on their face anyways.

[scarface74]

You'd be very surprised then at how fast some people at companies bang out code with very little understanding of the problem, get it done fast, and look like heroes because it works. They then build up an expectation of getting things done fast because "time is money" and end up with a garbled mess of spaghetti code that functions.

And honestly, experience tells you when that's okay. If you work for a venture backed company where the owners and founders only goal is to get something up and running to convince investors to give them money or to survive long enough to go public (statistically unlikely) or to get acquired, the goal isn't to make good code that can be maintained long term. They don't care if the whole business is built on a house of cards that will fall as soon as they get acquired.

Too many employees drink the kool-aid and think the owners are interested in anything else except for an exit strategy.

"Great code" rarely gets someone promoted or recognized.

[plutonorm]

In my experience in industry, the developers are seldom if ever allowed access to what the client actually wants. That's what the po or product manager/ba are for. This is the reason I have come to loathe software development.

[crispyambulance]

    > The problem with the 10x myth is that it assumes a single dimension of productivity...

There's another problem with "10x": people evolve.

No one starts their career as a 10x-er, juniors are not juniors forever and people take time to find their knowledge, preferences, the right context, employer, coworkers, etc, before they can even discover their "super-powers".

And anyway, all the people I've ever met who could be called "10x" would immediately reject that label and/or buffer it with generous praise of the team in which they work. They would also tell a LONG story of how they got to where they are-- hint: it never starts with being at the top of their game. Instead, it always starts with or involves a lucky-break or a hard situation made better by someone who believed in them.

[scarface74]

If I consider myself even twice as good as average with something, it’s probably time for me to transition to something else and start over.

Right now, for instance, I’m getting into the $cool_kids front end stack and I am barely above the level of “don’t eat the chalk”.

[slavapestov]

I think the number of years in your post is off a bit. In San Francisco, you become a senior engineer within 2 years, and after 5 years you're either expected to go into management, or retire to southeast Asia with your IPO money.

[ergothus]

Your summary is a bit outdated, I believe. While there is definitely a ceiling as the above poster added, the last decade has had a LOT of effort in improving options for non-management IC development. The big companies are realizing there is value in keeping strong technical people in technical roles.

You still have to improve your so-called "soft" skills, improving communication up and down the chain, and it does involve a reduction in actual coding time, but you end up more of a code manager than a person manager.

None of which says there isn't a struggle, but the world is very different than when I had a manager told me I could never expect a decent job if I stayed in coding.