How to Be an Engineer
Principles for building things that matter — in an era when AI can build almost anything.
Engineering is fundamentally the art of managing trade-offs — using the tools of science and technology to invent solutions to real-world problems. What follows is a set of principles we’ve developed over years of building biomedical instruments, diagnostic devices, software, and embedded systems. Some of these ideas are timeless. Others reflect what we think matters most right now, as AI reshapes what it means to be an engineer.
Here is the hard reality: many of the tasks that engineers once trained for years to perform can now be done by someone untrained in a matter of seconds with AI. This is something to really contend with. Engineering curricula have become increasingly vocational over the decades, evolving from roots in physics and mechanical engineering into further and further degrees of specialization. To get an electrical engineering degree is to become an electrical engineer—and that level of identification with a vocation is unfortunate, because it makes this current transition in technology challenging to navigate. You are more than an engineer. The principles in this guide are about developing the judgment, intuition, and breadth of understanding that let you solve problems—any problems—with rigor and creativity. That has always been the point of engineering.
1. Focus on Fundamentals
I believe that, unlike previous technological revolutions, which tended to be driven by specialists (VLSI engineers, RF engineers, full-stack web developers), this one will favor generalists, because there are far more problems to be solved at the intersection of fields than within narrow specializations, and AI enables generalists to call up depth on demand. What I’ve always loved about engineering and the foundational sciences upon which it’s built is: concepts in one domain often map elegantly onto another. Focus on these general principles that apply across many systems: resonance, exponential growth, and the power of thinking in the frequency domain. Closed-loop feedback. Sampling and noise. Mass transport phenomena, conservation laws, the mechanisms of wear and fatigue, and the effects of temperature. These things generalize across countless problems, and they inform a deep intuition that, when coupled with AI tool proficiency, will enable you to solve a wide range of problems.
Consider the difference between an electrician and an electrical engineer. Both understand that electric current causes wires to heat, and that if they get too hot, bad things happen. Historically, the electrician reaches for a derating chart—a tool that tells you what wire gauge to run in a particular conduit for a particular span and a particular load. A derating chart is useful when the problem is well-defined and you need a quick answer. Long ago, someone established design rules based on experimental models and a little math. The electrical engineer, on the other hand, might be developing something more custom and reaches for the Joule heating equation or finite element analysis. These are more sophisticated tools that require more skill to apply—at least historically. Today, the Joule heating equation is available to anyone who asks ChatGPT, and FEA is sure to follow. This means that most of what we have historically considered “electrical engineering” will increasingly look like “electrician” work: the application of easy-to-use tools to solve novel problems. Engineers might not like to admit it, but that’s actually been true for a while. Very few EEs spend their days solving differential equations. Most are reading datasheets, selecting off-the-shelf parts, and applying well-established design rules. And as AI becomes a conversational mentor who is informed not only in your jurisdiction’s building codes but also in the underlying physics of electromagnetics, this kind of work becomes accessible to most anyone willing to learn.
A common phrase today is “vibe coding”—software development while keeping your attention at a more fundamental level than syntax and implementation details. “Vibe engineering” is the same idea. When AI handles the rote application of formulas and design rules, what remains is the part that matters most: understanding what is physically possible, seeing the full system, and knowing which questions to ask.
So: focus on the core principles behind the technologies you work with, and understand their fundamental trade-offs.
2. Don’t Reinvent the Wheel
Most technology development challenges have, at their core, one key limitation in the state of the art that needs to be overcome before the technology can be made viable. As an engineer, your job is to understand this limitation and relentlessly chase it down. For everything else that isn’t core to the problem at hand, build on settled technologies and off-the-shelf components as much as you can.
“Settled technologies” are the best practices and platforms that have been validated by the industry and that you probably don’t need to revisit. A good example today is the ARM microprocessor architecture. There was a time when putting embedded software into a product meant you first had to choose a processor architecture, and this decision came with meaningful tradeoffs. Today, you would need a very good reason not to use an ARM-based MCU, SoC, or SoM. This is settled technology. “Innovating” here isn’t really going to offer you meaningful competitive advantage, and it’s very likely to slow you down.
Settled technology also includes injection molding as the preferred fabrication method for high-volume parts, along with the various automation-friendly technologies available for assembling hard and soft plastic components (thermal staking, ultrasonic welding, two-shot molding). Particularly when it comes to manufacturing, your best bet is to work within the existing supply chain. You’ll get better pricing and better advice. Be clear on what is unique to your technology, and for everything else, go for “boring and predictable”. Don’t reinvent the wheel.
At the component level, there are many standards, design motifs, and OEM modules that exist to make your job as a designer easier. A single-board computer or system-on-module lets you drop embedded Linux into virtually any product from the beginning and carry that architecture through the entire development lifecycle. T-slot aluminum extrusion (80/20) lets you frame up a test fixture, enclosure, or lab instrument in an afternoon without machining a single custom part. Thorlabs and similar vendors offer optomechanical components—breadboards, cage systems, lens tubes—that let you prototype an optical path without designing any mechanical hardware. Luer-lock and flangeless fittings give you a standard fluidic interconnect system that works from benchtop prototype through clinical product. Evaluation boards from chip manufacturers let you validate a sensor or communication interface before committing to a custom PCB. The same principle applies in software: use proven libraries, established communication protocols, and validated components wherever possible. Save your engineering energy for the problems that actually require invention.
3. Think at the Systems Level
Especially now, when AI tools let us go deep into particular topics very quickly, it’s more important than ever to see the bigger picture of an engineered system and how its subsystems fit together.
In hardware development—particularly hardware that intersects with biology and medicine—“the system” doesn’t stop at the electromechanical hardware interacting with firmware interacting with a cloud database. It extends to how that hardware interacts with tissue, molecular biology, a healthcare system, and the practice of healthcare itself. The future of engineering involves tighter coupling between those who understand the problems and those who understand the potential solutions. The more you can be both—the more you can have those conversations within yourself and your engineering team—the more successful you will be.
Systems thinking also exposes trade-offs that aren’t apparent to an engineer focused only on a PCB or a cartridge. There are often ways of solving problems between hardware and software, or ways of shifting how technology is applied in practice that make better or lower-cost solutions possible.
4. Break Down the Problem
Systems thinking leads to subsystem definitions, which lead to components. At each interface, there’s some input/output relationship to be defined—whether that’s an API, a bus specification, or a mechanical interface. Within each subsystem, there’s a set of behaviors, relationships, or state machines.
Break a system into block diagrams and understand the interfaces, behaviors, and relationships. This makes it possible to delegate effectively. It’s often better to break things down in terms of engineering artifacts—this is a PCB, this is a manifold, this is a cartridge, this is a housing—rather than along traditional engineering disciplines, which can create silos. If you can specify a component with enough granularity—what it needs to do, where the I/O ports go, how much power it needs—you can hand it to a specialist and they can build it.
5. Consult Experts
One hour with somebody who has deep experience in the technical area you’re working on can save you years and millions of dollars. This is not an exaggeration.
Think of your development journey as a tree of possibilities branching out from the present moment and your current understanding of the problem. The better you understand the problem, the more likely those branches lead to success. Expert guidance helps you prune entire branches of unproductive technical development before you invest in them. Seek out people who have been there and done that, and listen carefully.
6. Define the Problem, Then Define the Solution
Too often, engineers just want to start building. But particularly when someone is paying you money, it’s critical to align on expectations: what problem are we solving, who are we solving it for, and what criteria will we use to know we’ve solved it? Only then should you define solutions.
As a consultant, I’ve had many clients come to me with an idea for a thing they want me to build. But when I start asking how they arrived at their preferred approach, I often realize they haven’t fully defined the problem themselves. The customer discovery, the competitive analysis, the IP research, the regulatory strategy, the core product requirements—these things require serious upfront work before capital is invested in product development.
In my opinion, one of the best frameworks for this process is Stanford’s Biodesign curriculum. This curriculum focuses on medical device development, but the lessons transfer to anything. Good products start with unmet needs. Understanding your customer’s pain points and how technology can address them is the first step. Define the problem, be clear about the value proposition and who it’s intended for, and begin writing down requirements—understanding that they will evolve as your understanding of customers and users deepens.
Write a product requirements document (PRD). In 2026, with the AI tools available, there is no excuse not to generate requirements and specifications. The writing itself is easy now—what’s hard is having the conversations that inform them, especially with customers. If you’re not writing requirements, it most likely means you’re either not having those conversations, or you’re avoiding the difficult trade-off decisions that will come to define your product’s position in the market. This increases the likelihood that you’ll build a solution for a customer that doesn’t exist. The more you can write down requirements and specifications, the more you bring everyone to the same page and ensure you’re working toward a common vision of success. A good PRD is the source code for your product, and you’d be surprised how far you can get with that one document.
7. Translate Requirements into Specifications
What’s the difference between requirements and specifications? Generally, requirements are from the customer’s perspective and specifications are from your perspective as the design engineer. A requirement might be “the device must return a result in under 15 minutes”; the corresponding specification might define a target flow rate, reaction volume, incubation temperature, and detection threshold that together achieve that requirement. The most critical thing we do as engineers is translate customer requirements into engineering specifications and assess feasibility trade-offs along the way.
The more specific you can be about what you’re trying to build, the more likely you’ll actually be able to build it. A well-defined spec informs conversations with the engineering team and with vendors. It leads directly to verification test procedures, which confirm that the product is meeting spec. With AI, you can often draft these test procedures automatically from a well-defined specification—particularly when the AI has enough context from your tools and lab environment.
Once product requirements are defined in the PRD, draft specifications that trace to those requirements. If your understanding isn’t mature enough to write a spec, write an exploratory study plan that will lead to the data you need to shape it. That’s the difference between feasibility and design. But not writing anything down—no expectations, no statement of work—is a recipe for wasting time and money.
8. Think of All the Ways It Could Break
Risk analysis is an under-appreciated aspect of engineering. If you do it right, it can actually be really fun. It is the formalized process of asking “what could go wrong” and “how do we prepare for that”?
A common tool is the failure modes and effects analysis (FMEA). In an FMEA, you systematically walk through each component or process step and ask: what could fail here, what would happen if it did, and how likely is it? You score each failure mode on severity, probability of occurrence, and detectability, then prioritize the highest-risk items for mitigation. Sometimes you design features into the product that reduce or eliminate the severity of unacceptable failures—a mechanical stop that prevents over-travel, a current limiter that protects a sensor, a watchdog timer that resets a hung processor. Other times, you accept that the product comes with certain residual risks and work with your regulatory, marketing, and documentation teams to make sure those risks are properly communicated to the user.
Either way, if you don’t do this work up front, you put the customer and the company at risk. In medical devices, this is not optional—it’s required by regulation and enforced through design controls. But it’s good practice everywhere. Products fail in the field, and thinking through failure modes early is how you prevent recalls, injuries, and lawsuits.
A special note on software: in regulated industries, software is treated with an extraordinary level of scrutiny, and for good reason. The fundamental challenge with software is that it is effectively impossible to test exhaustively, in the way that it is often possible to characterize hardware. This is why hardware failsafes are generally preferred in safety-critical systems, and why software in these systems is subject to rigorous development standards and verification processes. In a future where AI models (the blackest of black boxes) are deployed into safety-critical systems, the role of engineered safeguards, whether simple procedural software watchdogs or hardware interlocks, will be even more important.
9. Make the Plan
Plans change—but without a plan, you’re lost. The most basic plan starts with a series of milestones, generally tied to project proof points or deliverables. From there, you establish a prototype roadmap, where at each step you ask: how do we demonstrate this goal? What are our biggest risks, and how do we de-risk them early? What prototyping methods get us results quickly and cheaply?
Plans are living documents: schedules shift, requirements change, teams evolve. Keep them updated. At every cycle, review what you learned and set yourself up for the next one so those learnings carry forward. At Mosaic, we are building AI-in-the-loop project management tools that help us keep our activities aligned to overall project goals, stay on top of milestones, and provide weekly visibility to our clients.
10. Understand the Assignment
Every prototype or experiment should answer a question. The more critical the question, the earlier it should appear in your prototyping roadmap. If you’re building an instrument around a new kind of sensor and you know that sensitivity is ultimately going to make or break your intended use case, it’s critical to evaluate sensitivity early in the process so you know you’re building around the right core technology.
The natural progression of early-stage development is proof-of-concept experiments—often “breadboard” works-like prototypes for evaluating fundamental system performance, combined with “looks like” mock-ups for evaluating user acceptance and human factors. Don’t get caught up in aesthetics and demos at the expense of confronting the core technical challenges—the ones most likely to fail. A good investor will look through a flashy demo and ask: How do you get the cost down? How do you avoid this blocking IP? How do you ensure adequate sensitivity? Be prepared to answer those questions.
As a communication tool, putting something physical in the hands of an investor or user is incredibly powerful. People respond to physical prototypes far more strongly than to CAD models. But you want to pair “looks like” and “feels like” prototypes with “works like” experimental validation: simple breadboards from off-the-shelf components that demonstrate the core science, combined with a well-articulated vision of how that science advances toward an integrated, cost-reduced product. At each prototype cycle, understand what this cycle is for and how to get the most from the investment.
11. Give Yourself Room
When you’re prototyping, especially early on, resist the temptation to optimize form factor or pin count or cost. Start with the Cadillac, then optimize towards the Toyota once the fundamentals are proven. If you try to size or cost optimize too soon, you’ll easily find yourself painted into a corner: “If we just had one more PWM channel,” or “if we’d just sized this with a 30A breaker instead of a 20A,” or “if I’d just given myself a little more room in this housing to add another connector.” Don’t get clever too quickly. Give yourself design latitude. The time to optimize is after you’ve proven the concept and understand the full design space—not before.
12. Always Consider Cost
Engineers should always consider cost as a design parameter. Even in early prototyping—where cost is less of a concern because you’re maximizing learning—you need to maintain line of sight to a manufacturable product that meets the customer’s cost targets.
Create a costed bill of materials (BOM) early, even if the costs are rough order-of-magnitude (ROM) guesses. A common approach is a spreadsheet with different columns for different minimum order quantities (MOQs)—1, 100, 1,000, 10,000 units. As you work with vendors, ask how costs scale: “How does this cost change as we go from 1 to 100 units?” “How much of that is NRE?” You can ask casually in conversation or formally through actual quotes at different volumes. It’s also helpful to look at adjacent products in the market and estimate their cost structure by writing out the BOM and estimating component costs—pretty quickly, you’ll develop an intuition for what things generally cost to mold, stamp, bond, and assemble. For back-of-the-envelope costing, a useful rule of thumb is that BOM is roughly half of COGS (cost of goods sold), and COGS is roughly half of retail price. You can estimate labor by timing how long it takes you to assemble something and applying basic assumptions for labor rates and overhead at a contract manufacturer. If you can do this well, you will be an incredibly valuable resource to companies who want to understand the true cost of their supply chain.
13. Take Things Apart
The world is full of stuff. There is an entire education to be had in taking stuff apart and studying how it was designed and manufactured. In particular, you can learn an enormous amount from products adjacent to the one you’re building. At Lucira, we did teardowns of digital home pregnancy tests and developed a pretty good understanding of their manufacturing process and cost structure. Get in the designer’s head: Why did they put this shielding here? What camera module are they using (and what are its specs)? Why are there two PCBs instead of one? How did they ensure optical alignment? What are the subassemblies, and in what order were they assembled?
Along the way, you’ll find ways the product could be improved. Products that go to market are rarely perfect. If your goal is to build a better version of an existing instrument, start by studying the ones that have succeeded. You can find used equipment on eBay and auction sites for very little money. There’s no excuse not to do it, and it’s fun.
14. Design for the Full Lifecycle
It has become incredibly easy to 3D print anything, and this is great in the early stages. But if you’re not thinking about how a part is eventually going to be manufactured, you’re setting yourself up for some hard lessons and expensive redesigns down the road.
Design for X (DfX) is shorthand for the discipline of considering the full lifecycle of a product as you design it. Design for manufacture: can this part be injection-molded, or have you designed geometry that only works as a print? Design for assembly: can a technician put this together efficiently, or does it require a surgeon’s hands and an hour of alignment? Design for test: how will you verify that each unit works before it ships? Design for maintenance: can a field technician replace the consumable or failed component without disassembling the entire instrument? Design for distribution: can it survive shipping, and does it fit in a standard box?
A hardware engineer who thinks through these questions will design things with fewer iterations, faster timelines, and lower cost. The same principle applies to software: if you’re not thinking about scalability, deployability, and maintainability from the beginning, you’ll accumulate technical debt that gets harder to pay down with every release.
Develop intuition around tolerances—what’s reasonable for a machined part versus an injection-molded part versus a 3D-printed part. When you design mechanical assemblies, be mindful of where your critical-to-quality (CTQ) attributes lie, and work to minimize the number of tight tolerances needed to achieve the desired operating characteristics of the system. Understand what manufacturing approaches are available to you, and get hands-on experience—whether in a prototyping lab or by working with a vendor and asking lots of good questions.
15. Make It a Software Problem
With every instrumentation project, I ask myself: how quickly can I make this a software problem? The days of op-amp control systems are long gone. We almost always embed a little digital intelligence—a microcontroller, an FPGA, a single-board computer—because it gives us options down the road. As a designer, you’re always thinking: what if this doesn’t work? How might I want to iterate, and what debug information might I want to gather to inform the next design? It’s almost always easier to answer these questions in the software domain than in the hardware domain. Hardware iterations involve PCB revisions and lead times. Software iterations involve a pull request.
Even if you’re a dedicated hardware developer, you need to understand the role software will play in your product. Virtually every product has a software component—whether it’s embedded intelligence, cloud services, a user interface, or even just manufacturing quality control. A friend who works at a major clothing retailer recently told me, “Every company is a software company.” That statement resonates, especially now, when software can be worked into layers of business operations that were previously thought to require human decision-making. The least expensive solution to a problem is almost always a software solution.
16. Listen to Your Manufacturing Vendors
Most design engineers haven’t spent a lot of time on a manufacturing floor. Part of that is cultural, and part of it is geographic. However, most contract manufacturers are happy to give tours to potential clients. Build these relationships early. Give vendors a chance to weigh in on design before it’s set in stone. Treat them like another member of the team. They know more than you about how things tend to fail and what tends to drive cost. When a vendor tells you your tolerances are too tight, that your part will warp, or that you have yield risk on an adhesive process—listen. Experienced vendors and manufacturing engineers can help you anticipate problems that won’t show up right away, but when they do show up, they can be extremely expensive to fix. What a lot of hardware design engineers don’t realize is that the design of the manufacturing process is often more complex than the design of the product itself. If you’re developing hardware, you really must think of these things together.
17. Be Data-Driven
If you can develop a model—whether it’s a finite element simulation in COMSOL, a ray-tracing model in Zemax, a SPICE circuit simulation, or an analytical model, use it to guide decision-making around geometries, sensitivities, tolerances, and resolution. With today’s AI tools, there’s no excuse not to do at least some level of analytical estimation, even if you’re not formally trained in the relevant discipline.
But ultimately, one well-designed experimental result is worth a hundred simulations. Emphasis on well-designed. Too often engineers run inconclusive experiments, ignore statistical significance, and make important decisions based on an N of 1. Know your statistics and apply them rigorously.
Data-driven decision-making is also critical for managing disagreements on a team. If you can orient everyone around an A/B test of two approaches, it takes the ego out of the discussion. Everyone responds to data. And don’t be afraid to critique the data if you think the experiment is flawed.
18. Learn to Work with Customers
The future of engineering will involve much more direct engagement between engineers and customers, as AI flattens hierarchies and eliminates disciplinary silos. Something that engineers have not always been good at—myself included—is working with non-technical people. But that’s what the discipline will require of us. Gone are the days of the “rockstar” engineer who sits in a corner behind a tower of Red Bulls and codes day and night. You’ve got to communicate.
Focus on your customers’ needs and educate them on potential solutions. Stay open to feedback. Don’t get too attached to your own ideas. Understand that the goal is to solve problems. If you’re not solving problems that impact other people, you’re building art, not developing products.
The most critical aspect of working with customers is managing expectations—specs, budgets, timelines, etc. If you’re following the advice in this guide, this part should actually be fairly easy. Follow a process for soliciting requirements, developing specifications, and defining acceptance criteria as early as possible. It’s much easier to argue about a spec up front than to argue about the bill after prototypes have been built and they don’t perform to the customer’s expectations. Let your modeling, feasibility experiments, “looks like” prototypes, cost analysis, and risk analysis guide these conversations. You will often need to tell a client that things they want to do simply aren’t possible—after all, there’s often a good reason why they haven’t been done before. Don’t hold back on that assessment, but be prepared to back it up with data and offer alternatives.
19. Disagree and Commit
Going back to the tree analogy: it’s important to avoid too many parallel branches. Fragmented effort saps motivation and resources. People lose energy when they feel they’re working on something ancillary to the primary objective.
It is the technology leader’s responsibility to weigh options, hear the points and counterpoints, and make a decision about how to move forward. That may involve a quick feasibility experiment to inform the choice. But “let’s try both” is, more often than not, a way to spend a lot of money, fragment attention, and not get anywhere.
Hear the disagreements, honor them, perhaps agree to revisit concerns later—but ultimately, everyone commits to the chosen direction and acknowledges the rationale.
20. Keep Humans in the Loop
Engineering may not involve coding or circuit design or VLSI layout in the years ahead. But the judgment that comes from understanding the customer, the market, the competition, and the problem at hand is more critical than ever. As AI takes on more of the execution, engineers become more like system designers, system designers become more like product managers, and product managers become more like executives. At every level, the challenge is to level up.
But don’t abdicate responsibility. There is no substitute for human judgment in the pursuit of human problems. Particularly for safety-critical systems, it is imperative that you understand what you are responsible for building and that you approve it along the way. Build development cycles with humans in the loop. Use versioning tools and review diffs that give you line-by-line approval control over AI-generated edits. This applies to PRDs and marketing materials as much as source code and BOMs. At Mosaic, we do the majority of our work with git-versioned text files—even many of our hardware design documents.
A Core Curriculum for the Modern Engineer
The following is what we consider essential preparation for the kind of engineering we do—building hardware and software systems at the intersection of life sciences, medicine, and environmental sensing. It’s opinionated, but broadly applicable.
When I was an engineering student, many of my classmates questioned why anyone would study philosophy or art history or dance. “Yeah, like those kids are really gonna contribute to GDP.” As the child of two English majors, I knew better. An education is so much more than training for a vocation—especially in a world where the vocational skills keep changing. Studies have consistently shown that liberal arts graduates fare better in the long run in terms of adaptability to change, leadership opportunities, and a greater sense of meaning in their work. Salaries converge as well. My sense is that a liberal arts education will better prepare students for the AI-native future than a traditional engineering curriculum. Even better is a curriculum which blends both—I’m quite fond of schools like Harvey Mudd College, which stress general foundational engineering skills alongside a genuine liberal arts core.
The difficult reality is that the next decade will see many engineers lose their jobs because their narrow vocational skillset has become obsolete. This will happen across a wide range of professional fields. Those who adapt will be the ones who can level up their thinking, applying what they’ve learned in their field to solve more general problems across systems, organizations, and industries.
A note on how to learn: you don’t need a four-year degree to build technology. You need the drive and the discipline. There are extraordinary engineering resources available online—YouTube alone offers world-class instruction in pretty much every subject. The best way to learn engineering is through open-ended projects where you work in the lab or the fabrication studio building things and solving problems that don’t have ready solutions. This is the kind of educational experience we hope to build at Mosaic: project-driven, hands-on, with AI as a constant learning companion.
Physics
Get as much physics as you can, especially courses with hands-on demonstrations, because these bring concepts to life. Pay particular attention to electricity and magnetism, heat and mass transport, and thermodynamics. Focus less on the mathematics of physical phenomena and more on developing intuition for their fundamental scaling relationships and trade-offs. Fluid mechanics, for example, is full of math. But for making day-to-day design decisions, people tend to rely heavily on a small set of easy-to-estimate dimensionless numbers (Reynolds, Peclet, Mach, etc.) which provide quick intuition about the dominant physics of a system.
Electric Circuits
Develop a basic familiarity with RLC circuits, transistor circuits and amplifiers, electric power, and electromagnetic signal transduction. These concepts come up across a remarkable range of domains—from EKG monitors to motor controllers to power grids to RF communication. A circuits course bridges the gap between the physics of electromagnetism and the practical reality of designing systems that sense, actuate, and communicate.
Math and Statistics
Calculus and linear algebra are the languages of physics and engineering—you need enough to follow derivations and understand what the tools are doing under the hood. But more practically, invest in statistics and probability. Too many engineers run experiments, collect data, and make decisions without a rigorous understanding of statistical significance, confidence intervals, or experimental design. Learn to design experiments with appropriate controls and sample sizes. Learn regression, hypothesis testing, and Bayesian reasoning. These skills are directly applicable to everything from process optimization to clinical trials.
Computing and Programming
The universe of open-source software available today is staggering. Whatever you need to do—signal processing, image analysis, machine learning, data visualization, hardware control, web applications—there is almost certainly a well-maintained open-source library that does most of it. And if it hasn’t been built yet, AI can build it for you with some guidance. Software coding as a discrete discipline is going away, and it’s going away quickly. You need to be able to spec software, not build it from scratch. This means the breadth of things you need to be able to spec has increased dramatically from even five years ago. Understand what’s possible, know the right questions to ask, and learn to evaluate whether the output is correct.
That said, foundational computing literacy is still essential. Gain experience with embedded computers and microcontrollers—there are far more microcontrollers in the world than people, and once you understand what’s possible through analog-to-digital conversion, sampling, embedded processing, and state machines, you can imagine countless applications. Prototyping has never been easier with Arduinos, STM32, ESP32, and Raspberry Pi.
Learn Linux. It powers the internet, most software systems in the world, and embedded products. It’s fully open source and free to use. Get comfortable at the command line—even though day-to-day you’ll ask an agent to do most of the low level work, you need to know the CLI tools at your disposal.
Learn Python—it’s the lingua franca of scientific computing, data analysis, and AI. If you’re going to learn two languages, add C, so you understand how source code translates to machine code. Gain some understanding of computer architecture, networking (TCP/IP, REST APIs), and how computing systems communicate.
AI and Machine Learning
Take a course—or work through a structured online curriculum—on machine learning and AI. Not because you’ll necessarily be training models from scratch, but because these tools are becoming embedded in everything: automated image analysis, predictive maintenance, natural language interfaces for instruments, generative design. You need to understand what they can and can’t do, how they fail, and when to trust their output. Understand the basics: supervised vs. unsupervised learning, neural networks, training data, overfitting, and evaluation metrics. At minimum, learn to use pre-trained models and APIs effectively.
Mechanical Engineering and Fabrication
Take a course in engineering mechanics if you’ll be designing mechanical or electromechanical assemblies. A course in microfabrication is valuable if you’ll work with microfluidics, MEMS, or integrated circuits. There are many product opportunities at the intersection of CMOS microfabrication, microfluidics, biology, and sensor technology.
Learn a CAD tool—OnShape and SolidWorks are both excellent. Get hands-on with 3D printing, CNC machining, laser cutting, and welding. Develop familiarity with supplier catalogs like McMaster-Carr and Digikey. The goal is not to become a machinist, but to develop enough fluency that you can design parts that are actually manufacturable and communicate effectively with the people who will make them.
Chemistry and Biology
Organic chemistry is foundational for many sensing technologies that bridge the physical and digital worlds, and it underpins biochemistry and biology. Human physiology and anatomy are valuable not just professionally but personally. Cell biology—understanding metabolic pathways, cellular communication, division, and death—is essential for much of the work we do.
Note: we don’t specifically recommend a course in microfluidics. The discipline is very applied, and university courses tend to focus narrowly on a professor’s research interests. It’s better to take the fundamentals and learn the state of the field through conferences and papers.
Instrumentation and Signals
A course in basic instrumentation—signals and systems, linear time-invariant systems, control theory, PID controllers, sampling rate, Nyquist criterion, SNR, sources of noise—is fundamental to any engineering system involving sensing and control. These concepts directly impact clinical sensitivity and specificity in diagnostics and translate across signal modalities.
Get comfortable with electronics troubleshooting: learn to use an oscilloscope, probe PCBs, and trace a signal path in a schematic starting from the power supply. If you can, study basic optics, imaging, and photonics—these are foundational in medical devices, life science tools, environmental sensing, and consumer electronics, and concepts like resolution, noise, and interference translate directly to other signal modalities.
Beyond Engineering
Study philosophy. Philosophy teaches you to think clearly, construct arguments, identify assumptions, and sit with ambiguity—skills that are at least as valuable as any technical course. Logic, ethics, epistemology, and philosophy of science all sharpen the kind of thinking that engineering requires but rarely teaches explicitly.
Develop a craft. Whether it’s woodworking, drawing, music, cooking, or ceramics—invest in making something with your hands. A craft teaches patience, attention to materials, and the relationship between intention and execution. It serves an intrinsic need for creative expression and grounds you in a way that extrinsic work cannot.
Build community. Engineering has always been a bit isolating, and it has become even moreso in recent years for those of us who spend a significant amount of time working remotely. I suspect that, as industries are disrupted, the average company shrinks, and the average project duration shortens, this trend will continue, and the workplace will provide fewer and fewer social opportunities. On the other hand, it’s never been easier to build community, whatever you’re into.
Move your body. Physical health is not separate from intellectual performance. Exercise, sleep, and time outdoors directly affect your ability to think clearly, sustain focus, and manage stress. Make it non-negotiable.
Embrace change. The pace of technological change is accelerating, and the skills that got you here may not be the ones that take you forward. Cultivate comfort with uncertainty. Learn how to learn. The engineers who thrive will be the ones who treat their career not as a fixed path but as a continuous experiment.
Frankie Myers is the founder of Mosaic Design Labs, a biomedical product development studio in the San Francisco Bay Area. We build instruments at the intersection of hardware, software, and biology — and we believe the best engineers want to work on products that matter, not just products that make money.