I'll add that rework is an underestimated part of 10x, not that I'm 10x. The best engineers I've worked with create solutions that can be forgotten until the business changes, often 3-5 years later.
One variety of 10x pretender I've come across will slam out new systems that then require a lot of care and feeding. Flushing caches, re-syncing data, JVM or autoscaling tuning, regular addition of new special cases, version updates for yet another ecosystem... the list goes on.
Another facet of your "making it look easy" observation: management perceives the latter engineer as doing a lot more than the former, sadly.
I wrote a system in a year and a half, that solved a big need at my company for many hundreds of people. Another group -- the group that SHOULD have written it -- got mad that I had done it, and started their own version. It took 10 people 3 years to create their system, and it was terrible, slow, and didn't work the way the business needed it to, but they didn't care. It was so bad, they brought Microsoft in to try to speed it up, and even they couldn't do anything with it. Management changed, and my system was taken away from me, and given to the other group. They made a couple minor patches right after the handover, but, basically, it's run without handholding for about 6 years now, while they try to force people to use their system.
Nice to hear this happens elsewhere, a colleague and I wrote an alternative interface for some horrible internal web tool. I don't really know why the webtool was so slow, but it took _minutes_ to load data from the database and display it in a table. The table wasn't a real table, it was some fake canvas thing that lagged when you interacted with it, it was basically unusable.
Luckily the tool was writing directly to the database from the client, so we could get the database credentials and query it directly. Things that took minutes now took a few seconds. Plus, the data was append only, so we just cached everything locally and fetched new data only. Super trivial and basic stuff that made a huge difference to performance.
They found out, changed the database credentials and killed our tool. They did eventually make their version better, but it still kinda sucked.
I have a similar war story, from a university. The portal where students see their grades had several full-time consultants working non-stop for a few months and wasn't gonna be ready on time. The interface was confusing, and different campi were different business entities legally, so students required multiple login sessions if they took courses on different buildings (they had to pick a campus at the login page).
Teachers were about to be instructed to give grades to students via e-mail by the Dean.
I then saw the one database table on the teacher's portal DB that contained all the grades and knocked off a new screen in 1-2 hours in an existing system I maintained. A single remote database query, an HTML table, good looking layout. It was easier to use, more secure (SSO and 2FA), more performant, better looking and better-isolated (no DB write access needed).
The biggest hurdle was political, of course. I was probably too slow, to do it, if anything. But I was definitely 300x faster than the consultants.
I call them an "almost 10x'er" ... they pump out 10x code but it is a horrible buggy mess. I got pulled in to help one team that was months late on a release and found that their entire team was swamped with whack-a-mole bug fixing code that the "superstar" had written while the "superstar" was banging out new features for the next release. None of the features they wrote actually worked but they got the credit for developing those features and the rest of team was being blamed for not being able to ship the features.
So I get why people can be jaded by the whole 10x thing.
One variety of 10x pretender I've come across will slam out new systems that then require a lot of care and feeding. Flushing caches, re-syncing data, JVM or autoscaling tuning, regular addition of new special cases, version updates for yet another ecosystem... the list goes on.
Another facet of your "making it look easy" observation: management perceives the latter engineer as doing a lot more than the former, sadly.