I disagree with more things in this list than I agree with, a few things seem particularly pathological:
37: This meme is just outdated. Please stop perpetuating it.
49: This is not that hard to fix, even in small organisations.
32: As edef put it, this is how you get low-frequency, high-impact bugs to hang around forever.
A lot of the technical things in this post are issues that a smaller organisation without the budget to build sophisticated tooling would have (e.g. 10) or that are indicators of larger organisational issues (e.g. 26, 5).
37: This meme is just outdated. Please stop perpetuating it.
Nah, I see this a lot at both my work and where I volunteer teaching programming. Most memorize a few commands for it that usually work. When they don’t work, they turn to StackOverflow or one of the few people who do understand it.
49 is still valuable. If your org has solved it, that’s great, but you still need to use the solution the org has come up with, rather than just looking at master.
I’m in an org that is switching to Gitlab from a long history with TFS. And it’s amazing how many of my “intermediate” and “senior” software engineers can’t get code out of git with out having to use Visual Studio. And God forbid they have to use the git cli. So I think 37 isn’t a meme for a lot of us.
And 49 is great till you find out somebody switched a pipeline to use a branch for some reason and never moved it back.
Doing 37 (simply rm -fr && git checkout) is tempting, but then you never learn. I’ve probably wasted a bunch of time doing so, but I can count the number of times I’ve done that on one hand and it’s a good exercise getting yourself out of that sort of hole (and improving your ability to identify exactly the sort of hole you’re in)
Yeah, nobody’s ever gonna learn Git that way. People think they can get away with it forever and then somebody’s checkin bites them in the ass and they’re like “Welp, guess I better read the documentation and understand how this abstracts everything.”
Knowing git is inescapable (as the standard SCM), whereas build systems are diverse and wrongly configured. git clean -dfx ftw.
Sure, git’s nomenclature is alienating. Case in point, that command should be git clone, as that’s what git calls checkout, because checkout means reset, and reset means something else… But as compulsory knowledge, the learning curve makes no difference in the end.
I disagree with more things in this list than I agree with, a few things seem particularly pathological:
37: This meme is just outdated. Please stop perpetuating it.
49: This is not that hard to fix, even in small organisations.
32: As edef put it, this is how you get low-frequency, high-impact bugs to hang around forever.
A lot of the technical things in this post are issues that a smaller organisation without the budget to build sophisticated tooling would have (e.g. 10) or that are indicators of larger organisational issues (e.g. 26, 5).
Nah, I see this a lot at both my work and where I volunteer teaching programming. Most memorize a few commands for it that usually work. When they don’t work, they turn to StackOverflow or one of the few people who do understand it.
49 is still valuable. If your org has solved it, that’s great, but you still need to use the solution the org has come up with, rather than just looking at master.
I’m in an org that is switching to Gitlab from a long history with TFS. And it’s amazing how many of my “intermediate” and “senior” software engineers can’t get code out of git with out having to use Visual Studio. And God forbid they have to use the git cli. So I think 37 isn’t a meme for a lot of us.
And 49 is great till you find out somebody switched a pipeline to use a branch for some reason and never moved it back.
It’s true. All of it.
And not just for DevOps, but also production support in general, legacy systems, data management, etc.
This is a great list with some wisdom only earned through experience.
That being said, I’m puzzled about 77. “Mandatory code reviews do not automatically improve code quality nor reduce the frequency of incidents.”
Of course code reviews don’t catch all issues, but the fact that they catch some seems like trivial proof that they reduce the frequency of incidents.
I totally agree, but try doing a
s/code reviews/types/here and watch people lose their minds :)You will ensure that all the binary versions of your tools report a revision/version only to find that either:
One of your dependencies transitively is pointed at a mobile ref (
master, or some branch) and reports that instead of thegit rev-parsed versionThe ref in production doesn’t exist anywhere in the source tree
Doing 37 (
simply rm -fr && git checkout) is tempting, but then you never learn. I’ve probably wasted a bunch of time doing so, but I can count the number of times I’ve done that on one hand and it’s a good exercise getting yourself out of that sort of hole (and improving your ability to identify exactly the sort of hole you’re in)Yeah, nobody’s ever gonna learn Git that way. People think they can get away with it forever and then somebody’s checkin bites them in the ass and they’re like “Welp, guess I better read the documentation and understand how this abstracts everything.”
I agree, git doesn’t fuck up. Build systems do.
Knowing git is inescapable (as the standard SCM), whereas build systems are diverse and wrongly configured.
git clean -dfxftw.Sure, git’s nomenclature is alienating. Case in point, that command should be
git clone, as that’s what git calls checkout, because checkout means reset, and reset means something else… But as compulsory knowledge, the learning curve makes no difference in the end.