Indeed, counting is difficult. It's one of the hardest things I do at work. Hell, you could even say that professional computer programming consists primarily of two seemingly simple activities repeated over and over:
1. Counting things: data points, log records, clicks, views, users, tweets, transactions, money, pixels, padding, percentage, significant digits, bytes, zeros — the possibilities are infinite (har har). But really, some of the nastiest bugs I've seen in practice are related to counting even the simplest of things. Some of the most complex systems I've used are glorified counting engines. Thus, to be a good programmer you must first learn to be good at counting. This is probably why they forced us to take discrete math and computability. I didn't appreciate that at the time.
2. Copying data around: user input to a POST, HTTP to request parameters, parameters to an SQL query, query to RPCs, RPCs to b-trees, b-trees to blocks, blocks to bits, and back again. At Google I call this "pushing protos" because ultimately a project isn't done until you have copied the contents of one protocol buffer into another with minor changes of the format (perhaps you'd even call this "Dean's Law"). Elsewhere this is all the conversions you have to make through JSON and POST parameter names just to get your JS frontend to talk to your database through a server.
Now that I think about it, I don't think these skills are limited to programming. As a musician, for example, you must count time and pitch, you must repeat themes in slight variation. Perhaps this is just the nature of information.