Author: Jud

Technologist interested in building both systems and organizations that are secure, scaleable, cost-effective, and most of all, good for humanity.
User Error Isn’t

User Error Isn’t

By | | Comments 0 Comment

It happens to every developer at some point. You spend a bunch of time trying to determine the source of an urgent bug, only to find out the problem was caused by action or inaction of the user. It’s easy in that moment to be frustrated, but may I suggest a more circumspect path? It behooves a thoughtful developer in these moments to consider if the source of the user error was caused by poor design. Perhaps the button wasn’t in an obvious place, or the side effects of the command were not obvious, or the name of the feature didn’t describe the outcome. In many (even most) cases, user error is preventable with good design.

Yes it’s difficult, and perhaps impossible in some situations. But it is the high calling of the software engineer to design products in a way that a user almost subconsciously knows how to operate without error. Viewing design with this attitude saves a lot of frustration.

It might seem this is a counter argument to Not Even Mostly, but actually they go hand in hand. A user must be carefully listened to and considered, but sometimes they must also be guided into the features they really need, versus what they say they want. Do that hard work up front, and you’re more likely to have a system that minimizes the potential for mistakes.

Also, go read The Design Of Everyday Things.

Covfefe

Covfefe

By | | Comments 0 Comment

Even the smartest and most experienced developers make bone-headed mistakes, the kind that require hours of painful debugging only to find a comma was misplaced, or a one should have been a zero. While a good amount of effort should go into avoiding these errors, the energy required to prevent them completely would be astronomical. A better approach is to balance prevention and detection, hence the importance of good peer review and solid automated testing.

Winging It

Winging It

By | | Comments 0 Comment

I keep a running list of topics, but today I’m ignoring it and shooting from the hip. A stream of consciousness post, if you will.

Yesterday evening I added a couple new features to an Ionic app. I’m really appreciating the improvements brought by Angular 2; it’s made the architecture quite a bit cleaner than before, and adding new capabilities is quick and painless. I still have a ways to go before I fully grok observables, but I’m getting there.

Was talking with a musician friend of mine on Sunday about the difficulty of making meaningful progress on a project without having at least 2 continuous hours of focused time to work on it. Half hours here and there don’t cut it. That’s an important truth both for us nerds who try to do side work in our spare time. It’s also an important reminder for non-nerds who feel the need to interrupt the nerds in their charge.

Speaking of interruptions, nearly 6 hours passed since I wrote that past sentence due to an urgent production bug. Who knew when I woke up this morning that by noon I’d be decompiling Java classes from a production server. Yay!

Numbers Do Lie

Numbers Do Lie

By | | Comments 0 Comment

The Internet is a funny place. Yesterday was the first weekday in some time that I didn’t write a post, yet I had the most page views in a single day since I created this thing. Apparently someone (or some-bot) in Canada decided to read every single post I’ve ever written. A roughly similar thing happened a few weeks ago, when a post I spent quite a bit of time on got only a handful of views, while the filler I wrote the next day got three times as much traffic. I’m not complaining, just observing that it can be difficult to predict how consumers will respond to a product.

I think there’s a lesson there for aspiring software developers (and really creators of all types). Don’t get too hung up on numbers or popularity. Don’t think less of yourself just because your app didn’t blow up like Facebook or Instagram (those guys will tell you that was luck as much as it was hard work). Simply do the best work you can.

When I decided to revive this blog, I wanted to post daily for two reasons. I figured it would draw more traffic to have more content, but more importantly, my writing muscles had atrophied and needed regular exercise. Ultimately this whole thing is for my own enrichment, but if it helps others, great.

Not Even Mostly

Not Even Mostly

By | | Comments 0 Comment

Customers are a finicky bunch (they’re human, just like everyone else). That means they’re not always right, and any business practice that assumes they are is likely to fail in the long run.

Don’t hear me wrong, I’m not saying that software engineers shouldn’t listen to customers. Nor am I saying businesses shouldn’t careful consider their customers’ demands and in certain situations give in. I’m really speaking more to an attitude of continual acquiescence. That’s not helpful for a customer who may not have the skill to evaluate what he wants, and it’s not healthy for a developer when they see their professional opinions thrown to the wayside.

If a relationship isn’t a two-way street, it’s probably not worth having.

Turn And Face The Strange

Turn And Face The Strange

By | | Comments 0 Comment

Writing requirements is hard. Rarely is enough thought put into them, and even when a lot of time is spent, gaps are inevitable. Thus the most important feature to build into a system’s architecture at the beginning is the ability to change. Without that, all other features will quickly become obsolete.

Trump Card

Trump Card

By | | Comments 0 Comment

I’ve had the opportunity to perform a bunch of job interviews in the past couple of years. It’s been a tremendous learning experience, and I’ve enjoyed contemplating the various psychological factors that go into both interviewing and being interviewed.

My quip from a few days ago was mostly tongue-in-cheek (sorry, dear wife), but if you do want to impress me in an interview, take some time to tell me everything you don’t know. Yes, you read correctly. I want to hear about your ignorance.

You see, there’s a well-documented psychological phenomenon called the Dunning-Kruger effect. It’s a cognitive bias where the incompetent person, due to their incompetence, lacks the skill to evaluate their own shortcomings, and hence overestimates his own capabilities (the opposite effect is known as Imposter Syndrome). I’ve seen these play out time and time again as I’ve evaluated job candidates; in fact, I know of no quicker way to get a general sense of a person’s skill. Besides, describing shortcomings demonstrates humility and self-awareness, two valuable personality traits in any field.

The domain of software development is immense; no single person can possibly know even one-tenth of one percent of what can be known (we’re all only human). The best developers know this, and can describe the boundaries of their own knowledge. Those who cannot probably have no idea what they’re doing.

On The Shoulders Of Giants

On The Shoulders Of Giants

By | | Comments 0 Comment

Last night I wrote my first Cordova Plugin (a little tool that allows an app to determine the local IP address on a Windows 10 device). I was proud of my success given limited documentation and a poor development environment (just a Surface 3 and command line tools).

What made me particularly excited, though, was that I could give my update back to the open source community via Github. Every developer on Earth has benefited greatly from the availability of high quality and easily modifiable free software, myself not the least. I enjoy every opportunity to give back in some small way, and I encourage all developers to do the same.

If nothing else, it makes your résumé significantly more attractive.