You’re not writing code, you’re solving problems
lanraccoon.com
lanraccoon.com
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Literally you can google "AI solves world peace" or "AI solves COVID-19" and you'll hit an article.
We also call ourselves ninjas when most of us are just building hugely complex infrastructure behind what is ultimately just a CRUD website.
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.
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.
And of course software development is about solving problems. And of course it‘s not just about where to place data.
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.
I can think of many classes of artists, but cannot put a blank statement for _all_ of them.
It may also be joked that some politicians aren't solving actual problems (but creating new ones) in their day job.
It would be more accurate to say some politicians solve problems for some time; after which their solution becomes someone else's problem.
By creating problems, they solve a problem of a lack of suitable problems. Thus creating the much needed liquidity in the free market of problems.
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.
what even is gaming
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.
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.
I know what you mean, but this is the wrongest thing I've seen in quite a while!
Because it ignores performance.
Try implementing a video game with human clerks.
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.
"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.
The goal of making applications is to have a piece of software at the end. That piece of software is the solution to the problem you have.
Actually, in that very sentence of yours you explicitly repeated what I already wrote
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.
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.
Edit: you don't need poetry either.
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.
Use Poetry. Resolves all your dependencies and manages your virtual environments.
Also lets you build and publish your own projects with a few commands.
In Lisp, I lose time manually writing FFI wrappers. It really makes you appreciate the size of Python's ecosystem.
In C++, I spend inordinate amounts of time buried in the language standard. It's just _so large_.
In C, I have "fun" with manual memory management, name collisions, and boilerplate.
I think Lisp is my preferred choice for the time being.
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.
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...) ;-)
Are there software engineers out there that don't know this?
You're there to solve a problem and/or create a product. Code is a liability.
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.
https://www.infoq.com/presentations/tesla-vpp/?utm_source=pr...
I guess cool is subjective.
Instead of number of problems solved MINUS the number of lines of code written.
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 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".
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 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.
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.
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).
s/Novice/Junior Dev/, s/Master/Senior Dev/
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.
This insight seems to making the framing even more useful, not less.
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.
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.
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).
I would not write a post about it.
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.
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.
Problem solving with real-world constraints = engineering
Problem solving without any constraints = art
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.
true and useful = math
true and useless = philosophy
"It is not possible to justify the life of any genuine professional mathematician on the ground of the 'utility' of his work." (G. H. Hardy, 1940)
Entertaining games solve people's desire to be entertained.
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.)
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.
It made me think about the definition of the word problem. Here is one list: https://www.merriam-webster.com/dictionary/problem
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.
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.
We're using frameworks and libraries that all come with very specific solutions.
But more ofteb than not, people underestimate the problem AND the tools that were created to solve them.
Also, most devs aren't simply as smart as they think they are.
I worked with many devs that tried to force their mental model on an framework that worked completely different.
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.
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.
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?
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.
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.