First off, let's define "hard". You could mean
a) absolutely hard: it takes lots of effort to make this work at all
b) hard to do well: it takes lots of effort to do this well even though I can do this somewhat acceptably with minimal effort
c) time consuming: this takes a lot of f-ing time, and it's unclear that the effort justifies the benefit
a) seems like the most appropriate definition, but judging by the list they seem to mean either b or c.
9. Designing a solution :
b. I can make you some working software based on your off-the-cuff requirements pretty easily. Anticipating what you really meant, what you will ask for next, and writing code that can be easily leveraged to do those things would be 'a'.
8. Writing tests
c. For small projects, automated testing way more time than it's worth. For large projects writing tests is the only way to make it work at all. Of course, all those medium sized projects and those projects that start small but may become large are a challenge. And weather or not the software lends itself and the programming team knows how to use a testing suites make a difference.
7. Writing documentation
c. No one /ever/ reads documentation because we all learn the hard way that it's perpetually out of date. The UI and API /are/ the documentation. If, by "writing documentation" you mean "designing a good UI/API" that makes it obvious to the user what's going on, then this becomes 'a'.
6. Implementing functionality you disagree with
WTF - If you're getting paid, do what you're told. If not, tell 'em to do it themselves. This is only "hard" in any sense if you're a pedantic a-hole. Oh, wait. This is /., so I guess that's all of us.
5. Working with someone else’s code
b - But if they instead had "writing code that isn't a PITA for others to work with", then it's an 'a'.
4. Dealing with other people
That's only because: http://www.dilbert.com/2013-10-10/
But I guess if we spent any time developing our social skills, we wouldn't have had time to learn how to program.
3. Estimating time to complete tasks
Okay, this one really is 'a'. On the other hand, you just shouldn't do this. Instead, you need to get good at getting customers/users on board with iterative development where they wait/pay a bit and get some incremental functionality as you work towards some end goal that neither of you can really predict up front.
2. Explaining what I do (or don’t do)
1. Naming things
See #5. Naming things is easy. And my names make perfect sense to me.
Also, queue the penis jokes based on my use of the word "hard" in the subject.