Curiosity is vital to your team’s talent and mood. It may seem like chasing after cars from the outside, but tackling some question that catches your attention is both energizing and inherently valuable.

How Chasing Ideas is Valuable

The core of any quest into Curiosity Land is “What if…?” or “What is…?”

That means you’re starting with the immediate premise of “There is a thing I don’t know or fully understand, and my goal is to fill that knowledge gap.” Figuring something out for yourself is probably the best learning you can do, because you don’t just have it handed to you. You reach the conclusion and you know how you got there. You know how the watch works, not just that it tells time. That sticks with you.

In software, that means testing, measuring, and finding answers. These are like muscles, and the more you use them, the faster those reflexes kick in. They positively affect your problem solving skills. Debugging becomes faster, and the developer becomes more resourceful.

A Silly Example

An example of curiosity might be a recent experiment: What if it’s possible to write an array_reverse function that’s faster than PHP’s built-in function?
Spoiler: It isn’t. I wondered if the knowledge that the array is sequentially keyed might help speed things up.

I started with a simple benchmark: Take a 1-million element array and reverse it. Run that 20 times, take the average of execution times. Try to make that number smaller.

In the end, I couldn’t beat the PHP system array_reverse time of 0.200 sec. The closest I got was 0.345. But it forced some interesting optimizations you don’t normally think about in day-to-day PHP code, and resulted in the following lessons:

  • If you know the array is sequentially keyed (i.e. not a hashtable) you can call end($var); $last = key($var); to get the array length in a much faster fashion than using count($var). A difference of 0.278 sec, or ~55%. I had used this trick before, but hadn’t benchmarked it.

  • Bitwise math doesn’t really seem to save you any time in an interpreted language (from what I’ve observed at least), so it’s best kept for actual bit manipulation versus trying to cheat your way around using floor/ceil functions.

  • In this very special case, you can use a sort of symmetrical loop to swap elements without needing to ever calculate the center point at all: for ($i = 0, $end = key($data); $end > $i; $i++, $end--) ...

These aren’t particularly useful lessons, except for maybe the bitwise math one in a “things not to do” sense. count() will usually be sufficient for your purposes unless you do something silly with it like use it on every iteration of your loop, and the end/key optimization only works on sequentially keyed arrays. I do think this was the first time I’ve ever had reason to legitimately use two different statements in the 3rd part of the for-loop, but I knew I could do it.

Ultimately the knowledge gained here is that the built in functions that call compiled C code are probably going to be faster than whatever you can cobble together, regardless of cleverness.

Knowledge is It’s Own Reward

Learning something new based on experimentation is very rewarding: You earned that knowledge. I may not have succeeded in my (admittedly ridiculous) attempt to beat built-in functions, but I learned a bit, and answered my question. That knowledge can now inform future work, code reviews, and so on.

There are mood benefits in addition to the raw knowledge gain: Reaching the conclusion is satisfying, and it recharges you for more boring day-to-day work.

Maybe you’re under a deadline all the time, but I’d encourage you to make the time to allow your developers to chase after ideas and curiosities. The benefits should generally outweigh the cost.