> I could try to solve an easy problem as quickly as possible
The "solve X as quickly as possible" is now the problem. Not just solve X. I And that sounds like a hard (therefore interesting) problem!
But I don't live for solving problems. Let alone "hard" problems.
I'm a "maker" (though I kind of hate that word). I like building things. If I'm not developing software then I'm making other stuff. Woodworking, theatre, props, clothing. Software applications are another thing to make and produce. Making new things always comes with a healthy dose of problem solving, but I don't get out of bed in the morning thinking "boy I can't wait to solve problems today .. I hope someone hits me across the face with a real stumper that's going to make my work a living hell until I can figure it out!"
For me it's more about whether or not I enjoy what I'm building, and would use the end product or at least can see the value it provides to others. Not so much about how many "challenges" there are in building it.
The combination wont magically become a "hard problem", except if we take "as quickly as possible" to mean achieving some optimal solving time, as opposed to just casually meaning "without adding stupid bloat and by doing a KISS solution".
Hard disagree with this one.
Summing all numbers from 1 to 100 is easy, summing 1 to a million is also easy, just time consuming. 1+2+3+4....
Coming up with (n*(1+n))/2 is not.
Also I think that the parent didn't mean "as quickly as possible" in the execution speed or algorithm sense, he meant in the clock time sense: getting it solved quickly and moving on.
So in their (and mine) formulation, the problem is easy by definition. It's not an "easy problem turned had because it has to be optimized for speed".
I thought that your objection was that finding a simple solution would be hard itself (which wouldn't be the case if the problem is easy as in "easy to solve").
[1] not that coming with a basic series summation formula is "hard" (except you're Gauss, and you're the first mathematician doing it, the rest just need to know how to search for it), but I'll accept it as hard for the sake of argument.
That’s exactly what the initial comment said:
> The "solve X as quickly as possible" is now the problem. Not just solve X. I And that sounds like a hard (therefore interesting) problem!
There were two separate points: 1) Finding a simple solution to a problem can be hard 2) Solving an ‘easy’ problem quickly enough can be hard
Too easy or too difficult sudokus arne't rewarding. The easy ones are basically just writing digits without thinking for a while (i.e. boilerplate work). The difficult ones are often frustrating and too much work for little progress. The sweetspot is something that offers some challenge but not so much that it's frustrating.
A simple solution to a simple problem will always be just boilerplate. It will be work that can often effectively be automated (But you can't try to automate it because then you have traded your simple problem for a more difficult problem of automation!). To me it sounds extremely boring and unrewarding.
I didn't quite understand the gist of this article. What is the left out bit of the title? "You don't need to work on hard problems to...."?
I immediately thought "be happy". I didn't think "be successful" (or similar).
I sometimes roll calculators with a gui and useless animations for things I don't need a calculator for. If i get to use it 1 time a year later it feels much better than it sensibly should. Now that I think about it they could generate code with very little extra effort and even smaller odds to be useful. The fun is there tho.
I don't think that's what the author means. Thought TFA is a little vague about this: "Instead, I learned it was possible—and fun—to optimize on other dimensions, or play a different game. Rather than competing for an A+ on a hard problem, I could try to solve an easy problem as quickly as possible (like Wave’s accounting), or find the easiest problem whose solution would be useful (like identifying Kenyan names), or hire a team to solve easy problems faster than I ever could myself".
To me "solve an easy problem as quickly as possible" doesn't imply "fast" as in program performance, but as delivery time. And this is further corroborated by line "hire a team to solve easy problems faster than I ever could myself".