Fair enough! Good point.
I'd be interested in what you've experienced as the hardest parts. I'm not sure I'm totally certain of what the hardest parts are, and I think everyone has different struggles with different contexts, for sure.
Here's a GREAT part of one of the responses:
When writing software, one might name hundreds to thousands of new things per year.
Entirely agree with naming things being the hardest thing in programming. Yeah documentation is ideal, but most of the time your variable names become your documentation, whether that be because you're running out of time on a project, or the piece of code has been rewritten without updating the documentation. Actually, having stale documentation is worse than having no documentation. But that's a separate topic.
Let's exclude the majority of PhD students that program with variable names strictly being single english letters or greek letters (alpha, beta, etc), since that code becomes impossible to read and debug after about a month. Maybe it's just my Stanford friend and his phD department that does that... but I'm assuming that's common practice. So yeah, let's exclude that section of programmers, because naming things as single letters (unless it's i,j,k) is insane.
Now, let's imagine you're working in a company with hundreds or thousands of developers who aren't clones of each other, so the codebase has conflicting conventions which cause a lot of confusion. Should you name a "person model" file PersonModel or just Person? Should you make all your ios View files have the word View in them? Do you call your initializer function "init", "setup", "configure", something else? Do you call things that touch the database fetchX, fetchY, as oppose to getX, getY? Do people know that fetch is an expensive db call and get isn't? And that one time someone called the function "getItem", did they mean to call it fetch? Or should it actually not touch the database, or is it backed by a cache, and is only slow the first time. So most of the time it's actually a get, so don't worry about it? So should you spend the rest of the day investigating this potential issue, or is the weird database call coming from somewhere else and the guy that wrote that call knew what he was doing? How far does this naming rabbit hole go?
In my experience, hard mathematical questions are rare in industry level programming. You have your search, sort functions as libraries. You have your lists and dictionaries. And anything weird you hope you can find as a library and fuse it into your code somehow, because if it's anything that complex it's probably not worth spending the engineering effort (we've got other lower lever fruit to implement first, and hopefully by that time, someone will have written a library for that complex math thing). Good luck reading the library and trying to understand it though. Unless it's written by some big company, the api calls probably make no sense, and you have no idea if it will have any adverse side effects.
And now you have to figure out how to name your things, such that the next guy (or you in a few months) will know what you were thinking. Also, since 6 months ago when you named the function getAllFiles, the product has changed, where getAllFiles actually means get all pdf files. Because at the time you though "all" meant all the files the database has. And the only files at the time were pdf's. But now there are pdf's, png's, jpg's, etc and there is "getAllFiles" and "getAllFiles2". Whoever wrote getAllFiles2 was probably afraid that if he were to change the original function, it would break everything else in the code. So adding another function seemed fine at the time, after all it does actually get all the files, so what else would it be called?
Hopefully you get the idea by now.