You may be wondering how coding relates to cars. This isn't about self-driving cars or coding in cars. This is about the art of dealing with complex systems and the shared experiences that somehow bridge programmers and mechanics.

I recently talked to a mechanic as they were working. As they described the problems they face in their job, I realized that it sounded very similar to what I face while programming. The clearest example is that when they take things apart in a car to fix one specific problem, they have to remove perfectly functional pieces to get to the broken part. Then, after they've fixed the problem, lets say by replacing the broken part, they have to put it all back together. While doing this, there is a nonzero chance that putting things back together causes a new problem.

Sound similar? As a programmer, it's near identical to when a bugfix goes wrong. A bug is reported, you go into the code and finagle around to fix it, but then in the process of fixing it, something else breaks. Some people might argue that with well-written code, bug fixes should never impact working parts of a program, but since when we were ever known for having perfectly written code? Even the best written code could have gained an extra dependency that relies on a buggy result from your code, so fixing the bug breaks what it expects.

It's really interesting because I realized that cars and coding are both such complex systems that even professionals barely understand all of after years. We know enough to work well, we understand how these systems react and can use that to do a good job, but there are minor details that will elude us until we need to dive into them. In my case, the mechanic had never worked on the parking break components on a four-wheel drive like mine. He used previous knowledge to predict what would work that's so similar to coding when you dive into a new concept that's related to one you've seen before.

It's even more interesting to me because you can start to decompose cars and coding into more layers that explain this phenomenon. Each has so much variation within different subsets. For example, types of cars will have different ways that their systems work, they're built, and maybe even the tools you use to fix them. Even just the engines will have some similarities in design but differences in other aspects like the number of cylinders they have. This sounds incredibly similar to different coding languages, platforms, frameworks, and more. Running python code within a Linux environment can be equated to having a specific engine in a specific car (notice how I don't know enough about cars to give specifics in this example).

A funny mechanic term I learned was "ever since". It's a joke about customers who will go in, get some work done on their car, and then come in 6 months later and say something like "ever since you worked on my brakes, the engine light has been on". Basically the idea that people who don't know about cars will say "ever since you did this, something completely unrelated has been acting up". It reminds me about how with code, people without the context to understand it often have unreal expectations. Before AI, a very common one was that a large task could be completed within a day. I wouldn't be surprised if the feasibility of certain tasks is overestimated even more with AI now, as people expect anything to be possible if they don't fully understand what actually needs to be done.

I wouldn't be surprised if many of my observations here translate to other skilled work because I think many of these experiences arise from the fact that both programmers and mechanics work with incredibly complex systems. I took it as a reminder that there's always a whole world hiding behind the work someone does, and it's incredibly valuable to find people who have the expertise AND will calmly educate you on it.