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 problems for – when I was a single person doing freelance web work (like this article seems to assume), I was always solving problems for customers and their clients.
Once I started working with other developers, I became interested in solving their problems too – sometimes in the form of a big refactor to improve the code, but also making tools to improve the codebase at scale.
> 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.
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.
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.
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.
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.
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.
This is also important to keep in mind, although I'd phrase it as, "You're feeding people." Or more specifically, "You're trying to make people healthy and happy."
I mean, think of all the mediocre, industrial-grade food you've eaten over the years. School lunches, maybe. Low-grade franchise food. Whatever's in the vending machine. How many people involved in making that are focused on the experience of the person eating the food? As opposed to maximizing revenue, or just doing whatever the manager says, keeping their head down, and getting out at quitting time?
Or let's think of all the food we've eaten that was made to please the cook, not the eater. A friend has an aunt that every year sends a giant box of absolutely terrible Christmas cookies. They're like iced cardboard. The important thing to the aunt is feeling like a big giver, not the experience of the eater. Or on the other end, consider fancy chefs who make tell-me-I'm-clever food, where the presentation is dramatic, but the actual taste is not so great.
Every time I cook for others, I see it as an opportunity to really see the person, to find the best intersection between my skills versus their desires and needs. And it's the same for software.
Never thought this way about food preparation, and the different motivations people have for doing it, not always prioritizing the "eater". Nice comment!
The goal of cooking meals is to have a meal at the end. Because people need to eat. The food is the solution to the problem you have.
People don't consume software, slurping up lines of code like ramen. Having a steaming bowl of software is not the end goal. The end goal is to solve some _other_ problem which may or may not, once you dig into it, require writing software, and if it does then still: more software doesn't mean more food.
You are missing the point. As is almost everyone else who says this stuff.
Most of us get paid to write software other people have requested in order to solve their problems. Every problem software solves can be solved by a sea of pencil pushers or factory line workers or human calculators or office clerks with filing cabinets or telephone switchboard operators or typists. The world used to run that way.
It no longer does because it is extremely cheap to program a computer to do repetitive actions. Compared to previous real-estate and labor-pool costs, paying even a thousand programmers to automate work done by people is incredibly inexpensive.
The problem is already solved. Your job is to translate the solution into a well-specified, easy to manipulate series of steps for a computer to execute that can be operated in production as cheaply as possible. You are literally the last step in the race to the bottom. You are literally payed to solve the problems of translating flexible human activities into code. That's the problem you are solving.
If someone asks you to program something that they don't already know how to do, then you are solving three problems - what to do, how to do it, and whether or not it is cheaper to do in software, which it ALMOST ALWAYS IS. You should be being paid three salaries - one as a business executive, one as a business analyst, and one as a software engineer.
The people pushing you to "solve problems, not code," are people pushing you to do more work in one job role to keep them from paying three people for those jobs. As a software engineer, you should be able to assume by the time something hits your task queue that others have decided that it will be cheaper to use software to solve the problem, they were competent in that assessment, and you can start executing.
As a consultant, I frequently take on all those roles for a client. But they pay me as a consultant to do those three roles. Remember that as an employee, in an extremely in-demand field, with specialized expertise compared to the rest of the work pool, you are a sole proprietorship trading time for resources. If that trade is lopsided, you need to push back and negotiate higher pay and a promotion. Don't give away work responsibilities for free because of culture hero points.
> Most of us get paid to write software other people have requested in order to solve their problems. ... The problem is already solved. ... You are literally payed to solve the problems of translating flexible human activities into code.
OK then, I think the confusion is that your experience (and definition) of software development doesn't align with mine.
> You should be being paid three salaries - one as a business executive, one as a business analyst, and one as a software engineer. ... Don't give away work responsibilities for free because of culture hero points.
I don't know what culture hero points are. Anyway, while I agree those are three different roles, I don't think because the "BA" role exists the "Soft Dev" role should just ignore req gathering and demand a fully completely spec that they then in no way question: that feels like waterfall from the 2000s. In the same way I think that a BA should understand how software works to a point and use that knowledge to direct their design, a software dev should understand the problem and design and contribute to that solution. The roles are not rigid black and white barriers where you throw things over the wall to the next person, they are just places where you concentrate.
> Every problem software solves can be solved by a sea of pencil pushers or factory line workers or human calculators or office clerks with filing cabinets or telephone switchboard operators or typists. The world used to run that way.
I know what you mean, but this is the wrongest thing I've seen in quite a while!
It's a good counterpoint; high-speed games like platformers and FPS are only really possible with a computer. Lots of other game types have analog analogs, though.
Pinball is certainly a precursor to video games; there's other low-impact games of manual dexterity like ring toss/bocce/..., darts/target shooting. Choose your own adventure books/pencil and paper role-playing/wargames obviously predate computer gaming -- the computer just runs a timer maybe and acts as the gamemaster.
People have been playing various forms of puzzle solitaire with cards for years; Bejewelled or whatever could be done with a custom deck. Minesweeper is not different in kind from the old logic game Mastermind. Even something like Tetris seems new, but I think is similar fundamentally to a tabletop game like Boggle: randomized input + a timer to find solutions -- the geometrical nature of Tetris is kinda just an implementation detail.
But I would venture that the number of problems that are only quantitatively different -- i.e., faster -- because of computers utterly dwarfs the number that are qualitatively different, or even impossible without them.
Like what? A first person shooter/ - try combat or paintball. Fighting game? Get in a fight. Sports? Play sports! Mystery? Detective work, mystery dinners. RPG? Dungeons and Dragons tabletop, magic. Flight simulator- actually flying.
"Reality is the only place you can get a decent meal."
Video games are simulators of things in real life that are taken to extremes because death in the real world is permanent. They do impossible things - like fight aliens - but you can definitely fight using weapons (even airsoft or nerfed counts) in contrived situations in the real world. Imagine a cast of actors and you fight them with an airsoft rifle. No computer needed.
Some artists, I believe, are playing the game of creating and solving problems - where they make up the rules so that interesting problems can arise. J.S. Bach and his canons for example.
It may also be joked that some politicians aren't solving actual problems (but creating new ones) in their day job.
Some politicians do solve problems sometimes; it's the bulk of the massive bureaucracy in government that doesn't solve problems, other than feeding itself and ensuring its own propagation.
Honestly, you really can't separate the two. Half the bureaucracy is the direct result of political action, and each political action further constrains the ability to quickly mobilize further political actions due to the necessity of conflict resolution.
It would be more accurate to say some politicians solve problems for some time; after which their solution becomes someone else's problem.
The idea is to keep your mind clear on what the priority is. If you didn't write many lines of code but still solved problems, you did your job. The two aren't mutually exclusive, but it helps in prioritization
This classification of applications as CRUD or not CRUD is not helpful. It‘s like thinking about software as just IO or as just some sort of transformation or even as just some sort of function. It says nothing about the complexity and very little about the structure of the problem at hand.
Maybe a better way to put it is: that the end result is just a website where data is moved around and/or some calculations are done. The whole infrastructure/architecture thing are just strategies on where to place data, how to move data, when to do calculation in the name of mitigating load or making future changes easier.
Ultimately, the end result is we're just building interactive documents. "Interactive document maker" or "Dynamic form writer" is a more humble term than "Problem solver" or "Coding Ninja" because that's literally all we're doing.
It doesn‘t matter if the output is a „document“ or if it runs in a browser. And more so with SPAs. These are not more like documents than any desktop application twenty years ago.
And of course software development is about solving problems. And of course it‘s not just about where to place data.
I completely agree with you. Really getting sick and tired of the tech industry thinking they are better than everyone else because they can program. Very egotistical culture. Down to even morals. I had one guy comment to me "Hard to believe someone in the tech industry believes such things."
But I think it is mostly just American programmers. Or maybe just big city programmers. I've had the opportunity to work with people in Spain, The UK, and Prague, others remotely as well, but I haven't seen the level of ego in those guys as I have seen in Americans.
It's part of the reason I loathe the idea of hiring developers from America. EVERYOTHER industry is perfectly fine with criticizing or reanalyzing the work of others either underneath their authority or about their competitors. I'm sure even some of these programmers have even said "OMG this caffe macchiato is crap. I'm never drinking from this place again." But nope, don't criticize programmers or ask them to redo work. It's just so rude.
But it is probably the fact that companies like Google literally put slides and children's toys in their offices for their apparently adult programmers to enjoy. An artifact of programmer scarcity I'd imagine.
Plumbers and custodians also save lives through sanitation. But when you google "Plumbers save lives" you get nothing.
I myself have had my cancer personally cured by AI and machine learning, but does the electrician who provided power to the computer get any credit? No, and that is a huge discrimination problem.
I liked this article, but one point it misses is that you should be solving problems in a way that makes it easy to keep solving problems in the future, and that's a tradeoff that even more people get wrong.
For instance, writing good, maintainable code only matters because if you don't, you might reduce your ability to solve more problems in the future when the problems you need to solve might change, due to learning new information about your users/customers, your users/customers changing, etc. For example:
- the code itself might be difficult to understand, reason about, and change, making it hard to make changes.
- the code might require time spent on maintenance, which reduces the time you can spend making forward progress.
Depends on the language. I find that in C++, I spend a lot of time working on figuring out the language, while in python I spend far more time solving the actual problem.
I vaguely remember the exact same sentiment being expressed for both pip and Pipenv. The project I'm working on is currently migrating from Pipenv to Poetry, and while it's an improvement I have no hope that the fifth generation (setuptools, EasyInstall, pip, Pipenv, and now Poetry) Python packaging tool is in any way the last one.
I second this. Poetry is a great all-in-one tool for dependency and package management. I've written a few blog posts about it, and I remain happy with it. The Poetry team has done a great job making quality of life improvements to the tool, and it's actively maintained. It's worth checking out.
Personaly I just stick with manual venv and pip. It's not hard to use, it works, it's standard. But of course I'm lucky enough to be the one making the decisions.
Via the FFI declarations you manually wrote to your favorite graphing library that exports a C API? All major Common Lisp implementations have threading built in, and unlike Python performance is excellent without dropping to C.
As an example, I recently wrote a GLFW backed program with the GPU boilerplate in C++ and all the high level logic in Lisp. I could have done the entire thing in Lisp, but there was less API surface area to wrap this way.
Good software is a sequence of good ideas. Deep knowledge of computer science, the tools and frameworks, and the offline side of problem domain including the market mechanics expands the surface area of possible ideas.
Pareto Principle... If some young person is at a loss for a science fair project, I humble suggest to attempt to replicate this experiment: Grow some peas. Count the number of peas in a pod. Verify that 20% of the pods contain 80% of the peas.
In case you prefer the thought experiment version, consider that you have 100 peas. 80% of 100 is 80 (I like easy math). That means that 20% of the pods contain 80 peas. It means that 80% of the pods contain the other 20 peas. If we have 10 pods total, it means that 2 of the pods have 40 peas each and the other 8 have 2.5 peas each on average. I ain't never seen no pea pods with 40 peas in them, so it must be more pods. I think the most peas I can imagine in a pod are 10, so let's say that 8 pods have 10 peas each and 32 pods share the remaining 20 peas. Since you can't have less than 1 pea, that means that you have at least 12 pods empty even if the other 20 pods only have 1 pea each. If you have a more reasonable distribution, you will find that more than 40% of the pods will be completely empty.
I've grown peas a lot. I've never, ever seen a distribution of peas like that in pods. What strange peas was Pareto growing? Is it just that we have better strains of peas now, or was Pareto just making stuff up? (small voice: just like practically every application of the Pareto principle I've ever seen...) ;-)
There are a ton of engineers that don't know this. They like building things, and talking to users is hard. So they just build stuff and throw it over the wall.
And I get that. I have hobby projects because it's nice just to go wild and code for my own entertainment. My home lighting system is a custom Scala actor-model daemon, because 5 years ago I thought Scala was cool. (In retrospect: nope!) Building things is fun.
But when I'm on the clock, I've learned to be relentless in understanding actual users and their needs, and ruthless in pruning back the many things I'd like to build down to what actually serves people.
That's not easy even in the best of cases. And in companies that have waterfall-ish leanings or command-and-control managers, it's often impossible. So a lot of programmers learn to build whatever they're told, regardless of whether it solves a problem. And a good chunk will do it in ways that entertain them, because when managers drain all meaning out of a job, we are forced to find ways to create some for ourselves.
Loads of people work in places where they need code monkeys and there is bunch of non coders as management who solve customer problems. Those are sad places to work for.
I imagine that how it was in the '90s so all business people were there to make UML and "proxy code" that was supposed to be typed in by code monkeys. Code monkeys also would handle all those "not important technical details".
But you have other type of places where one can work. Where you work with sales or business people together on solving problems. In those places it is more like described in the article.
This second type of places in my opinion started winning, because you cut out middlemen who don't code. So in startups you should sell or code there is no place for middle management who rounds up code monkeys. In those places devs get some power because usually it is a company that sells software so they are not cost center but competitive advantage for company.
"You’re not writing code, you’re solving problems" is true, but in an appropriately bad company its also true and maybe much more important:
You are not solving problems, you are writing code.
That's when management or upper levels in hierarchy are not experts and have no idea what's the software and the particular problem is about and micromanage.
My point is that the warning the title refers to is real, but there is another (bigger) problem when people know they are not solving the problem the right way but they are forced to ship asap and "just code".
This is golden advice and for me understanding this is one of the differentiators between junior and senior developers.
All too often developers seem to be bent on the idea that they have been hired to write code and so the solution to any problem they are asked to solve must be more code.
The truth (or at least the way I understand it) is that writing code should be something that happens when you have explored every other option possible.
Even if it is easy to write, code is expensive to maintain later on and the costs do not add linearly.
The larger the project the more it costs to maintain anything. Simple operations become huge projects.
The best bet, in my mind, is to try to have as little code as possible by treating the code as a liability and trying to curb the amount of it from the start.
Even if you need to add code to add a functionality, it is frequently possible to shift it from somewhere else. Refactoring as you add functionality is a good way to curb the size of the code base.
Another way I have noticed that seems to be frequently overlooked is to have the object model as close to your real problem. Any inconsistencies between real life and software object model seems to result in heaps of code in multiple components to deal with various exceptions, translations, mappings, etc. and this seems to grow exponentially with time. Sometimes there is no better way than just do it right from the start.
I work for a large bank on a system that deals with risk calculation. It seems every part of organization has a slightly different understanding of what a trade is or definitions of its properties. The net result is that, in my estimation, there is about 3 orders of magnitude more code that would be necessary if there was single shared definition of all those properties.
I think this is important advice that needs to be repeated over and over and over again. The number of software developers who get caught up in the latest fashion choices, instead of carefully picking the right set of tools for the job, is absurd. Sometimes it's really important to use the latest thing because it solves a key part of your task; often it's better to use a "boring" technology that is well-understood and does the job without a lot of fuss.
I remember years ago, when I was in high school, reading advice that "customers don't want drills, they want holes". Software developers should constantly focus on what the customer actually wants (that is, the problem the customer is trying to solve).
It sounds trite, but it's easy to get distracted when you're knee-deep in trying to solve the problem.
And “ninjas” or whatever the term is for senior+ programmers know when to solve problems without a computer at all!
That’s when you’ve reached enlightenment :)
And I don’t mean that in a woowoo wishy washy way. I mean that when someone comes to you with a business problem, often the solution can be something as simple as “why not just change the text to say X” or “did you know that dept Y already do that thing? Let’s ask if they will take on this task also”
A junior will have already coded 100 lines of “something”. And some seniors I know of will be knee deep in microservices whiteboard sessions by now. The truly great programmers I’ve worked with prefer simplicity first and foremost.
Interestingly, for us it's the opposite. Senior dev responsibilities are to:
a) Get ahead of the computer problems that junior devs would otherwise create in their frenzy to solve business problems (frameworks, infrastructure services, design reviews, etc).
b) Clean up the ones they missed (architecture initiatives).
This is all very well and good until the code you’ve written to solve the problems becomes a bit too unwieldy, then you need to become better at writing code.
The problem you were solving was solved, but now you have a new problem to solve.
True then, the best code you can write, is indeed, no code at all.
I've given a couple presentations along these lines and found it's important to make another point: Code is just one tool in our toolbox.
We can make our interfaces more intuitive. We can make our documentation clearer and closer to the user's terminology. Our examples can be more explicit and tuned to people's common use cases. Our FAQ can address actual frequently asked questions instead of what we guess people will ask. We can treat FAQs as bug lists/things to improve so people stop asking.
If code is the only tool we use, we'll always write more code which comes with costs now and down the road.
Code is a means, not an ends. Furthermore a sexy cool "solution" is no solution at all if it doesn't solve The Right Problem. Too many obsess over solving a problem, or a client want.
Unfortunately, that's not the same as solving for the actual biz need. This is a key reason why IT has a reputation for failed projects. What's delivered - even tho it was what the client wanted - turns out to not meet the (never defined) need. Wants are not the same as needs; sometimes the difference is significant.
Editorial: I had a semi heated exchange with a proj manager a couple weeks ago. He said, "The client like this (i.e., example from another site). This is what you need to build." I asked why the client liked it; what was the underlying biz need that the proposed solution satisfied? I never got an answer.
Despite having used the "we're solving problems" argument myself on occasion, I think what we're really doing is identifying problems and assisting with possible solutions using particular knowledge of our domain.
Somebody wants something done within particular constraints, so our job is to identify potential issues that may occur, such as scalability problems, costing issues, UX concerns, etc. And help explain to that client such concerns and possible solutions or compromises, and let the client decide on the solution.
Once actually implementing some plan, we have some creative freedom on the implementation details, but I'd hardly call that solving a problem (apart from it being your own problem on how to get the design coded up).
Yet another article on HN that reads as if the entirety of programming = making CRUD web apps.
I make games, it has nothing to do with the real world, I'm not solving any real world problems. I'm making a new fantasy world.
Still, in my point of view, your viewpoint and the article's one can be aligned. Strictly speaking, converting your ideas about the fantasy world into code to run the game is "solving a problem". I'd argue that any creative process can be coined as a problem-solving exercise, except for the fact that in many such cases the problem isn't tangible and the outcome isn't measurable.
Art has always had constraints: funding, the physical media’s capabilities, and the ability to reach an audience. This is why any time a new technology shift happens there’s a spike of artists trying things which were not previously feasible.
> Also, an artist's constraints are often self-prescribed, and they can easily change them if they like.
the most amazing art (both graphics and music) i have seen on computer were from atari, amiga, & c64 demosceners. these artists had real software and hardware contraints.
i like what you said about it being a spectrum though. i think it's hard to tell when engineering becomes art and art becomes engineering. but one can easily spot pure (for its own sake) engineering or pure art.
There's also a fair bit of "engineering for engineering's sake" (as a parallel of "art for art's sake" - "https://en.wikipedia.org/wiki/Art_for_art's_sake), "divorced from any didactic, moral, politic, or utilitarian function".
Having watched a significant amount of the hand made hero series (the closest I’ll get to writing games) i’m more inclined to side with the grandparent on this one.
Game dev can be just hardcore programming juggling everything from euler equations to hardware performance budgeting.
Sure you can take the view this are just constraints in a problem solving exercise.
Or it’s highly skilled programming. I fall on the latter view for sure.
Yeah, thats a bit of a stretch tho.. The article really emphasizes 'real world problems' .. They are clearly thinking building some kind of web-app like uber or airbnb or whatever.
Like, you could also say that I'm solving the real world problem of, 'this exact game not existing, cus these specific people would love to play it but it doesnt exist' .. But that is a super-stretch.
Also, this article is extremely short and seems to mainly just be repeating a few already very well established and common ideas; as if it was put together by a marketing guy by cutting and pasting a few things. Is it just an ad for the link at the end 'webflow' ?
I think game is art. Art is made for publish thought of creater, which has power that solves real-world problems. Writing game code (art) is equals to solving problems.
As a literal example, I've occasionally been asked to put some process that was previously done physically "on the computer". That is, perhaps a paper log of some important activity that they'd now like to have a program for, or a physical token system for tracking a critical resource.
Often computerizing is useful, but sometimes it turns out that any conceivable software version would actually be significantly worse than what they're already doing.
In a case like that, you truly can solve their problem by not writing any code.
(Obviously, this only works if they ultimately agree.)
a question I like to ask to my reports is "are you solving a problem or are you solving a puzzle?"
puzzles are neat! They're a lot of fun! But we shouldn't mistake puzzles for problems. Just because something isn't right or doesn't fit together doesn't mean that it matters. You can do great engineering work coming up with beautiful solutions, making order and beauty out of something that doesn't work quite right but provide no value whatsoever if the thing you were working on solving wasn't actually a problem for anybody.
I don't think either word, "puzzle" or "problem", requires it to have a solution. I would say the distinction is that the purpose of a puzzle is in the act of solving, while the purpose of a (business) problem is to have the solution.
NOTE: This is tongue-in-cheek (for the most part). However, I cannot help but feel that articles like this are a subtle form of social manipulation; especially for younger, less experienced programmers.
From the article:
* The software is not the purpose
Translation: your craft, how you do it, and why are not important. Going meta for your profession is not valued and if people see you doing it, you're in trouble. Let the guilt wash over you, heathen!
* Understand the problem
Translation: going meta (refactoring, egads!) is wrong. We're watching you and if you do this, you're in trouble. If you aren't feeling guilty yet, now is the appropriate time. In addition, you must feel shame for your irresponsibility!
* Perfect is the enemy of good enough
Translation: going meta -- unless it is to realize a clever kludge -- means you are a perfectionist. You're wrong! We're watching you and if you do this, you're in trouble. You're one of those prima donna programmers, aren't you? We have no need for you!
* Choose your battles
Translation: Everyone starts off doing everything by hand, so -- you know -- the whole notion of writing software in the first place is kind of a Faustian Bargain. Hey, why did we hire you anyway? It's clear you're one of those whinging, prima donna, basement dwelling, perfectionist, programmer A-type people. I see we need more money in the "team building" budget. You're fired. Now is the appropriate time to feel like a loser, because you are!
* The best cod (sic) you can write, is no code at all
Translation: We can't even be bothered to spell "code" properly, which shows you how important it is to us. Truthfully, if there were a magic product we could buy that does what you do -- but better! -- we would. Don't you dare start thinking about weighing cost/benefit of buy-versus-build. We know you programmer types. You just want to build stuff and it's never the right stuff and you can't estimate for crap and your profession doesn't matter. Screw it, let's just put out an RFP and see if someone has a silver bullet so we can use it against you programmers! Lead bullets aren't working.
Postscript:
OK, now that I got all the snark out of my system, I feel better. It isn't that parts of this article are wrong but rather it makes extremely broad assumptions that all programmers are doing the same thing, in the same context, for the same reasons.
The current gestalt around software development appears to be that only a select few are allowed to decide the "state of the art" in the profession. These anointed few enjoy autonomy and full creativity but the rest of us must check our brains at the door.
Maybe it's just me, but I find this attitude extremely risky and deleterious to the industry and the human race. Of course, I am a grey beard, basement-dwelling, prima donna, perfectionist, anti-social, programmer so nobody will be surprised.
> I cannot help but feel that articles like this are a subtle form of social manipulation; especially for younger, less experienced programmers.
Indeed, I'd go as far as saying this is straight up managerial tautological BS like I've heard many times.
"If the software doesn’t do what you need it to do, it’s useless.", said Captain Obvious. Well, of course it must solve the problem, but that's not enough, far from it.
And then the article promotes things like wordpress and webflow... well, I for sure know what code base I won't have to deal with when a bad plugin will break the "best code is no code" mantra.
Well it's more like using the tools other developed to help you solve your problems faster. If you're spending more time understanding the tools you're using, reconsider your tools.
That’s what everything is. And we shouldn’t short programmers for doing the same thing.
Even cutting edge research or new developments in any field are built on lifetimes of other people’s work. It’s always been that way, and it’s one of the things that allowed us to prosper as a species.
Very well written article. But i dont agree you should always rely on someone elses solutions. I think we went too far with it. Too many dependencies is as bad as duplicating code. Also i would add that sometimes solving problems with software can create new problems. Problems that can be solved only by more software. And this is also a risk
>>We’re programmers, so writing code is what we do, is it not ? As the title suggests, our job is a bit more complicated than stroking keys on a keyboard in front of a screen all day.
I don't know what it is about the tech industry but it really seems to think highly of itself and is constantly self congratulatory.
If you write code to solve problems then you are a coder, just like if you drive trucks to solve a transportation problem. What's the point of getting into semantics?
What programmer on the face of this earth doesn't realize that they're hired to code up a solution to some problem? Is this article implying that there are programmers out there who believe they are employed to write beautiful code to be looked at and admired and never to solve a single problem?
From reading HN, it seems like there is a cultural outlook where everything other than the problem to be solved is first and foremost when choosing a place to work. Like, do they use the right tools, the right OS, the right management methodology, have the right perks.
And when I look at job ads, it seems clear that there is a fair amount of competition among employers to appeal to these sorts of employees, by following trends or appearing to.
I think it's obvious why - people who care about things other than problems for their own sake, if talented and self-motivated, are more versatile and therefore valuable, because they will do a more or less equally good job on any problem.
This cultural dynamic is, I think, an obvious emergent dynamic that has made "don't be evil" a futile aspiration, not just for Google, but for the software industry in general.
Yeah, I never understood the HR reps approaching me and listing all of the technologies company uses.
After reading that I still have no idea what company is doing and why they would need someone like me.
My last phone screen, I had a job and was pretty sure I didn't want to go anywhere, so I was free to express myself and talked about how much I liked the sort of problems I was dealing with at work. The feedback to the recruiter was "he didn't sound technical enough"...despite them not asking any technical questions.
Everybody wants to save the world of course, but it seems like the modal outlook is that everything else comes first, including all the dealbreakers, and the substance of what you are doing is mostly pro forma.
If you don’t like it, don’t vote for it and move on. A content-free comment complaining that someone on the internet made something and gave it to you for free doesn’t add to the conversation.
My life would be much easier if I didn't have to dig through piles of useless garbage like that post.
As a matter of fact that's why I like and keep coming back to Hacker News is because most of the posts I can read here are less fluffy than anywhere else.
So yeah, if I don't respect something I am willing to fight for the right to see something I have respect for; even if I don't like it btw.
The big question is who you're solving problems for – when I was a single person doing freelance web work (like this article seems to assume), I was always solving problems for customers and their clients.
Once I started working with other developers, I became interested in solving their problems too – sometimes in the form of a big refactor to improve the code, but also making tools to improve the codebase at scale.