their company has refused to read or implement one or several of the fundamental principles

The companies I worked for just kept doing shit the same way they always had but renamed everything with terms borrowed from agile.

My favorite approach to team processes was to work entirely alone and do everything by myself.

At my last job I had to endure 2-hour daily standups involving 120 people. Yes, I know that that’s as far from actual agile as you can possibly get – we still called it “agile”.

I briefly wrote Blackberry apps circa 2010 (yes, I knew RIM was dying a quick death). The development process was insane: any module from the framework that you incorporated into your app had to be digitally signed by RIM servers every time you tried to compile your app and deploy it to a device, even if you had only made a one-line change to the code. On good days, this would make the compilation take 5-10 minutes; on bad days it would be upwards of an hour or never happen at all. Some wags had even set up a special website that would tell you whether the RIM servers were down or not (long gone now, of course). I got in the habit of making a large number of code changes before attempting to run and test stuff, which is obviously not the ideal way to do things but it certainly teaches you to be careful. It also make me think long and hard before including a new module into my code. As one example, for my GUI I needed to use trigonometry functions which were naturally (lol) part of one of the cryptography modules which took an especially long time to get signed. I ended up writing my own sin() function in Java just to avoid the hit of including that module.

The great part of this was that I always had a ready-made excuse whenever I felt like taking a long lunch or going shopping or going home early. “Sorry boss, the signing server is down” and I made damn sure they never knew about isthesigningserverdown.com. It also helped that it was Blackberry circa 2010 and it didn’t make a shit bit of difference whether I got the app done or not.

I started working as a professional programmer in 1995. From the outset, I was pitching to clients how a GUI (thanks, Visual Basic 3!) would be so much easier for their employees to use than a command prompt. I find it very interesting how command prompts are still around 30 years later. I’m way more amazed by the continued existence of vinyl LPs, however.

We don’t have that in software engineering. And outside of critical software we don’t need it. When the audio fucks up in Teams and you have to leave and re-enter the meeting, people don’t die.

I had a co-worker who was writing remote control software for a baseball-throwing machine. Not exactly “critical software” but he ended up firing a 125 mph knuckleball a foot above a 10-year-old kid’s head.

I wish to god Visual Basic was still around so Copilot et. al. could get infected with ON ERROR RESUME NEXT statements. Or its under-appreciated but vastly more horrific cousin ON ERROR RESUME.

My favorite thing about the “all comments are bad” crowd is that their first example is almost always something like this:

// Add 1 to x
x = x + 1

Like, nobody that thinks comments are good and important would ever add a useless comment like that. The point of commenting is to add documentation (usually the only form of documentation that a future developer is ever going to read) only to code that would otherwise be inscrutable.

That long-ass horizontal scroll bar reminds me of how I used to put unfindable easter eggs into my Visual Basic apps. I would have amusing little messages pop up from time to time in message boxes. To prevent anyone from just searching for the exact text in the message box, I would reduce it to a series of concatenated Chr() statements and then I would put like 200 characters of whitespace in front of the message box call. The only way anybody would spot it would be if they noticed the horizontal scroll bar this produced and nobody ever did.

At least that’s my theory. It’s also possible that nobody ever used the software that I produced.

Ironically, one of the universal things I’ve noticed in programmers (myself included) is that newbie coders always go through a phase of thinking “why am I writing SQL? I’ll write a set of classes to write the SQL for me!” resulting in a massively overcomplicated mess that is a hundred times harder to use (and maintain) than a simple SQL statement would be. The most hilarious example of this I ever saw was when I took over a young colleague’s code base and found two classes named “OR.cs” and “AND.cs”. All they did was take a String as a parameter, append " OR " or " AND " to it, and return it as the output. Very forward-thinking, in case the meanings of “OR” and “AND” were ever to change in future versions of SQL.

I started my career with Visual Basic (3!) and I appreciated the loose typing because it meant I could get going and actually have something running quickly as a newbie. A few years later I switched to C# and saw how an entire class of errors disappeared because of the strong typing. Both have their place, depending on the skill level of the coder and the needs of the application.

It’s funny, the exact same logic applies to method and variable names. There’s no compiler that ensures that a method’s name accurately describes what the method does or ensures that a variable’s name accurately describes what the variable represents. Yet nobody ever says “you shouldn’t use descriptive method and variable names because they might be misleading”. And this is hardly academic: I can’t count the number of times I’ve run into methods that no longer do what the method name implies they do.

And yet method and variable names are exactly what people mean when they talk about “self-documenting” code.

There are no comments in the code

At my last job, I was assigned to a project being run by a straight-out-of-college developer who felt that not only were comments unnecessary, they were actually a “code smell”, a sign of professional incompetence on the part of whoever added them. It’s an insane philosophy that could only appeal to people who have never had to take over an old codebase.

I’m squishing your head!

Overrated. ON ERROR RESUME was much more fun.

Back when I still rode airplanes, I used to never shut my notebook off except when I was about to leave for a flight. Then I had the pleasure of watching Windows install 957 updates while the cab was honking outside.

I remember Macintosh computers from circa 1990. Even then Apple loved to just remove buttons because they hate buttons. Because it was so perfectly intuitive to drag a disc icon over to the fucking trash can icon in order to eject the floppy disc, they didn’t have a physical eject button for the floppy drive. Helpfully, they instead put the power button right where a floppy drive eject button should have been. So I was constantly turning the computer off whenever I wanted to eject a disc.

I assume this meme was meant to be pronounced like Gal Gadot’s “Kal El, NO!”?

I usually preferred male PMs, solely because my contempt for their lack of technical knowledge was never mistaken for chauvinism. Women PMs who stayed in their lane – or even better were actually technically competent – were A-OK with me.

My good PMs understood that their role was to attend meetings and create a buffer between myself (who understood what had to be done and was doing most of the work) and the higher-ups. The awful PMs were the ones who thought they were running the show and driving everything.