PDX 2025 registration is live! Use code “WBH50” for $50 off registration!

Enter to win one of two free expo passes by filling out the survey.

Welcome to The Wave Engineering Newsletter, your weekly guide to the cutting edge of engineering. Whether you're a seasoned professional, an eager student, or simply curious about innovation, we’re here to inform, inspire, and connect.

More than just a newsletter, we tell the human stories behind the tech—spotlighting the innovators, dreamers, and changemakers shaping our world. Backed by insights from Pipeline Design & Engineering and the Being an Engineer Podcast, we deliver the latest advancements, impactful collaborations, and stories that redefine what’s possible.

Join the conversation at The Wave, where ideas spark, questions find answers, and the engineering community comes together to create the future. Engineering isn’t just about technology—it’s about people. Subscribe and ride the wave of innovation with us.

[Action Required]: Reply to this email answering the following question. Top, thought provoking comments will be featured on The Wave!

In order to push innovation in physical product development, do we need hardware engineers who are more native in software, or software engineers who are more native in hardware?

I’ve been browsing engineering jobs in the mechanical R&D and manufacturing in various industries. Once thing has stood out: a lot of companies want the typical Solidworks + extensive GD&T experience, but buried in these job descriptions was also mention of experience with coding languages preferred. The first time that I saw it, I figured it was a copy-paste error, but the more it pops up the more I realize that this is a fundamental shift in the industry. Hardware engineers that can code are no longer unicorns, but becoming the norm.

This pattern is hard to ignore. When I talked to professors at local engineering schools, they told me they're scrambling to add programming courses to mechanical engineering curricula because their graduates kept getting turned away from interviews for lacking software skills. Startup founders I know can't build hardware products anymore without significant firmware components, data collection systems, or IoT connectivity. Even traditional manufacturing companies want engineers who can automate their design workflows and build custom analysis tools.

It hit me that we're living through a fundamental shift in what it means to be a hardware engineer. The coolest innovations today - whether it's Tesla's self-updating cars, SpaceX's reusable rockets, or medical devices that learn from patient data - all exist at the intersection of atoms and bits. Pure hardware knowledge isn't enough anymore, but neither is pure software expertise. The future belongs to engineers who can speak both languages fluently.

This isn't just about adding a programming language to your resume. It's about understanding how software is reshaping the entire hardware development process, from initial design through manufacturing and into the field. Over the next four weeks, we're going to explore this convergence from a hardware engineer's perspective - not how to become a software developer, but how to remain a great hardware engineer in a world where the two domains are inseparably linked.

My hot take: We need experienced hardware engineers that are willing to take the leap and hybridize their tool kit. Against the typical Silicon Valley narrative, the future belongs to hardware engineers who become native in software too.

I got thinking about this question when debating the future of development with a buddy of mine - a software engineer. For years, we’ve geeked out on each others profession and the impact we both have on our respective industries. In our most recent debate, he asked me the question: “To really push innovation in physical product development, do we need hardware engineers who are more native in software, or software engineers who are more native in hardware?”

Here's the uncomfortable truth that most tech companies don't want to admit: building physical products is fundamentally harder than building software products. When a software engineer writes buggy code, they push a patch. When a hardware engineer designs a flawed component, thousands of units might need to be recalled.

This difference in consequence creates a different kind of engineer. Hardware engineers think in constraints, failure modes, and physical reality from day one. They understand that you can't just "move fast and break things" when those things cost $50,000 each and take six months to manufacture.

Software engineers who try to bridge into hardware often bring dangerous assumptions with them. They expect infinite computational resources, assume perfect sensor data, and design systems that look elegant in code but fail catastrophically in the real world scenarios. I’m not trying to downplay software engineering’s role in product development innovation (see part 3 of 4 in this series), but I’ve seen this pattern repeat itself dozens of times across different industries.

But when hardware engineers learn software, something different happens. They bring their constraint-based thinking into the digital realm. They write more robust code because they're used to designing for failure. They build better APIs because they understand the physical systems those APIs need to control. They create digital twins that actually work because they understand both the atoms and the bits.

I've seen this hybrid approach transform projects across multiple industries. In automotive manufacturing, hybrid engineers are building digital twins that don't just model individual components but entire production lines. These systems use real-time sensor data to optimize manufacturing parameters, predict maintenance needs, and even simulate the impact of supply chain disruptions.

One particular example stands out. A traditional manufacturing engineer might design a quality control system that samples 1% of products and flags defects after they occur. A software engineer might build a machine learning system that analyzes images but struggles with the physical constraints of the production line. But a hybrid engineer builds a system that integrates computer vision with real-time process control, automatically adjusting manufacturing parameters to prevent defects before they happen.

The difference isn't just technical capability. It's a fundamental shift in how we approach engineering problems. Instead of building physical systems and then adding software on top, hybrid engineers design integrated solutions where the physical and digital components are optimized together from the beginning.

True hybrid engineers don't just use software tools. They think like software architects while maintaining their hardware engineering discipline. This means understanding database design when you're building sensor networks. It means thinking about API scalability when you're designing distributed manufacturing systems. It means applying DevOps principles to hardware validation processes.

This integration happens at multiple levels. At the component level, it means designing sensors that produce clean, consistent data rather than just functional measurements. At the system level, it means architecting software that can handle the unpredictability and latency of real-world hardware. At the organizational level, it means building teams where hardware and software development cycles are synchronized rather than conflicting.

The most successful hybrid engineers I know didn't just add software skills to their hardware knowledge. They developed what I call "bilingual intuition" - the ability to instantly translate between physical constraints and software possibilities. They can look at a mechanical design and immediately see the data structures needed to model it. They can review an API specification and understand its implications for hardware performance.

So where do you start? Don’t abandon your engineering discipline, but extend your thinking into the digital realm.

Start with data. Every hardware system generates data, but most hardware engineers treat data collection as an afterthought. Begin by building systems that collect, store, and analyze the data your hardware produces. This will naturally lead you into database design, API development, and data processing pipelines.

Next, focus on automation. Instead of manually running tests or collecting measurements, build scripts that automate these processes. This introduces you to software development practices while solving real hardware engineering problems.

Finally, think systems. Start designing solutions where the hardware and software components are optimized together. This is where the real value of hybrid engineering emerges - not in using software tools to support hardware development, but in creating integrated solutions that neither pure approach could achieve.

I was to reiterate, I’m not trying to diminish the value of software engineering. It's about recognizing that the future of engineering lies in seamlessly integrating physical and digital systems. And that integration works best when it's led by engineers who understand the unforgiving constraints of the physical world.

The engineers who master this hybrid approach won't just be more valuable in the job market. They'll be the ones defining the next generation of engineering solutions, building systems that are impossible to achieve through traditional specialized approaches.

Engineering is about solving, innovating, and connecting ideas to make a difference. Progress is a collective effort and your curiosity is what drives it forward. Thank you for exploring the dynamic world of engineering with all of us at Pipeline Design & Engineering and The Wave.

If you found value in this newsletter, share it with a friend or colleague who might enjoy it too. Don’t forget to subscribe so you never miss a new perspective, idea, or breakthrough.

“Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while.” - Steve Jobs

In collaboration and creativity,
Brad Hirayama
Blueprinting tomorrow, today