One of the most difficult things to identify are personal assumptions. We can quickly understand new things by making assumptions based on previous, similar things. For example, it is assumed nearly all Windows programs will have a toolbar running across the top with a File option. Under this File option, you typically expect or assume another set of options that may include something like Save, Open, and/or Print.

Personal assumptions are very difficult to identify because they are often so ingrained or, possibly worse, shared among a group that to question it (is it an assumption or is it fact/standard?) is pretty rare. But to ask the right questions can sometimes be eye-opening.

For example, there were a few assumptions that I made in the above toolbar statement. I addressed one, that being, “nearly all Windows programs” have a toolbar. Some browsers, like Chrome, do not have this specific toolbar. Another assumption was that it ran across the top (ex. Chrome, it’s actually a menu off on the side). The third assumption is the File option being present on the toolbar (ex. Chrome, there is no “File”, just an icon with 3 horizontal bars or the hamburger icon). I won’t go into the sub-options of Save, Open, and Print, but you can hopefully see where I’m going with this.

Another example. In an interview, I was asked to design some classes based on a set of character types in a video game. There were three character types: melee DPS, ranged DPS, and a tank. Having done extensive research on games not too long prior and having a preference for a specific genre of games, my mind jumped to the holy trinity of RPGs (tank, heal, DPS). Problem was, this was a major assumption on my part and the interviewer called me out on it. Turns out he wanted to make a strategy game. (Oops.) It didn’t feel good, but it’s one of those lessons that help keep you grounded and have a more open perspective.

But, no one’s perfect. Even after that embarrassing experience, I struggle to identify my assumptions with my daily work. Turns out it’s very easy to get hyper-focused on requirements, but really difficult to realize when you’re being too narrow. In my case, I didn’t realize it until I was just about to check in my code.

We have an old SQL Server database with a table and VARCHAR column, meaning, unless we tinker around with collation options, its character set is limited to ASCII and extended ASCII. This table is associated with usernames and passwords. My task was to add in the required checks to make sure data going in met VARCHAR requirements. And passwords also have to be strong–at least one special character.

Early in development, I decided instead of using my “!” special character, I would just replace it with a Chinese character assuming a user would get smart and try to use it to fulfill the special character requirement. That Chinese character became synonymous with the “special character” requirement in my mind. My development goes on, my tests get written, I’m ready to check-in, and all is–wait.

I check to make sure my Chinese character doesn’t count as my special character. But I never check to make sure Chinese characters are nonexistent in the string. That second point is more important because if a Chinese character gets into the database, the system gets unhappy. Yes, I had to make sure a special character from the ASCII set was present, but I also had to make sure non-ASCII characters were not present. Narrow vs. broad.