01 / The physical foundation: Materials Science & Deepening the Craft
I didn’t take the traditional computer science route. I graduated with an MSc in Materials Science from AGH in Kraków. While it wasn't a software degree, it gave me an invaluable mindset for embedded engineering: an understanding of physical systems. When you work with household appliances, code doesn't live in a vacuum—it drives motors, heats water, and reacts to physical sensors.
As I transitioned fully into software, I became obsessed with mastering the craft properly. I went through two intensive, week-long live Python trainings (from foundations to advanced mastery), and later, in my free time, tackled Daniel Bourke’s famous 24-hour PyTorch course—spending a solid week grinding through the material and the next year practicing and building real training loops from scratch.
02 / 2019–2020: Starting from zero (with pencil and paper)
When I joined BSH in Rzeszów in December 2019, I was the first software engineer on site. There was no existing ecosystem to plug into. I literally started by designing our systems and writing out our test automation processes by hand, with a pencil on paper, before writing a single line of infrastructure code. From those sketches, I set up our Git strategies, configured Jenkins and GitLab CI/CD pipelines, and established how we manage releases.
At the time, my daily work revolved around system requirements. Anyone who has worked in R&D knows how inconsistently functional requirements are written by humans. Turning those documents into testable code was a massive manual bottleneck. To solve this, I built an intelligent parsing engine that acted as a "Single Source of Truth"—reading complex, human-written specs and automatically generating executable Python code and data structures from them.
03 / 2020–2021: A year in Germany & scaling across borders
Shortly after setting up the local foundation, I spent a year in Germany working directly with firmware engineers, embedded Linux maintainers, and product leads. My task was to design an automated software release pipeline that could serve teams across multiple countries.
Technically, it was a great challenge, but the biggest takeaway was organizational. When you build tooling for distributed teams in Germany, Poland, and China, code is only half the battle. Establishing clear interfaces, shared standards, and mutual trust is what actually makes an architecture survive in production.
04 / 2022–2023: Evolving the SDK & Containerizing the Hardware
Back in Poland, I stepped into a Senior role and began guiding a small team of engineers. By this point, our initial scripts needed to mature into a serious platform.
I redesigned our legacy communication layer from the ground up using Python asyncio and DBus, enabling non-blocking message passing between the embedded Linux boards inside the machines and our external control systems. This became the backbone of our unified test SDK.
To run this at scale, I designed our multi-container test bench architecture—separating the test execution containers, the web control interface, and the central hardware broker that talks to PLCs and measurement gear. Because the architecture is so lightweight, we don't need expensive server racks; an old office laptop easily serves as a bench host. I also engineered the thing that makes 24/7 hardware testing actually viable: autonomous failure recovery. When a test fails on a real machine, the system logs the exact path to the failure, physically recovers the appliance back to a clean initial state, and continues executing the queue.
05 / 2024–Present: Global Architecture, Synthetic Data & End-to-End Automation
Today, I guide 4 engineers and oversee the test architecture from unit tests all the way to full hardware integration. I also directly own the Service Menu module—a critical piece of embedded software used by field technicians worldwide, running across all 15 of our hardware platforms.
My recent work has focused on machine learning and removing the final bottlenecks between requirements and hardware:
- Synthetic Data & PyTorch Pipelines: To visually validate appliances without software telemetry, I spent a significant chunk of time mastering PyTorch training loops. Rather than manually labeling thousands of photos of coffee machine screens, I built a large-scale synthetic data generator that produces training images and videos on the fly, feeding directly into our custom classification and OCR pipelines.
- Internal AI Developer Tools: When we needed modern AI workflows, I built an internal ecosystem—combining a RAG-based GPT assistant over our proprietary docs with a custom Cursor-style prototype and A2A (agent-to-agent) workflows.
- Closing the release loop (2026): Building on my early work with requirement parsers, I recently engineered a complete Wiki–Jira–Polarion integration. The system monitors Confluence tables for new software builds, automatically creates the corresponding Jira tasks, sets up the test runs in Polarion, and triggers execution directly on our physical test benches.
06 / My Leadership & Mentoring Philosophy
Leading my team of 4 engineers is the culmination of my journey so far. I don't see management as a separate discipline from engineering; I see it as an extension of building a great product. My role is to design an environment where talented people can do their best work.
Growth Through Real Ownership
I believe deeply in learning by doing. Rather than handing out isolated scripting tasks, I mentor my team by giving them ownership of core architectural pieces of the SDK we use every day. They aren't just writing tests; they are contributing to a living product, tackling challenges of rising difficulty that stretch their skills in system design.
Curiosity as a Standard
Stagnation is the enemy of good engineering. Just as I pushed myself through live Python trainings and spent my evenings learning PyTorch, I actively champion continuous learning for my team—successfully advocating for company-sponsored access to platforms like Udemy and giving them the space to explore new technologies and bring fresh ideas back into our stack.
Smarter in Pairs
The hardest embedded and architectural problems are rarely solved in isolation. I foster a culture where collaboration is the default, frequently using pair programming—one keyboard, two minds—to untangle complex bugs or design new features. It produces cleaner code, spreads domain knowledge organically, and builds a team culture where asking for help is seen as a sign of strength.