Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Aren't a lot of jobs about solving problems?

A therapist solves psychological problems.

A lawyer solves problems between people and organizational entities.

A surgeon solves medical problems.

The reason I'm asking this question is because a few groups proudly say that they are problem solvers. The most notable groups that I've seen are programmers and the consulting industry.

But who isn't solving problems? Why this focus on it?

Sorry for derailing the thread a bit, but my friend group doesn't have the answer.



I think it's a reaction to programmers' particular tendency to focus on things that aren't best serving the goal of solving the problem at hand. Programmers often have a "pet" focus that relates to what they enjoy: performance optimizations, writing "clean" code, using some particular pattern or technology they like or want to try out, etc. None of those things are bad as long as they don't take precedent over solving the problem at hand.


> Programmers often have a "pet" focus that relates to what they enjoy: performance optimizations, writing "clean" code

This seems like preventing new problems from happening. Which is indeed a wrong thing to do if the metric for evaluating employees is "number of problems solved".

If you create a fizzbuzz application with good performance and clean code, you have solved one problem. If you create a fizzbuzz application first, then fix three bugs in it, and then improve the horrible performance, you have solved five problems.


> If you create a fizzbuzz application with good performance and clean code, you have solved one problem

You haven't necessarily solved a problem if the definition of "clean" is subjective and not actually associated with any real benefit to the client/user. In that case you've just scratched an itch or wasted time. Same goes for optimizing something that happens rarely or wasn't prohibitively slow to begin with. Crucially, it's not about what _you_ perceive to be a problem but what the _user_ perceives to be a problem.

Again, I'm not saying you shouldn't strive to write clean code that performs well but it's important to know what that actually means within the context of that particular project.

Some examples of a "pet" focus:

* The designer gets absolutely up in arms because something doesn't match the wireframes, but doing it as shown in the wireframes is much harder. You show it to the client and it makes absolutely no difference to them.

* A coworker spends time to refactor code to make it more Pythonic, aka rewrite look-before-you-leap code to ask forgiveness instead of permission. The code is now arguably worse.

* A user adds memoization to part of the code that doesn't have any particular performance issue. That code is now harder to understand.

The key is to focus on _real_ problems, not ones you want to work on.


Oddly enough, problem solvers can also have a "pet" focus. One manager in my former department would interrupt every technical discussion to tell us that we were solving the wrong problem, and to point us towards the "real" problem. It can be completely subjective.


Other than medical problems the rest aren’t necessarily real and could be seen as learned habits.

We “make up” problems and invent solutions at scale for people to abide social norms of needing a job.

Feeding oneself and learning about the world is work enough.

We don’t need all these “jobs”.

It’s social control at scale. Necessary evil, but we can do it differently now.


Hypothetical problems are still problems, and they still can be solved. I think the best case of that is the tower of Hanoi. Most abstract problems are made up, here is one:

If you add something to itself, what do you get?

I just made that up. The solution is: you get twice of that something.

With that said, I disagree that these problems are made up. I can see that it is the case in some cases or the majority cases of an industry (the software industry being one of them) but it's unfair to say that all of them are made up.

psychology problems: I've seen some terrible stuff from psychologically damaged people. If a psychiatrist would've helped them, then a few calamities could've been prevented.

Also, I've seen useful things that laywers do. One time a family member had an issue with a big company. Without a laywer he wouldn't be able to right the wrong that they did to him.


Ok I can contextualize it better perhaps: life disagreements and emotional issues are real. We’re squishy biological creatures in a physical world we don’t entirely understand.

Our framework for solving them, of anointing experts undemocratically who are afforded special say in solving localized trade disputes and creating a market for casual babysitting of adult emotions is pandering to selling frameworks of agency that are outdated.

Historically it was a matter of literal ability to educate and train at scale not existing. It does now.

Law as we know it is hundreds of years old and obviously not working for the species.

Psychology is rapidly being superseded by “take this pill”.

We don’t need to cling to old solutions to problems.

YouTube broke while trying to fingerprint a legal debate of copyright, it became a circular mess. It’s obvious how we’re repeating ourselves: Dems quietly inflate inequality & keep political prisoners, the GOP gaudily so. Enjoy your exceptional legal system.

Sure there’s some psychology, the basics, that “normalize” folks through curve fitting responses. There’s a shit ton of terrible, useless frameworks out there, many do more harm than good. I’d prefer to put my money on a pill then that normalizes my brain as I design rather than some experts favorite rhetorical mess.


Flipping bits on a computer screen can appear helpful when it isn’t. Building an abstraction needs to be constantly grounded with solving real world problems.


>But who isn't solving problems?

Unskilled labor. Unskilled labor is there to execute a solution. Programmers (and others) are expected to innovate. Its important to remember that instead of simply cranking out code for the facet of the problem that happens to be immediately in front of you.


Isn't moving in itself solving the problem of location? I guess one of the issues is that the word "problem" has a broad definition and can lead to a lot of misinterpretations since many people use different definitions. Because it does not feel like the same type of problem solving that would befit solving a math problem, for example.

Other than that, whenever I did unskilled work I had to solve problems like: what to do if too many guests show up and you have too few chairs, because management calculated the wrong amount of people showing up?

Potential solution: get more chairs.

Alright, but how will you make it look aesthetically pleasing? The place is full!

Solution: ask some people to stand.

But some will politely stand, and will then have a bad taste in their mouth of the experience.

So on and so forth.


Most unskilled labourers are presented with non-routine problems frequently throughout their work


Sure. Unskilled labor isn't the only thing "unskilled labourers" do. But the routine work is, well, the routine. For lack of better terminology I mean how an assembly line worker is not usually expected to "solve" the assembly line in novel ways. They might anyway but its not the expectation.


For example, the problem of how to survive on minimum wage, with a terrible boss and no job security.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: