Every now and then, I find myself writing about a topic that's been written about (too?) many times in the past. Usually, this happens when I stumble across an old article that resonates with my current work.

In this case, however, I didn't stumble across an old article – I had to actively go out and find it, because I remembered exactly what I was looking for: I was recently asked about the worst programming advice I've ever received (or read). ➦

You've spent days (or weeks or months) working on your project, and you're finally done! It feels great to be finished, and while you're not one to toot your own horn, you're really pleased with the results. You're going to be showing your project off to the group tomorrow, and you're stoked. With all of that pride and excitement bubbling inside, it can be crushing when the first three words of feedback you receive are, "it's good, but..." or "why doesn't it...?"

Having been on both sides of the fence – as both the critique-or and the critique-ee – I know firsthand that it's often very easy to immediately focus in on the negatives or shortcomings of something. Sometimes, this "negative focus" can even be rooted in a genuine interest in further advancement (versus simply ego or baseless criticism) – but rarely does it come across that way. Knowing that, let me suggest a small change that can make a big difference: ➦

Meeting etiquette has been written about ad nauseam, but given the recent surge in remote work, I did want to make one point...

Virtual meetings should be treated with the same respect that you would treat in-person meetings. If you booked a conference room for half an hour and someone else had the room right after you, you'd have to wrap up your own meeting quickly to let the next group have the room. Just because there's no physical room to relinquish in an online meeting, this shouldn't be an invitation to let meetings run long – especially if it means keeping you or others from their next scheduled meeting or obligation. ➦

If you add a breakpoint and your entire screen turns red, you may want to rethink things. I recently inherited a .NET/C# project – and what I found shocked me... ➦

If you've read my article The Stigma of Simple Software, you know that I'm a big proponent of keeping things simple... and this includes making design decisions. Now obviously, I'm not advocating throwing things at the wall and hoping they stick. I'm advocating being pragmatic. ➦

This is probably the only phone-related post you'll ever see from me because (quite frankly) I hate cell phones. They're addictive distractors that ruin driving and family dinners, and if it weren't for the growing ubiquity of multifactor authentication to do even the most mundane things, I probably wouldn't even own one.

That said, about a month ago (mid-December), my Moto G7 stopped providing notifications when I received a text message. The screen would turn on and notify me visually if I were lucky enough to be looking at my phone at that moment, but it simply would not ring or vibrate. From what I could tell, the issue started roughly at the same time my phone auto-updated to Android 9.

I tolerated the problem for a while initially, thinking only to myself how asinine it is that the most basic functionality of a cell phone can not only be inadvertently (or even automatically!) disabled but also such an ordeal to figure out how to restore. After missing several important text messages, I'd had enough, and I needed to get this figured out. ➦

I'll admit it: I write simple software. I'm hesitant to actually use the word "admit", however, as it suggests that writing simple software is some type of engineering sin. That said, I'll also admit that on a broader scale, I aim to design simple systems.

There is no shortage of advocacy for writing simple software – some dating back several decades. The Zen of Python, a list of 19 (or 20) software design tenets (largely applicable to any language) decrees "simple is better than complex" as its third commandment. Software design acronyms like KISS (keep it simple, stupid) and YAGNI (you ain't gonna need it) are familiar to many developers, and despite their wide, general acceptance amongst most, there nonetheless seems to be no shortage of over-architected and over-complicated software being written. Why are we making things so complicated, even when we know we shouldn't be? ➦

American psychologist Abraham Maslow is noted for what is often called law of the instrument and his famous quote, "I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."

This quote is frequently used today in a variety of contexts to speak to the natural tendency to rely (often too heavily) on a familiar tool to solve unfamiliar problems. Of all of the technologies I've worked with, I've seen this "everything is a nail" mindset most often in the realm of Node.js. ➦

While this post could really apply to anyone in any job, I think it's particularly relevant to developers – where staying up-to-date with technology is part of the job career and critical to success...

Early in my career, I willingly took a job for far too little pay – and far too much work, including a lot of out-of-state travel. I did so because I wanted exposure to newer, better tech stacks and a larger team to collaborate with, and I knew I'd never get this at my then-current company. ➦

There are things in life that you find folks either love or hate, with seemingly no one sitting on middle ground – things like squirrels and cilantro...

Some people find squirrels just the cutest little things, even inviting them to their yards enthusiastically, eager to watch their foraging and deft acrobatics. Others find them nothing more than vermin, seemingly set only on stealing bird seed, harassing pets, and damaging property.

Cilantro's another one... ➦

I took the Google Cloud Platform (GCP) Associate Cloud Engineer exam today – and passed. ➦

A coworker came to me today and asked if I would take a look at some code he'd written. He was getting an exception in a Razor view, and he couldn't figure out why. After picking apart the code, it turned out to be a pretty tricky issue – one which I'm assuming is actually due to a bug in Visual Studio 2017. ➦

I try not to get sucked into age-old programming "religious wars". You know, things like tabs vs. spaces, light vs. dark IDE, semicolons in JavaScript, etc. I have my opinions on them (like everyone else), and I have my rationale as to why: tabs (faster), dark IDE (easier on my eyes), and yes to semicolons (readability) – but I'm not going to waste any time writing about those opinions (beyond this paragraph, I guess...)

There is one topic, however, that I do have a stronger opinion on, and that topic is programming font ligatures. I'm still not going to get into a heated debate over the topic with someone, as it is (like many things) personal preference. That said, I did want to share my thoughts on why I dislike them. ➦

So the thing is, I never actually intended to start this blog. I wrote the exact same blog engine three times using three different stacks as an exercise. I wanted to see how long the same project would take me in three different stacks – and whether any differences in time were due to my level of proficiency with the given stack or due to inherent differences in the stacks themselves. Ultimately, when I was done, I decided to keep the blog engine around and use it for some random musings of mine... so here we are. ➦

JS1k 2019 has ended, and the results are in! I wrote a quick Python script to take the official results page and the page containing all of 2019's demos to produce a consolidated list of all participants, their entries, scores, etc. for easier review. ➦

When the JS1k 2019 theme of "X" was announced, the first things that popped into my mind were "X games" and "generation X". Eventually, I started pondering retro games of my youth, and I decided to try to do a few (hopefully) faithful 1K reproductions of (or at very least, tributes to) some classics.

I've always liked Activision's Atari 2600 games, so after a quick search, a flood of nostalgia, and a few failed attempts at cramming other games into 1K (Pitfall, River Raid, Jungle Hunt), I figured I'd give Activision's classic Boxing a try. ➦

Now that my JS1k 2019 entries have been submitted, I put together a list of all of the JS1k demos I've done over the years. ➦

JS1k 2019 opens today! If you're not familiar with JS1k, it's an annual competition where the challenge is to write something cool in no more than 1K of JavaScript. Packers, minifiers, etc. are all allowed – your entry simply needs to be 1,024 bytes or less of valid JavaScript with zero external dependencies. ➦