Favouring tools is bad engineering (2018)

This is abstract enough to be mostly useless, but concrete enough to piss off everyone who has had success using certain tools. Even the mechanical engineering argument has the counterexample of equivalent but differebt pieces of CAD software used to design a bridge.

"You shouldn't like things" is an absolutely horrible piece of advice. Especially when presented vaguely... Especially when becoming productive in software involves displaying the grit of constantly solving small problems that arise day to day within the tools everyone uses.

Having a preference is a perfectly natural shortcut to productivity, and not a sign of poor engineering. There are dozens of other things we can improve as a community of software engineers which would actually make software better, faster, easier to debug, more maintanable.

> I want to go even further than this. I want to say its bad engineering to even like a technology or tool.

This assertion is pure nonsense. To really believe in that, first you need to somehow believe that hard technical requirements like availability of technical features is something that does not exist.

Afterwards, it requires you to believe that different levels of proficiency with a tool has absolutely no impact on productivity.

I mean, what does the author think that "favourite" means in this context?

Even though it's important to review technical choices, let's not fool ourselves into believing that all tools are equivalent and that different levels of mastery and experience have zero impact on performance and turnaround time.

There is a kernel of truth in the post, but the mental rigidity makes it impossible to take seriously.

Sometimes you need to standardize on one tool, and sometimes you don't want to do a study on what the best tool is--you just use what you know.

Choose your battles.

Hyperbole abounds. What the author means by "bad" engineering is that it's "not 100% optimal" engineering.

It's hard to take this article seriously. The message would be better without the exaggeration and strong tone.

The article may as well say, "Being human is bad engineering." People are, for better or worse, going to have experiences with tools. These experiences will color their perceptions of the tool and their willingness to use the tool for future projects. Personally, I like Typescript. I've had nothing but good experiences with it. But I also know of other people who dislike Typescript because it was foisted upon them by a senior developer (who presumably also had good experiences), and it turned into a morass of build-time complexity.

Heck, it's not just software tools. Some of my friends once got into a heated argument over whether adjustable crescent wrenches were ever acceptable to use. One side was saying, "Crescent wrenches just round off the nut and ruin the part in the long run," while the other side was saying, "Yeah, but we can't haul a 100-piece mechanics tool set everywhere we go."

People are going to be people. They will have likes, dislikes and strongly held opinions about their tools. Saying, "its bad engineering to even like a technology or tool" is tantamount to saying, "it's bad engineering to be human".

Eh. There's nothing wrong with using tool or a stack you're familiar with and know you can execute well on. It may not be optimal, but it's certainly not always bad to reduce uncertainty.

>Sure, I find Swifts syntax pleasant, or readable, or maintainable. But at the end of the day, I’ll use it when it’s the best possible way to solve a problem.

Yea, I too know people who have tendency to pick random stack that 2 devs are "proficent" (including him/her) when the rest of whole company has 0 experience in it

>It’s fine to dive deep and master a technology, but the best engineers or developers don’t have a tool name in their title. Senior Java Developer sounds as ridiculous as Senior PVC Pipe Plumber. The best start with the problem and find the best solution for it.

the difference is that Java's environment with all its quirks and stuff - jvm, GCs, graalvm (I don't do Java, so idk) and stuff is 1000 times more complex than PVC Pipe

I do wonder if you'd say

>Senior Linux Kernel maintainer sounds as ridiculous as Senior PVC Pipe Plumber

I do agree that the best people aren't people of one stack.

Hard disagree. By this logic we’d still be writing COBOL. Yes, switching tools has an inherent cost associated but, you must calculate what makes sense for your team. Not everything is relative, some tools are simply better than others.

Definitely agree with the spirit of the article. Favoring tool or anything without concrete reasoning is laziness in thinking. Note that this is different from choosing established convention for solving minor issues without much investigation. In cases of minor problems, the consensus is that they are simple enough to justify common tools, there is no process involving favoring tools or certain solutions in the process...

Others have already made great points about why this is a weird argument to make (and almost feels like it's mean to rankle the crowd here and get us to react, but you got me, too, I guess), but I hate it for one very big reason: it makes engineers into robots who only do things to optimise, leaving no room for creativity or joy. Most poeple here may not like thinking about it that way (or even agree), but writing code is about lot more than just solving a bunch of constraints, it involves tons of creativity and passion. The best bits of code made me feel like I added something beautiful or elegant to the world, and on the flipside when I have no choice over how I'd do things I'm miserable writing code. We're all humans, and we should do things we like, as much as possible.

This is possibly a perfect example of a faulty/unwarranted generalization.

Everyone has a little bias. It's not necessarily bad or wrong.

That kind of depends on the reasons for favoring some tools over others.

I couldn't disagree more. Liking and mastering a particular technology stack, tool or programming languague enables productivity and efficiency.