7 ms·

I wish I could upvote this multiple times. You go into any experienced woodworker’s shop, you can divide it into maybe 20% of the tools that see the vast major

I wish I could upvote this multiple times. You go into any experienced woodworker’s shop, you can divide it into maybe 20% of the tools that see the vast majority of the action—table saws, band saws, milling machines, proper hammers. But then there is a halo of 60% or more of the things there are little helpful things—doodads, mallets, jigs, often even shelving and work surfaces—such that she uses a bunch of these on any build she undertakes, and she made them herself. “Why would I stumble around with someone else's mallet when it’s about the same cost and about half a day’s work to machine my own mallet down in a router that has exactly the weight and shape that I like it to have? Pays for itself.” We are so far from this ideal. All of our software breaks because we imported left-pad and somebody unpublished left-pad. Wasn't even a world changing perfectly V8-on-x64-tuned performant version of left-pad, but we gotta “not reinvent the wheel.” I don't think we do it for no reason, there is something about software itself right now that is amateurish. We’re still writing subroutines working on data structures; our brains are FORTRAN even if we call it Java, and whatever that is makes it really hard to decouple the tools that we are using to build software from the final outcome that has been built. The woodworker has a sense of the “shape” of the artifact, we routinely build the equivalent of gorgeous wooden tables that start spewing garbage onto their shiny surfaces after three weeks unattended, “oh, I didn’t realize that the built-in trash chutes could get clogged.” Wait—what? “Yeah, we allocate more wood at the bottom of the table to make up for the wood that we remove at the top of the table every night so that the surface is always clean.” Your user doesn't clean the table? “Hahaha you’re silly, users could not possibly have the technical knowledge to keep anything clean, they are not trained in sponges, and I especially could not trust the with something as beautiful and delicate as this table.” The problem has a beautiful sort of fractal quality to it, every zoom-in is more WTF.

abiogenesis 6y ago
Obligatory: https://xkcd.com/2347/ https://xkcd.com/2347/
411111111111111 6y ago
"don't reinvent the wheel" is specifically for projects which other people will be forced to maintain. You can reinvent the wheel as many times you want. If you however do that at work, your colleagues and your replacement after you left the job likely won't think too kindly of you.
- jraph 6y ago
  true, but it is a balance. If you import packages for things that can be done in one small function, you force them a lot of dependencies, which can be worse.
- tutfbhuf 6y ago
  I think that developers, albeit knowing about "don't reinvent the wheel", will do it nonetheless. I think psychological factors play a role here, like the "IKEA effect": > The IKEA effect is a cognitive bias in which consumers place a disproportionately high value on products they partially created. The name refers to Swedish manufacturer and furniture retailer IKEA, which sells many items of furniture that require assembly. A 2011 study found that subjects were willing to pay 63% more for furniture they had assembled themselves, than for equivalent pre-assembled items. https://en.wikipedia.org/wiki/IKEA_effect https://en.wikipedia.org/wiki/IKEA_effect I think this effect also applies to developers. They tend to value self-written applications subconsciously higher than "pre-assembled" applications.
  - vbezhenar 6y ago
    I value self-written applications consciously. Because I know everything about them, I can quickly change everything, adapt it as I need, fix any issues. That's not true for other applications and might be impossible for proprietary ones. I don't think that this is the same about Ikea, though. If I bought Ikea table, I can't really adapt it, unless I'm advanced woodsman with proper tools. If I'm just ordinary guy with screwdriver, I can just follow the script to build that table. I think that Ikea analogue is someone building his vim environment from other's plugins following guides. He does not know C, so he can't hack vim, he does not know vim configuration language, so he can't hack plugins.
    - tutfbhuf 6y ago
      As a developer you will always use tools and rely on applications others have written. If you write your program in C, then you use a C compiler like gcc and most developers have not read the whole source code of gcc. Same is true for the C library you use, including standard library, you rely on others developers code you have never seen. Therefore, I think the IKEA effect holds true in software development, because you rely on "pre-assembled" items, but I agree that you have much larger degree or freedom on how you build your application in e.g. C compared to a IKEA build. Maybe, this higher degree of freedom even strengthens the effect.
