4 ms·

I like working on complex problems. But I like making simple solutions. And making those is often hard. So you might say I like hard problems. > I could try t

I like working on complex problems. But I like making simple solutions. And making those is often hard. So you might say I like hard problems. > 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!

coldtea 3y ago
If X is an easy problem, solving it "as quickly as possible" would be easy too. 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".
- dacryn 3y ago
  > If X is an easy problem, solving it "as quickly as possible" would be easy too. 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.
  - deleted 3y ago
    [deleted]
  - acer4666 3y ago
    "easy, just time consuming" ... Also known as hard
    - throwaway14356 3y ago
      If the easy task involves 7 things all straight forwards. You get 6 opportunities to waste time in between. Each sub task completed (to me at least) seems like the perfect time to look out the window, check email, have a snack etc but you wouldn't [say] half way typing a sentence. You could but won't.
  - coldtea 3y ago
    Then you didn't have an easy problem to begin with, you had a hard one ("summing too many numbers fast enough") [1]. 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.
    - lowkey_ 3y ago
      > Then you didn't have an easy problem to begin with, you had a hard one ("summing too many numbers fast enough") [1]. 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
  - johnnyanmac 3y ago
    Well, not easy but it's not exactly a crazy proof to derive for anyone who spends time on formal proofs. This was probably derived centuries before Taylor solved an entire series of problems in one fell stroke.
- alkonaut 3y ago
  Yes it becomes a matter of interepretation. But to make an analogy, I enjoy my work through the same mechanisms as I enjoy solving sudokus. It's not that I need to actually keep or use the result. The reward comes from the mental challenge. 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).
  - throwaway14356 3y ago
    If you do automate it you will develop a routine for it. 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.
- n4r9 3y ago
  Counterexample: "Find all prime factors of N".
  - coldtea 3y ago
    I think you too take "solve an easy problem as quickly as possible" as meaning finding the fastest performing solution to the problem. 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".
    - n4r9 3y ago
      You're right, I misunderstood. Thanks for the gentle clarification.
gspencley 3y ago
I've always been good at solving problems, if I weren't then I'd be a pretty bad software engineer. And I guess I don't dislike solving problems, if I did then same deal. 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.

coldtea 3y ago

If X is an easy problem, solving it "as quickly as possible" would be easy too. 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".

dacryn 3y ago
> If X is an easy problem, solving it "as quickly as possible" would be easy too. 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.
- deleted 3y ago
  [deleted]
- acer4666 3y ago
  "easy, just time consuming" ... Also known as hard
  - throwaway14356 3y ago
    If the easy task involves 7 things all straight forwards. You get 6 opportunities to waste time in between. Each sub task completed (to me at least) seems like the perfect time to look out the window, check email, have a snack etc but you wouldn't [say] half way typing a sentence. You could but won't.
- coldtea 3y ago
  Then you didn't have an easy problem to begin with, you had a hard one ("summing too many numbers fast enough") [1]. 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.
  - lowkey_ 3y ago
    > Then you didn't have an easy problem to begin with, you had a hard one ("summing too many numbers fast enough") [1]. 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
- johnnyanmac 3y ago
  Well, not easy but it's not exactly a crazy proof to derive for anyone who spends time on formal proofs. This was probably derived centuries before Taylor solved an entire series of problems in one fell stroke.
alkonaut 3y ago
Yes it becomes a matter of interepretation. But to make an analogy, I enjoy my work through the same mechanisms as I enjoy solving sudokus. It's not that I need to actually keep or use the result. The reward comes from the mental challenge. 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).
- throwaway14356 3y ago
  If you do automate it you will develop a routine for it. 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.
n4r9 3y ago
Counterexample: "Find all prime factors of N".
- coldtea 3y ago
  I think you too take "solve an easy problem as quickly as possible" as meaning finding the fastest performing solution to the problem. 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".
  - n4r9 3y ago
    You're right, I misunderstood. Thanks for the gentle clarification.

gspencley 3y ago

I've always been good at solving problems, if I weren't then I'd be a pretty bad software engineer. And I guess I don't dislike solving problems, if I did then same deal. 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.