This happens to me all the time, but mostly with work code.
I'm under pressure, I have to deliver, things get rewritten many times, edge cases are found and fixed in production after they slipped through multiple qas but need to be fixed instantly or we lose money.
It happens.
But personal code? I am almost always proud of my work. It shows in general I was not under pressure and enjoying building it.
Even my code from the first year of programming, it shows it was made to make a point in writing a nice solution.
I may cringe at times, but still proud.
Context does matter, and code quality is more often than not a byproduct of our emotional state rather than skills.
One reason to stick to a restricted naming scheme for tables is that table names cannot be parametrized. This means you need to implement escaping manually in tools/scripts where table names are not hardcoded. Snake casing creates word boundaries that do not rely on casing and thus do not need to be quoted, there for your manual escaping/sanitization is greatly simplified (lowercase ascii characters, numbers and underscore). I’ve found this reduces the number of footguns by one in databases maintained by a team with varying degrees of familiarity with RDBMS.
One of the fun things with SEI Capability Maturity Model is that you reach level 1 just by having your process written down at all, no matter how stupid it sounds.
But the giggle test is just something I borrowed from business, which is, “can I say this with a straight face?” Which eliminates a lot more censorious than you would think. Writing something down is one thing, making eye contact with someone while repeating it is a bit harder.
censorious appears to mean 'severely critical of others'. I expect they meant 'censoriously', with the full intent being that the embarrassment felt by the critical reactions of others when reading the instructions out loud will cause you to eliminate or fix obviously broken, complex or tedious processes that you had, until then, just quietly been putting up with.
I like it because it’s really easy to extend the editor with custom language support/tooling if you know JavaScript/Typescript. Providing custom completions, diagnostics, etcetera. I can also provide custom Go to definitions for cross-language support.
True. What I think is missing (and probably the more interesting question) is an analysis on _why_ LLMs failed to spot it. I imagine it has something to do with the model architecture.
Yeah. Ironically the JLS includes a complete specification of what the type E1|E2 is, because if you write a catch block that catches both then that's the type of what you catch, there's just no syntax for it.
reply