Hacker News new | ask | show | jobs
by bloblaw 1277 days ago
FTA: > Otherwise, the only thing that matters is that the tool works. Every tool comes with its own upsides and downsides, but most of them are increasingly the same. They mostly differ in workflow. But I can promise you: they all draw rectangles equally as well. If you can accomplish your work with the tool, then it serves its purpose.

Eevee dismissed with that argument succinctly when they wrote in their "PHP: a fractal of bad design" article:

> Do not tell me that “good developers can write good code in any language”, or bad developers blah blah. That doesn’t mean anything. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best.

That last sentence drives the point home.

2 comments

As the saying goes, it is a poor craftworker who blames their tools... but the popular understanding in our community that it means a craftworker should be able to do anything with crappy tools is wrong. The real meaning is that it's a poor craftworker who has crappy tools, but just keeps using them. They should either fix them or get better tools. It is a poor craftworker who blames their tools because it is a poor craftworker who continually uses blameworthy tools!

(Or, in other words, I 100% disagree with the original post. Tools do matter, and it is folly to think otherwise in the face of overwhelming evidence.)

Since our tools are Turing complete, we are in the unusual position of sometimes being able to use our crappy tools to carve out better tools within the tools themselves, but in general, you should be using the best tools you can. And, yes, it is completely fair to judge a tool as being either bad for a job, or just a bad tool in general. Craftworkers who refuse to make such judgments are not exhibiting wisdom, but lack of discernment.

That is not to say that you must always use the best tool to the exclusion of all else. Much as we may not like to hear it, we aren't really craftworkers here for the most part, we are engineers. If I got moved to a big PHP 3.0 project, I would not make it my first order of business to insist that we drop everything and rewrite it in $BETTER_TOOL. That's not a good engineering move. The quality of our tools is only one part of a very complicated melange of relevant issues. But we're still allowed to have judgments, and the fact that tool quality is not 100% exclusively determinative doesn't mean the only other alternative is that they must be 0.0000...% relevant.

> The real meaning is that it's a poor craftworker who has crappy tools, but just keeps using them

The "real meaning" of a common aphorism is the one that's obvious to everyone. That's the point of aphorisms.

If common aphorisms needed special "truth knowers" to explain them, then the words themselves might qualify as religion.

I don't live in Silicon Valley. I live in a place where trades are a much bigger portion of the economy, and much of my social circle is in them. This is the common meaning that everyone else around me knows. I've explained the programmer meaning of "it's OK to stick with bad tools and you should just expect the user's skills to make up the difference" to the people who actually work with physicals tools in the trades, and it is met with either befuddlement or open laughter. No one who actually works with physical tools for a living could possibly think what programmers think about tools. You only need to experience once in your life the night-and-day transition from a blunt saw to a sharp one to get it. A skilled user of saws does not sit there bashing away at wood with a blunt saw and expecting their "skill" to cut the wood. No job foreman will sit there watching you bash away with a dull saw and smile approvingly because he knows you're making it up with "skill".

This is a peculiarly programmer misconception of an aphorism that predates the entire industry of programming.

I've heard it differently, but is a corollary: bad tools make it easy for bad developers to do bad things. Good tools make it easy for bad developers to do good things.
Bad tools make it hard for good developers to do good things, and good tools make it easy for good developers to to good things.

Why do you care about bad developers? They won't do good things either way.

We should all care about bad developers because if they make bad products sooner or later you or I will use one! Bad developers are the ones who store your password credentials and personal information in plain text. We should all care about making it easier to do things the right way because then the right way happens more often.

This is one of those things that are obvious in the specific, but we're talking in abstract terms.

Because I am very often (temporarily at least) a bad developer. I am tired, or sloppy, or unmotivated by a particular project, and I make mistakes. I want my tools to help me.

Most people, in my experience, are both good and bad developers in different measures. Tools that help the bad developer therefore help all developers in those moments when we make mistakes.

> bad tools make it easy for bad developers to do bad things

Who get to say if it's good or bad?

We need more "software things".

Users can decide what's good.

A few billion people have decided FB (done in php) is good.

Eevee also dismissed with this argument as well in the same article: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

> Do not tell me that Facebook and Wikipedia are built in PHP. I’m aware! They could also be written in Brainfuck, but as long as there are smart enough people wrangling the things, they can overcome problems with the platform. For all we know, development time could be halved or doubled if these products were written in some other language; this data point alone means nothing.