3 ms·

Imagine any other profession needing to inspect, rebuild, and fix the tools that they are given to do their job.

by bmitc 3y ago

rootw0rm 3y ago
that's actually, um...common? i just had to repair an electric jackhammer last week. i worked in a machine shop for a large well drilling company not long ago, and not only did we create/repair tools for the company, but obviously had to keep our mills and lathes and cranes, etc. in good working condition.
- bmitc 3y ago
  It's not common in the same sense. First of all, tools are very different from software products. And there is never the same level of analogy that one has to do in software. Imagine buying a hammer, that hammer not working, the hammer's design being so complicated that it's impossible to understand or mend, and then having to design and build your own hammer, and then putting up with that situation over and over again and accepting that as the status quo. That would be the correct analogy.
  - nik_0_0 3y ago
    I'll agree wholeheartedly that the analogy needs some work. Tools are different - we have our literal physical tools that we don't generally dive into (keyboards, mice), we have tools that are maybe more battle tested and rarely examined (cat, grep, find). We have do have tools like the hammer - there is one design, everyone more or less agrees on it. There is still high quality and low quality, but it has one job. We have tools like a bulldozer - complex, numerous parts, requires constant maintenance, closed source. As the parent said - it is not uncommon to have to maintain old equipment, as well as design new tools as new requirements pop up. Sure, our rust is a little bit different - time wears on software in a different way. Use wears on software differently. (Changing product requirements leading to a new tool is probably common.) The maintenance may be trickier - but I'm sure changing components on a tool when a certain component is no longer available is not easy, thats where shim layer comes from!
NoPicklez 3y ago
I feel like this is quite common but it depends on the optics of situation. A mine site usually fixes its own tools used to do their job, they usually fixed things they've purchased to use that are broken or become broken, is that not the same?
- bmitc 3y ago
  I highly doubt that a mining operation finds it acceptable that tools that they have purchased show up broken, undocumented, and unsupported.
  - worthless-trash 3y ago
    You'd be surprised how common it is.
    - bmitc 3y ago
      I've worked in many industries, and none of them put up with the poor state of tools and treat it as a given like the software industry does.
      - NoPicklez 3y ago
        Hmm again I think mining are pretty good at making do with the poor tools they have Very different situation I've also found that the software industry obsesses over tools more than any other industry
  - NoPicklez 3y ago
    Your job as a developer is to write code and piece code together to make your life easier. That includes taking the work that others have done and make it work to suit your code base. On a mine site, the job is to mine and process minerals. That includes engineering a mine using products that eventually fail over time and need fixing. As part of that process an automotive electrician may need to fix the electronics on a vehicle that have become faulty or damaged. Mechanics and engineers need to inspect, rebuild, and fix the tools they are given to do their job. The difference is that yours may not work up front, whereas these tools need maintenance over time.
