All the hominins made tools
johnhawks.net
johnhawks.net
Hominin = species related to humans after the split from proto-chimps
IIRC.
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...
Please assume the lowest possible bar for “abstraction” in my argument. A function that calls 2 other functions is an abstraction.
A poor abstraction is costly in complexity. In a chain of tools, even modest complexity multiplies, and quickly becomes unmanagable. Whereas a clean abstraction (ideally) resets complexity to zero.
As the most prevalent & familiar here modern example, I'd suggest writing to .bashrc & using ssh-keygen are 'making tools' in the relevant sense.
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.
Maybe they researched and found actually all the options out there have whatever drawbacks that they don't fit the bill. Maybe they didn't bother to research because it only took them 10 minutes to script that manual process we perform multiple times a week, and they were curious to see if they could improve that. Maybe some of the 5 were pretty good actually, but the coworker has some specific ideas how their "6th" new tool could be better in certain important ways.
The good off the shelf tools make it easy to build on them with custom tools to fit your purpose.
I really don't mind if people lean a bit one way or the other in their inclination toward custom tools. But I do expect people to be supportive of attempts to build nice tooling, and show a curiosity toward the trade offs, and willingness to try an experiment.
Don't be afraid of building a tool, hacker friends. If nobody else displays an interest in what you build, or it doesn't turn out to really save time, or it costs too much to maintain.. you can ditch it! You are a professional with good critical judgment whose ability to improve the productivity of your group and provide repeatable "executable documentation" will carry you far in your career. Let your creativity shine, and have fun.
If the tool works, and I don't have any better ideas myself, and it's not going to lock us into piles of hacky scripts forever, I'm all for it.
They solved the problem, they're a professional with the same rank as me, they can do whatever they want. I'm interested in products and features, not endless code polishing.
But I would still be far more excited to hear "Hey check out this declarative framework I found" than "I wrote a bash script that does stuff".
A lot of the time the in house solution doesn't have many advantages besides hackers love of elegance and minimalism.
Some of these internal tools.get pretty extreme, like full DSLs that could have been python libraries.
It's like when people use dd over Etcher. The load time and disk space of Etcher has no real practical significance, and people do in fact make mistakes with dd all the time. I don't care if it's 80MB, it's a solved problem, and a repeatable process that you can teach in seconds(By saying "just use Etcher to flash it").
I could build something better than Etcher in a week, I'm sure. But that would be another thing to maintain, another internal repo to tell people about, documentation to write, cross platform issues that could pop up, etc. Maybe they even integrate workarounds for OS or hardware bugs that I have no clue about.
I have been that coworker wanting to try something new. I've built systems at home for personal use.
And nearly every. single. time. I wind up ripping them out and replacing them with something off the shelf.
Still, I am not the police.
If you're making custom tools, you're probably one of those hacker types with a really active mind who has a need to do things they can deeply understand, and I sure don't want to be the reason the smart people all get bored and quit!
Unless it's really extreme you're making the whole codebase into an unprofessional tinkering project. Then you're probably not helping the product...
At the end of the day I guess my experience has shown me that if given a nudge, people are capable of solving problems with automation, that can yield order of magnitude improvements in this or that process. I don't care if the automation is a custom script or an off the shelf tool, but let's do it. I want to share that inspiration with the field - we can automate that and we may be rewarded for it, let's give it a try and earn the nice things that we want!
In my experience quick scripts that leverage existing tools, that abide by some conventions, and that show some consideration for others using them - are great! Every software team has a bucket of routine tasks that developers need to do - are they one liners in the veterans' command line histories that are passed around in chat, or are they organized and documented in source control as "tools"? The later, please. (thank you framework designers that allocate a place for these as do Rails, Elixir, and npm (even if I hate the way npm does it ;) ).
It sounds like you've been burned by too much reinventing the wheel and not invented here. Like I said, it's possible to overdo it. What you've experienced sounds shitty, and I'm sure you're just trying to steer people away from the pitfalls you've observed, which is noble.
I just come down the other way: people declining to try to invent better solutions has been more of an impediment to my team's success, than their over-eagerness.
But if someone asks me how to flash a disk, I'll probably tell them I use Etcher.
It's a FOSS Electron-based GUI tool for flashing disks, which has a few extra features like verification, hiding things that aren't removable disks so you don't accidentally overwrite /, a progress bar.... and that's about it, aside from ads for Balena's other products.
But it works, it's what pretty much every beginner tutorial says to use, I've never overwritten the wrong thing(Like I did one time with dd a long time ago), and I don't really have much reason to go looking for alternatives.
It's also what I consider the canonical example of something GUI fans love, but CLI enjoyers hate.
Presumably any well run place wants their developers to have some level of continuing education stuff, right?
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.
And as things fell apart, nobody paid much attention.
Is the claim that no hominid is known the have given up tool making? That's a hard claim to make (no evidence of absence and so on), and anyway seems like a circular definitional argument (an "only true scotsman" if you will).
The central chart is interesting, but to my (note: non-paleontologist!) eye hardly "striking". Feels like the opposite would be more interesting, though again, hard to be persuasive.
Am I missing something important here? Again, I'm no expert.
I've seen a few fail no matter how hard they try.
Sometimes even at the initial conceptualization, so not all hominids are as smart as they think.
------
I love crows, but it is not true they're the only non primates able to use tools.
Many animals do! Otters, octopuses, other birds, some fish, etc.:
https://en.wikipedia.org/wiki/Tool_use_by_non-humans?wprov=s...
That belief is an outdated one from people who were too anthropocentric and didn't spend enough time with animals.
Even then, however, elephants have been known to modify branches (https://psycnet.apa.org/record/2002-10036-002), other birds in the same family (corvids) can manipulate wires similarly to the crows (https://www.pnas.org/doi/10.1073/pnas.0901008106), dolphins can use shells in non-obvious ways (https://www.wired.com/2011/08/dolphin-fishing/), etc. There are probably more out there that we just never noticed... and it's probably also a matter of degree and circumstance.
In order to do so they’ve tried to argue that other early primates or hominins apparently outside the human lineage did not. It has been clear for some time to most reasonable observers that this is not the case.
This is just more data that tool use and tool-making are more broadly distributed than the anthropocentrically-fixated would like to admit.
A study of associations between stone tool evidence and fossil hominin remains shows that a wide range of species made stone artifacts.
Perhaps in the context of the field, the hypothesis is more clear. Also, does "study" refer to a particular published study that the author is reviewing, or to this blog post?
- Well they had small brains, so there's no way they were the toolmakers
- We found lots of remains of Australopithecus here, and usually there are very few remains of the toolmaking species, so obviously, Australopithecus is not the toolmaker
It seems remarkable how much of the whole scientific edifice described in the article is pure conjecture with little in the way of "actual discoverable/provable truth". I can see how this field must be so fascinating and keep someone's fascination going for a lifetime.
Anthropology is trying to answer questions about things that either aren’t measurable, or only measurable by proxies.
Otherwise it’s “history” - being basically every data that is recorded directly from the source or with few proxies
This really messes with epistemological reasoning chains and strength of “proof” that can be made from proxy data
You can’t build an a/b test or experimental process or define a study population for questions like:
“what happened in 15000BC”
“Why did humans develop language”
Etc…
That’s not to say you can’t have very strong conclusions, but just think of the predictive power of keplers equations compared to the process of specieation.