Good... the industry for developers has been slowly moving in a direction that seems to be trying to turn us into glorified auto mechanics. This is unacceptable. Let's keep supply tight!
I'm not sure what this is supposed to mean. My brother is an auto mechanic and the type work he does constantly blows my mind. Diagnostics, transmission/engine rebuilds, you name it; especially with these newer models.
With the exception of a few, there's nothing special about what we do. I don't see how we're any different than "glorified auto mechanics".
You don't really mean this, do you?
That, and our employers are taking 99% of the value we create, when that figure should be closer to 90%
Seriously, it’s not best practices when everyone apply them differently.
While I get the gist of what you're saying, I think building and repairing physical things is different from building and repairing more abstract things.
You'd be surprised how much variation there is in the solution when it comes to autofabrication, and yes there's similar amounts of "figuring it out" that there is in the software world.
Quite frankly the automechanics <-> software engineer analogy is apples to oranges.
Used to be that they could repair every car, but now they are tied to brands because they need certifications and special tools. Not because the manufacturer needed the tools to build the car, but because without them, anyone could repair it.
> we're building systems.
Someone has to maintain them.
There's always been factory repair manuals, and while repairs used to be something that were more common across brands and something more accessible to the weekend wrench turner, that doesn't change that the manufacturer had explicit guidance that was there to follow.
The "specialization" aspect of things from a mechanical standpoint is a by product of additional complexity and advanced proprietary systems. Consumers (and regulators) ask far more of a modern car than what could be delivered with simpler, purely mechanical systems. Whether it's safety, emissions, reliability, or just features, as those evolve and progress, repairs and maintenance get more complicated and involved.
>> We're building systems
> Someone has to maintain them
Software maintenance and vehicle maintenance is fundamentally different. Vehicles have wear items that need replacing (brakes, hoses, tires, etc), consumables that need to be changed (oil, lubricants, belts, coolant), and parts that are subject to mechanical wear. Systems don't have any of those things.
The closest analogs I can think of would be upgrading a dependency or maybe bug fixes. While some bug fixes might be small changes to fix typos or incorrect logic, some bug fixes may be significant enough to necessitate redesign of subsections of the software. You wouldn't expect your mechanic to redesign your car's brake system because you found it wasn't stopping as quickly as you'd like it.
Which they do, but it took years of setting up governance to get people to agree on what the best best practices were. I mean, at that point it’s not really best practices anymore, because that implies that they have a broad adoption.
Also, most developers in America don't make that much more than European developers. It's just that we happen to be willing to pay seasoned developers quite a lot more. Most junior and mid-level developers here don't make much more than $90k, and many of the companies that are willing to pay at least that or more are located in areas where the cost of living makes that salary abysmal.
But the ceiling for top developers in most of the world is below that. Even here in the UK, where salaries are starting to get pushed up a bit, there are still only a few employers who would beat that today, and mostly in places like London where cost of living is also relatively high. Hardly anyone is making the kind of money that you see devs with as little as 5 YOE routinely making with half the companies in SV, even people with multiples of that experience who would be staff/principal level in a big US tech firm.
Except these days it seems the whole of Europe undervalues software engineering.
It's simply that demand is skyrocketing, but we didn't make software substantially easier in the last decades.
Larger teams also ship faster, there's a lot of complexity to enable that collaboration.
Like what? Earlier systems worked if your computer worked. Adding a server is a DRM move and doesn't help the user with reliability - usually the opposite.
My experience is that in most situations larger teams ship slower, precisely because of the collaboration costs you mention. There are ways to reduce the dependencies, but most organizations can't get there.
Most software is complete shit, and we're lucky when the end user doesn't notice too much. As a software engineer, I'm appalled by the average "web app" both in terms of how the product functions and the code making it happen. Accessibility is still a complete afterthought and the documentation on accessibility standards is too confusing.
The only reason many of us are still around is that no one has truly figured out a good replacement for the average software developer yet. The closest we have is things like Wix and Squarespace. The junior and mid level developers of today are ripe for obsolescence and it's a matter of time before someone finally figures out how to give small companies the power of software development without all of the overhead they currently endure.
The world also doesn't need that much software, hence we don't necessarily need more software developers all the time. Software scales with problems to be solved, not with population. Those paying our bills need to figure out just how much of their money they are wasting on what is essentially the same kind of software development that took place 30 years ago.
I think, we didn't scratch the surface of the true demand yet. But, yes, we should get dramatically better in so many ways.
It's only been a few years since developers (outside of these niches) stopped laughing when hearing about sound static type checking, static analysis, model checking, object capabilities, abstract interpretation, message passing APIs, getting rid of NULL, reactive programming, stream programming, let it fail, transactional memory, linear types, etc.
Of course, at the same time, we moved everything to web programming, where everything is broken for different reasons. Research has been studying that for a couple of decades, too, so I figure we should start using more robust paradigms within 10-20 years.
now you're talking about "society," but you were the one who compared them to cogs to begin with, lol.