Thorentis 6y ago
Is affirmative action with pronouns a thing now?
pushrax 6y ago
A woodworker would have more off the shelf tools if they were equivalently cheap/good/fast/efficient as a custom tool. Physical objects can’t be so freely copied as a software library. I do agree fully that programmers should strive to understand every layer, and building your own tools is a great way to get experience that helps with that. Yes, left-pad is unnecessarily granular abstraction. However, in each domain, we inevitably depend on other software, and that breadth of that graph is part of the reason for why you can accomplish so much with so few people writing software.
fifticon 6y ago
To be honest, whenever I put up a new table in our house to get some fresh cleared working surface, within a matter of months, said table has accumulated a lot of clutter, spurring me to soon put up another table to get some cleared working space. If only there were some way to return tables to that uncluttered state.
molf 6y ago
All analogies fall down at some point, but the woodworker analogy you make is just not correct, in my opinion. The problem is that many things a developer considers tools (as in: "the best tool for the job") are actually components. The equivalent of a woodworker's tool for a software developer would be an editor. Only you or your team might care about which particular brand of sawing machine or editor you use. And they are not an integral part of the end result. A component for a woodworker would be a hinge or drawer rails. You would probably not appreciate it if your woodworker uses hinges that they made themselves. They are not worth the time to build. They're probably not very reliable. And if they fail they might not be easily replaced or repaired except by the person that made them. So you would only use custom components if the part you need is otherwise unavailable or does not meet specific needs. Are you a woodworker and making a cabinet for yourself? Go ahead and make your own hinges, but for paid projects you probably should rely on standard components as much as possible; only doing custom woodwork or software engineering where it adds value.
- RobertKerans 6y ago
  I think the analogy is tortuous, but parent has a fair point -- it's just that left pad is maybe a bad example. If we were to go with components over tools, I'd say very simple building blocks are very useful as components. It's more complex dependencies where the issue lies. To absolutely torture the analogy: say you have a general hinge that you can attach to any door. And that's fantastic, but it's a lot more complex than it needs to be (it being generalised necessitates this) and it isn't actually completely optimal in most cases (it just works ok, ish). You can use Super Hinge on all your paid projects, and it will work, it's just that it's often better to make a hinge that exactly fits the required specifications.
- RobertKerans 6y ago
  Edit: dropped connection, double post
- TheOtherHobbes 6y ago
  For software you're more likely to get a hinge from CarpentryHub. Hinges - like everything else on CarpentryHub - are either in a state of permanent development or abandoned. So you design your project for Hinge 13.2, but then you come back a month later - just before you open your Etsy store - and discover that Hinge x.n has now become HingeOS, which is breaking change. It also has its own HingeAPI, which is poorly documented, somewhere. You were used to Hinge's ScrewHole 5.3. But that's now buried inside HingeAPI, which calculates your project budget and lifetime carbon footprint for you, but no longer accepts external screwhole positions, because it works its own values from the complex project specification you have to supply - defined in DirkLang, which is a hot new carpentry specification language only ten people know, and replaces HammerLang, which was fifty five years old and very popular but had a lot of frankly questionable design choices. And the values HingeAPI returns aren't mutable, because mutability is bad practice.

abiogenesis 6y ago

Obligatory: https://xkcd.com/2347/ https://xkcd.com/2347/

411111111111111 6y ago

"don't reinvent the wheel" is specifically for projects which other people will be forced to maintain. You can reinvent the wheel as many times you want. If you however do that at work, your colleagues and your replacement after you left the job likely won't think too kindly of you.

