By Simone Panja
Listen. Keep Asking Questions
I realized early in the process that building an effective HMI would require more than technical implementation; it needed a deep understanding of the machine, the workflow, and the problem it was meant to solve. This was the foundation of the needed Requirements Specification.
The experience taught me that successful engineering starts not with implementation, but with listening: understanding the system, the people who use it, and being willing to let solutions evolve.
Building Not From Scratch
One of the most important lessons I learned was that not everything needs to start from ground zero. I initially believed that for a product to be meaningful or innovative, every line of code and every design decision had to come entirely from my own effort.
Over time, I realized that leveraging existing resources, whether codebases, libraries, or shared knowledge, does not diminish originality. Instead, it accelerates development, reduces errors, and allows you to focus on solving the core problem.
Learning Through Community
As I worked on building the HMI using a 480×320 SPI-driven TFT display, I encountered an issue where the screen would suddenly turn white. Interestingly, the rotary encoder still registered input, incrementing worked, but decrementing caused the display to fail. After days of debugging and discussions with Chris, I turned to online forums.
Buried in an Arduino forum thread from 2024 was someone facing the exact same issue. The root cause turned out to be a pin conflict: both the TFT_SCLK pin and the rotary encoder’s DT pin were assigned to GPIO 18. This overlap caused the display malfunction.
That moment reinforced a simple but powerful lesson: someone has likely faced your problem before. Knowing how to search, interpret, and apply solutions from a broader community is an essential engineering skill.
Using AI as a Productivity Tool
Another major productivity shift came from incorporating AI tools into my workflow. Tasks like positioning gauges on the display or aligning a menu system were surprisingly time-consuming. By using tools like Claude to generate layout code, for example, centering gauges or structuring a left-aligned menu, I was able to significantly speed up development.
However, I quickly learned that AI has its limits. While it performed well for structured, repetitive tasks, it struggled with more complex logic such as coordinating rotary encoder input with dynamic gauge behavior or debugging state transitions in the menu system. In those cases, relying on AI often introduced more confusion than clarity.
This taught me to use AI intentionally: as a tool to accelerate simpler tasks, not as a replacement for understanding core logic.
Learning from Those Ahead of You
When I first started working with an Arduino-based prototype, the learning curve felt steep. That’s when I turned to YouTube creators like the Curious Scientist, whose walkthrough on building an advanced menu system with a rotary encoder became foundational to my implementation. Other creators, such as Upir and The Last Outpost Workshop, also provided valuable insights into display handling and embedded design.
At one point, I struggled with implementing animated gauge visuals for the HMI. Instead of starting from scratch, I explored examples from the TFT_eSPI library, particularly Bodmer’s sprite-based animated dial. This gave me a strong starting point for rendering smooth, responsive gauges.
These resources didn’t just give me code, they helped me understand how experienced developers think through problems, structure systems, and debug effectively.
Stepping Outside My Comfort Zone
Even pre-built examples aren’t always perfect. At one point, I encountered a bug where the dial needle overlapped the gauge markings during rotation.
Fixing this required modifying the underlying graphics, which led me to use Photopea to redesign the dial assets, something I had no prior experience with.
That moment captured one of the most valuable lessons from the summer: growth often comes from stepping into unfamiliar territory. Whether it was debugging hardware conflicts, learning from online communities, leveraging AI tools effectively, or even editing graphical assets, each challenge pushed me beyond what I initially thought I could do.
Move Faster. Think Critically. Build Better!
This experience reshaped how I approach problem-solving. Innovation is not about building everything from scratch, it’s about knowing when to build, when to adapt, when to learn from others, and when to jump in the deep end of the pool. By leveraging communities, tools, and existing resources, I was able to move faster, think more critically, and ultimately build a more effective system.
Becoming a Better Engineer Part One >
