I’ve been reading a series of technical and computing books recently, as I pick up my Python studies. I naively stumbled into coding assuming all I needed were the terms and grammar of a knew “language”. But there’s so much more to learn for someone who has mostly had a liberal arts education.
It’s a completely different mode of thinking. You often see coding/development described as “problem solving”, but I don’t think that is quite acurate. I have been bumbling my way through a kind of alien logic.
Actually, the best example comes from a recent problem I encountered on Brilliant:
Define a comparison as an operation which takes in one number and tells you whether it is larger than, smaller than, or equal to, another. Suppose you are given a sorted array with 1000 elements, and you can use at most n comparisons to determine whether a certain number is in this array. What is the smallest value of n such that you will always be capable of making this determination, regardless of the values of the elements in the array?
Essentially what they are asking me to do is conjure up a number and find that same number in a sorted list of 1000 numbers. What’s the smallest number of comparisons I would need to make to find the match? I sat stumped for quite a while with this problem.
Eventually I gave up. I couldn’t fathom how to even approach it. Having now seen the solution I can’t imagine I would ever have arrived there through deduction alone. It wasn’t so much a lack of knowledge of terms etc., my regular heuristics simply don’t apply.
Another example comes from a book called How Software Works, which I am currently working my way through. This is from a chapter on protecting passwords:
Authentication systems need a way to strengthen hashing without a performance-crushing number of hash iterations; that is, they need a method of storing passwords that requires an impractical time investment from attackers without creating an equally unrealistic time burden on legitimate access. That method is called salt… The salt is a string of characters, like a short, random password, that is combined with the user’s password before hashing. For example, user mrgutman chooses falcon as his password, and the system generates h38T2 as the salt….
The salt and password can be combined in various ways, but the simplest is appending the salt to the end of the password, resulting in falconh38T2 in this example. This combination is then hashed, and the hash code stored in the authentication table along with the username and the salt…
If there are, say, 100,000 users in a stolen authentication table, and the salts are numerous enough that no salt is duplicated in the table, the attacker will need to create 100,000 tables. At this point, we can’t even call them precomputed tables because the attacker is creating them for each attack.
Buried in a section about scrambling (not the right word I know) passwords so that they cannot be reverse engineererd and easily matched, we have this interesting solution. Simply append a random string to the password before scrambling. Put this way it’s quite simple and I can follow the logic. But getting this far requires a kind of thinking to which I am unaccustomed.
On the surface, that different fields have different approaches isn’t particularly profound. But it’s not often that we get to feel out of our depth on a “I don’t even understand how to logic this out” level. I am definitely feeling that right now.
(As always, my emphasis)