Hominin and hominid are both valid terms; hominid is broader, and includes all the Great Apes, in addition to modern humans and their ancestors. (Although apparently hominid used to mean what hominin now means, according to https://australian.museum/learn/science/human-evolution/homi....)
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 your coworker wrote such a script, would you respond positively or gloomily?
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.
Never heard of etcher, used dd for more than 20 years. Your comment is strange to me. You have some kind of problem with "people who use dd" instead of the thing I haven't heard of?
I don't have a problem with people who use dd, people can use whatever they want, disk flashing doesn't really need to be organization-wide standardized.
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.
Yeah, but that's "somewhere" and "something" - it's likely that the time spent finding the particular thing you need is greater than it takes to write your own script, and that doesn't even include time to understand how the thing you found, and a host of unfortunate consequences of adding a new third-party dependency to your project...
The time to understand that thing is a time investment that can be used on any similar project, and makes me a more effective developer. Plus it exposes me to the current popular ideas of what best practices look like.
Presumably any well run place wants their developers to have some level of continuing education stuff, right?
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.
Attaching a the stone to a stick makes a very advanced hammer. While we've been using hammers without sticks for over 2 million years, hammers with sticks only came around 30k years ago.
And none of the improvements on hammers for specific actions count. The orientation or prongs on a modern hammer isn't going to stymie a neanderthal unless they are destudding drywall.
True. But the quality of an abstraction is also significant.
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.
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.
Pretty much all of programming is constant toolmaking, usually much more abstract and sophisticated than anything in the article. Every subroutine, utility function, library, and interface, for example.
I'm not sure what point is being made here. The article says that we evolved from pre-hominid primate species that used tools (there are non-hominid toolmaking species as well), which I don't think anybody disputes, and doesn't appear to be claiming that that is novel either.
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.
You’re not missing much, maybe just an implicit and aging position in the field. People have made the argument (in the long line of “this is what makes humans unique” arguments) that our consistent use of technology is what separates us from other animals.
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.
I looked at some of their examples, such as " accumulative stone throwing" [1] and I don't get how this is a good example of "tool use". It seems like a very thin definition of the term. Maybe I don't understand anthropology and this is and any use of tools at all is bigger deal than it seems.
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?
Didn't read the article, I was hoping it was a gallery with a time line. Anyway, look for New Caledonian Crows, they make tools (bended hooks). It's the only non primate species that does. Supposedly, to make a tool you have a super accurate model representation in your head on what you want to achieve while elaborating such tool. That is awesome.
I'm not surprised, brains are incredible, even tiny ones in organisms like insects. Is a bird's nest a tool? There's a continuum all the way up from ant nests to rocket ships.
What is most striking to me about this article is the level of fallacy in reasoning that's exhibited throughout this entire scientific debate:
- 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.
