Is Robotics Harder Than Web Development? An Honest Comparison

Yes, robotics is harder than web development, though not for the reason most people expect: the code is comparable, the feedback loop is not. A browser gives an error and a refresh; a machine gives a quiet wrong answer, and choosing ROS 2 or HORUS changes setup cost, not difficulty. It flips for a supervised bench arm you did not build, which is easier than shipping a real website. This post is for engineers who write software for a living, know the web well, and want to know what actually gets harder before committing a year.

You have shipped things. Real things, with users, on deadlines, where a bad deploy was somebody's bad afternoon. So when people describe robotics as hard, part of you assumes it is the usual hard: unfamiliar libraries, a build system with opinions, a week of confusion and then fluency.

Then you buy a kit, and something is off in a way you cannot name. The code is short. The concepts are not exotic. And yet a whole evening disappears into a motor that turns the wrong way, and another into a camera that works when plugged into the laptop and not into the board.

The part that unsettles you is the silence. Nothing throws. There is no failing test, no red trace, no line number. The robot simply does something slightly wrong, repeatedly, and the only evidence is your own eyes.

Then you rerun it and it behaves differently. Same code, same command, different result, and no diff to look at. That is the moment people either get fascinated or quietly put the kit in a cupboard.

Should the difficulty put you off moving from web development into robotics?

No, but it should change how you plan the first year. The difficulty is real and it is concentrated somewhere specific: not in the language, not in the algorithms, but in the loop between making a change and learning whether the change was right. On the web that loop is seconds long and the evidence is complete. On a machine it is minutes long, requires physical setup, and produces evidence that is partial at best. Everything that feels hard downstream comes from that one fact. Plan around it and robotics becomes a slower but perfectly learnable craft. Ignore it and you will spend a year feeling incompetent while doing nothing wrong. The practical consequences are concrete: buy hardware you can trust before you write anything clever, record everything the machine sensed so a bad run can be examined afterwards, and expect calendar time rather than effort to be your constraint. People who make the switch successfully are not smarter. They stopped expecting the web's feedback loop.

What does robotics work actually consist of, in plain terms?

Robotics work is four jobs stacked on each other, and only one of them resembles web development. At the bottom sit drivers: code that talks to a motor controller, a camera, an encoder or a battery monitor, mostly about protocols and datasheets. Above that sits control: a loop that runs on a rhythm, comparing where the machine is with where it should be and issuing corrections, which has to hold that rhythm while everything else is busy. Above that sits perception and decision making: turning pixels and distances into a belief about the world and a plan for what to do next, which is where models increasingly live. Around all of it sits the plumbing: getting data from the program that produced it to the program that needs it, on one board or several, before that data is too old to use. That plumbing is what middleware means in this field, and the layer between a model and a motor is mostly this.

What are your actual options for the software under a robot?

You have seven realistic starting points, and the right one depends far more on your goal than on your ability. You can write plain Python on a single board, which is the fastest way to see something move. You can put everything on a microcontroller, which suits machines that are mostly motors and switches. You can buy a robot and drive it through the vendor's interface, which trades ownership for speed. You can learn a simulator first and buy hardware later. You can buy an educational platform that comes with lessons. Or you can adopt middleware and treat the robot as several cooperating programs: ROS 2 brings the largest body of existing robotics code anywhere and is what most job adverts name, while HORUS is an open-source real-time robotics middleware for Rust, Python and C++ in which the three languages share the same shared-memory ring buffers, so messages between processes on one machine are not serialised. Both assume you already know what your robot should do.

Read those rows as descriptions of goals rather than as a ranking.

What should you do if you have a full-time job and only evenings?

Buy a machine that already works, pick one behaviour, and finish it completely before starting anything else. Evening time is fragmented, and fragmentation punishes robotics more than it punishes web work, because a robotics session has a setup cost: plug in, power up, clear the desk, re-establish where things are. Two hours becomes ninety minutes of real work. This changes what you should attempt. Building a robot from parts spreads your evenings across mechanical problems, electrical problems and software problems, and the software is the only one you are fast at. A finished platform collapses three of those into one. Pick one behaviour that is genuinely complete, such as the machine finding an object, driving to it, stopping without hitting it and going home when the battery is low. That single task contains sensing, control, decision making and recovery, and it will teach you more than five half-built projects. The wider switch from web to robotics is mostly a sequencing problem rather than a talent one.