jraph 6y ago
true, but it is a balance. If you import packages for things that can be done in one small function, you force them a lot of dependencies, which can be worse.
tutfbhuf 6y ago
I think that developers, albeit knowing about "don't reinvent the wheel", will do it nonetheless. I think psychological factors play a role here, like the "IKEA effect": > The IKEA effect is a cognitive bias in which consumers place a disproportionately high value on products they partially created. The name refers to Swedish manufacturer and furniture retailer IKEA, which sells many items of furniture that require assembly. A 2011 study found that subjects were willing to pay 63% more for furniture they had assembled themselves, than for equivalent pre-assembled items. https://en.wikipedia.org/wiki/IKEA_effect https://en.wikipedia.org/wiki/IKEA_effect I think this effect also applies to developers. They tend to value self-written applications subconsciously higher than "pre-assembled" applications.
- vbezhenar 6y ago
  I value self-written applications consciously. Because I know everything about them, I can quickly change everything, adapt it as I need, fix any issues. That's not true for other applications and might be impossible for proprietary ones. I don't think that this is the same about Ikea, though. If I bought Ikea table, I can't really adapt it, unless I'm advanced woodsman with proper tools. If I'm just ordinary guy with screwdriver, I can just follow the script to build that table. I think that Ikea analogue is someone building his vim environment from other's plugins following guides. He does not know C, so he can't hack vim, he does not know vim configuration language, so he can't hack plugins.
  - tutfbhuf 6y ago
    As a developer you will always use tools and rely on applications others have written. If you write your program in C, then you use a C compiler like gcc and most developers have not read the whole source code of gcc. Same is true for the C library you use, including standard library, you rely on others developers code you have never seen. Therefore, I think the IKEA effect holds true in software development, because you rely on "pre-assembled" items, but I agree that you have much larger degree or freedom on how you build your application in e.g. C compared to a IKEA build. Maybe, this higher degree of freedom even strengthens the effect.

Thorentis 6y ago

Is affirmative action with pronouns a thing now?

pushrax 6y ago

A woodworker would have more off the shelf tools if they were equivalently cheap/good/fast/efficient as a custom tool. Physical objects can’t be so freely copied as a software library. I do agree fully that programmers should strive to understand every layer, and building your own tools is a great way to get experience that helps with that. Yes, left-pad is unnecessarily granular abstraction. However, in each domain, we inevitably depend on other software, and that breadth of that graph is part of the reason for why you can accomplish so much with so few people writing software.

fifticon 6y ago

To be honest, whenever I put up a new table in our house to get some fresh cleared working surface, within a matter of months, said table has accumulated a lot of clutter, spurring me to soon put up another table to get some cleared working space. If only there were some way to return tables to that uncluttered state.

molf 6y ago

All analogies fall down at some point, but the woodworker analogy you make is just not correct, in my opinion. The problem is that many things a developer considers tools (as in: "the best tool for the job") are actually components. The equivalent of a woodworker's tool for a software developer would be an editor. Only you or your team might care about which particular brand of sawing machine or editor you use. And they are not an integral part of the end result. A component for a woodworker would be a hinge or drawer rails. You would probably not appreciate it if your woodworker uses hinges that they made themselves. They are not worth the time to build. They're probably not very reliable. And if they fail they might not be easily replaced or repaired except by the person that made them. So you would only use custom components if the part you need is otherwise unavailable or does not meet specific needs. Are you a woodworker and making a cabinet for yourself? Go ahead and make your own hinges, but for paid projects you probably should rely on standard components as much as possible; only doing custom woodwork or software engineering where it adds value.

RobertKerans 6y ago
I think the analogy is tortuous, but parent has a fair point -- it's just that left pad is maybe a bad example. If we were to go with components over tools, I'd say very simple building blocks are very useful as components. It's more complex dependencies where the issue lies. To absolutely torture the analogy: say you have a general hinge that you can attach to any door. And that's fantastic, but it's a lot more complex than it needs to be (it being generalised necessitates this) and it isn't actually completely optimal in most cases (it just works ok, ish). You can use Super Hinge on all your paid projects, and it will work, it's just that it's often better to make a hinge that exactly fits the required specifications.
RobertKerans 6y ago
Edit: dropped connection, double post
TheOtherHobbes 6y ago
For software you're more likely to get a hinge from CarpentryHub. Hinges - like everything else on CarpentryHub - are either in a state of permanent development or abandoned. So you design your project for Hinge 13.2, but then you come back a month later - just before you open your Etsy store - and discover that Hinge x.n has now become HingeOS, which is breaking change. It also has its own HingeAPI, which is poorly documented, somewhere. You were used to Hinge's ScrewHole 5.3. But that's now buried inside HingeAPI, which calculates your project budget and lifetime carbon footprint for you, but no longer accepts external screwhole positions, because it works its own values from the complex project specification you have to supply - defined in DirkLang, which is a hot new carpentry specification language only ten people know, and replaces HammerLang, which was fifty five years old and very popular but had a lot of frankly questionable design choices. And the values HingeAPI returns aren't mutable, because mutability is bad practice.