Live data from Hacker News

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

benkuhn.net

51–60 of 115 posts

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

#51

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…

Is it true that their friends ghost after graduation? I thought they would have more contact through Snapchat etc. Do you have personal acquaintances who had that happen.

Im older, 30s but I felt that friend contact really fell off after moving away from SF former room mates and startup friends.

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

#52

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?

Hi - of course. I hope your wife is doing well.

I'll share what I can. The app[0] we built is now owned by Huma, and is active in I think about half of all NHS trusts. You have to be attached to one of those trusts to gain access to it. I'm aware of Badger, but I never saw it in use, so I can't say much about it. I think they weren't quite a direct competitor as we were purely targeting gestational diabetes, and they are more of a general-purpose system. But perhaps they now have enough specialisation in gestational diabetes to be a decent tool in their own right.

[0] https://apps.apple.com/gb/app/gdm-health/id1421840751 - same name for Android Play Store

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

#53

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.

I train software engineers with the apprentice model, and it takes about 500 hours to train a person to be able to get hired as an entry level full stack engineer. Maybe not in today's market where even talented engineers are struggling. But over the last sixteen years I've trained sixteen engineers who all still work in the industry.

I use TDD, a list of projects that gradually increase in difficulty, multiple languages, and solo practice on tools like CodeWars. After they are comfortable with basics I'll have them build a personal project of their own design. Between CodeWars and TDD they've now gotten used to getting dopamine hits from programming. Add in intrinsic motivation on a personal project with a full stack website and they are glued to the editor. Time flies as they rapidly achieve a decent level of skill at reading and writing code. By the time they are wrapping up that personal project, as long as they've kept up with algorithm practice they're ready to interview.

Some have taken longer, usually about a third take a break and circle back around later. Some do take more like 1000 hours to feel confident. Sometimes I end up hiring them myself for contract work to help them build a resume and help me with a project. But on average it's only about 500 hours to teach the fundamentals of unit testing, algorithms, data structures, functional programming, SQL, Typescript, React, and a backend language like Python or C#. They'll not be a master of any of them, but know enough to build a website with persistence and use tools like Google and ChatGPT to get answers when stuck.

The "simple trick" is just making them write absolute tons of code, every day, for months. Then making them read other's code to learn new tricks. It's not easy, I'll work them like a rented mule but they'll come out way over qualified for an entry level position. By the time they're interviewing most will have written 10-20k lines of logic, often grinding a problem a half dozen ways to really see the pros and cons of various solutions.

I think most people greatly overestimate how much code the average CS graduate actually writes for their degree. I've interviewed hundreds of new grads who've written maybe a few hundred lines of code total. Sure they know the theory of computer science, but aren't prepared at all to be software engineers.

I'm not saying the bootcamp model is better, generally those students only know basics of copy paste. This is entirely the fault of the bootcamp instructors who are just trying to churn out graduates.

There just isn't much effort in actually teaching software engineering. Bootcamps have students do some basics and stop way before they're ready. Universities just have them study theory. Rarely is anyone teaching how to read and write code so fluently the students are dreaming in code. But this is extremely effective.

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

#54
I think it depends what we define as hard problems because their are lots of problems in the world that need solving but the scale of which your solving it at matters. So if their problems that get solved with your product/service helps 1 billion people as a hypothetical example over 10-15 years then that’s a hard problem worth solving. But if it’s say for 10 people it may not be worth solving. So the scale to which your solving it for matters.

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

#55

Interesting to hear about your perspective. I’ve always been on the other side of the coin, programming has always been a means to and end, not an end itself.

> I’ve always been on the other side of the coin, programming has always been a means to and end, not an end itself.

This point of view is actually validating to hear. Now, on my own time, I do enjoy programming and even dabbling in things like gamedev, but at the same time I don't seek out difficult problems in particular - it's more about the end result.

When it comes to professional work, I have an even more conservative perspective: to just pick well known tools to solve problems in ways that have been proven to work over the years, ideally without blazing new trails and working on stuff nobody has ever done before.

In regards to technologies, that also means lots of Debian or Ubuntu, relational databases and boring back end languages like .NET or Java, with whatever is stable enough for the front end, but then again, the people shopping or submitting forms or whatever won't necessarily care whether you use NoSQL, serverless functions, or something else entirely.

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

#56

Earlier quoted context omitted.

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

Is it true that their friends ghost after graduation? I thought they would have more contact through Snapchat etc. Do you have personal acquaintances who had that happen. Im older, 30s but I felt that friend contact really fell off after moving away from SF former room mates and startup friends.

Everyone I knew at uni stopped talking after a while.

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

#57

I've always thought that people underestimate the mental acuity needed to find simple truths within complex systems and to use them to achieve useful results. Especially in academia, many professors, who are wedded to particular models, go so far as to dismiss simplicity without sufficient consideration. It was not always this way. Among the older philosophers, you can observe a strong affinity for simplicity. Figure…

Simplicity does surely survives better.

But you clearly do have a biased picture on your head. That claim that current people value it less than ancient people is not only baseless, but quickly dismissable just by reading those genius you quote.

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

#58
post #21

Earlier quoted context omitted.

How do you not cringe at a comment that so matter-of-factly states that our modern researchers all have this assumed negative propensity that somehow the wisend researchers, thinkers, and leaders of the past did not have. You must be speaking of personal experience, because otherwise your comment is completely ridiculous. But if you are, you certainly have no personal experience with historical figures. So how can yo…

Top modern researchers/practitioners do seem to value simplicity heavily, but can't say the same for most. The propensity for misuse of abstraction/models/data/theories is pretty high from what I've seen. That's my view. You are free to disagree! PS: It is always better to rely on older sources for illustrations, because they have lived their life fully and you have documentation of their lives + effects of their eff…

Largely, it seems top modern researchers are able to free themselves from many of the perverse incentives of the academic game. You might be surprised how many who have not reached such a level also value simplicity, but simply must play the game. It's very common to see a clear and simple (in the good sense) paper grow increasingly complex in response to reviewers demands, going through a sequence of one or more rejections before finally getting accepted.

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

#59
post #43
post #28

Earlier quoted context omitted.

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

> 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

Post reply on HN