3 ms·

...but software engineers are not "repairing" things, we're building systems. Mechanics repair things in a similar way because there's literally repair manuals

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

moksly 5y ago
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. > we're building systems. Someone has to maintain them.
- polygotdomain 5y ago
  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.

moksly 5y ago

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. > we're building systems. Someone has to maintain them.

polygotdomain 5y ago
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.