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.
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.
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.
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.