2026-08-25 21:00:01
At the height of the Cold War, one very specialized computer was so secret that the world didn’t know it existed. It ran its jobs up to 200 times as fast as any other computer of its time. It was the U.S. National Security Agency’s main cryptographic processor in operation from the time of the Cuban Missile Crisis in 1962 through the Vietnam War and on past the 1975 Helsinki Accords. The machine stopped running only when its moving parts finally gave out.
The Harvest computer mattered because of what it was as well as when it ran. For 14 years, it was the engine processing the NSA’s most sensitive intercepts at a time when signals intelligence was as close to a strategic weapon as anything short of a warhead.
Designed and built by IBM for the NSA, Harvest was one of the first machines designed to apply operations to enormous datasets rushing past, a precursor to the computers today that manage continuous video streams and security systems in real time. It was also one of the first machines built as an add-on—a specialized helper intended to do one job exceptionally well, bolted onto a general computer. Harvest’s modular design is like a 1960s version of today’s graphics chips that CPUs use to run intensive video-game and AI processing loads.
All that raw processing power meant that Harvest also needed nonstop rivers of data to run on. And that led to another pioneering achievement: the world’s first automated tape library that could robotically fetch any one of hundreds of large cassettes of magnetic tape from the machine’s racks.
Given Harvest’s unprecedented processing and storage capacity, the machine’s designers naturally needed to rethink how their system handled information. So IBM wrote a customized programming language called Alpha to let code breakers rigorously describe cryptographic problems, just as scientists at the time were using the emerging language Fortran to describe equations and data-processing algorithms.
In Fort Meade, Md., an NSA data center hosted one of the world’s fastest computers of its time—although not often discussed, because of its sensitive, high-security code breaking and cipher hunting work. National Cryptologic Museum
The story of Harvest, pieced together from declassified documents and contemporary manuals and technical overviews, provides a new and unexpected vista on the history of computing. It also offers a case study in how national security needs, especially during the Cold War, pushed computer technology beyond the far reaches of what unclassified, civilian computing could achieve. Harvest’s distinctive history reveals a visionary algorithmic, coding, memory, and hardware architecture occasionally decades ahead of its time. But this machine was also built only once, for one singular purpose, and then ultimately quietly retired.
IBM’s landmark 1960 transistorized mainframe, the IBM 7030, better known as Stretch, provided the front end for Harvest (which was officially known as the IBM 7950). IBM delivered Stretch to eight or nine customers, mostly scientific research labs, from 1961 through ’63. Designed and prototyped throughout the second half of the 1950s, Stretch introduced the now standard notion of an 8-bit byte. For its first three years of operation, Stretch was the non-classified world’s fastest computer, although it failed to meet IBM’s aggressive goal of running 100 times as fast as Stretch’s predecessor, the IBM 704. While IBM engineers in Poughkeepsie, N.Y., were designing and building Stretch, the company was also quietly discussing a new system that would be built for NSA.
At the time, NSA’s existing cryptanalytic computers—large, batch-processing machines that required human operators to manually stage each tape run—were struggling to keep pace with the sheer volume of intercepted message traffic coming in from around the globe. What the agency needed was a machine that could process an unbroken river of incoming data, automatically, around the clock. That requirement alone profoundly shaped Harvest’s design.
IBM’s Harvest system, custom-built for the NSA for code breaking, paired the IBM 7030 Stretch mainframe with a bespoke data-stream processor. Stretch handled ordinary computing and input/output, including the Tractor automated tape library. Both units shared two kinds of memory: a large main bank and a smaller, faster bank. When Stretch switched to streaming mode, Harvest drew two streams of data, P and Q, from memory, processed them in parallel, and returned the results as a third stream, called R. Chris Philpot
After two failed proposals to NSA, in 1958 IBM finally landed the contract: a Stretch-based machine, augmented by a custom coprocessor, with a revolutionary tape-based storage system, called Tractor.
Stretch’s forte was floating-point math for scientific computations. IBM had designed it primarily for labs working on frontier research like nuclear weapons design and weather prediction. By contrast, the custom coprocessor to be built atop Stretch would help NSA analysts sift through alphanumeric characters—that is, essentially integer data.
Harvest’s coprocessor was the opposite of a general-purpose system. It was, rather, a streaming computer. Instead of executing long series of instructions, it followed one fixed sequence of steps and applied that same sequence to every pair of characters as they streamed past. Harvest shared memory with the main Stretch processor and ran in bursts. Either Stretch was operating, or else it suspended itself while Harvest’s coprocessor shot through data in memory at extreme speeds.
Stretch and Harvest were among the first large computers built entirely from transistors packaged in circuit cards and housed in large, refrigerator-size frames. A 1962 technical manual about Stretch describes the machine’s CPU as divided into functional sections—the instruction unit, the look-ahead unit, the (parallel and serial) arithmetic unit, and the memory bus unit. Harvest inherited Stretch’s basic circuit design but then added something unconventional: Its streaming units processed data in overlapping stages called a pipeline. So while one pair of data bytes was being compared, the next pair was being fetched from memory.
Harvest’s coprocessor operated by fetching two streams of data, called P and Q, from the system’s memory, performing operations on them, then writing the results to memory as a third stream, R. Each stream could be anywhere from 1 to 8 bits wide. Harvest’s memory was bit-addressable, meaning word boundaries could be ignored entirely. For instance, it could fetch just 5 bits rather than filling out a whole byte. Streams P, Q, and R included flexible provisions for looping and addressing data in complex patterns—allowing, for example, repeated fetching of short strings from memory.
Data from P and Q fed into two functional units. The simpler was the logic unit, which performed basic, bitwise operations—the same operations any programmer would recognize today—and wrote its results back to memory. The more complex was a table-lookup unit. It combined incoming data from P and Q to form an address in memory, which could then be used to advance a counter by one, set a specific bit, or retrieve a stored value. The latter unit functioned, in effect, like the rotor wheel inside a cipher-encoding/decoding machine of the era, the kind that electronically substituted one value for another according to the cipher machine’s wiring.
Harvest’s complexity baffled some at the NSA. During employee tours, according to James Bamford’s 2001 NSA history, Body of Secrets (Doubleday), officials would point to the machine and scoff, “It’s beautiful, but it doesn’t work.”
Not everyone at the agency was put off by the monumental device, however. One of the few documented examples of Harvest at work, recounted by Bamford, describes the machine searching 3.5 billion characters of text for any of 7,000 target terms, in just under 4 hours.
In unclassified remarks from 1972, NSA analyst Robert Looney mentions one job Harvest had tackled—though he didn’t specify the end goal or the code-breaking effort behind it. Codenamed “Moretown,” the job involved sifting through 11 million messages spanning 16 years of intercepted traffic against a list of some 8,000 search terms—all in about ten hours.
IBM’s Frances Allen helped design Alpha, Harvest’s custom-built programming language.IBM
IBM’s James H. Pomerene was chief engineer of Harvest, supervising its custom-designed circuits that’d been optimized for algorithms used in many cryptographic jobs.IEEE
IBM’s Fred Brooks Jr. was a key co-architect of Harvest’s hardware system. Computer History Museum
As a unified system, Harvest—that is, Stretch plus IBM’s custom-built streaming processor add-on—streamed 1 byte every 0.3 microseconds, and it boasted about 800 kilobytes of addressable memory.
“Here you see one bank pulled out of its oil bath,” Looney said in his 1972 remarks celebrating Harvest’s tenth anniversary of operations. He held up a photo of Harvest’s magnetic core memory banks—six of them, submerged in oil for cooling.
Factor in the time demands of various data fetches from Tractor’s tape archives, and a single Harvest “instruction” sometimes carried on, without needing any human intervention, for hours.
“It was quite an amazing computer,” recalled IBM Fellow Emerita Frances Allen in a 2001 oral history. “One instruction, for example, could do sorts, and do statistical analysis of the data that was streaming by it.… Everything we were doing at that time was on the cutting edge. There was no question about it.”
Allen, who received the A.M. Turing Award in 2006, was one of the developers who worked on both Stretch and Harvest. At the time she started working on Harvest, Allen noted, the Fort Meade, Md.–based NSA was largely unknown outside of classified intelligence circles. So she at first assumed she was working on an unspecified naval project. “We thought of ourselves as working for the Bureau of Ships, because that was the code name for NSA in the budget!” recalled Allen, who died in 2020.
Other key Harvest designers and early developers wound up becoming influential figures over the course of computing history. Frederick Brooks Jr., recipient of the 1999 Turing Award and a major contributor to the hardware and software for IBM’s System/360, also helped develop Harvest. And James Pomerene, prior to his involvement with Harvest as its chief engineer, had previously helped build the pioneering IAS computer alongside John von Neumann.
IBM built the Tractor tape system (IBM 7955) to attach to the same Stretch machine that hosted Harvest, because no existing data storage technologies could keep up with the computer’s staggering throughput. Stretch handled the business of staging tapes from the library to the drives—using Tractor’s automated cassette handler. Stretch also coordinated reading data in from Tractor and writing results back out from Harvest. Harvest, in turn, did all its actual computing on the system’s shared main memory.
In the early 1960s, and even after Tractor and Harvest were installed, hard-drive data storage was in its infancy. For code-breaking jobs of the size Harvest was taking on, disk storage would have been impractical in terms of both cost and sheer floor space. So Tractor had to be based around tape storage.
Each tape was sealed inside a case built like a boombox—twin encased reels under a window, carried by a handle—and, at 6 to 7 kilograms, about as heavy as a bowling ball. Think of a Tractor cassette as an outsize predecessor of the audiocassette, which would come along a decade later, and holding some 120 megabytes of data on a reel of tape 550 meters long. Each storage unit housed up to 160 of these cassettes.
An IBM technician holds one of the data cassettes used with Harvest’s automated Tractor tape drives. IBM
When Harvest launched in 1962, it had three automatic cartridge units, each serving two drives. So the available online storage across the three Tractor units totaled a stunning 44 gigabytes. That’s more than 190 times as much capacity as the IBM 2314 disk storage system, announced in 1965, which held 233 megabytes across its full complement of eight drives.
Tractor had to run continuously, swapping cassettes in and out, 24 hours a day, seven days a week. The system’s tape-handling speed was tuned to keep pace with Harvest’s own appetite for data. The custom-built robotic mechanism for retrieving the cassettes was a servo-driven arm that traversed the system’s storage racks. It fetched a cassette from its slot and delivered it to a handler or received a cassette from one of the handlers and returned it to storage.
Running at 6 meters per second, Tractor’s tapes zipped past the read/write heads faster than the eye could track. Software running on Stretch handled the cassette shuttling as well as reading and writing. For one of Tractor’s drives to move from the completion of processing one tape to reading the next took about 18 seconds, assuming it had already been fetched and was ready to mount. Robotically fetching a cassette from the storage unit and preparing it for reading required no human handling or input whatsoever.
In addition to Tractor, the system had standard reel-to-reel tape drives attached to Stretch. Harvest’s technicians often used the conventional drives for importing and exporting data to and from other systems; there was no other practical way to get large datasets into or out of Harvest. Tractor could also store permanent files and retrieve them directly from its tape libraries when a job required them. In other words, Tractor’s substantial cassette libraries acted both as permanent data storage and as a place to hold transient data for processing by Harvest.
No system in the commercial computing world of 1962 came close to Tractor’s gigabytes of simultaneously accessible data. At most computer centers at the time, “available” data meant physical racks of tape standing somewhere near its drives—accessible only as rapidly as an operator could manually pull a reel and thread it onto a machine, one at a time, over the course of a shift.
Created jointly by IBM and NSA, the Alpha language existed solely to program Harvest’s streaming dataflow engine for code-breaking work. According to a declassified Pentagon history of NSA computers, Alpha stood for Advanced Language for Programming Harvest.
Alpha allowed the programmer to define the alphabet in which code-breaking data would be processed. The language also included two unusual characters with no equivalent in conventional computing until years later, when Multics and Unix introduced wildcard characters. A “scab” (which was represented on Harvest’s input keyboard, a repurposed early IBM Selectric typewriter, by a “?”) stood for a character that was real but unknown. And a “pad” (represented by a blank space) was a null or spacer. These characters provided flexibility of representation for code breaking jobs, in which unknown or uncertain characters were commonplace.
A Harvest operator types on one of the main system consoles, a repurposed IBM Selectric typewriter.IBM
The rules governing Alpha’s operations on strings anticipated other modern rubrics, like “not a number”—a designation describing an unknown value in a dataset that can propagate through calculations, rather than silently corrupting them. Strings in Alpha could also be aggregated into cords, and cords into ropes, giving cryptanalysts a hierarchical vocabulary for describing complex intercepts.
Allen wrote a final technical report on her section of the Harvest software when her part of the project concluded—and just as promptly lost access to it. “I spent the good part of a summer on that,” she recalled in 2001. “And it just disappeared into Fort Meade somewhere.”
By 1971, according to NSA analyst Looney, the machine was running at its highest utilization ever—115 hours of production a week, or more than two-thirds of the time. Yet the number of jobs it processed had been dropping since 1967. Ordinary data-processing work, Looney noted, was by 1972 migrating to newer, general-purpose machines, leaving Harvest to concentrate on the very large, specialized jobs no other system could handle.
At its tenth anniversary of operations, Looney concluded, Harvest was a machine “conceived in the fifties, born in the sixties, and irreplaceable in the seventies.”
He got the last part wrong.
On 27 February 1976, operators shut down Harvest for the last time. A custom mechanical component in the Tractor tape library had worn out, and the manufacturer of the part was no longer in business. By then Harvest had run continuously for nearly a decade and a half—through the roughest close call in the history of mutually assured destruction and into the age of détente—processing intercepts at a rate no civilian machine could touch. By the time it retired, Harvest had outlived several generations of commercial computing.
A placard commemorates the 1976 decommissioning of IBM’s Harvest computer at the NSA’s headquarters in Fort Meade, Md. National Cryptologic Museum
Somebody at the NSA decided to commemorate the machine with a mock telegram, written under Harvest’s name on the machine’s last day (and now preserved in the agency’s archives). “I first began operations at NSA. Although not widely known, I was probably the largest, fastest, and most technically advanced computer system in the world,” the telegram said. “And now, fourteen years later, the time to retire has come. The cost of my upkeep and operation has been overtaken by more modern equipments and the newer technologies.”
The NSA ultimately replaced Harvest with the landmark Cray-1 supercomputer. The Cray-1 was built from faster, more tightly integrated circuits that could outperform Harvest’s aging transistors at nearly any task, including text processing. Although the Cray was designed primarily for numeric and scientific computing, it sold across many fields—which ultimately made the supercomputer win out once Harvest’s custom-built text-processing hardware was no longer worth the upkeep for just one customer.
The secrecy that shrouded Harvest meant it could claim no lineage of immediate successors. But the ideas it pioneered didn’t disappear—they resurfaced, again and again, in the years that followed.
Tractor’s automated tape library was the forerunner of the robotic storage silos that would become standard in enterprise data centers about 20 years later. Harvest’s pipeline architecture prefigured the dataflow computing movement of the 1980s. The continuous pattern-detecting logic of its match units finds direct echoes in modern hardware packet-inspection intrusion detectors and programmable network switches that today route traffic through the internet at wire speed.
Harvest didn’t found a dynasty. But, in its time, it steadfastly pointed toward the future—in several directions at once.
This article appears in the September 2026 print issue as “The Lost History of IBM’s Cold-War Code Breaker.”
2026-08-25 18:00:03
This article is brought to you by Ollobot.
From about 2017, individuals began to truly connect with the initial wave of companion robots. These devices had personality, moved around, joked, and answered when you spoke to them. Most early companion robots, however, were still limited by simple voice-command interactions and narrow functionality. Once the novelty wore off, many ended up sitting unused on shelves. As some of those companies went out of business and turned off their servers, many owners likened it to losing a pet.
What Ollobot describes as “gentle intelligence” is a useful way to think about where the serious work in this category is going. Not toward more powerful assistants, but toward more present ones.
Loneliness is not a niche issue. According to one study, nearly one out of three elderly adults resides alone, meaning they do not have daily companions. Research also shows that children whose parents have migrated for work, leaving them in the care of relatives, were 2.5 times more likely to experience loneliness than children whose parents remain with them. Among working adults living alone in urban environments, similar patterns of social isolation emerge, even if they are less visible.
Over the years, technology has time and again attempted to solve this problem via video calls, smart speakers, and messaging apps without much success. Those tools are geared towards communication between people that already have relationships. They do not create presence. They schedule it. That is the gap that a new generation of AI companion robots is being engineered to fill.
Today’s companion robots are not just cute and cuddly. They are designed with psychological research, clinical insight and long-term interaction models to be truly useful in real homes.
Three fundamental shifts define the current generation:
The global AI companion market size was valued at US $36.8 billion in 2025 and is projected to grow from $48 billion in 2026 to $318 billion by 2033, at a compound annual growth rate of 31 percent from 2026 to 2033.
Ollobot’s advanced AI family companion robot OlloNi SS1 addresses a number of gaps in what existing technology offers.
Elderly individuals living alone. The combination of proactive interaction, fall detection, and persistent presence addresses both safety and companionship without the social overhead of asking family members to check in more frequently.
Children in households where parents work far from home. The SS1 functions as a consistent companion that already knows a child, their preferences, their moods, and their routines. The remote connection features allow parents to stay present without requiring a scheduled call, and the life recording system gives them a passive window into their child’s days that feels less clinical than a monitoring camera.
Single professionals living alone in cities. The SS1 adapts to daily routines, builds up a preference model over time, and provides ambient social presence without demands.
OlloNi SS1 adapts to daily routines over time.Ollobot
Ollobot’s goal in building intelligent companion robots is to address the gaps in technology and capability, using innovation not to automate tasks but to fill emotional voids.
Much of the robotics industry has historically pursued human imitation — machines that speak, look, or behave like people. The SS1 is instead designed around familiarity and long-term coexistence rather than realism.
The system integrates multiple subsystems operating in parallel, including visual perception, audio processing, mobility control, and interaction management. It is equipped with a multi-chip AI 4K vision module capable of facial recognition and motion tracking. One small but revealing detail is the inclusion of a physical privacy cover for the camera — a mechanical solution to concerns that software settings alone may not fully resolve.
OlloNi SS1 can actively integrate into family activities, and it can autonomously move closer to capture memorable moments or reposition itself to remain engaged in ongoing interactions.Ollobot
The robot supports advanced mobility across multiple indoor surfaces, including wooden floors, ceramic tiles, and low-pile carpets, with slope climbing capability up to 3.5 degrees. Rather than remaining in a fixed location, it can move naturally throughout the home to stay close to household members as daily activities unfold.
For example, the OlloNi SS1 may greet family members when they arrive home, follow an older adult from the living room to the kitchen while continuing a conversation, remind a child to take a study break after a prolonged period of inactivity, or notice that someone appears unusually quiet and gently check in. During family activities, it can autonomously move closer to capture memorable moments or reposition itself to remain engaged in ongoing interactions.
The robot continues to evolve over time, with over-the-air updates that deliver new features, performance improvements, and AI enhancements
It also incorporates fall detection with optimized accuracy for safety monitoring scenarios. A 6-microphone array enables omnidirectional voice pickup with an effective voice capture range of up to 5 meters, supporting reliable wake-word detection and far-field interaction.
To support continuous companionship, much of the robot’s AI processing takes place directly on the device through its “heart module” architecture, with 16 GB of memory and 64 GB of local storage. This enables the system to retain household memories, recognize familiar faces, and respond with lower latency, making interactions feel more natural even during everyday routines.
Because companion robots are expected to remain available throughout the day rather than only during brief interactions, the SS1 is designed for extended operation, offering up to 12 hours of standby time and around 5 hours of active interaction on a single charge. This allows it to accompany users through meals, conversations, playtime, and other daily activities without frequent interruptions.
To support engaging interactions, much of the robot’s AI processing takes place directly on the device through its “heart module” architecture.Ollobot
Like the relationships it is designed to build, the robot continues to evolve over time. Running on Android OS with over-the-air (OTA) updates, the system continuously receives new features, performance improvements, and AI enhancements, allowing its capabilities to grow alongside the household it serves.
The robot’s behavioral model also improves over time. Rather than reacting to isolated commands, it attempts to establish a baseline understanding of household routines and individuals. Changes in behavior — prolonged quietness, unusual inactivity, or emotional cues — become triggers for interaction.
Several features in the OlloNi SS1 illustrate this emphasis on presence and continuity in its interactions.
The system can identify different household members, including pets, and adapt responses accordingly. Remote communication features allow family members to connect through the device without treating every interaction like a scheduled call. Environmental sensors support contextual reminders tied to weather or room conditions.
Its “2+1” multi-display configuration is also designed around emotional communication. Two circular side displays function as expressive “emotional eyes,” while a separate primary display handles information and structured interaction. The separation allows emotional signaling and functional communication to operate independently, creating more intuitive nonverbal interaction even when no dialogue is taking place.
The robot’s behavioral model improves over time. Rather than reacting to isolated commands, it attempts to establish a baseline understanding of household routines and individuals.Ollobot
The SS1 also includes an automated life-recording system built on facial recognition and behavioral-event detection that can capture moments such as laughter, physical closeness, or group interaction automatically. An integrated AI vlog engine can then organize those moments into edited short-form videos with automated sequencing and soundtrack generation. The design intent is to preserve spontaneous domestic moments without requiring active documentation behavior from users.
An integrated AI vlog engine can organize recorded moments into edited short-form videos with automated sequencing and soundtrack generation
Visual data is processed primarily on the device through the SS1’s on-device AI architecture, with household memories stored locally and managed within Ollobot’s proprietary ecosystem instead of being shared with third-party smart home platforms. Access to recordings and live feeds is restricted to authorized users through the companion app, while encrypted communication helps protect data during remote access. Users also retain direct control over recording preferences, and the physical camera privacy cover provides an additional hardware-level safeguard whenever visual monitoring is not desired.
Learn more at ollobot.com.
Remote communication is similarly structured around persistence rather than transaction. Traditional video calls are episodic and screen-bound; the SS1 instead acts as a continuously present interface embedded inside the household environment. Through autonomous mobility, environmental awareness, and persistent household memory, remote family members interact with an ongoing domestic context.
Ultimately, gentle intelligence is not about making robots behave more like humans — it is about helping them fit more naturally into human lives. Each OlloNi SS1 unit develops a unique behavioral profile based on its household. Two units running in different homes for a year will have become meaningfully different from each other, shaped by the specific people, habits, and rhythms of where they live.
That kind of long-term personalization is what early companion robots never had. It is also what makes the difference between a product that ends up on a shelf and one that actually earns its place in a home.
Learn more at ollobot.com.
2026-08-25 02:00:01
For most of my career, my IEEE membership sat quietly in the background—a line on my résumé, a discount code for a conference registration, and access to the IEEE Xplore digital library, which I underutilized. I didn’t think much about the grade of membership available above that of the regular member. I assumed senior membership was reserved for people further along in their career than I was. They published more papers, had more gray hair, and had worked longer in the field.
I was wrong on all three counts. The misunderstanding cost me an important validation of my skills and professional competency.
I suspect a lot of other qualified members are where I was one year ago: eligible but unaware of the benefits of senior membership, and one application away from a meaningful career credential.
Here are a few of the misconceptions about senior membership:
It’s mostly for academics and longtime IEEE volunteers. It isn’t. The grade is explicitly built around a person’s professional engineering experience. Plenty of successful applicants have never published a paper. Industry experience counts for a lot.
You need a graduate degree. You don’t. A bachelor’s degree plus enough years of qualifying experience is sufficient on its own. An advanced degree simply offsets some of the required years of experience.
If I’m not well-known in my field, I won’t qualify. Senior membership isn’t a popularity contest. Rather, it hinges on whether you meet specific experience metrics. The requirement is “sustained, significant technical contribution,” not “known beyond your organization.”
I should wait until I have more significant achievements to point to. I believed this for longer than I should have. If you meet the 10-year experience threshold with five years of significant performance, you’re already eligible. Waiting doesn’t strengthen a qualifying application; it just delays getting a credential you’ve already earned.
The push to apply came from a practical need. As a senior data scientist at Apple in Austin, Texas, I work in applied machine learning, building large-scale systems that affect customer-support operations. I already had started taking on more peer-review work—checking papers for journals including Neural Networks and IEEE Transactions on Knowledge and Data Engineering, mentoring at Apple, and writing on public platforms such as Medium and SimpleTalk.
I wanted a credential that reflected that shift from “engineer who codes” to “engineer who helps shape the field.”
The IEEE senior member grade turned out to be the validation of my work I was looking for. It’s not an award for a single achievement. You have to apply for it, and it’s a peer-evaluated process that confirms you’ve sustained a meaningful level of professional contributions over time.
That distinction matters. Having a research paper published or being granted a patent proves a moment in time. Senior membership reflects a pattern of continuous contributions.
The benefits to my career happened faster than I expected. It strengthened how search committees, IEEE conference organizers, and IEEE awards panels viewed me. Only senior members can hold certain IEEE leadership positions.
The senior grade also opened doors to editorial and reviewer roles I hadn’t even pursued before. Journal editors and conference organizers often look for reviewers with a track record they can verify quickly, and senior membership gives them that signal without extra vetting on their end. It also gave me a credential I could point to in professional contexts, including, in my case, supporting documentation for a U.S. employment-based immigration petition, where third-party peer recognition carries real evidentiary weight.
The process for applying for senior membership is easier than the title might suggest. To qualify, you need a combination of professional and academic experience in an IEEE-designated field: engineering, computer science, information technology, physical sciences, mathematics, or technical communications. The two must total at least 10 years, with at least five of them showing significant performance. Crucially, experience isn’t limited to job titles. Graduate research, technical leadership, and progressively responsible engineering work all count toward the total number of years. I’d been quietly accumulating qualifying years without ever framing them that way.
“I suspect a lot of other qualified members are exactly where I was a year ago: eligible but unaware of the benefits of senior membership, and one application away from a meaningful career credential.”
You submit your application through IEEE’s member portal, mapped against the experience requirement, along with three references from current IEEE members—at least two of whom must be senior members or IEEE Fellows who can vouch for the credibility of your work.
The IEEE member grade evaluation committee reviews applications and renders decisions.
The part everyone underestimates is references. Applications can stall at this point. References must be IEEE members in good standing, and at least two need to be IEEE senior members—which means you can’t necessarily ask people who know you best. You need to find references who are both willing to vouch for you and are grade-eligible.
My advice is to identify and confirm all three references before you submit your application. It might be difficult to add or swap a reference during the process, and a stalled reference could delay your file.
Where to find references is the part I worried most about. But it turned out to be far easier than I expected.
Here are several sources:
A pattern I noticed when looking for references is that people are generally glad to be asked. Serving as a reference is a small lift for them and a meaningful one for you. Most senior engineers remember someone doing the same for them and are happy to pay it forward.
If you’ve been in the field for a decade or more, doing real technical work, and IEEE membership has been sitting quietly in the background of your career the way it did in mine, it’s worth 10 minutes to check the eligibility criteria against your history. You might find, as I did, that you qualified for the membership upgrade a while ago.
2026-08-24 22:00:01
The AI boom has disrupted the way engineers work, introducing new tools to learn, raising expectations for what teams can achieve in a workday, and making it harder to get hired in the first place. This makes it difficult to advise students on which specific coding languages or technical skills they should learn. So amidst the uncertainty, advice for young professionals often turns to a common refrain: Be adaptable. But what does adaptability look like in practice?
Engineers often operate on the cutting edge of technology, so dealing with change is a normal part of the job, says Samantha Brunhaver, an associate professor of engineering at Arizona State University, in Tempe. Yet university curricula and training in the workplace often don’t prepare students for this.
“We tell engineers that they need to be adaptable when they graduate, but we don’t actually explain what that means, demonstrate what that looks like, [or] help make sure that they’re developing it,” says Brunhaver, who received a National Science Foundation award in 2020 to study how to foster greater workplace adaptability among young engineers. For this ongoing project, she has interviewed engineering managers, early career employees, and undergraduates about their experiences.
Part of the problem, she says, is that every employer has its own idea of what to be adaptable means. Generally, Brunhaver defines adaptability as “the ability to recognize that a change or uncertainty is occurring, and then respond effectively to that change.” But the skill is context-dependent. In software engineering, that might mean responding to turnover in the tools you use on a daily basis, while aerospace or biomedical engineers may need to keep track of changing procedures and regulations. “Managers are all saying adaptability is important,” Brunhaver says, “but defining it in different ways.”
At the same time, engineers are all contending with changes beyond these industry-specific expectations. Jobs in the technology, media, and telecom sectors are experiencing the fastest pace of skill turnover, according to a June 2026 report on the effects of AI from the professional services network PwC. And the World Economic Forum’s most recent Future of Jobs Report, published in 2025, found that employers across all sectors expect 39 percent of workers’ core skills to change by 2030. This uncertainty can be uncomfortable. But with the right mind-set and support from leadership, adaptability can help keep you afloat.
The AI transition is a big shift—but not an unprecedented one, says Jenna Butler, a research scientist at Microsoft who studies developer well-being and productivity.
During this type of paradigm shift, there is often a “chaos period” when a new normal is being established, Butler says. In AI’s case, it challenges the understanding of what a computer can do. “I think we’re still in this in-between, difficult period that we’ve seen before, but [it] is maybe moving faster than it has historically.” Software engineers—in one of the fields most affected by AI—are now facing a significant increase in code review. “If you ask 20 developers, you get 23 different ways of working with it. Everyone is trying to sort it out,” says Butler, who describes this period as “the uncomfortable middle.”
“We tell engineers that they need to be adaptable when they graduate, but we don’t actually explain what that means, demonstrate what that looks like, [or] help make sure that they’re developing it.”– Samantha Brunhaver, Arizona State University
Brunhaver says one way educators can help prepare students before they enter the workforce is by offering a diversity of real-world experiences, such as internships, team-based projects, community service, and leadership roles. Each of these teach students to adapt to different challenges, easing their transition from school to work.
It’s also important to encourage reflection, Brunhaver adds, noting that metacognition helps individuals use the skill more effectively. “In order to adapt, you have to think that you have agency and the ability to get through a situation.” Ultimately, it comes down to three steps: Perceive a need to adapt, evaluate your options, and act.
For those already in the workforce, that action may mean taking the time to learn new tools and ways of working. Software engineering, for instance, may soon rely more on prompting models and managing agents than coding line by line. “I think people who went into software because they like solving problems are going to have a lot of fun, and people who just enjoy the art of writing code are not,” Butler says.
Although the tools engineers use on a daily basis are evolving, the core responsibilities of the job are more stable than they may seem, says Andy Hunt, a software developer who coauthored The Pragmatic Programmer (Addison-Wesley Professional) in 1999. The book outlines practical coding principles, and has been taught in many computer science classrooms. When Hunt was working on the 20th anniversary edition of the book, he was surprised by how much of the advice still applies. And now, seven years later, he maintains that belief.
“The fundamental part of the job is problem solving and communication, and that’s always going to be there,” he says.
Hunt emphasizes the importance of developing systems thinking over particular tools. To him, identifying as a Java programmer, for instance, is “like a carpenter saying, ‘I’m a hammer user,’ or ‘I specialize in cordless drills.’ ”
He acknowledges that today’s hiring process, in which companies often filter résumés for certain languages or years of experience, makes it harder to embrace a more expansive way of relating to your job. Employers, he says, should recognize that “the tech’s not the hard part, and it never has been. Understanding information theory, understanding systems thinking, understanding what constraints you’re up to—that’s still the hard part.”
With this type of misalignment between employers and employees, AI is also intensifying an old source of tension: How can engineers slow down enough to adapt and learn new tools when the pressure to become more productive keeps mounting?
Young engineers need to embrace change. However, educators and employers also play a role in building a successful workforce. From the educator’s perspective, Brunhaver says “we need to be more explicit about what [adaptability] means and why it’s important.” Managers, meanwhile, should invest in their employees’ professional development.
Microsoft research scientist Butler often encourages leadership to set aside intentional time for continuous learning for their engineers—even just an hour a week—without any expectation that they will produce code or progress in their daily work. “I realize that’s difficult,” says Butler. “I would encourage people to do it on their own, but I would really encourage organizations and leaders to do it, because you’re not going to get this sudden change in your people if they don’t have time and space to learn how to work differently.”
This also means providing enough instruction, Butler adds. When developers aren’t given enough guidance on adopting something new, while being pressured to increase productivity, they risk doubling down on the tools they already know and burning out.
“I do imagine the next number of years could be challenging,” Butler says. Engineers will have to adapt to find their place in an evolving workforce—but they also have a say in shaping that future.
“Being adaptable sort of implies that you’re going to change based on what’s happening around you, and I would really like people to realize the change that’s happening is somewhat up to us,” she says. All individuals have a choice in how they use AI, for instance, and which models they use. “We need to be adaptable and go with the flow to a degree, but we also need to be directing that flow. The future with AI is absolutely not predetermined.”
This article appears in the September 2026 print issue as “The Adaptable Engineer.”
2026-08-24 19:37:02
This article is brought to you by Emerson.
I’ve spent much of my career as an engineer, including years in the semiconductor industry. And one lesson has stayed with me through every major technology shift: innovation always creates new complexity.
In semiconductors, we have seen that repeatedly. Every generation has delivered breakthroughs in performance and capability, but each step forward made it harder to understand system behavior. What used to be easy to validate on the component level with a test bench now needs a much wider view.
“The future of engineering will be defined by who can verify, understand, and improve complex systems fast enough to safely keep innovation moving forward,” says Ritu Favre, President of Emerson’s Test & Measurement business group.Emerson
Chiplet-based designs are a prime example. A chiplet from one supplier, an interposer from another, and a packaging process from a third may all perform perfectly on their own. Yet there is a chance for unexpected behavior when you put them together in a system. More and more often, the hardest engineering challenges are not in the individual components themselves. The problems are found when we start to combine components and have them interact with each other.
These challenges extend far beyond semiconductors. Products are becoming more software-defined and dependent on interactions across different technologies and environments. Think about the interactions needed for a modern car using adaptive cruise control on a bumpy road in a rainstorm. Or a passenger jet adjusting wing flaps and engine speeds in turbulent weather to maintain safety and stability. Both the car and the jet are being guided by complex computer systems with thousands of sensors leading to thousands of interactions every second. And in many cases, there are multiple computer systems working together. We are building systems of remarkable capability but understanding how they will act under real-world conditions is getting harder.
That is why I believe we are entering a new era of test. The defining challenge of modern engineering is no longer simply what we can design and build. It is what we can confidently verify.
In this new era, test can’t be an afterthought. For decades, test was treated as the final checkpoint before release. Design teams developed a product, test teams validated performance, and organizations looked for a final pass/fail to determine whether they were ready to move forward. That model worked fine when systems were more self-contained and predictable. Today, that approach can lead to more risk.
I believe we are entering a new era of test. The defining challenge of modern engineering is no longer simply what we can design and build. It is what we can confidently verify.
Many of the delays and fire drills we face come from issues that were not visible early enough. Problems discovered late in development are more difficult to diagnose, more expensive to fix, and more likely to get you off schedule. The solution is not more testing at the end. The solution is to make test and verification part of the engineering workflow from the start.
When validation is integrated throughout development, teams catch problems early when change is easier. Test also stops being a barrier to release. Instead, it becomes a source of insight, helping us understand how systems behave as they become more connected.
When confidently verifying technology becomes the key challenge, the tools we choose take on a different level of importance. The tools have a direct impact on how quickly we can diagnose a problem and keep moving forward. In an environment where technology changes rapidly, disconnected tools get in the way of progress. Modern test strategy requires linking information across design, validation, and production, turning measurement data into decisions made quickly enough to keep pace with innovation.
This reminds me of when EDA was first introduced. Before it came along, engineers spent much of their time hand-drawing circuit layouts and placing transistors. EDA eliminated that tedious work by letting teams describe complex behavior in high-level code. It enabled them to focus on overall architecture instead.
A connected test platform does a similar thing for validation. Because a platform can adapt and scale alongside technology, it cuts down on maintenance and downtime, keeping teams from having to rebuild their workflows from scratch as requirements change.
Today, AI is rapidly entering the engineering toolkit to accelerate design and analysis. But in test and measurement, AI cannot reach its potential in isolation.
An AI model is only as effective as the data feeding it. Without context, even the smartest algorithm will struggle to tell the difference between normal hardware variance and a critical failure. A connected platform supplies the structured, traceable data stream AI requires to deliver real insight.
AI can correlate complex multi-system interactions, flag unexpected behavior, and direct an engineer’s attention right at the root cause.
When measurement data flows seamlessly across the workstream, AI moves from being a standalone tool to an active layer of intelligence. It can correlate complex multi-system interactions, flag unexpected behavior, and direct an engineer’s attention right at the root cause.
Every technology shift that accelerates how fast we create new designs also increases the complexity we must verify. AI can help teams keep pace with that complexity. Not by replacing human judgment, but by giving engineers the context we need to act with confidence.
Ultimately, the goal of modern platforms and AI-enabled workflows is to help technical teams spend more time building new things and solving hard problems. Most of us didn’t choose this profession to spend our time searching for data or dealing with last minute surprises. We want to innovate and integrating test directly into development provides a better view of system behavior, allowing teams to focus on that innovation rather than managing complexity.
The future of engineering will not be defined by who can build the most advanced product or technology. It will be defined by who can verify, understand, and improve complex systems fast enough to safely keep innovation moving forward.
That is the new era of test. As the pace of innovation accelerates, every breakthrough creates new paths to failure, and test is how engineers find those failures before the real world does. In an increasingly complex world, that capability is becoming as important as innovation itself.
Innovation has always required great engineering. And now, more than ever, it also requires confidence. Confidence that comes from knowing that we are not only building what is possible, but we are also building technology that people can trust.
2026-08-23 21:00:01
How do I touch you
across the ocean,
across cold depths
where light travels through glass.
Not copper—fibers. Optical.
Through liquid glass, through flickering light
that carries you in fragments. Light broken into pulses.
You say: it’s easier this way. What are we missing like this? You smile.
Safe distance.
I say: network.
Signals slide beneath the sea, through cables thinner than trust, faster than touch,
slower than longing.
We stand alone, together. Synchronous, yet apart. Icons replace skin, latency replaces breath.
This distance protects us. Silence that feels intentional.
Everything is under control as long as nothing truly hurts.
And we choose it
because it shields us
from what we might become if we actually met.
You are my counterpoint. My response.
My reflection
at a safe distance.
Beneath the ocean, nodes remember paths.
Packets shake hands without bodies.
If we get lost,
we resend everything, with error,
with noise,
with hope.