Any developer demonstrating that level of daily incompetence with their basic tools of the trade should never be allowed to write code. The fact that this level of incompetence seems the rule rather than the exception speaks to the rather terrifyingly pathetic state of software, where badly engineered systems end up killing people. Source: firmware engineering consultant that cleans up messes like these for some of the biggest corporations in the world, who build things that will kill people when they fail. I would love to blow the whistle, if I thought that would have any positive outcome whatsoever.
Who defines which tools are "basic tools of the trade" and which are just bland infrastructure?
And who decides how much of each tool one should know to move beyond "daily incompetence"?
If I'm getting the job done and produce more net value than my peers for my salary, why should there be requirements on how well I know some specific tool?
I'm willing to bet a ton of value has been generated by folks who don't know the first thing about git beyond "commit, push, pull request". Who cares?
Now, of course, whatever my core job role is (perhaps it is firmware development, as in your example), I should know that role inside and out if my output is going into safety-critical places. But that's a different comment all together.
I'll admit as a 20yr c++ developer, I don't know what rebase is or when to use it. I've only been using git for a few years, cvs before that. I commit and push often, then do a merge request via a web portal gui(bitbucket or gitlab), then merge it squashing commits again using the gui.
I prefer merge/fast forward because I want all history preserved. People can rebase their changes in their branch, but rebasing is never done on the main or development branches. Most of the worst merge conflict I’ve had to deal with were caused by someone rebasing changes they didn’t make. I reject all pull requests that change history.
We ask candidates the most ridiculous algorithm and data structure design questions when we should be asking them to describe the git data structures. Let’s fix interviews and kill two birds with one stone.
Huh, how did it get so bad that "blow[ing] the whistle" about "things that will kill people when they fail" "would have [no] positive outcome whatsoever" ?!
I disagree, the point is to get code written that solves problems, and the tools are a means to that end and not an end in of themselves. Our tools should make that task easier and more accessible to more people.
