Correct isn't enough, on time matters too
In everyday programming, correctness usually means one thing: does the program produce the right answer? Real-time programming adds a second, equally strict requirement: does it produce that answer within a guaranteed time budget? A motor control loop that computes the perfect next command but delivers it ten milliseconds late hasn't done its job, it has effectively failed, because the physical world didn't wait for it. The wheel, arm, or rotor kept moving on the old command in the meantime.
This is a genuinely different mindset from most software engineering, where being 'usually fast' or 'fast on average' is considered good enough. A web page that occasionally takes an extra second to load is a minor annoyance. A control loop that occasionally takes an extra few milliseconds to run can mean a robot arm overshoots a position, a balancing robot loses stability, or a safety interlock reacts too late. Real-time correctness is about the worst case, not the average case.