A common comment I hear when I tell people I'm a coder is something along the lines of 'Oh I wish I could do that, but I'm bad at math'. I'm faced with skepticism when I tell people that the math is easy and that most projects require only a basic level of algebra. I have a joke that if you sorted your halloween candy as a child you would probably make for a fair programmer. There definitely are hard and non-obvious parts of coding for me and I thought I'd highlight those.
Programming at its core is a creative exercise. In our creation we have to constantly name everything, from small numbers being stored to brand new processes and products. Naming things is hard and it is difficult skill to level up. Anyone who has experimented with Web3 (wallets, transactions, clients), Kubernetes (pods, clusters, nodes, containers), or Amazon Web Service (EC2, ECS, RDS, S3) has surely been frustrated working through poorly named products. Names are sticky and difficult to change. Naming and words matter and shape our thoughts and the difference of success or failure can sometimes be simply attributed to its name. Naming is a skill and I often find myself picking the wrong name and feeling lasting regret. Some names are so good they've become synonymous into our understanding. I think some great names are Google, iPod, or even Browser. Bluetooth is an example to me of a terrible name and I think that is partially why I attribute Bluetooth to being a flaky suboptimal product.
Programming tools are constantly evolving. At my last shop we used Typescript on the frontend and Kotlin on the backend. Neither of these languages were in serious circulation 10 years ago, so to contribute at all to the codebase required learning a whole new skill set for most engineers. Learning does not occur passively so it is the responsibility of an engineer to be active in their learning and be comfortable with never being an expert. This is humbling feeling and requires a constant effort. I spend at least one weekend a month up-leveling my skills away from work and bringing those new skills to my employer to ensure I'm always delivering the most value. It is a sacrifice to work on your profession outside of working hours and most engineers have to embrace that. It is not a coincidence that many engineers code as their biggest hobby as well.
As I've discussed previously most engineers don't actually pick what they're working on. Convention is that engineers are assigned tasks from a product manager. It is not uncommon for engineers and product managers to have conflicting view points on what they should be building. It can be frustrating to be assigned to build something that does not interest you and you don't feel will be valued. Ultimately, the product managers have final say, their performance is based on the success of the product. I think this is probably why many engineers end up starting their own company so they can have control of the product as well.
This is just my personal experience. We all different strengths, weaknesses, and demons, but these are the hardest parts for me. I have never regretted becoming a software engineer and the hard parts only make me appreciate the rest of the experience that much more.