Erdem Ipek
ROS2, Python, and what robotics software engineers actually ship
Search traffic for ROS2 developer, robotics software engineer, or Python robotics is high because the job titles are vague. This article maps those terms to concrete deliverables: what shipping software actually involves, how it shows up in code review, and what a serious technical review can cover beyond tutorials.
ROS2 is a middleware, not a single skill
Knowing the ROS2 command line helps, but shipping software means designing nodes with clear responsibilities, defining message contracts your team will not regret in six months, and understanding executor models enough that you do not starve critical callbacks. Good reviews look at how responsibilities split between control, I/O, and UI, and how failures are logged and reproduced when a robot misbehaves on a customer floor.
Python remains the default language for robotics research and a large share of application code. The useful signal in portfolios is not syntax, but structure: packages, tests, typing where it pays off, and documentation that another engineer can follow without a screen share.
Flutter and operator-facing tools
Industrial customers expect tablets and HMIs that are stable and readable. Flutter is a practical choice for cross-platform operator tools that talk to your backend or ROS2 bridges. A solid review looks at screenshots or architecture notes: how state sync works, how authentication is handled on the plant network, and how updates roll out without stopping production.
Integration testing and hardware in the loop
Robotics has a physics problem: simulation catches a lot, but not everything. Strong engineers describe their bench setup, how they mock hardware when they must, and what they validate only on real devices. Mentioning Modbus TCP, EtherNet/IP, or specific sensors shows they have crossed the gap between simulation and factory reality.
Location, time zones, and distributed teams
Teams in Europe, North America, and Asia collaborate on robotics products. Being based in Istanbul does not limit impact if communication and documentation are strong. Async-friendly writeups, clear handoffs, and overlap windows that respect both sides matter more than a single office location.
What to verify in a technical review
Practical checks that map to real work: a small coding exercise that involves parsing device feedback, a system design prompt for a weld or pick-and-place cell, or a code review of an existing driver with intentional bugs. Combine that with behavioral questions about production incidents and you get signal fast.
My own background spans autonomous agricultural systems, transportation data platforms, and current work at RBW on real-time robotics. More detail is on my portfolio; freelance work is listed on Fiverr, and the site has a contact path for general questions.