[ubernostrum]

I find it amusing that you liked an article which argued against "X years' experience" as a way to define a senior developer, but your disagreement is that you want to insist on "X years' experience" as a definition.

And as others have pointed out, it's not "technical ability" that is being devalued; more likely it's that a particular subset of technical knowledge is devalued -- perhaps appropriately for the situation -- but it just happens to be a subset that you personally feel is extremely important (and I might well disagree with you on whether that subset, or any specific subset, is actually essential).

And that's without getting into the irony of how much we as an industry approve of successful high school or college dropouts who learn to code well without completing a formal CS degree, but then turn around and, frankly, shit on the idea of actually hiring any such people because it'd require lowering our technical standards.

[lliamander]

I can't speak for the parent comment, but I will say that while there are plenty of developers with "X years experience" who are not operating at a senior level, it is unrealistic to expect that someone will be operating at senior level without those years of experience.

I liked their ideas around direction given vs. direction required. I liked their distrust of the notion of "cultural fit". I liked that they identified leadership and connectedness as distinct skills, and that a senior developer has both technical skills and at least one of the other two (leadership or connectedness).

But true technical expertise requires the ability to make holistic, contextual decisions. That kind of stuff takes experience shipping multiple products, full-stack exposure to at least one or two mature software stacks, and awareness of the historical context of how technology has changed. That is, it's not so much about "years of experience" as it is "diversity and quality of experiences".

[ubernostrum]

This is the kind of thing that bugs me, though, this sort of software-engineer exceptionalism. We like to pretend that somehow we're the only ones who have complex projects with tight deadlines and changing requirements. We like to pretend that if you haven't been coding since you were in diapers you can't possibly have enough context or experience or sense of the history of tech to make good decisions. We like to pretend that somehow the only people qualified to be software engineers are the kinds of people who've traditionally been software engineers.

But that's just bullshit. People with CS degrees from big-name schools and years of experience still do a shit job of managing software projects. They still do a shit job of picking tech stacks. Our literature, such as it is, is positively overflowing with stories demonstrating just how fundamentally horrifically awfully bad we are at this stuff. Often, they're bad at this stuff precisely because of the background that's supposed to make them exceptionally qualified; they're bad at it because they got extensive training in how to coordinate a dozen threads in an application but precisely zero in how to coordinate a dozen people on a team. They're bad at it because they got a bunch of ideology about theoretical purity shoveled into their heads in college instead of a bunch of pragmatism. They're bad at it because in the easy-VC-money days nobody cared what your tech stack was, as long as you picked something shiny and new. They're bad at it because they literally do not have the relevant background to be acting in a senior-engineer role.

But what about someone who gets tired of being, say, a lawyer and decides to do a coding bootcamp? They come in from a field where research, shifting requirements, teamwork and pragmatic approaches to dealing with a client's wants are all front-and-center required skills. The same is true for plenty of professions: we can take in somebody with the project-management skills and teach them about tech and coding. We're good at teaching tech and coding. What's hard is taking the person who has only ever learned tech and coding, and teaching them all the other skills.

[lliamander]

I'm going to make myself very plain: For anyone who intends to pursue a technical/engineering career path, as opposed to switching to the managerial/entrepreneurial path, you're going to need to master some very difficult technical subjects. The point of calling a profession "engineering" implies that there is quite a bit of depth to the technical side. Therefore, calling someone a "senior" engineer implies that they have a good grasp of that deep skill-set.

> This is the kind of thing that bugs me, though, this sort of software-engineer exceptionalism. We like to pretend that somehow we're the only ones who have complex projects with tight deadlines and changing requirements.

In other news, the lead civil engineer on the local levy project has only two years experience and their only training was an associates degree in CAD, but don't worry because they used to be a lawyer and so they know all about "shifting requirements, teamwork and pragmatic approaches to dealing with a client's wants".

>They're bad at it because they got a bunch of ideology about theoretical purity shoveled into their heads in college instead of a bunch of pragmatism.

Others have addressed this better than I can[0].

[0]http://weblog.raganwald.com/2008/01/no-disrespect.html

[ubernostrum]

Others have addressed this better than I can[0].

And the very first comment on that post is a better rebuttal than I have time to write up:

But working as a consultant to a lot of big companies (and a lot of small ones) over the past few years, I don't think the degree matters so much. The thing that matters to the exclusion of everything else is which side you're on: are you working to make something great or are you collecting a paycheck and trying to stay out of the line of fire?

A CS degree, X years of experience in tech, writing PDP-11 assembly in your diapers, etc. are terrible indicators of which side of that divide someone will be on.