Item — HN Reader

FTFY: "I don't understand why those who spend most of their time __using tools__ focus so much on the tools they use to do it."

It should be more self-evident now.

When there are many tools which meet the minimum requirements for doing a job, then the focus becomes not on which tool can do the job, but which tool you feel does the job the best (or you enjoy using). Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker.

You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.

4 comments

"Carpenters argue about the best saws/drills, artists argue about the best brushes/paints, musicians argue about the best instrument maker."

Is that actually true? I can't think of a single example of such an argument. I have heard recommendations, and heard various trendy tools being promoted (at least for music), but never an argument.

I think it has to do with transferability of skill. In music, carpentry, and painting, skill readily transfers to different tools even if it causes annoyance or a stylistic change in the result.

The stakes are much higher for web development; at least that's the perception. Skills probably transfer better than people think, but it's scary to have 10 years of experience and a high billing rate and then go back to "hello world".

It's much more comfortable to try to promote what you already know so that you don't have to do that. And it also avoids wasting time on a new framework that seems promising but never gets critical mass.

I've never had a problem moving to another language, I'll never understand why people pigeonhole themselves into categories like "rails dev" or "java dev".

The fundamentals are transferable, I don't even mention specific technologies or stacks these days if I don't have to.

Well, two things. Lots of people are good on the mechanics of a particular stack and weak on the fundamentals, making the description accurate.

And lots of people hire based on the assumption that expertise in a particular stack is the most important thing (perhaps in part as a result of the preceding point).

Definitely, which is how you end up with half of NPM's package repository.

It's not necessarily a problem, but it takes humility.

"When art critics get together they talk about Form and Structure and Meaning. When artists get together they talk about where you can buy cheap turpentine." -- Pablo Picasso

Haha.

But there is a big difference between discussing tools and arguing about them like your career depends on a particular opinion being right.

>You're right, customers don't care about what tool was used to build something, but they care that you can do your job well and good tools help you do that.

True, but I do my homework too. My code needs to be maintainable for the next guy. We can't invest inordinate amounts of time on V2 where it isn't necessary. I don't want unrelated parts of the program breaking because I fix a bug. The next set of features should be easy to implement from an architectural perspective. All of this is important to the customer and my business.

I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.

> I care about my craft, but there's a line at which I stop investing my time in debating the toolset. If I'm spending ~10 hours / week writing blog and forum posts about why everyone should use X framework instead of Y I'm seriously wasting my time.

Sure, but that line is in a different place depending on how important the tools are. If you're doing a project where the functionality is 40% custom code and 60% tooling, that will naturally give you a very different attitude to a project where the functionality is 1% custom code and 99% tooling.

Except, really, none of those analogues are accurate. Professionals in the other fields identified don't argue about told the way programmers, and particularly web devs, do.

The kind of tool-centered identification and tribalism seen in large segments of the development community is not only rare among other professionals, it's seen (usually correctly) as a sign of being an amateur that doesn't know the craft well in other fields.

To a point, but then it is just self indulgence. Comparing camera gear is huge in the photography world, but making a great picture is rarely limited by the gear. People spend so much time arguing over gear they never take any pictures.

I see a lot of the same thing when people argue over programming tools. Just go build stuff in whatever tool you feel comfortable in. Do not lose site that building stuff is the goal, not using some tool.