My kids play a game where they pick out people and argue about what their superpower is. If we’re all indeed born with a superpower, I’d have to say mine is ignorance. Admittedly – and, yes, unfortunately – this is a superpower that couldn’t be more lame. But accepting the hand I was dealt, I feel like I’ve turned ignorance into an advantage.

Before we go further, let me clarify what I mean by ignorance. I’m not going by the scornful “he’s an ignorant jerk” definition, I’m using the dictionary definition: lack of knowledge or information. Being engineers in a very technical field, it’s normal to work with all kinds of genius types that genuinely seem to know a lot about everything. I’ve worked with many; sadly I’m not one of them. There’s so much I don’t know that it’s embarrassing at times. But again, I feel like I’ve turned not knowing things into an advantage.

Thinking back to my first experiments with agile development and a tactic I learned called The Feature of the Week, this is probably where I first realized the power of not knowing something. In the early days with one of my first ever clients I inherited the responsibility of verifying a moderately complex SoC subsystem. It came with a testbench that was fully featured and mostly coded but untested and yet to be used. Before learning much about the subsystem or understanding the testbench code, I stuck my neck out and suggested I could deliver a small bit of useful functionality a week after our planning concluded.

I’d never done it before, but making that early commitment was the right thing to do. I could provide designers with a small yet valuable portion of the testbench that they could use to start eyeball checking the design. It also gave me a chance to build trust with my team much earlier than I was used to (i.e. they could see first hand that I was doing something useful). The challenge with that early commitment, however, was that I was forced to compartmentalize to an extent I never had before.

At first, I thought I could simply ignore 99% of what I responsible for to focus on the 1% I needed to deliver. The testbench code was there and I could just use the part I needed. Compilation and unrelated runtime errors struck down that theory about 30 minutes in. It was obvious I had a lot of work to do just to focus, also that I wouldn’t have time for it. This is where my superpower kicked in. Instead of fixing the testbench code necessary to focus, I removed it. All of it. Entire transactors, commented out, regardless of whether or not I knew they worked. The code I didn’t need was in my way and it had to go.

Stripping the testbench down to what was absolutely necessary wasn’t something I planned but it was absolutely the best approach given the circumstances. It turned an unattainable goal into something manageable. It helped me compartmentalize the problem in front of me while demoting everything else to the periphery. It did provide a small value to the design team and also helped build early trust, just as I hoped. That first delivery also became a baseline on top of which I could incrementally overlay new functionality. Aggressively focusing on functional, near term objectives in this way – assuming of course they provide value to others on the development team – is something I’ve done regularly ever since. It’s never let me down.

The moral of the story? I’ve found that knowing only what you need to know and ignoring the rest can be a valuable addition to verification strategy. Embracing a day-to-day need-to-know policy can be just as valuable – not to mention easier – than trying to know everything.

I’d rather be a genius. But knowing what not to know can work, too, especially for people with superpowers as super-lame as mine.

-neil