[lawn]

I think there's a connection here with the mythic 10x developer as well.

Some developers are just so much slower at the Difficult Problems, so that the developers that are good at them seem like 10x (or 100x or infinitely) more productive than their peers.

But I don't think they have the same leverage on the Hard Work problems.

[marcosdumay]

Every time developers are extremely productive, it's because they converted hard work into difficult problems. It's not only that they solve those problems faster, but also that most people won't even try to convert them.

It certainly does not work for every kind of work. But when that doesn't work, you don't have extremely productive developers.

[TheOtherHobbes]

There are problems that can be solved with a clever, elegant, minimal algorithm.

And there are problems that are tedious because there's a huge amount of not very well organised data, and you have to go through it case by case.

Especially true if you're trying to fully internationalise something.

Examples: verifying international addresses, dealing with sales taxes in various countries and jurisdictions, dealing with import/export codes. Etc.

There's nothing conceptually hard about these problems. But a complete solution is just a very long list of nested ifs, and there's nothing much anyone can do about that. (Except buy/hire an existing solution - if someone else has done the work.)

[klysm]

The tough thing about the problems that are just a long list of ifs is the shape of the data. It’s usually not clear till you’re very deep in the problem what the “right” data structures are. That’s problematic because those are the difficult things to change. I think it’s a very valuable skill to be able to sniff those out early.