DEV Community: Ricky

A Mistake Is Not An Error

Ricky — Fri, 18 Apr 2025 06:38:14 +0000

I think the topic of this post is related to "Error Prevention and Handling" from the Human-Computer Interaction (HCI) usability principle. I think most people (in related fields) are already aware of this topic.

Recently, a client asked me to make an event schedule and its editor interface (imagine Google Calendar but way simpler) for one of their event's websites. The implementation is quite straightforward, a button to an item to the schedule, an editor for the item details, some validation, sorting the items by time, and making the frontend display the data. The implementation itself is not technically complex. But, something interesting happened when the client tried to interact with the interface.

I was surprised that the client asked me how to manually sort the events (i.e. putting a certain event before another). Me being me, I told them that the events are automatically sorted by their date and time to prevent mistakes and remove the need to sort. Thankfully, the client understood what I meant and apparently, they just needed a reverse sorting order. From that interaction, something just clicked in me. A mistake is not an error, let me explain.

Say, for example, you are writing a list of alphabetically sorted fruits from 'A' to 'Z' in Notepad. If you put 'Banana' before 'Apple', I would call that a mistake. However, if Notepad crashes after you type 'Apple', that is what I would call an error. In reality, Notepad won't crash if you somehow messed up the order of your fruits, because it does not care about ordering or what you typed in as long as it can be parsed to text. Why is all of this important? Well, because the principle is called "Error Prevention and Handling", I think it is pretty reasonable to expect that we need to understand what an error is, so we apply the prevention and handling part to it. I think my mental model of what counts as an error is quite simple and quite common; If a system cannot continue to function normally after a specific sequence of events I would categorize that sequence of events as an error.

Going back to the original schedule editor, allowing the client to sort the events manually is not an error, because the system won't crash when the order of items is changed. However is it wrong to see an event at 8 AM nestled between events at 6 and 7 AM in an otherwise orderly list? I would say so. However, here is where things get more 'human'. If all stakeholders agree that the ordering is not wrong, then it is not wrong, and vice versa. After all, it’s our design choices as humans that decide what is right and wrong.

I think it is good to have an understanding of what an error is and what is not. That being said, I don't think having too rigid of a definition would be good either since the real world often doesn't agree nicely with a rigid definition of stuff. Why do I think it's important to have an understanding of this topic? Because it will result in different ways of handling an error and a mistake. With an error, I would try to prevent it from happening in the first place or make sure there is a recovery path if the error occurs. But with a mistake, I can be a bit more lenient with how to handle it, I can ask users to make sure if they inputted the right thing or not, or I can make sure that the mistake is easily reversible.

Anyhow, this is the end of this post. I don't know what else to say. For anyone reading this, thank you for reading until the end. Also, what do you think about this topic? Do you have your mental model of an error and mistake? Do you think I just wrote a bunch of nonsense? Leave a comment, and tell me what you think. Cause I am curious about what other people think about this topic too.

This post is also available on my personal site

Edit:
Now, that I think about it, maybe this is another way I can put the difference between an error and a mistake into words. An error is something the system can detect, but a mistake is something a system cannot detect. Not sure if putting it this way is a good way to say it or not.

Is Authentication Just About What The Server And Client Know And Don't Know?

Ricky — Mon, 19 Aug 2024 13:58:27 +0000

Context: I'm writing this while watching YouTube, and this goddamn thought just went through my head. I'm writing this to see what other people think about this.

Alright hear me out...

Does every authentication method relies on the server having something to validate the client's credential?

Password Authentication, the server got the hashed password (or whatever form it stores the password in) and the client don't. This security lies in the client knows or not about the original password that was used to create the hash.

API Keys (or token auth), the server got a list of valid keys/token, and the client doesn't. Again similar to password, the server knows something the client may or may not know.

MFA, when you create the authenticator, the server give you the unique MFA string (no idea what its actually called, but you get it the MFA seed/qr code thingamajig). Again the server has the code to validate against and your authenticator has the algorithm to generate the code that will pass the validation. Isn't this pretty similar to password based auth but with extra steps that generate the unique MFA code?

Biometrics, IDK... The server has your biometric info and you have... Your biometric I guess, and you input your biometric and the server will validate against its data (I think thats the gist of it). Sounds close enough to password to me.

In theory, can I just have a random string sitting somewhere on my server and allow user to login if they know that string? Isn't a dumb version of the password authentication?

My fucking god, I feel so stupid when thinking about this. What do you think? Does my rambling sounds about right or nah?

Also there is the Google Prompt you get on your phone when you log in from a new place, does that also relies on the server knowing something the client does not? Or how does that work? I got no idea really.

Also what other authentication methods are out there? Do they also hinges on the server knowing something the client does not?

Human Friendly Code?

Ricky — Tue, 28 May 2024 12:35:12 +0000

Why do we code? Do we code only to satisfy the requirements of the product owner? Or do we code just so it could pass through QA? Are we just trying to get a passing grade for a class assignment? Or are we just having fun writing random stuff?

I think it is easy to forget that there are real people out there who will interact with our code when we are so deep in implementation details. Different people may interact with your code in different ways. An end user might interact with your code through the user interface, another developer may interact with your code through the API, or maybe the coworker next to you is interacting directly with your code. Whatever the means, there will always be another human in the chain interacting with the code you’ve written.

Knowing that there is another person that will interact with your code (be it user interface, API interface, or class/method interface), how do you make your code more "human friendly"?