kortex 3y ago
Have you met farmers? They will readily tear apart their equipment to fix an issue or modify the tool to make them more ergonomic. This trend of massive multi-million dollar John Deere combine harvesters with DRM widgets that you need to take to a specialized tech to get fixed, is a relatively modern one, and one detested by virtually every farmer. This was and is quite common in any blue-collar field where works don't always have the money or time for a brand new jawn every time something goes wrong. I love estate/yard/garage/barn sales and going through the tools and reading the tales they tell from their wear patterns, field repairs, revisions, and hacks from their owner. Case in point, here's a tool which has gotten multiple leases on life through modifications. https://youtube.com/watch?v=oTA513ttrbQ https://youtube.com/watch?v=oTA513ttrbQ
- bmitc 3y ago
  I worked on a farm. I think the things you're bringing up are still subtlely different. Modifying something you can see and touch for some unintended purpose versus modifying some piece of software because it doesn't work are miles apart from each other. For example, I have a graphics project where screen tearing suddenly started appearing although my code didn't change, and the tearing wasn't there before. Is the issue in Skia, OpenGL, the graphics driver, the Intel or NVidia GPU, or the OS? Or is it some latent issue in my code that started showing up because of a change in these dependencies? Or is it some other complex interaction between multiple dependencies? I couldn't possibly know, and I actually don't think there is anybody that actually knows. And there is zero chance I could ever figure it out. I mean, it at least appears it was a driver issue as after some updates and a reboot it just went away, but there is zero insight into why or what actually made it go away. If I modify a plow because some part as originally designed was flaky and constantly broke, you usually know to a pretty good degree why your fix works. In software, the abstractions are such that it is practically impossible atbtimes to understand.
  - kortex 3y ago
    That to me sounds like a difference of degree or heap problem, rather than a categorically different condition. Sure, welding back on a hardpoint that broke off a plow is concrete and obvious (maybe that's analogous to fixing a broken dependency that got renamed), but there are other fixes that definitely fall under "I don't know why it works but it works". I've had electrical gremlins and fixed them by grounding something that looked like it ought to be grounded, and was grounded when I tested for continuity, but nonetheless was acting floaty. It was probably a loose connection elsewhere in the system, but I didn't know that for sure, nor do I even know that it was the problem in the first place. Software definitely reaches insane depths of complexity, but again, if you can dig down and understand the abstraction well enough to attempt a fix, and the problem goes away, isn't that good enough? The real difference is mechanical systems typically only have a few layers of abstraction, while software has dozens to thousands of layers of abstraction.

Imagine any other profession needing to inspect, rebuild, and fix the tools that they are given to do their job.

by bmitc 3y ago

Imagine any other profession needing to inspect, rebuild, and fix the tools that they are given to do their job.

that's actually, um...common? i just had to repair an electric jackhammer last week. i worked in a machine shop for a large well drilling company not long ago, and not only did we create/repair tools for the company, but obviously had to keep our mills and lathes and cranes, etc. in good working condition.

bmitc 3y ago
It's not common in the same sense. First of all, tools are very different from software products. And there is never the same level of analogy that one has to do in software. Imagine buying a hammer, that hammer not working, the hammer's design being so complicated that it's impossible to understand or mend, and then having to design and build your own hammer, and then putting up with that situation over and over again and accepting that as the status quo. That would be the correct analogy.
- nik_0_0 3y ago
  I'll agree wholeheartedly that the analogy needs some work. Tools are different - we have our literal physical tools that we don't generally dive into (keyboards, mice), we have tools that are maybe more battle tested and rarely examined (cat, grep, find). We have do have tools like the hammer - there is one design, everyone more or less agrees on it. There is still high quality and low quality, but it has one job. We have tools like a bulldozer - complex, numerous parts, requires constant maintenance, closed source. As the parent said - it is not uncommon to have to maintain old equipment, as well as design new tools as new requirements pop up. Sure, our rust is a little bit different - time wears on software in a different way. Use wears on software differently. (Changing product requirements leading to a new tool is probably common.) The maintenance may be trickier - but I'm sure changing components on a tool when a certain component is no longer available is not easy, thats where shim layer comes from!

NoPicklez 3y ago

I feel like this is quite common but it depends on the optics of situation. A mine site usually fixes its own tools used to do their job, they usually fixed things they've purchased to use that are broken or become broken, is that not the same?

bmitc 3y ago
I highly doubt that a mining operation finds it acceptable that tools that they have purchased show up broken, undocumented, and unsupported.
- worthless-trash 3y ago
  You'd be surprised how common it is.
  - bmitc 3y ago
    I've worked in many industries, and none of them put up with the poor state of tools and treat it as a given like the software industry does.
    - NoPicklez 3y ago
      Hmm again I think mining are pretty good at making do with the poor tools they have Very different situation I've also found that the software industry obsesses over tools more than any other industry
- NoPicklez 3y ago
  Your job as a developer is to write code and piece code together to make your life easier. That includes taking the work that others have done and make it work to suit your code base. On a mine site, the job is to mine and process minerals. That includes engineering a mine using products that eventually fail over time and need fixing. As part of that process an automotive electrician may need to fix the electronics on a vehicle that have become faulty or damaged. Mechanics and engineers need to inspect, rebuild, and fix the tools they are given to do their job. The difference is that yours may not work up front, whereas these tools need maintenance over time.

kortex 3y ago

Have you met farmers? They will readily tear apart their equipment to fix an issue or modify the tool to make them more ergonomic. This trend of massive multi-million dollar John Deere combine harvesters with DRM widgets that you need to take to a specialized tech to get fixed, is a relatively modern one, and one detested by virtually every farmer. This was and is quite common in any blue-collar field where works don't always have the money or time for a brand new jawn every time something goes wrong. I love estate/yard/garage/barn sales and going through the tools and reading the tales they tell from their wear patterns, field repairs, revisions, and hacks from their owner. Case in point, here's a tool which has gotten multiple leases on life through modifications. https://youtube.com/watch?v=oTA513ttrbQ https://youtube.com/watch?v=oTA513ttrbQ

bmitc 3y ago
I worked on a farm. I think the things you're bringing up are still subtlely different. Modifying something you can see and touch for some unintended purpose versus modifying some piece of software because it doesn't work are miles apart from each other. For example, I have a graphics project where screen tearing suddenly started appearing although my code didn't change, and the tearing wasn't there before. Is the issue in Skia, OpenGL, the graphics driver, the Intel or NVidia GPU, or the OS? Or is it some latent issue in my code that started showing up because of a change in these dependencies? Or is it some other complex interaction between multiple dependencies? I couldn't possibly know, and I actually don't think there is anybody that actually knows. And there is zero chance I could ever figure it out. I mean, it at least appears it was a driver issue as after some updates and a reboot it just went away, but there is zero insight into why or what actually made it go away. If I modify a plow because some part as originally designed was flaky and constantly broke, you usually know to a pretty good degree why your fix works. In software, the abstractions are such that it is practically impossible atbtimes to understand.
- kortex 3y ago
  That to me sounds like a difference of degree or heap problem, rather than a categorically different condition. Sure, welding back on a hardpoint that broke off a plow is concrete and obvious (maybe that's analogous to fixing a broken dependency that got renamed), but there are other fixes that definitely fall under "I don't know why it works but it works". I've had electrical gremlins and fixed them by grounding something that looked like it ought to be grounded, and was grounded when I tested for continuity, but nonetheless was acting floaty. It was probably a loose connection elsewhere in the system, but I didn't know that for sure, nor do I even know that it was the problem in the first place. Software definitely reaches insane depths of complexity, but again, if you can dig down and understand the abstraction well enough to attempt a fix, and the problem goes away, isn't that good enough? The real difference is mechanical systems typically only have a few layers of abstraction, while software has dozens to thousands of layers of abstraction.