4 ms·

I think this article constructs a strawman argument – pretty much all developers are solving some sort of problem. The big question is who you're solving probl

• mettamage 7y ago
  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.
  • stank345 7y ago
    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.
    • analog31 7y ago
      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.
    • Viliam1234 7y ago
      > 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.
      • stank345 7y ago
        > 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.
  • urioro9 7y ago
    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.
    • mettamage 7y ago
      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.
      • urioro9 7y ago
        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.
  • jayd16 7y ago
    >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.
    • chottocharaii 7y ago
      Most unskilled labourers are presented with non-routine problems frequently throughout their work
      • js8 7y ago
        For example, the problem of how to survive on minimum wage, with a terrible boss and no job security.
      • jayd16 7y ago
        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.
    • mettamage 7y ago
      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.
  • friendlybus 7y ago
    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.
• wpietri 7y ago
  I don't think it's a strawman at all. E.g., I've seen plenty of code where the problem the developers are solving is "I'm bored with work" or "I don't like my boss yelling at me about the deadline". As an example, I was once brought in to help sort out a build pipeline. It was quirky, unreliable, and mysterious to the team using it. I dug in and it was built around Docker 0.8. But not even the official Docker 0.8; there were assorted patches applied for who-knows-what. And there was a bunch of other stuff glued on around it to compensate for the kinds of issues you would expect in 0.8-grade software. Looking at the version history, the person who wrote it was long gone. So I searched for him on the Internet. One of the top hits was a conference talk, presented not long after finishing the build pipeline, on how awesome Docker was, and how very clever he was in applying it. Sure, he was nominally solving the company's build pipeline problem. But really, the only problems he was solving were his own. Ego. Resume building. Wanting to play with fun toys. At the end of the day, I ripped it all out and did what he should have done in the first place, which was to use simple, reliable tools that the team was comfortable working with.
  • whatshisface 7y ago
    How can managers ensure that employees feel that their personal goals are aligned with the goals of the organization?
• zerkten 7y ago
  > The big question is who you're solving problems for > Once I started working with other developers, I think the problem is about drift. Moving from working on your own problems as a freelancer, to bigger teams and organizations, tends to shift problem solving to a more nebulous state. As the freelancer you fixed problems that perhaps you saw directly, and could fix end-to-end. These could be business or technical problems. The cost of certain actions was evident. As you progress up to larger and larger organizations you lose that connection. The organizations are supposed to have processes that make up for this lack of connection, but, at best, only do a very average job of it. Further, you have new sets of problems to deal with, that are not limited to: your colleagues' code, a worse understanding of requirements, PMs having less of an understanding of the requirements than you because management has perverted their work, not being allowed to work on small fixes because everything has to be A/B tested, sales teams perverting the priorities of management, the support team being sidelined by management even though they know the real problems etc. These articles about solving problems versus writing code never capture this progression for me because the authors generally don't have that experience. That's fine because we are all different and it still leads to valuable discussions.