I don’y interact with other people very well.
Also because building takes forever when you screw something on the wrong way.
I personally find notebooking to be pretty fun.
My hand eye coordination is to say the least, lacking. Building is process of measuring 4 times, and still managing to attach the screws in the wrong spots. And my driver skills have “improved” over the years.
Kinda surprised how little people find trouble with teleop code. I mean ya, if you just direct map things its easy. But for more advanced teleop code you should be merging your auto code with the controller inputs. Things like auto aim and shooting, auto ball indexing, preset lift heights, auto stacking, auto cube detection and pickup, etc. all while the field remains inconsistent due to it being midmatch unlike the consistent field setup in auto. I find it a bit more difficult than auto.
I understand why you find advanced driver control to be hard to make, but driver control should always be easier to program than an autonomous program. In addition to this once you understand complex coding techniques and the process to make driving macros or advanced autonomous routines, both become significantly easier to do.
But even after you know the techniques to make either autonomous or driver control, driver control should still be easier to make in my opinion. The tasks used for driver control are repeated, short, and are able to be constantly observed and kept in check by a knowledgeable human.
I have never heard a team say that their macros were inconsistent on different fields, only autonomous programs are significantly affected by this.
Anyway, that is probably why most find autonomous significantly harder to do than driver control.
Honestly coding autonomous is really annoying, because of how precise most things have to be. But another thing that really grinds my gears is when the team blames an obvious structural/mechanical issue on the coder(s).