Sometimes I have to step back and take pause because I’m just too darned fascinated by the technical puzzle in front of me. This is a very common pitfall for a lot of software engineers, I think: losing sight of the larger problem (building a high-quality, functioning software application/library) in favor of some obscure smaller problem that seems more interesting.
I mean, it’s in my bones or something. Ever since being a kid I’ve always loved puzzles, logic problems, “mind twisters”—whatever you want to call them. I would always prefer those extra credit problems to the regular math homework; they were just more fun to think about, and more satisfying to solve.
This is just a personality trait, and I think it’s one that a lot of software engineers probably share. And it’s probably part of what has led so many of us to become engineers in the first place, as well as what makes us good at what we do (if we are, in fact, good at what we do!). But as I’ve said, it can also be a curse. It can seriously hinder your productivity when instead of fixing bugs or building new features you spend all your time thinking about the most efficient algorithm for, say, comparing two sequences to see if they contain the same elements.
And that is precisely what I’ve been spending too much time thinking about this morning.
Incidentally, can you think of a better way than this?
- Create a hash table from the first sequence, where the element is the key and its number of occurrences is the value.
- Scan the second sequence:
- If an element is not in the hash table, return
- If an element is in the hash table, decrement its value and return
Falseif this falls below zero
- Check whether all values in the hash table are now zero.
I definitely need to work on this.
[This ending left intentionally ambiguous]