I think you’re the first person in this comment section to mention this. Git has a structure for machine-readable structured data. Put it there, not in free text fields for humans.
That's all good and well but the UX sucks. I usually have dozens of commands like
git commit -m "PROJECT-XXXX Foo the bar to baz the qux"
in my shell history, which means 1) I can easily create follow-up commits under the same ticket number (no having to type the ticket number again), 2) I don't have to keep remembering the ticket number once I created the first commit on the given ticket. I'm sure I could set up an elaborate set of shell scripts and git aliases to auto-insert a ticket number as structured data at the bottom of each of my commits. But good luck convincing the rest of your team to do that.
Also, having the ticket number in the subject line means every git-related tool I use will always display it (even if the rest of the message gets cut off).
Annoyingly, npm audit relies on github's advisory DB, which is currently incorrectly flagging all versions of these packages, not just the compromised ones.
There’s also a strong culture of ownership of quality for individual developers. Design documents are expected for even minor changes, and each change goes through at least 2 rounds of well-documented testing by 2 other developers on your team. Compared to other companies where automated testing is the norm, it’s startling how few bugs they manage to ship.
Another thing I thought was interesting given modern dev practices is that you don’t even touch production code until after about 6 months of training, including exams and testing on the actual functionality of the product, even bits you’ll never interact with personally. They’re serious about making sure you know what you’re doing before you get within a mile of something that could affect patients.
They also have a pretty strong accountability culture. I shipped two fairly embarrassing bugs my first year and had a very serious conversation with my manager about whether I should continue to be employed since I’d used up about 50% of our team’s allowed bugs for the year. But on the other side, once I got my feet under me, they were very good about recognizing improvement.
The state of MUMPS has progressed a lot since this article was written, to the point where most MUMPS developers would probably only vaguely recognize this. Even the "MUMPS" they were using back in 2014 or so was really a higher-level dialect + higher-level framework (Chronicles) that was transpiled down to actual MUMPS. It was more like writing ES2015 + JSX or whatever and then actually executing ES3 + DOM operations.
Source: was on a team that was performance sensitive enough that I spent a lot of time in the actual transpiled MUMPS code that did look more like this article.
And yet, per the spec, new syntax features are allowed to break ASI:
> As new syntactic features are added to ECMAScript, additional grammar productions could be added that cause lines relying on automatic semicolon insertion preceding them to change grammar productions when parsed.
So really, the rules are “there are currently 2 exceptions and an infinite number allowed to be added at any time”. To me, that’s worth letting prettier auto-insert semicolons when I hit save.