What hardware should you buy first?

Buy something that already moves, cannot hurt you, and has more than one person writing about it online. Those three filters eliminate most of the market and every one of them earns its place. Something that already moves means you skip the mechanical and electrical projects hiding inside a kit of parts, which are genuine engineering disciplines and not a warm-up. Cannot hurt you means small, slow, and weak enough that a bug is embarrassing rather than dangerous, because your code will be wrong for months and you want those months to be cheap. More than one person writing about it means that when the camera driver misbehaves at eleven at night, somebody has already posted the answer. Beyond that, prefer a machine whose parts you can replace, because you will break something. Avoid anything whose interesting features live behind a subscription or an app. A small wheeled robot with a camera teaches more per evening than an arm, because driving around gives you a hundred small failures a session instead of five.

How long before you have something that moves on its own?

Something moves on the first evening, something useful takes a season, and something you would leave running unattended takes considerably longer. Those three milestones are far apart and people conflate them constantly, which is the source of most disappointment. Driving motors from a script happens immediately and feels wonderful. A machine that performs a task reliably in your own room, with your own lighting, while you watch, is a few months of evenings. A machine that does the same thing when you are not there, recovers from its own mistakes, restarts cleanly after a power cut and does not need nudging is a different order of work again, and this is the step that separates a hobby project from a product. Web development has the same three stages, but they are compressed: a page renders in minutes, a feature ships in days, and production hardening takes weeks. Robotics stretches every one of those, mostly because each iteration includes a physical setup you cannot automate away.

Which of your web skills transfer, and which will hurt you?

Your instincts about interfaces, versioning and separating concerns transfer directly, and your instincts about retrying, scaling and statelessness will actively mislead you. Start with what helps. Defining a clean boundary between two components is the single most valuable habit in robotics, where a badly drawn boundary between thinking and moving costs months. Logging discipline transfers. Testing discipline transfers, with the caveat that you now test against a physical world that will not cooperate. Now the traps. Retrying is not free: a second attempt is a second collision, not another request. State is unavoidable, because the machine keeps existing between your function calls and holds a position whether or not any code is running. Throughput thinking is the wrong frame, since a robot cares about a message arriving before the next cycle needs it and not about how many messages arrived overall. And there is no rollback, because a knocked-over cup stays knocked over regardless of what you deploy next.

What do web developers try first, and why does it stop working?

Almost everyone writes one Python script that reads a sensor, decides, commands a motor and repeats, and that script stops working the first time the machine must do two things at once. Starting there is right, not naive: one file, no framework, changes in seconds. It breaks in a predictable sequence. Everything shares one loop, so the slowest step sets the pace for all the others, and the pace is uneven. Threads come next, which turns a slow machine into an unpredictable one. Then queues appear, then shared state, then somebody discovers the robot has been steering from a camera frame several moments old. The version that survives divides work by rhythm rather than by feature: a fast part that must never pause, a slow part allowed to think. That split is where robot software departs from web architecture entirely, since a web request has no obligation to finish on a schedule and a motor command does. Once split, the only question left is how the two halves share data on one machine.

What does a robotics failure look like next to a web failure?

A web failure announces itself and a robotics failure has to be noticed by a person. That is the whole comparison in one sentence, and it explains why the same engineer feels fast on one and slow on the other. Something breaks on the web: a status code changes, an exception surfaces, a graph moves, an alert fires, and a log line records what happened with a timestamp. You reproduce it from a request and fix it before lunch. Something breaks on a robot: the arm reaches slightly short. Nothing is thrown, nothing is logged, no metric moves, because a stale reading and a fresh reading are the same number in the same variable. The camera stopped a moment ago and the last frame is still there, looking exactly like a frame. You cannot reproduce it, because reproducing it means putting the object back in a place you did not measure, under lighting that has since changed. That is why what makes robotics hard is rarely the algorithms.

What do you give up by leaving web development for robotics?

You give up speed, and that loss is the one people feel every single day. A web change is written, seen and judged inside a minute, and that rhythm is the reason the work feels satisfying. Robotics replaces it with a cycle that includes clearing a desk and putting an object back. You give up rollback, since a machine that did something cannot undo it. You give up the deployment story, because your users are boards in cupboards and vans rather than a server you control. You give up a huge, well-mapped ecosystem where every question has an answer written for your exact library version, and you inherit a smaller field where the answer may be a mailing list post from years ago. You also give up salary breadth in the short term, since robotics roles are fewer and more concentrated by geography. What you get in exchange is a machine that does something in a room, which turns out to matter to people in a way that a page never quite does.

