When Gary Johnson first encountered NI LabVIEW, it arrived in the form of a simple brochure.

It was the mid 1980s, and at the time, Johnson was an electrical engineer at Lawrence Livermore National Laboratory (LLNL). His daily work involved complex instrumentation, proprietary software, and measurement tasks that often took far more time to configure than to execute. Like many engineers of the era, he knew the challenges of data acquisition built on custom code and rigid tools that resisted change.

Then a single image shifted his perspective.

The brochure showed an oscilloscope transformed into a spectrum analyzer. No hardware swap. No expensive overhaul. Just software reshaping the capabilities of an instrument. Johnson understood immediately how much traditional effort this transformation would normally require. Seeing it presented so straightforwardly felt like a breakthrough.

“I remember thinking, ‘How in the world can that happen?’” he recalls. “Then in 1987, I took the class, and even during the class I knew exactly what I wanted to do with it.”

Johnson was the only electrical engineer on a multidisciplinary team of physicists, chemists, mechanical engineers, and technicians. Their work supported laser isotope separation research, which meant constant measurement, data review, and iteration.

Before LabVIEW, even routine tasks felt slow and inflexible. Tools were difficult to reconfigure as experiments evolved. LabVIEW offered something entirely new. It allowed Johnson to draw a system, connect it visually, and make it run.

There was no internal debate about adoption. There was simply a Mac, a GPIB board, instruments already in the lab, and the freedom for Johnson to choose the most effective solution. The results appeared immediately.

During his first demonstration to colleagues, the reaction was instant recognition. They did not need to understand the programming to understand its impact.

“That was all it took,” Johnson says. “They could see it was useful. They could see it would make an impact.”

The early challenge was not convincing engineers to try LabVIEW. It was helping them recognize how much it enabled.

At that time, personal computers were rarely connected to external systems. The idea of a virtual instrument was entirely new to many engineers.

LabVIEW changed that mindset. It brought data directly into the computer, allowed engineers to manipulate and visualize it, and made it possible to achieve multipurpose functionality through software rather than additional physical devices.

Visibility played an essential role. Engineers were already accustomed to block diagrams. LabVIEW allowed those diagrams to execute. Instead of describing the system, the diagram became the system.

While LabVIEW history often highlights its most visible contributors, Johnson notes that many of its early breakthroughs came from individuals working behind the scenes.

One of those people was Jack McCrisken, a LabVIEW coinventor who played an important role during the platform’s formative years. McCrisken excelled at connecting engineers, identifying opportunities, and helping bridge the gap between what users needed and what NI was creating.

His influence on Johnson was especially meaningful. McCrisken encouraged him to write what became the first LabVIEW book. Johnson had never published a technical book and doubted he could. McCrisken disagreed. He arrived with an outline based on topics Johnson knew well and provided the momentum needed to turn the concept into reality.

The resulting book LabVIEW Graphical Programming became an essential resource for the growing LabVIEW community. It documented early best practices in data acquisition, timing, parallelism, and software structure. Many of its foundational principles remain relevant today.

LabVIEW did not just shape Johnson’s technical work. It also shaped his life in quieter, more personal ways.

The illustrations in LabVIEW Graphical Programming were created by Katharine Decker, an artist whose ability to translate complex technical ideas into clear visual form matched the spirit of the software itself. What began as a professional collaboration grew into something more enduring. Johnson and his illustrator eventually married, a fact that colleagues often remembered as emblematic of the LabVIEW community’s unusual blend of rigor and creativity. 

Engineering, for Johnson, was never isolated from the rest of life. The same curiosity and openness that made LabVIEW compelling also defined the relationships formed around it. In an environment where disciplines overlapped and collaboration was essential, it felt natural that technical work and personal connection would intersect. 

Throughout his career, Johnson led and supported increasingly complex systems. One project stands out as a defining milestone. He served as software architect for the control system of a 50 million dollar high average power laser known as HAPLS.

Developed at Lawrence Livermore and deployed in Prague, the system required nine full time developers, formal quality assurance processes, thorough testing, and complete documentation.

When the project concluded, the productivity data was striking. A parallel effort at the National Ignition Facility, staffed by more than one hundred programmers using traditional languages, achieved results of similar rigor. The LabVIEW team delivered its work with a documented productivity advantage of six to one.

The team did not take shortcuts or reduce quality. They simply used a different approach to engineering software.

“That is how I ended my career,” Johnson says. “After that, I was done.”

Technologies change constantly, yet LabVIEW has endured. For Johnson, the reason is simple. LabVIEW reflects how engineers naturally think.

It supports visual programming, parallel operations, and optimized machine code generation. It gives domain experts the ability to participate directly, even if they are not programmers. Johnson describes this collaboration as programming while you help. The system evolves while others watch, understand, and contribute.

“That is almost impossible in text-based languages” he says. “But with LabVIEW, people can follow what is happening.”

The ability to be both accessible and powerful is rare, and it continues to set LabVIEW apart.

Now retired, Johnson spends his time on hobbies such as ham radio, often using LabVIEW to automate and explore new ideas. When asked what advice he would offer new engineers, he does not focus on tools.

He emphasizes perspective.

“Learn a little about everybody’s job,” he says. “Everything is multidisciplinary. Depth matters, but so does curiosity.”

Curiosity is what drew Gary Johnson to a brochure decades ago. It is what led to a book, a community, and contributions that still support critical systems today.

Curiosity—more than any specific tool or technology—will continue to propel engineering forward.