Comment by molf | Hacker News Reader

Comment by molf | Hacker News Reader

Parent Full thread

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.

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.

> CarpentryHub

I too look forward to the 2021 YC batch

As a wood worker I often build things that make my current set of tools work better. Router that I own Let me make a router table that fits in my workspace and has the features I need, now the router can be used in other ways. Want to cut circles, make a circle cutter for my router. Dovetails, jig to make that with my router. All of the tools are add on to a pretty basic tool, and they are set up for me.

To go back to the static website, I really like the Wiki format (Current favorite is http://pmwiki.org ). I picked it for three reasons 1) It's a very powerful wiki 2) I can convert the site into static pages. This lets me build in the wiki format, then publish out. 3) There is a cookbook (a tool another user wrote) to make PDF. You can select the pages in page order and produce a PDF. To that base I've added my custom items.

Pmwiki in it's own right is simple (a router), but allows for cookbooks (custom extensions) that others can add. One of the interesting things is the current lead developer doesn't really add features to the core, they also create cookbooks to add on. And the core is pretty soft, if you don't like the markup, you can change it.

A long way to go to say that I can see writing software like the OP article. But if you should look at a core tool and see if you can build around that. @Molf uses hinges as an example. You can do a lot around a stock hinge (paint, bevel the edges, add "hand crafted tool marks", a process that is easier to do than starting from ground zero.

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.

The other thing this makes me think -- custom built carpentry is currently very expensive, for real. If you also want all the components to be custom-designed and bespoke, it's only the wealthiest who will be able afford it.

There are for sure economic factors behind choices in how software is built, for sure.

Back to the analogy and actual tools -- what employer is going to pay you to write your own editor to use to write the software the employer wants? It's not just that they are mean and choose not to pay you for this, it is not a cost they could sustain (for all but the biggest employers I guess. Google, sure, can have an editor team. Still can't let every individual programmer build their own editor)

On the other-hand, most woodworkers I know (unlike, say construction workers) try to use joinery when possible. The joinery is usually custom built by necessity, often assisted with a mix of home-built or purchased jigs. The one exception are dowels, which are standard and very generalized. I think that the software analogy might be design patterns.

You can also think of lower-level components, like nails and glue, which even more general and standardized than something like a hinge, maybe these are like standard-library or builtins for a language?

Edit: dropped connection, double post

Reply on news.ycombinator.com