MongoDB does it, too. So it’s not exclusively a SQL thing.

Bottom should be Composer.

Static analysis won’t save you from all of them, but they will definitely save you from the great majority of the ones ProgrammerHumor seems to get worked up about.

I still see people sharing ancient memes about pouring over code for hours looking for mismatched curly braces, missing semicolons, and greek question marks. These and the bulk of minor syntax problems like them should all be complete non-issues with modern tooling.

It’s 2023. If you’re not using an IDE or a highly extensible text editor with simple static analysis features, I really don’t know what to tell you.

Yeah, how much time you get to dwell on it will depend on lots of factors and the needs of your client/employer.

I happen to work at a place where timeframes for fixes are quite lax, and the codebase I’m working with is slowly being recussitated from a decade of bad decisions from a D-tier web developer. (Dreamweaver was involved… let’s leave it at that.) I can imagine if you have a codebase that was somewhat competently designed from the start and/or your client/employer has a “I need this fixed yesterday or else your ass is FIRED” urgency, you don’t have time to dwell on such things. But it helps to have the experience that at least lets you do it a little bit rather than not at all.

We hired a greenhorn dev several months ago. He had two years experience at a larger company. I only have about five so far and my company doesn’t really pay all that well to field great talent, so I wasn’t hoping for the world. But we were expecting at least something a little above entry level experience.

The guy did know how to write basic code. Frankly not to the degree I hoped for, though. Also lacked all auxilliary skills like effective use of version control, logging in to remote servers over SSH, documenting code with doc comments. He doesn’t even write particularly legible code without the formatter to fix it for him. Very sloppy with spacing, braces, etc.

But those are all of little concern. Those could all be taught. It meant more effort needed to be spent in onboarding than we wanted, but it could be done. Helps that he has a very positive oulook on constructive criticism and he uses it to improve.

One thing that I don’t think I can teach him in any reasonable amount of time, though, is how he mentally tracks the structure of the program he’s working on.

When I program, every time I change anything, I construct a mental web of everything this piece of code might affect when changed, and the ramifications it might have. I think of neighboring code and concepts looking for patterns, and whether the new thing I’m adding or changing could be better expressed differently to leverage those patterns. I think of the future trajectory of the module or feature, and whether it would be advantageous to bake-in a certain kind of forward-thinking extensibility now rather than after it becomes partially entrenched later. And most of all, I think of how someone completely unfamiliar with this code might read it, and how I can improve the way it is written to make the most important parts stand out clearest.

And when I’m debugging code, even if I see the problem and think I immediately know the solution, I still take time to read the surrounding code. I try to piece together the original bugged code’s intent. Is this onvious-looking problem the real problem? Or is it a poorly documented, poorly structured mess that looks like it wants to do one thing but is intending to do an entirely different thing? This hesitation has saved my ass on several occasions.

New dev doesn’t do any of these things. He pulls a bug ticket, figures out what module or function is the supposed source of the problem, and bangs on it until the effects of the problem disappear. Little research done to understand what the intent of the code he’s altering wants to do, and even less spent on figuring out what downstream systems will be affected. And once he achieves his singular result, he just pushes it as-is. No cleanup pass, sometimes forgets to format it the way we ask him to.

To be fair, it’s a big new codebase. I can’t expect him to reason around things he is not familiar with, nor would I think it reasonable that he study the entire codebase before touching it.

I also don’t think these things can’t be learned. I had to learn them at some point, after all. But I do believe that people like myself and one of my fellow devs are more predisposed to picking these programming soft skills up, whether it be through nature or nurture or some combination. That, and I don’t think these kinds of soft skills can really be “taught” in the traditional sense. These are wrenches you can only really learn to dodge after being hit by a few.

I’m not into the culture so I didn’t want to lean too heavily on this one source. It’s good to have some corroboration!

“Tubular” I can at least trace where it came from. It’s surfer lingo. Sometimes when you catch a wave, the wave crests all the way over you and encloses into a tube. Surfing through that is supposedly the most euphoric thing about the sport. “Tubular” is thus “anything that makes you feel the way a surfer surfing through a tube-shaped wave feels”. Thrill, wonder, excitement, etc.

I have no idea where tf “based” came from. Wiktionary suggests that it ultimately comes from the chemical definition of “base” (i.e. the opposite of an acid). “Freebasing” is a way of converting certain drugs, particularly cocaine, into smokable form by converting them from acid to base. Rapper Lil B. is alleged to have coined “based” to describe his lifestyle as someone who is unafraid to be himself as an individual (which, I guess, included smoking crack). This supposedly filtered into 4chan to become an alt-right slogan for “admirable person who bravely maintains alt-right opinions in spite of adversity” (“based and redpilled”), and later was claimed by groups outside the alt-right to simply mean, “someone with admirable opinions”.

I got an application that runs through a big calculation that has to pass several sanity checks along the way. If any check fails, the input parameters are tweaked and the calculation starts again from the top, iteratively approaching the ideal solution. Do-while is perfect for this.

It beats recursion in non-tail-call-optimized implementations (JavaScript…). And while this could be done just as well with a comon while loop plus a flag variable, I like the way the syntax of do-while naturally reads as, “Do [thing]. … Did it work? No? Do it again”.

I’d still argue it’s redundant. If they got rid of it tomorrow I’d refactor and cope with no complaints. But as long as it’s around, I like using it.

Alexey Pajitnov. He worked for the government, and made Tetris in his spare time across several late nights at his shared workstation. It was a hobby project made out of boredom, not something designed for any ulterior purpose.

He was a fan of those toy puzzle games where you have to fit shaped tiled pieces into a rectangular grid, so he decided to program a version of that for his workstation. When he succeeded with that, he found it rather boring to play with. So he spiced it up by making pieces fall from the top (to add challenge) and made them clear away when you completed rows (so the game would last longer). That’s pretty much it. Dead simple. Everything else from the iconic tile colors to the music were added by licensees later down the line.