Every engineer remembers the first project that changed the way they think.

Mine wasn’t a production test system or a customer deployment. It was an alarm clock.

At the time, I was a chemical engineer at a seven-person startup, testing a material designed to shunt electricity to ground and turn itself back into an insulator in an instant. We needed mountains of data—and at a startup, you roll up your sleeves. For me, that meant pushing a button, reading a graph on an oscilloscope, hand copying the result onto a piece of paper and doing it again. And again.

Then we came into contact with someone who was good at programming in NI LabVIEW but didn’t know what I as an engineer was trying to test, so we sat together. I told him the what and why. He implemented the how.

Watching over his shoulder, something clicked. I wasn’t a software developer. Honestly, I had a hard time programming even my calculator—but I got my hands on a copy of LabVIEW, installed it, and asked myself how I could learn to use it. The answer: build something useful, something I had a stake in, something fun.

I wanted to wake up to music, so I built an alarm clock.

The first version was humble. When the alarm time arrived, a Boolean indicator lit up on the front panel. Nobody wakes up to a Boolean on the front panel.

I kept going. I figured out how to control Windows Media Player and wake up to a song, then I fed it a whole directory of music. Next I randomized it, filtered out anything that wasn’t an MP3, added support for as many directories as I wanted, and finally taught LabVIEW to scan my entire computer and assemble playlists.

Every answer led to another question. Every question led to something new I could build.

LabVIEW let me dream.

For many engineers, learning software means translating their thinking into someone else’s language. For me, LabVIEW felt different. LabVIEW thought like I did.

The palettes were navigable, with functions arranged in an intuitive hierarchy that invited exploration. I didn’t know how to traverse a programming language. I didn’t even know the questions to ask. The integrated development environment (IDE) let me discover those questions, and the block diagram parlance I already used as a chemical engineer translated almost one-to-one.

The tool became invisible and just worked with how I thought. I self-taught programming by chasing my own curiosity. I still have the source code.

That curiosity carried me to the NI Applications Engineering department, where I became the go-to for LabVIEW questions. It also followed me into my side projects. Curious about the 3D picture control, I decided to build a virtual Rubik’s Cube I could rotate in space, just for fun, a couple of months before NI Week.

Serendipitously, a fellow AE, Rudi Ngnepi, happened to be building hardware that could physically solve a Rubik’s Cube. We started wondering: could my software talk to his hardware? Soon, a scrambled cube placed in his machine appeared as a 3D model on my screen. Then we flipped the roles, and button presses in my UI physically articulated the cube in Rudy’s machine.

Today, the industry would call that a digital twin. At the time, it was two engineers, one in software and one in hardware, asking the engineer’s favorite question: I got it to do this. I wonder if it can do that?

That pattern repeated across my career. Five years in DAQ R&D owning the DAQ Assistant, a tool built so scientists could get their data without worrying about which API call to make. Development on the NI Sound and Vibration Measurement Suite. A move into marketing, where I created the LabVIEW Champions track and delivered a LabVIEW keynote in Germany, Poland, and Washington, DC. Then to Cirrus Logic as LabVIEW Validation Infrastructure Architect, and on to founding GCentral, a nonprofit devoted to helping LabVIEW developers share code, which NI backed with $100,000 in funding. Today I’m a consultant at DMC, applying the NI platform in compliance with NASA 7150.2 to the automated test system for NASA’s Space Launch System boosters.

Ask me what connects it all, and I don’t hesitate. My vision is a world where the full force of scientific discovery and engineering innovation accelerates human flourishing. LabVIEW and the NI platform are the best tools I’ve found to keep engineers and scientists close to the engineering problem. 

I think about AI in engineering in terms of what it does for the person trying to accomplish a task. The applications that excite me are the ones that remove what I call administrative work, and the NI Nigel™ AI demonstrations from the NI Connect keynote were exactly the right kind. Show me the data for the tester that’s currently running. Overlay yesterday’s data. Identify the outliers. No dashboards to hunt down, no code to write. I could think of a thousand other tasks that I want AI to do.

I’m equally clear-eyed about the harder problem: as engineers, we remain accountable for what AI generates, and verifying tens of thousands of lines of generated text is difficult work. That, I would argue, is exactly where LabVIEW holds an advantage.

Graphical programming lets me condense more information into an observable space than a whole bunch of linear text. I can see at once more than I could by scrolling through tens or hundreds of thousands of lines of code.

Block diagrams are the language of engineers, and they are the language of LabVIEW. In an era when humans must be able to observe and verify what intelligent tools produce, a platform built around observable, visual code is not a legacy. It is a leg up. That’s why I foresee the future of LabVIEW as positioned better than other programming environments.

I’ve seen this platform from every angle: builder, marketer, customer, champion, and critic. My conviction traces back to something simple. The same quality that let a chemical engineer teach himself programming by building a better alarm clock is the quality the future of engineering demands: A tool that thinks the way engineers think and gets out of the way of the problem.

After all, it was the tool that let me dream.