Refusing Limits on Learning
Chris Sommers spent a lifetime testing his limits, well before we even knew what “comfort zones” were. He was a startup junkie during the dot-com era. He taught himself how to code. He even bought a ranch and learned how to raise cattle and sheep. He heartily describes himself as “one part fearless, one part reckless.”
Oh, and he also loves LEGO® bricks…or at least LEGO metaphors.
This invention journey is one of the many stories we've been sharing as part of our Refusing Limits series. We’ll dive deeper into the unique approach each Keysight inventor brings to solving problems and explore how they are refusing limits to help Keysight and its customers push the boundaries of technology.
It seems like engineering students have more questions than answers about their careers. They know their choice of study will likely put them on a path to success, but they want to “engineer” that journey. How did you go from studying electrical engineering to earning patents related to a software dataplane programming language?
Thanks for asking. Well, I've always had an active interest in software development since I was a kid. I mean, I kind of learned software and hardware both when I was young, just as a hobbyist. Even though I got a degree in electrical engineering, I was always playing with code, and reading hobby magazines. I had the first “PC” in my college dorm, a Commodore PET with 8K of RAM!
Back in the old days of embedded software, a lot of the hardware folks wrote the code on microprocessors. There wasn't really an established firmware industry, as microprocessors were new, and whoever wrote the code was probably a hardware engineer who built the board, too. I developed a lot of software “by default,” but it was never officially part of the job.
Is this self-teaching an ongoing process?
I’ve been a voracious technical book reader since maybe the seventh grade, when Radio Shack was the main supplier of books and components for hobbyists, a million years before Fry’s Electronics. I also subscribed to Popular Electronics, Byte Magazine, and the rest. Relatives and friends would give me used trade magazines and data books. I ate them all up. Reading a lot of diverse stuff is like cross-fit training your brain for whatever it may encounter. Over the years I’ve gone through hundreds of books as each new technology became the rage: C++, Java, PHP, HTML, XML – it never ends and it’s all intriguing stuff. Now everything is online, which saves a lot of money and shelf space! I still cling to some of my favorite printed editions though, like old friends.
Over the years I morphed from a hardware design engineer into a software architect with almost no formal software training. There was a turning point when I quit my job as a Director of Engineering at a successful startup and I hung up my shingle as a “Software Consultant.” I literally was learning Java while hiring myself out.
That’s not always the easiest thing in the world to do—trying new things when you’re not fully prepared.
Yeah, I know that people don’t really like the phrase “fake it till you make it,” but there’s value in trying to get good enough at something to where you're ready to take that leap and just start doing it for real. I've just decided, finally, after a few decades that that is my modus operandi, and I just embrace it. Embrace the fear. Embrace the new stuff and just have some confidence that you'll be able to pull it off. I was relieved when I first learned the term “imposter syndrome.” It meant I wasn’t the only one who felt anxious when taking a chance and stretching out. It’s a sign of growth and opportunity. Imposter syndrome has been my steady companion!
That’s partly how I find myself in this awesome research job at Keysight. I joined the company with the acquisition of Ixia in 2017 and later discovered an internal job opening to research cutting-edge technology, exploring new things, and finding opportunities to use them ourselves, or generate new business based on them. And I thought that’s right up my alley—trying something new without knowing what I’m getting into and just go for it!
And that’s essentially what I do now. I’m given a lot of latitude to look at new emerging trends, pick some cool things to investigate, and then chew on them a bit until I land on some compelling ideas. I love to jump quickly into an internal POC [proof of concept] of some kind and/or engage with potential customers or partners to test the waters.
Is that what led you to your innovation in programmable dataplanes?
Yes. One of those investigations was in the P4 [Programming Protocol-independent Packet Processors] dataplane programming language, which was a new way of designing packet forwarding equipment to rapidly develop and deploy network device features.
I looked at using a new P4-programmable chip called the Tofino™ from Barefoot Networks [an Intel® company] to form the core of a Network Packet Broker. This would replace the fixed-function switching ASICs [application-specific integrated circuits] we were using. I did some PoCs but it didn’t get immediate uptake with stakeholders. I then tried using the Tofino as the core of a Packet Tester, which is normally built using FPGAs [field-programmable gate arrays] programmed in Verilog [a hardware description language]. This is a very difficult, time-consuming, specialized hardware design task and few can do it. If we could do it in P4, it would be a game-changer because P4 was comparatively easy to learn and use by hardware and software engineers alike. It would turn a tremendously difficult hardware task into a “routinely difficult” software task.
After learning the technology and experimenting with bits and pieces, we decided to go for broke and pull it all together in the form of a hackathon. Just go for it, right? The goal was to find a way for programmable chips built for network switching to generate and analyze test packets, which is kind of the opposite of the intended use case, i.e., switching. Normally we make equipment that generates and receives packets to test network switches. Instead, we hacked a network switch to become the tester itself. We sort of turned the paradigm on its head.
How do you jump back and forth between the hardware and software aspects of a complex system?
It’s all LEGOs to me – abstract components which fit together. And so that's what's so satisfying about it. Some of the LEGO bricks are typed into your laptop, and some of them are tangible hardware, but it's all about fitting them together. To me, the most satisfying thing is hearing that click when the pieces fit.
Thinking back over many complex projects, I think a lot of times some of the differentiators between successful ones, versus those that are struggling, are the composition of the team and how much collective experience they have in systems design, in addition to knowing their pieces. That only comes with experience and overcoming challenges. Like the saying goes, “If you’re not failing occasionally, you’re not trying hard enough.”
If you’re not failing occasionally, you’re not trying hard enough.
Engineers need to be not just curious but have the courage to try a little bit of everything, even when it's not comfortable. Try being an embedded developer. Try learning Python. Try writing test code. Seek out the things you love, knowing that no matter what that might be, it's going to inform the creativity and the originality that you bring to the table.
Originality? Is that formulaic in some way, or does that come more in the form of epiphany?
It’s a bit more of a continuum. That try-everything mindset creates different kinds of connections in your brain when you're looking at a problem. There is actual physical growth of your neurons when you learn something. So, learning a lot of different new things enables your brain to come up with novel ideas; it works like an app refreshing in the background—while I’m taking a shower or when I go to feed my cows during my lunch break. I go out. I throw them some hay. I'm walking up the driveway and then, poof, something new pops into my head. If you feed your brain, it will repay you with awesome ideas for free!
If you feed your brain, it will repay you with awesome ideas for free!
So, that’s your innovation process?
That’s the spark. There’s always a process on paper, but that’s more about helping people to collaborate, to stay on the same page, than a creative formula. It’s not like you can throw people into a conference room with some flip charts and an invention process diagram and expect meaningful results. Rather, I start with exploration, with research. Feed your brain. Figure out the unique problem. A goal worth achieving. Pitch a concept. An ambitious concept—because go big or go home. Start doing some experimenting and writing some code that stitches ideas together. See if it might bear fruit. Give yourself some latitude to try and fail and try again. To iterate.
Hopefully, you’ll achieve that “aha moment” and others will feel the same way. That’s the payoff.
Working on startups taught me the value of having short deadlines and tangible goals stripped to their minimum. It creates focus, drive, and creative tension, even a bit of fear. Get to a proof-of-concept, get more funding. Create a prototype, get more funding. You just commit to the challenge. Making it work when you weren't sure how you're going to get there when you started. Have faith that your past success will predict future success. Put some skin in the game and don’t give up.
We haven’t heard the word “faith” yet in our Refusing Limits interviews.
Faith. Shared enthusiasm. I think we need mavericks in every organization. People who don't play completely by the rules, and, you know, challenge the status quo of ideas. People who are just willing to say “I disagree” or “How about trying this?”. Mavericks don’t get overwhelmed by complexity. They find the straight line between the two points that are challenging them. They think about what’s easy. So brilliantly easy that someone will look at you one day and wonder why no one ever thought of it before—like the invention of the button or the zipper.
Mavericks aren’t afraid to look a little silly or a little crazy at times, and they keep pushing their ideas until they either convince their colleagues to press forward or take comfort that their idea may have been ahead of its time, and they move on to the next. They trust in the meritocracy of ideas.
That sounds a bit like the HP “next-bench syndrome.” Of pushing to create ideas that would intrigue the engineer at the bench next to you.
Yeah, I know Keysight has evolved over the years, having been spun out of HP and later Agilent, but The HP Way* is still alive and well. The ethics, integrity, high quality, and the down-to-earth engineering culture. Doing things with excellence and encouraging innovative ideas. I think that's just been built into the company.
You know, I started using HP equipment as a college intern. I can still remember these instruments and their model numbers. Power meters, vector network analyzers, spectrum analyzers, logic analyzers! And they were such a revelation because they were like magic boxes. The things they could do in measurement that I didn't even know could exist. And while I live in software now, I look at what our researchers are producing, at the specifications, and I can't believe these instruments can do what they do. It’s all just magic. I can't believe a scope can sample at, you know, sixty-four billion times a second. The limits they are pushing just boggles my mind. And now, it’s quantum physics meets electrical engineering. We never stop learning.
It’s all just magic.
(*) David Packard, The HP Way: How Bill Hewlett and I Built Our Company, New York, HarperBusiness, 1995
LEGO® is a trademark of the LEGO Group of companies which does not sponsor, authorize or endorse this site.
Intel and Tofino are trademarks of Intel Corporation or its subsidiaries.