[jbverschoor]

Is there Really a difference between welding metal and welding software libraries? Pick the right tool for the job. If you’re wrong, or don’t know how to use your tools / understand the metals, you in for some trouble.

Most programmers think too highly of themselves.

Software projects have the exact same problems as construction jobs, with the main difference liability.

[silisili]

> Is there Really a difference between welding metal and welding software libraries

I'm not sure this is a serious question, but the two have nothing at all in common. Anyone who says otherwise either has never welded or never used a computer.

[whstl]

Those "software vs physical stuff" discussions remind me of modern vs old-school music production. Not the final product (the music) but the production process in itself.

One goes "commit to nothing, you can always change it later, hundreds of convenient tools at hand, move super quick but you don't 'finish' it, you just 'abandon' it".

The other is "commit early, make the best you can since changing anything is expensive, not too many tools, slap the roof and proclaim it good enough, ship it".

The difference is mostly due to destructive vs non-destructive workflows.

I'm not really saying one is better than the other, or even that the difficulty is different... but process-wise those things are miles apart.

[jrflowers]

>Is there Really a difference between welding metal and welding software libraries?

Yes.

[jbverschoor]

I dunno. Rails welds very good to metal. So does ML on Apple Metal

[fc417fc802]

> with the main difference liability

I mostly agree but dimensionality is also a huge one. Being constrained to 3 dimensions and standard building materials really limits the problem space. It's why you can probably figure out how to build a structure where all the entrances lock but you definitely shouldn't roll your own crypto.

[benhurmarcel]

I find that physical work is different but not simpler than programming. Yes there are only 3 dimensions, but there are lots of layers of important "details" that you can't ignore, whereas digital work only deals with "ideal" objects, which simplifies a lot.

[fc417fc802]

> digital work only deals with "ideal" objects, which simplifies a lot

I'm not clear what you mean by that. Most of the library code I deal with is far from ideal (IMO). Even most of the things I implement aren't ideal because either I'm interacting with the real world or even if not I don't want to spend unlimited time fully generalizing it.

As a concrete example, absolutely nothing that touches floating point arithmetic is "ideal" in any sense of the word.

[jbverschoor]

You can swap out or improve your library at any stage.

That’s kind of hard with a foundation, or other materials

[jbverschoor]

Something went wrong. Oh, just remove and fix the underlying problem from weeks ago.

No git, version control, copy paste.

You need to a bigger crane? Ouch.

Rainy season causes some delay? Welcome to the domino effect.

Supply chain issues? Oh well.. you better have good contracts.

Most applications are a 2D problem space: carthesian products.

[fc417fc802]

Scheduling, staffing, and tooling constraints all exist in the software world as well. If you're going to extend to the entire job site then you'll need to extend to the entire dev team plus associated management.

I don't immediately see an analogy to supply chain issues but then I hadn't intended this as a pissing contest to begin with.

It's interesting to me that I'm getting defensive replies when all I pointed out was the increased dimensionality of the problem space when writing code versus assembling a physical product. I don't think that observation can realistically be contested.