As a developer who works with code base that's got a git history going back over a decade and lot of legacy parts that haven't been touched in a long while, written by devs who've long since left, I fairly frequently wish they'd been more careful with the commit history.
You do mention project context as being relevant, but if bug fixes and refactoring _can_ be decoupled, it's a kindness to pull-request reviewers (if there are any) to do so and keep PRs small. It's also helpful if something needs to be rolled back if the commit history is fairly coherent.
I'll just say that the emphasis should be on clean branches and PR's much more than clean individual commits. And on good code much more than clean git branches.
If there's too much ceremony around branches and pull requests I tend to avoid small fixes because it's just much work and that definitely doesn't improve the quality of the code.
A manager with a sense of humor is different from a manager who jokes about ending your employment. Imagine getting pulled over and a cop jokes about arresting you- are you laughing or do you feel unnerved? You were being sarcastic, but unnerving employees by making jokes rooted in your power over others does have the potential to negatively impact company culture and thus the company itself. The power dynamic matters.
Making jokes about firing subordinates shows a bad sense of humor -- it's not funny, it's making light of a power imbalance at the expense of the subordinate.
It's like when a cop makes jokes about shooting you after pulling you over for expired tabs (happened when I was a teen).
It is more or less universally recognized that jokes are only funny if they are punching upwards. Someone in a position of power making jokes about using that power against someone with less power is more akin to bullying.
I would argue that breeding camaraderie requires empathy and understanding with other person as opposed to blindly projecting one’s sense of humor upon another.
Fully agree. I work on a small team (3 devs + 1 designer) and all three devs are, to some degree, full-stack. We all have areas of relative strength and weakness, but all can and do work across the full stack.
It also seemed pretty absurd to me that the author suggested the only reason any kind of full-stack developer is conceivable is JS on the backend, as if the main issue is needing to know more than one language.
As a developer who works with code base that's got a git history going back over a decade and lot of legacy parts that haven't been touched in a long while, written by devs who've long since left, I fairly frequently wish they'd been more careful with the commit history.
You do mention project context as being relevant, but if bug fixes and refactoring _can_ be decoupled, it's a kindness to pull-request reviewers (if there are any) to do so and keep PRs small. It's also helpful if something needs to be rolled back if the commit history is fairly coherent.