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!
>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".
I wouldn't be so fast to say there is nothing special about what we do. It may seem that way because we are in it day in and day out...but in the same way that I am fascinated by the work that others outside of my industry do(farmers, mechanics, small business operators)...they are fascinated and often dumbfounded by what I do(and I am no rocket scientist).
Auto mechanics are in much greater supply than and make a much smaller salary than software engineers, and repair/diagnostic work is much different than the design work that seems to be less and less of my job. We're more and more in a place where we're just stringing together other people's rent-seeking SaaS services and putting up with all the resulting bullshit, rather than actively making our lives as developers easier by making stuff that results in less work.
That, and our employers are taking 99% of the value we create, when that figure should be closer to 90%
Are the stakes really lower? A simple brake job gone wrong can literally kill people. I can't remember the last time I miscalculated profit/loss for a client where the result was a fiery death.
Maybe a better way to say it is, software development usually has a bigger financial consequence. And that consequence scales along with the skill and judgment of the developer.
Auto mechanics at least have the common sense to repair things the same way, so that the next mechanic can work on the next fix in a few hours instead of first having to spend 10 weeks getting into the “mindset” of the previous mechanic.
Seriously, it’s not best practices when everyone apply them differently.
...but software engineers are not "repairing" things, we're building systems. Mechanics repair things in a similar way because there's literally repair manuals from the manufacturer that tell them how to repair your vehicle because _the manufacturer_ has thought of how to repair 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.
I mean, mechanics aren’t exactly happy that it’s become like that though.
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.
My overall point was how the roll of a mechanic is not really the right comparison to a software engineer.
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.
There are many, many ways to write even a small piece of code/functionality and small sub-optimal choices can lead to tons of entropy down the road. To compound this, almost every solution is going to be different, and there just isn't a '300 Page Manual on Servicing Your Jaguar' equivalent for every possible software solution.
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.
It’s not even that though. We have open source projects with multiple private companies are supposed to work together.
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.
"Glorified auto mechanic" is exactly how I'd describe how software development is viewed in Europe. There is a much bigger emphasis on "just" buying software from Microsoft and SAP to "solve" problems.
It reminds me of the ancient joke about how in Germany if you tell your neighbour you are an engineer he will introduce you to his daughter, in the UK he will ask you to fix his microwave.
Except these days it seems the whole of Europe undervalues software engineering.
It's not so much different in America other than that we get paid more. Most companies "hire some geeks" to solve what they see as just a different kind of plumbing without physical pipes. The average person doesn't respect software engineering so it's no surprise that management doesn't either. So that extra pay we get is mainly to compensate for the mental abuse we're guaranteed to endure.
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.
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
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.
We also didn't improve our standards in any meaningful way.
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.
The scary part is that researchers have been working on making software more reliable for the past ~50 years, with really good results. Industry? Nah, except for a few niche cases, we've been adopting a worse is better approach, thank you very much.
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.
The systems we can build today with a small team are much more complicated than what we could do ten years ago. It's just that we also somehow managed to solve essentially the same problems we solved ten years ago with much more complex software.
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.
> handle faults in ways that were impossible in the past
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.
If anything we've made it harder. You want a senior engineer who also can run k8s and is well versed in a multitude of languages. Don't get me started on tooling, especially in the JS landscape. I'm amazed engineers pick it up without having grown up with it.
Clearly have not been abused by a company wanting you to do 5x as much work as one developer should. We need many more software engineers and many more innovations in the industry so software engineers don't suffer from chronic burnout and being underpaid.
The skill required to be an auto mechanics is hugely underrated by people that doesn't know how to work with cars. They are one of the few craftsmen jobs still left.
The issue isn't whether auto mechanic satisfies some platonic ideal of a professional, the issue is how one is treated by society or by their employers. I know little of the experience of auto mechanics, but I don't think its a stretch to say that society treats them as interchangeable cogs moreso than, say, doctors or lawyers.
Sure, you can see it that way. Or you can see it as attempting to make a different point casually without having to avoid everyone's personal landmines and bugaboos.
My comment was in response to you apparently not understanding the distinction being drawn by the OP between software development as a relatively high status profession and the relatively low status auto mechanic career. The OP was alluding to the waning status of being a software dev since the 2000-2010 heyday. Injecting your opinion regarding my take on the status of the auto mechanic profession was entirely unwarranted.
I understand the comment - my point was that I don't consider being an auto mechanic to be a low status, or shameful profession to begin with - hence my original reply to begin with. I believe it is you who did not understand the point of my original comment. Oh well.
Oh, so you were in fact feigning ignorance as some kind of bad Socratic method? I figured as much, but I like to give people the benefit of the doubt. It's also a mistake to assume a casual example to make an entirely unrelated point is representative of someones views.
