by 
Computational Thinking may sound like a practice reserved for programmers and engineers, but in Project Tomorrow’s new series of Computational Thinking at Work we are here to challenge those assumptions. Professionals across every field use computational thinking core practices daily — decomposing complex problems, recognizing patterns, abstracting unnecessary detail to focus on what matters most, and designing step-by-step solutions.
The second piece in our series follows a drone technician through the rhythms of a workday and reveals how these foundational problem-solving skills are essential to keep drones in the air.
The Mind Behind the Machine: How Computational Thinking Keeps Drones Flying
When Rob Cupit arrives at work at 6 a.m., the floor is quiet. Most of his colleagues will not filter in for another hour or two, and he uses that early window to review work orders, consider the priorities ahead, and prepare for the day. By the time the 9 a.m. meeting begins, however, the plan may already be changing.
A drone might return unexpectedly from the field, or a floor manager might introduce a repair that demands immediate attention. Asked to describe a typical day, Rob acknowledges that he can arrive with a clear sense of what needs to be done, “but it can change so quickly.” The ability to adapt is nearly as essential to his work as the technical expertise he brings to it.
Rob is an Unmanned Aerial Systems (UAS) technician at a company that designs, manufactures, and maintains large commercial drones, some with wingspans roughly the length of a dining room table. His responsibilities include mechanical repairs, software diagnostics, flight-system calibration, and the investigation of problems that have resisted earlier attempts to solve them. A former high school engineering teacher, Rob brings a unique perspective to a profession that requires both deep technical knowledge and the ability to learn continuously.
Much of Rob’s work happens with his hands, but the reasoning behind each repair is less visible. Before a drone is ready to fly again, he must isolate the malfunction, recognize whether he has seen it before, decide which information matters, and settle on a solution he can trust. This kind of reasoning reflects the foundational practices of computational thinking, including decomposition, pattern recognition, abstraction, and algorithmic design. Although often associated with computer science, these approaches extend well beyond programming. For Rob, they guide how he investigates uncertainty, makes decisions, and improves the ways his team works.
Narrowing the Possibilities
When a drone returns from the field, it arrives with a history that Rob must understand before he begins the repair. He reviews Slack discussions, Salesforce tickets, and notes from technicians who attempted to resolve the issue remotely, looking for clues about what has already been tested and what remains uncertain. “Knowing where it’s been, what people have already done, can speed up the process,” he explains, and make his job “a lot easier.” As he puts it, “They’ve tested these three things in this subcomponent, so I can rule out this wire, or this device.”
By the time Rob picks up a tool, he has often eliminated several possibilities. What initially appears to be a single mechanical failure may involve intricate relationships among electrical components, software, and the aircraft’s physical systems. He recalls one drone in which a stray piece of copper wire had caught in the lens of a first-person-view camera less than an inch across, shorting the entire drone so it would not start.
Experiences like that have taught him to approach each malfunction methodically. He begins by identifying the affected area, considering the components and connections involved, and ordering the possible causes from simplest to most difficult to investigate. “I take the easiest route first and work my way back to the hardest portion,” he says. “I don’t want to spend four hours on something that could have been something simple.” Through decomposition, Rob breaks a complicated problem into smaller, testable questions, narrowing the possibilities while preserving time and attention for the work that follows.
That discipline extends beyond individual repairs to the organization of the work itself. Rob and his colleagues prepare and inventory subcomponents so they can respond quickly when an aircraft requires attention, and they have gradually refined procedures for repairs that recur. “Throughout time and experience,” he explains, “we’ve created a step-by-step process that we as a group feel is the most efficient way to perform complex repairs.” What begins as one technician’s reasoning can, over time, become a more efficient practice shared across the team.
Learning What the Drone Is Telling You
Rob estimates that he and his team understand about 90 percent of the problems they encounter. That knowledge has accumulated through years of observation, unsuccessful attempts, effective repairs, and careful attention to the circumstances surrounding each failure. The technicians call it “tribal knowledge,” and it resides both in their collective experience and in the flowcharts they have developed to document what they have learned.
“Everything we can do to fix the drone is based on past experience,” Rob explains. When a familiar warning code appears or an aircraft behaves in a recognizable way, technicians can draw upon previous cases rather than begin each investigation anew. The flowcharts guide them through likely causes and potential solutions, translating experience into a resource that others can use. What some might think of as intuition often reflects an extensive process of pattern recognition, built through repeated encounters with similar problems.
Those patterns also help the team recognize problems that extend beyond a single aircraft. Rob has noticed recurring issues with electronic boards supplied by particular vendors, including components that appear in repairs more frequently than expected. “The biggest issue we have is the quality of vendors who provide our electronic boards and parts,” he reflects. Recognizing a recurring failure gives the team evidence to raise concerns and advocate for changes before the same issue affects more drones.
Experience, however, cannot anticipate every problem. Firmware updates, redesigned components, and unfamiliar configurations continually introduce conditions that no existing flowchart fully addresses. “We don’t even know the problems that are going to occur,” Rob says. “There’s so much to learn still.” The remaining challenges demand experimentation, collaboration, and the judgment to recognize when a familiar explanation is no longer sufficient.
Seeing the Whole While Fixing the Part
At the center of each drone is what Rob and his colleagues call the corestack, which he describes as “the brain of the drone.” Although a repair may concentrate on a component small enough to hold between two fingers, that component belongs to a much larger system in which failures can have consequences far beyond their apparent point of origin. “Every piece is connected in some way to the corestack,” Rob explains. “Every component relies on the others to make a fully functioning drone.” Understanding how those relationships affect an individual repair is an exercise in systems thinking.
In practice, this means moving continually between the detail in front of him and the aircraft as a whole. The hands-on work includes soldering, assembly, component replacements, and mechanical repairs. Equally important is the software side of the work, in which Rob uses C++ and Python to run firmware, install updates, and calibrate the aircraft so it flies as intended. Understanding how those domains influence one another is essential to diagnosing the source of a malfunction and determining whether a repair has truly resolved it.
The complexity is heightened by the fact that the aircraft itself is still evolving. The company developed its drone from the ground up after deciding it could no longer rely on external manufacturers, and the current version is already being followed by an entirely new internal system in testing. Each iteration brings adjustments that can alter familiar relationships among components and create new questions for the technicians maintaining them. The work calls for a systems perspective grounded in existing knowledge but flexible enough to accommodate change.
In his work, Rob regularly has to decide which details deserve immediate attention and which can remain in the background. This selective attention is a form of abstraction, identifying the information most relevant to the immediate problem while temporarily setting aside details that can wait. Quality is his first priority, particularly because an aircraft failure carries safety risks as well as the potential loss of a $40,000 aircraft. He also considers mean time between failures, or MTBF, a measure of how long a drone operates before requiring another repair. These priorities help him evaluate the consequences of a decision without becoming overwhelmed by every variable in an exceptionally complicated machine.
When the Established Process Is Not Enough
For repairs that the team has performed many times, Rob can describe a dependable sequence of steps. He reviews the work order history, develops a plan, begins with the most likely and accessible causes, and then proceeds through the repair, programming, calibration, quality checks, and test flight before the drone is shipped. This process reflects algorithmic design, turning accumulated expertise into a logical, repeatable sequence that other technicians can follow, evaluate, and refine.
Rob is equally clear that an established procedure cannot resolve every problem. “All manufacturing should end the same,” he says, “but it doesn’t necessarily always have to be completed in the same way.” Engineering instructions can be incomplete or fail to account for what technicians encounter on the floor. He explains that “It’s my job to fill in the gaps.”
Filling those gaps requires both technical expertise and a willingness to reconsider the prescribed approach. Technicians consult colleagues with knowledge of particular subsystems, compare alternative explanations, and test different materials, configurations, or sequences of steps. “Most of our common issues have two or three solutions,” Rob says. “The fun is figuring out which one solves the issue.” The procedures establish consistency, while professional judgment allows the team to respond to circumstances those procedures could not anticipate.
Rob’s years teaching high school engineering have made him particularly attentive to the distinction between following instructions and solving a problem. He recalls his own math teachers marking him wrong for reaching the correct answer without following their defined steps. Now, he sees greater value in evaluating the effectiveness of an approach while still meeting the demands of safety and quality. What matters on the job, he says, is whether the work gets done. “If you can do that faster, it doesn’t always matter if it’s done a different way,” he says. “Off-the-wall ideas are sometimes the best solutions to problems.”
A Structure for Approaching the Unexpected
For Rob, the freedom to question established approaches is an essential part of what makes the work rewarding. His experience as both an engineering teacher and a technician has given him an appreciation for structured procedures, along with an understanding of their limits. In practice, the different elements of computational thinking rarely operate in isolation. A single repair may require him to break a malfunction into manageable questions, recognize familiar patterns, isolate relevant information, and adapt an established procedure as new evidence emerges. The problems that demand the greatest ingenuity often require technicians to draw connections across disciplines and reconsider assumptions that once seemed settled.
Rob’s time in the classroom has impacted how he thinks about preparing students for this kind of work. In his view, schools often emphasize content knowledge and following instructions over learning how to solve problems. Educators may name critical thinking as a goal, but “the only way to teach it is to experience it,” he says. Computational thinking provides a foundation for that kind of learning, bringing structure to uncertainty while leaving room for creativity, experimentation, and revision. In Rob’s words, “Solving any problem, you have to stay calm, you have to do your research, you have to figure out what your path is, and then approach it with confidence.”
Discussion Questions
Can you think of any other jobs that are similar to Rob’s? Would you want to be UAS technician? Why or why not?
Looking back on Rob’s story, where do you see him using each of the four computational thinking practices (decomposition, pattern recognition, abstraction, and algorithmic design)?
Which of the computational thinking practices do you think is most helpful in Rob’s day? Why?
Before Rob starts trying to solve a problem with a drone, he reviews its history and what other technicians have tried. Why do you think that is important to do?
Rob says he believes the primary way to learn critical thinking is to experience it. Can you think of an experience you’ve had in school or outside of school that has helped you learn how to solve problems or think critically?
Since 2020 Project Tomorrow’s Computational Thinking Project has been supporting the adoption and integration of Computational Thinking in partnered schools in NY, MI, and PA, by providing professional development to elementary school teachers. The goal of this professional development is to increase teachers’ competency, confidence and comfort with integrating CT concepts and practices within their everyday curriculum. To learn how Project Tomorrow can support CT integration in your schools, contact CT@tomorrow.org. You can also download our latest case study HERE for more information.
