The main problem I see is that the people who get those leadership positions are usually the ones who like to overcomplicate/over-abstract things a lot.
I never wanted to become a team lead or staff engineer but the older I get the more I feel like I should.
And the worst engineers are the ones who _really_ like specific things, like really liking a certain language or a certain library or a certain tool.
It baffles me because I usually have at least a mild dislike about all tech I work with (including systems of my own design), I think it keeps me honest about the flaws of the systems I work with.
I don’t get why our profession is so prone to this. From what I’ve seen, actual engineers and people working in the trades have a “pick the right tool for the job” approach. At least the ones that haven’t been co-opted into becoming vendors for some large company.
Because software engineering isn't engineering, isn't taught like engineering, doesn't come with the responsibility that engineers have, doesn't come with the barriers that engineering does, refuses to take itself seriously as an engineering discipline, refuses to organize in any way that would be required if we WANTED to enforce engineering best practices, etc.
I don't understand what you DON'T get? Our profession is full of incompetent people that have done nothing but make things worse everywhere they go, and they all make more money than I do, and some of them have been deified as thought leaders.
From what I hear in other engineering industries (software engineering is engineering) it is more like people just stick with what they know because it can take 5-50 years for a new technique/tool that is significantly better to show up.
You can literally just specialize in something and just do that for the rest of your career. In fact they have the opposite problem, sticking with very old "proven" techniques despite innovation happening.
Yeah. Structural engineering is probably a good example of this. For any one component (a beam, an anchor, etc.) There might be a dozen or more solutions that would work. The engineer of record (the one in responsible charge) absolutely SHOULD pick the one they are most familiar with. (Different options may have totally different analysis methods) This reduces the cognitive overhead allowing them to focus on other aspects of the design, and reduces the likelihood of making analysis errors.
The incentives are not to grab the latest thing because it's 5% "better" or to pick the shiny new thing because its more interesting. Instead, the engineer of record thinks to themself: "gosh if this fails on a snowy day and kills an assembly of school children, I'm personally liable for it. I've got a lot of experience in the design, construction and verification of this technology, that's the one I'm going to choose." Only when a new technology comes along that is MUCH better will they consider using it. Some may call this an excessively conservative approach, but failures in this regard are very rare as a result.
Programming is basically expressing your thoughts in extreme detail. The medium you do it through matters to you. Very few other professions are encoding their actual thoughts.
Imagine asking a writer to switch dialects. "It's the same thing, but just Old English." While some would find it fun, if you randomly swapped out dialects for each process I bet authors would get really tired of it really quickly, especially once they figure out which ones jobs with their natural thought process.
I am an amateur developer (my own stuff and open source) and I always pick the same stack when writing something. This is because I found the optimal, third-best stack that pretty much fits everywhere with minimal friction.
It is not optimized. It is not the fastest. But it works everytime.
This is akin to using the arrow library in Python whenever I have to do the slightest date whatever. Display a date? arrow. Manipulate a date? arrow. Store a date? ISO. Yes this is a dependency, yes, there are edge cases but it mostly works - certainly better if I had to understand dumb vs full dates etc.
Unfortunately I am a curious and excited person and I keep changing this "ideal stack" twice a year but still.
Lack of official standards, lack of certifications (not everywhere thankfully), and the relative youth of software as a profession all lead to a bit of a "will wild west" industry. I don't fault the developers themselves mind you, but it will take time (probably a few decades) for things to settle.
I never wanted to become a team lead or staff engineer but the older I get the more I feel like I should.
And the worst engineers are the ones who _really_ like specific things, like really liking a certain language or a certain library or a certain tool.
It baffles me because I usually have at least a mild dislike about all tech I work with (including systems of my own design), I think it keeps me honest about the flaws of the systems I work with.