
You’re not writing code, you’re solving problems - lanraccoon
https://lanraccoon.com/2020/youre-not-writing-code-youre-solving-problems
======
muglug
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.

~~~
mettamage
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
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.

~~~
Viliam1234
> 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
> 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.

------
datalist
"You're not cooking meals, you're solving problems"

~~~
SCdF
You're missing the point.

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.

~~~
jackcviers3
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.

~~~
BurningFrog
> _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!

Because it ignores performance.

Try implementing a video game with human clerks.

~~~
wool_gather
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.

------
Ozzie_osman
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.

~~~
klysm
This seems like an interesting generalization/characterization of technical
debt.

------
liquidify
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.

~~~
lainga
Hoh! I spend most of my time figuring out pipenv (not my design choice!) .

~~~
reedwolf
Python packaging is now a solved problem.

Use Poetry. Resolves all your dependencies and manages your virtual
environments.

Also lets you build and publish your own projects with a few commands.

[https://python-poetry.org/](https://python-poetry.org/)

~~~
ngngngng
I'm excited to give this a shot, but I've heard this promise many times
before.

------
carlsborg
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.

------
mikekchar
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...)
;-)

------
Nursie
This reads to me like the faux-deep inspirational, vaguely-self-help-ish
platitudes that litter facebook.

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.

~~~
wpietri
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.

~~~
ccthr
Tesla are using Scala actors for their power distribution network.

[https://www.infoq.com/presentations/tesla-
vpp/?utm_source=pr...](https://www.infoq.com/presentations/tesla-
vpp/?utm_source=presentations&utm_medium=london&utm_campaign=qcon)

I guess cool is subjective.

------
pezo1919
"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".

------
lmilcin
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.

------
dwheeler
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.

------
boraoztunc
“Creative people don’t have a goal of wanting to be creative,” Flaherty says.
“Their goal is to solve a problem.”

------
jl6
Junior devs solve computer problems using computers. Senior devs solve
business problems using computers.

~~~
jspash
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.

~~~
jl6
I think you’re describing the currently-terribly-unfashionable-but-still-vital
role of architect.

------
jpswade
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.

~~~
dwaltrip
It sounds like you are stating that solutions vary in effectiveness,
especially across time.

This insight seems to making the framing even more useful, not less.

------
caseysoftware
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.

------
chiefalchemist
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.

------
wetwiper
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).

------
everyone
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.

~~~
webn3rd
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.

~~~
amelius
> I'd argue that any creative process can be coined as a problem-solving
> exercise

Problem solving _with_ real-world constraints = engineering

Problem solving _without_ any constraints = art

~~~
thaumasiotes
This is reminiscent of the old divide between mathematics and philosophy:

true and useful = math

true and useless = philosophy

~~~
wwweston
Which side does the practice of distinguishing between the useful and the
useless fall on?

~~~
blondin
philosophy decides :)

------
downerending
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.)

------
zemo
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.

~~~
mettamage
Aren't puzzles a subclass of problems? Isn't a problem simply a question that
has a solution?

It made me think about the definition of the word problem. Here is one list:
[https://www.merriam-webster.com/dictionary/problem](https://www.merriam-
webster.com/dictionary/problem)

~~~
ken
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.

------
nybblesio
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.

~~~
guggle
> 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.

------
k__
Funny thing is, coding today is mostly understanding how other devs solved a
problem.

We're using frameworks and libraries that all come with very specific
solutions.

~~~
ativzzz
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.

~~~
k__
Some tools are overengineer, true.

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.

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

------
CodiePetersen
>>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.

------
ulisesrmzroche
“Writing code is considered harmful”

~~~
pezo1919
lol

------
bartq
Title should be "If you don't work on software product, you’re not writing
code, you’re solving business problems with code".

------
crimsonalucard
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?

~~~
perl4ever
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.

~~~
superpermutat0r
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.

~~~
perl4ever
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.

------
megamindbrian2
I'm definitely not solving problems. I'm just writing code. And copying and
pasting. And merging.

