Live data from Hacker News

You don't need to work on hard problems (2020)

benkuhn.net

41–50 of 115 posts

Re: You don't need to work on hard problems (2020)

#41
post #2

Absolutely true. I do believe most engineers experience this maturing when they get access to leverage in the workplace, such as going from being an individual contributor to a leader or mentor. Try sales for a while, and you will realise that no customer has a neatly defined problem for you to solve. They have real complex problems, which you may be able to shoehorn your general solution into. But even then, there i…

As time goes on I can only agree with you. Also I find it kinda funny how there's a whole boutique industry propped up by silver-tongued people convincing business customers with poorly defined problems what those problems "ACTUALLY ARE" and oh boy it just so happens that they have a solution for it. In a way some people are stuck with a solution in search of a problem, I suppose.

But sometimes the customer doesn't want the alternative solution for various reasons, some ridiculous, a few valid.

Anyway my 2 cents and YMMV, it's not all doom and gloom.

Re: You don't need to work on hard problems (2020)

#42

I'll try to apply this as I've been battling the problem of my job being too easy and never applying what I learnt in school. There were so many interesting problems and theories in school that you never see as a regular developer, often I think that I have a job that any person could do with a few months of training (does this make me a narcissist? Is the complain here just that my job is unglamorous or is wasting y…

> often I think that I have a job that any person could do with a few months of training

I occasionally think that too, but then I remember trying to introduce programming to people who couldn't even figure out how to save a text file.

Re: You don't need to work on hard problems (2020)

#43
post #28
post #26

Earlier quoted context omitted.

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".

> 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.

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.

Re: You don't need to work on hard problems (2020)

#44
post #22

It's true. Since starting in health tech, the areas of which are sometimes technically interesting, but not in a cutting edge sort of way, I feel a lot more motivated. Three women I know personally have used (and totally loved) the app we made for gestational diabetes, and half the NHS uses it to manage this type of patient, so the total number of people helped just keeps going up. I think of it as something to put o…

Half my career has been in HealthTech. I've found the problem to be interesting just because of the constraints. I've never had to use math and care about big O notation so much as when I needed something to run on these potato computers they had. Beyond the technical constraints, there's just the domain itself. I've focused my efforts in this domain of just digitizing paper processes. There's so much to know from a…

Yup - we digitised some existing, hilariously inefficient paper-based systems. Incredible what a difference it makes.

I think at least for the NHS, making procurement more effficient would actually be a pretty impactful idea. It cost us more than a year's licence fee just to onboard each trust, as they're all different.

Re: You don't need to work on hard problems (2020)

#45
post #37
post #26

Earlier quoted context omitted.

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".

Counterexample: "Find all prime factors of N".

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".

Re: You don't need to work on hard problems (2020)

#46

When you're young (think HS and college aged), difficulty seems indeed to be the "ultimate" prestige. If you're a musician, that means playing that most technically advanced piece flawlessly. If you're an athlete, that means raw ability like speed, strength, etc. If you're a mathematician, that means having a go at some unsolved/open problem. If you're in the military, that means joining the special forces or becomin…

>One thing I've noticed with young and ambitious employees, is that many need constant feedback. If they don't get any direct feedback immediately, they feel left out in the cold, and don't know how to react.

It's an increasingly cold world and some young people may legit get zero feedback outside of work. Ghosted on dating scene, ghosted by the remaining friends post graduation, and now feeling ignored at work.

Add on no third place to go to and how work is increasingly ceasing to be a second place with wfh and you just have a loneliness sandwich. They spend 18-20 years having people their age all around them and then it poofs up in smoke. I'm sure they want some kind of feedback in the one remaining place that is now taking up more and more of their time.

Re: You don't need to work on hard problems (2020)

#47
post #28
post #26

Earlier quoted context omitted.

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".

> 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.

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.

Re: You don't need to work on hard problems (2020)

#48

It's true. Since starting in health tech, the areas of which are sometimes technically interesting, but not in a cutting edge sort of way, I feel a lot more motivated. Three women I know personally have used (and totally loved) the app we made for gestational diabetes, and half the NHS uses it to manage this type of patient, so the total number of people helped just keeps going up. I think of it as something to put o…

I would love to hear more about your work if you’re allowed to share it?

My wife was considered at risk for gestational diabetes but I’m not sure if she was directed towards an app.

What do you think about Badger Notes?

Re: You don't need to work on hard problems (2020)

#49

> In school, if you pick an easy problem instead of a hard one, you lose leverage because your extra problem-solving ability goes to waste. But in real life, you can redirect it to prioritizing which problems to solve, or working more quickly, or building a machine that solves the problems for you. I'm surprised that for once this kind of perspective is on HN. The world is absolutely full of low hanging fruit problem…

>Nobody wants naive solutions, overabstraction, or premature optimization. The end user can definitely tell the difference even if they don't know how to say it.

Not necessarily. Sometimes the naive or not optimal works just fine, especially with such powerful hardware. They don't care if a web app is made in electron if it works and is snappy (most users aren't opening up their task manager to measure cpu load).

Re: You don't need to work on hard problems (2020)

#50

I'll try to apply this as I've been battling the problem of my job being too easy and never applying what I learnt in school. There were so many interesting problems and theories in school that you never see as a regular developer, often I think that I have a job that any person could do with a few months of training (does this make me a narcissist? Is the complain here just that my job is unglamorous or is wasting y…

I also sometimes think most people could train to be an entry-level dev over a summer. Yet that seems demonstrably wrong. I wonder if it’s similar to how a musician can’t comprehend how I can barely hear a beat.

Maybe not a few months, but students spend years and I imagine 70%+ of them can train just fine to any entry or mid level work. But companies are inherently risk averse and no one really wants to risk hitting that 30% snag
Post reply on HN