When is ROS 2 the better choice?

ROS 2 is the better choice if you want a robotics job, and it is the better choice whenever the robot must map a building and drive to a goal. Those are two separate arguments and both are decisive on their own. On employment, the vocabulary of the field is ROS 2: job adverts name it, teams interview around it, and being fluent in launch files and message types is a portable skill in a way that a personal architecture is not. On capability, navigation and mapping packages represent years of accumulated work that nobody should reproduce in their evenings, and the same is true of the drivers your sensors ship. HORUS is not the answer to either of those, and choosing it because it is simpler to set up would trade the wrong thing away. Add to that a large community, tutorials written for beginners, and a simulator integration that works out of the box. If you are unsure, learn ROS 2 first and form your own opinion afterwards.

Is robotics just embedded programming with extra maths?

No, and here is why: embedded work is about making one program behave correctly on a small computer, while robotics is about making several programs agree about a world that keeps changing. The embedded part is genuinely present and genuinely valuable. Writing firmware for a motor controller is embedded work, and doing it well requires exactly the discipline that field teaches. But a robot spends most of its difficulty somewhere else. It has to decide whether a sensor reading still describes reality. It has to hold a belief about where it is that is definitely a little wrong. It has to act now with incomplete information, and then live with the consequences of having acted. None of that appears in a thermostat or a fitness tracker, no matter how constrained the processor is. The maths point is also overstated: libraries carry the formulas, and what actually takes time is developing a feel for coordinate frames and for how error accumulates when one estimate feeds another.

Will coding assistants make robotics as easy as web development?

Partly, but not the way you think. Assistants are already good at the parts of robotics that look like other software: reading a datasheet into a driver, writing message definitions, scaffolding a node, explaining an unfamiliar framework's conventions. That help is real and it removes a meaningful share of the beginner's grind, particularly the grind that comes from a smaller field with thinner documentation. What assistants cannot do is stand in your room. They cannot tell you the belt is slipping, the camera is auto-adjusting its exposure, the table is reflective, or the reason the robot behaves differently after lunch is that the sun moved. They cannot close the feedback loop, and the feedback loop is the actual difficulty. There is a specific trap here too: an assistant will confidently produce a plausible architecture with no idea that your loop must hold a rhythm, and a beginner cannot yet tell the difference. Use the help for the typing and keep the judgment.

How do you tell whether robotics is actually the thing you want?

Spend one weekend making a cheap machine do one small physical task, and pay attention to how you feel when it fails silently for the fourth time. That reaction is the whole test, and no amount of reading substitutes for it. Some people find the silence maddening: no trace, no line number, nothing to grep, just a machine doing something slightly wrong while they watch. Those people are not weak engineers, they are people who get their energy from a tight feedback loop, and web development gives them that honestly. Other people find exactly the same moment fascinating, because the only way forward is to reason about physical causes and design an experiment, and that feels like actual investigation rather than lookup. If you are the second kind, the field will keep you interested for decades. There is also a middle answer worth taking seriously: robotics teams need tooling, dashboards, teleoperation interfaces and fleet software, and that work is genuinely web development pointed at machines.

Decide by situation rather than by ambition:

• If you want a robotics job -> learn ROS 2 on a small mobile robot, because the vocabulary is what teams interview on.
• If you have evenings only and a full-time job -> a finished platform and one complete behaviour, because setup cost eats fragmented time.
• If you want to know whether you like it at all -> one cheap wheeled machine for a weekend, because the silent failure is the real test.
• If you already know you want one board with Python thinking beside a compiled loop -> a shared-memory middleware, because moving frames between them is where the motion goes.
• If you want to stay in web work but nearer the machines -> robot tooling and fleet interfaces, because that skill is scarce and immediately useful.

When two options stay close, weigh them on the five axes of the HORUS Fit Framework: ecosystem size, setup effort, team size fit, deployment target, and licence. Take the one that loses on the fewest, and note that every axis asks about your situation rather than about the software. If your path leads to a single board with a model in Python and a control loop that must not wait for it, star HORUS on GitHub so it is in your list when you start building.