Unless you are truly pushing the envelope of tooling development, I consider learning to use an existing tool well far more important than inventing a new one. The developer tooling has become so complex that it takes a truly exceptional individual to build a tool on their own, and the vast majority of tools are built by teams of people.
That is why you rarely meet developers who build their own tools, it's a often futile effort usually better spent elsewhere.
In fact I would go on to say that in my personal view people who do roll their own tooling usually do so due either to ignorance of existing tools or as a fun little side-project.
Woe be to those who push their opinionated tools onto their teammates...
You define tooling too narrowly. That custom script that the team uses to cut a release branch and notify people with contributions on the branch that it's being deployed? That's a tool, that itself uses off the shelf tools/products (eg. perhaps Python, GitHub, Slack). And it could possibly be a very helpful tool that saves manual effort and improves results, for a fairly low cost.
Sure you can spend too much time and effort building tools, rather than focus on meeting the most important business objectives, and we've all met developers that do that. But you can certainly build too few tools, as well.
If someone shows you how to take a stick and a stone and make a hammer, and you imitate, you're certainly not 'pushing the envelope of tooling development', but you're still making a tool.
As the most prevalent & familiar here modern example, I'd suggest writing to .bashrc & using ssh-keygen are 'making tools' in the relevant sense.
It is, but most developers I know (including myself), spend more time in meetings talking about what the tool should be except in the concrete details that would allow any of us to craft the tool while never actually getting around to making it. Occasionally, we'll spend time criticizing broken tools that someone made in ways that let us feel like we're getting better at making non-defective tools.
However, we definitely know theoretically what an acceptable software-as-a-tool look likes, and we're constantly the lookout for one if someone were to stumble upon it. In the meantime, we make mock tools sort of like how the Allies made inflatable tanks, and we deploy those in places to keep the enemy... er, customer, guessing about our true intentions and position within the market.
lpapez|2 years ago
That is why you rarely meet developers who build their own tools, it's a often futile effort usually better spent elsewhere.
In fact I would go on to say that in my personal view people who do roll their own tooling usually do so due either to ignorance of existing tools or as a fun little side-project.
Woe be to those who push their opinionated tools onto their teammates...
CoffeeOnWrite|2 years ago
Sure you can spend too much time and effort building tools, rather than focus on meeting the most important business objectives, and we've all met developers that do that. But you can certainly build too few tools, as well.
OJFord|2 years ago
As the most prevalent & familiar here modern example, I'd suggest writing to .bashrc & using ssh-keygen are 'making tools' in the relevant sense.
Swizec|2 years ago
Please assume the lowest possible bar for “abstraction” in my argument. A function that calls 2 other functions is an abstraction.
simonh|2 years ago
NoMoreNicksLeft|2 years ago
However, we definitely know theoretically what an acceptable software-as-a-tool look likes, and we're constantly the lookout for one if someone were to stumble upon it. In the meantime, we make mock tools sort of like how the Allies made inflatable tanks, and we deploy those in places to keep the enemy... er, customer, guessing about our true intentions and position within the market.
Koshkin|2 years ago