
Programming is boring art - tomkwong
https://ahsmart.com/pub/programming-is-boring-art/
======
combatentropy
Comments are harsh on what I took merely as a pedagogical example, but maybe
it's because y'all have been burned so many times. I agree with you who advise
to resist speculative programming. Don't write it till you need it, since all
code incurs a burden of maintenance.

But I would like to address a tangent: extracting configuration from code.
Let's take the article's example and change it a little. I'll decompose it,
since it already has become a function, but often the first step is just a
series of statements. (I will also port it to javascriptish pseudocode, since
I don't know Julia.) So this might be your first draft:

    
    
      response = HTTP.get('https://www.example.com/');
    
      if (response.status !== 200) {
         email('someone@example.com', 'something is wrong');
      }
    

Instead of abstracting this into more general functions, I might simply move
the literals to the top of the file:

    
    
      url = 'https://www.example.com/';
      ok  =  200;
      to  = 'someone@example.com';
      msg = 'something is wrong';
    
    
      response = HTTP.get(url);
    
      if (response.status !== ok) {
          email(to, msg);
      }
    

The only reason I know to do this is to maybe make changes easier. Even if you
never need to generalize your code to other uses, you may need to update it
for reasons outside your control. For example, someone leaves the company, and
now you need to email someone-else@example.com. Or marketing changes the URL.

Is there a name for this kind of refactoring?

~~~
tomkwong
I don't know if there's any name about this specific refactoring change :-)

In general, it is best to create small functions that takes few dependent
variables for the intended flexibility. The first judgment here is to decide
whether a value should be a constant or variable. Constants would then be
declared at the top, and variables come in as function arguments.

You reminded me that another pattern to handle this is to put some of these
values as configuration parameters. For example, the email alert may need to
be sent to different people for different environments - DEV, QA, and PROD.

~~~
ehnto
In the grand-parent comment's example, you just want it to be more readable,
because it is a once off block of code, so that whoever maintains it next can
easily figure out what it is doing. Moving it into a function doesn't stop it
from being a once off block of code, and we need to be careful not to increase
complexity for the sake of it. By your last paragraph you had already
introduced a configuration store and the concept of environments!

~~~
combatentropy
In all fairness, I led him that way. I called it "extracting configuration
from code", which is reminiscent of #3 of the 12-Factor App
([https://12factor.net/config](https://12factor.net/config)).

You can extract config to various degrees. My example is perhaps the mildest:
just group it together, near the beginning. You don't need complex frameworks.
In fact this technique first caught my attention when I was reading other
people's shell scripts.

The next step would be to move the config to its own file. This is very common
in Linux. You have some tight binary, that is compiled and hard to change. But
then you have config files, often with dozens of options. It's a nice way to
do things.

The next step would be to move the config to a different level, no longer in a
simple file. This is often either a relational database or environmental
variables. Linux commands use environmental variables along with their config
files.

For very large systems, this technique is the same in kind, just different in
degree. You get fancy specialized systems, like Hashicorp Vault, to store your
configuration, at least your secret ones, like passwords and stuff.

------
MaxBarraclough
> There is nothing wrong with this function. Really. It does exactly what it
> should do with the least amount of code. In fact, this is probably what I
> want to deploy in production as well. But, it is inflexible.

It does one well-defined thing, and does it well! That's the good kind of
'inflexible'.

> A skillful programmer looks at the problem and says, hey, why don't we build
> an abstraction layer to make it more flexible?

In this example, the additional complexity just doesn't seem justified. You
ain't gonna need it. [0] Unnecessary abstractions cause bugs, bloat, and
baggage. The article then goes on to acknowledge this, but I really question
the chosen example.

> Just having these few abstractions opens up a lot of possibilities. Why?
> Let’s suppose that you have 3 different kinds of fetchers and 3 kinds of
> notifiers. Now, you can easily compose 3 x 3 = 9 different kinds of health
> checks.

You've just introduced an exponential explosion into your testing burden. The
pay-off: additional functionality that _might_ be useful later.

 _edit_ On reflection I suppose it's not a 'exponential explosion', it's
merely a 'multiplicative explosion'.

> Enjoy your programming life. It's a fun art!

The article doesn't go into detail on what it means here, but the more serious
the software work, the less the artistic mindset applies. [1]

I think the most sensible approach to software engineering is to draw
satisfaction from solving a challenging problem well. Things like 'programmer
freedom' strike me as false idols.

That said, I'm a sucker for elegance (a famously subjective commodity), so
maybe I'm a hypocrite.

[0]
[https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)

[1] [https://www.fastcompany.com/28121/they-write-right-
stuff](https://www.fastcompany.com/28121/they-write-right-stuff)

~~~
horsawlarway
Ding ding ding. I agree one hundred percent. This isn't elegant, this is
needlessly over engineered and now much more likely to slow development. The
biggest cost isn't lines of code, it's understanding abstractions.

What happens when an "abstractnotifier" blows up? Where does the error happen?
what are the possible side effects? What systems might be impacted?

What happens when 'alert's start failing? Is it queued/buffered? Do I need to
worry about OOM errors on systems? Will it retry?

I lead a team of developers - This kind of abstraction tends to slow
everything down. The only place it fits is during a refactor of software
delivering real business value already. Basically - You can do this if you
know exactly what your requirements are, and this nicely solves them.

If you do this before you understand EXACTLY what you need, you're going to be
wrong. You will abstract the wrong pieces, with the wrong assumptions. I
promise you. Then later you have to rip it all apart anyways, except now
instead of 4 simple lines with clear consequences, you have a bloated monster
of bad assumptions.

~~~
goostavos
>If you do this before you understand EXACTLY what you need, you're going to
be wrong.

The main problem with this is culture imo. I agree 100%, but it is so hard to
fight against the idea that "real engineering" or being a "good developer"
means tiers of abstraction.

To me, being a good developer actually means understanding what your operating
parameters are, and then writing the smallest amount of code that satisfies
the business requirement. Sometimes (a lot of times!) this DOES mean you have
to go back and refactor or completely throw away code. By _design_ you chose
to only solve the immediate problem. However, culturally, this is seen as a
failure rather than a success.

------
TheOtherHobbes
These articles reliably confuse art with craft and technique.

Art is about giving other people rich, engaging experiences that distill
and/or highlight some element of relatable human emotional, psychological,
and/or sensual experience.

The more unusual, original, and insightful the experience, the more
interesting the art.

Doing something difficult with elegance is not art. Solving problems is not
art. Complex but comprehensible systems that have "beauty" are not art.

If there's no emotional or sensual content, there's no art - just technique.

There's nothing wrong with technique, and art isn't better or worse than
technique on its own terms. But they're _different languages_ with different
goals.

Calling software abstraction "art" is like watching someone who has discovered
a for loop trying to persuade you they're an expert developer.

~~~
combatentropy
> Art is about giving other people rich, engaging experiences that distill
> and/or highlight some element of relatable human emotional, psychological,
> and/or sensual experience. The more unusual, original, and insightful the
> experience, the more interesting the art.

This is a great definition (and this is coming from someone who has studied it
for decades).

I wonder, though, if you're being too hard on the writer. _Art_ originally
meant the same as _skill_ or _craft_
([https://www.etymonline.com/word/art#etymonline_v_17037](https://www.etymonline.com/word/art#etymonline_v_17037)).
You can see it also in the word _artisan_ , which would likely be applied to a
cobbler or carpenter. I believe you are defining the _fine arts_ , which more
specifically refer to art purely for the sake of emotional expression, as
opposed to the more practical arts, like cabinetry.

Nowadays the sense of the word _art_ has narrowed more to what you're saying,
to what our forebears meant by _fine arts_. But it is not always used that
way. Many times I have heard people refer to common, practical activities as
requiring some "art". Or they might say that someone who does it with
exquisite taste has elevated the activity to art (like, cooking). This is even
though it wasn't about, as you say, distilling experience into some other
medium.

People loosely use the word _art_ any time that an activity presents some
options, any time there is a choice to be made, and a much better result
happens when you choose well. By this definition, almost anything could be
called an art, or at least could involve art. The only exceptions would be
things that are 100% formulaic, like maybe working an assembly line (even
then, I wonder if assembly-line workers distinguish some room for art in their
duties).

The two meanings continue to intermingle, because all of the arts take craft,
and all of the crafts take art. If you want to be a composer, painter, or
writer, there are skills to master (the musical scales, paintbrushes, sentence
structure). If you want to be a carpenter, chef, or architect, there are
always choices to be made, every project is unique in its own little ways.

My point is, your definition is very useful to anyone attempting fine art. But
I wouldn't attack people who use the word more broadly (and this is coming
from someone who likes writing and who often is irritated by imprecise
diction).

~~~
deltron3030
Boring means that it's predictable, something you'd expect or have seen
before.

In design you work towards a desired outcome, usually something that adresses
a group of people, and therefore a set of characteristics. The outcome can be
repeated, or changed in a predictable manner. That what lies between the
outcome and your intent is what design is obsessed with, process, templating,
decoupling from environmental factors, including your own personal
characteristics. Sounds like functional and good OO programming right?

Art is the opposite, it's obsessed about capturing unique outcomes,
originality. This means that what lies between the outcome and your intent is
also about the opposite, coupling unique personal and evironmental inputs.

Performing arts, or arts and crafts are more like design, outcome driven, it's
only that they can't remove human inputs because those are also expected to be
there.

------
rswail
I don't consider programming an art in the term of humanities (eg
painting/drawing/music etc) but more a craft (eg cabinet making,
stonemasonery).

There are assemblers, people that can follow a set of IKEA instructions and
end up with a reasonably stable bookshelf. The average starting developer out
of college is at this level.

There are journeymen programmers, they have a few years experience, understand
some of the nuances, know a bit about what doesn't work, can use the word
"strategy" both correctly and ironically.

Then there are master craftsmen, they understand the material they are working
with. Know when to use an IKEA wooden dowel and when a custom joint is
required. They build cabinetry that can be on display for its own inherent
structure and leverage the natural capabilities of the material.

The same applies to programming, both in the small and in the large.

~~~
qznc
Programming can be everything.

I agree that most programming is craftsmanship.

Code like the Obfuscated C Contest is art.

The code that orchestrates your cloud servers is more like engineering.

Prototypes in language research is science.

------
phkahler
One of the most beautiful pieces of code I've ever read is this:

[https://github.com/solvespace/solvespace/blob/master/src/srf...](https://github.com/solvespace/solvespace/blob/master/src/srf/ratpoly.cpp)

If you have a basic understanding of spline and NURBS surfaces but never knew
how you might actually implement that, well there it is. Incredibly readable
IMHO.

~~~
amelius
If you want to write truly beautiful geometric code, watch this:

[https://www.youtube.com/watch?v=tX4H_ctggYo](https://www.youtube.com/watch?v=tX4H_ctggYo)

Discussed here:

[https://news.ycombinator.com/item?id=22282452](https://news.ycombinator.com/item?id=22282452)

~~~
phkahler
I kid you not, I just watched that 2 days ago at the suggestion of a friend.
It will take more viewings and study to digest. Really amzing!

------
cheez
> A skillful programmer looks at the problem and says, hey, why don't we build
> an abstraction layer to make it more flexible?

No he doesn't

~~~
zelphirkalt
On the other hand looking into my internal glas orb and expecting the next
possible or useful use-case amd making my code flexible / abstract, while
keeping it readable, enough to also represent that use-case has saved me hours
time and time again.

I think there is something to say for not overdoing it, but for not mindlessly
implementing only the thing either. Thinking about what is the next
abstraction that includes the functionality your want to implement and also is
useful to implement anyway, because you already expect the need for
flexibility in a certain direction.

It depends probably on what type of software you write. Just a few procedures
in a legacy code or a little command line tool, standing on its own for
example.

Certainly implementing only "the thing" gets the job done though. Perhaps
doing more is doing more than what one is paid for.

~~~
cheez
I write code that lasts decades and I can promise you a glass orb is
unnecessary.

------
horsawlarway
I don't disagree with your title. I pretty strongly disagree with your
content.

You started with a simple solution that nicely handles the current needs.

You then over-engineered a solution so badly that you haven't even noticed the
'url' param isn't used in the last method you've shown.

You went from simple enough a junior dev can make meaningful changes, to
bloated enough the original author is fucking it up.

Don't do this. Wait until you actually have a REAL use case for adding
complexity.

~~~
tomkwong
OP here. Thanks for the note.

The intention to illustrate the power of abstraction. Based upon yours and
other people's comments below, perhaps it wasn't the best example.

I did correct the typo about 'url'. Best regards.

~~~
buzzkillington
A good rule of thumb is to abstract inherent complexity and not incidental
complexity.

Loggers are examples of incidental complexity. There is nothing fundamental
about sending the warning by email vs slack vs irc. The way to deal with this
is not to keep adding more and more options, because you end up with
combinatorial growth in the number of interactions, it's to make it company
policy that you only use email and discipline anyone who doesn't.

~~~
pdonis
_> There is nothing fundamental about sending the warning by email vs slack vs
irc._

I agree with this but I would put it somewhat differently. To me,
notifications are a separate service, and whatever options there are for
notification should be orthogonal to whatever is doing the notifying. If
company A's policy is that notifications only go by email, nothing else, while
company B has email, slack, and irc, that's for their respective notification
services to worry about, not for each individual application that is using the
notification service. To the application, it should be
send_notification(content, recipient) and that's it.

------
7373737373
[https://en.wikipedia.org/wiki/Asemic_writing](https://en.wikipedia.org/wiki/Asemic_writing)

[https://en.wikipedia.org/wiki/Artist%27s_book](https://en.wikipedia.org/wiki/Artist%27s_book)

~~~
tomkwong
Another way to express semantics is the use of Unicode in source code. For
example, I have this Julia package that performs Box-Cox transformation, and I
was able to use bold face for vector data and greek letters for the parameters
as found in research paper and literatures.

[https://github.com/tk3369/BoxCoxTrans.jl/blob/master/src/Box...](https://github.com/tk3369/BoxCoxTrans.jl/blob/master/src/BoxCoxTrans.jl#L37-L48)

~~~
klysm
I’ve been conflicted about using verbose names or symbols for mathematical
expressions in code, and I don’t think there’s an easy answer for when to use
them. For simple arithmetic expressions, it seems like verbose names are
superior because it’s easier to derive their meaning and we already understand
the operators at play. When translating complex expressions, however, we
usually a priori understand the meaning of the expression with our algebraic
mental model and it makes sense to use that nomenclature. At the same time
though, someone who is unfamiliar with the particular source of the algebra
used would find such code quite opaque. For something like the Box-Cox
transform I think it makes sense to use the symbols widely employed by the
mathematical nomenclature.

This certainly also depends on the language you are using and the ability to
define arbitrary in/postfix operations.

It’s also rather annoying to type them, but that’s also probably because I
just haven’t developed a workflow for it.

~~~
7373737373
>It’s also rather annoying to type them

I wonder how mathematicians do this, I suppose they use latex notation most of
the time, inputting ASCII which is formatted as the symbol instead of looking
up tables

------
Tade0
This brought me back to the time my SO tried to explain an 84 year old lady
she was assisting what is it that I do for a living.

The consensus was that I'm a writer.

Also there's one thing I ask everyone seeking to get into programming: "are
you resistant to boredom?"

This appears to be a good predictor of future success.

~~~
ironmagma
Hmm, interesting. I can’t tell, though, if that question means, “do you not
bore easily?” or “do you avoid boredom at all costs?”

~~~
Tade0
Something must have been lost in translation then. Pardon, I half of my
vocabulary was shaped by RPGs.

I was thinking of the former.

------
dkersten
> A skillful programmer looks at the problem and says, hey, why don't we build
> an abstraction layer to make it more flexible?

A skillful programmer doesn't add layers of abstraction unless there's a good
reason or need to.

~~~
JoeAltmaier
The article was presuming a need? Otherwise there's nothing to discuss.

Yes, pedantically this approach is only used in certain circumstances. Then, a
skillful programmer has a ready set of skills. And so on.

------
trmsw
Upvoting this just for the title ... and was disappointed by the article.
Rats.

~~~
tomkwong
Appreciate the upvote anyways LOL

~~~
trmsw
You're welcome. It's an attention economy these days

------
gherkinnn
> _How boring is it to produce something of the same shape over and over
> again._

Same applies to any text written. Yet, few people would argue there aren’t any
artists among novelists, screenwriters, and poets.

~~~
narrationbox
Does copywriting count as art? Or is it merely the equivalent of CRUD-style
boilerplate?

~~~
gherkinnn
Depends on your definition of art. Good copywriting must be a very skilful
trade. Not sure about the whole "must serve no purpose other than itself"
aspect.

------
mateusak
Any skillful programmer will tell you this is horrible. The 3 rules of thumb
of programming are:

1\. Paradigm purity is worthless 2\. You ain't gonna need it. 3\. Less
complexity is better.

You just broke all of them.

------
jerzyt
Git is art. All programming is a solution to a problem. Some of the problems
are very pedestrian and the solution is very boring. There have been many
version control systems before Git. I remember using SCCS, RCS, CVS, ClearCase
and finally Git came along, and just redefined the whole concept. Sure, the
CLI may be clunky at times, but the fundamental problem of version control is
solved. I suspect, that historically, Git may be considered as a bigger
accomplishment for Linus Torvalds than Linux. After all, Linux is a clean room
implementation of Unix, whereas Git is completely original.

~~~
frou_dh
I thought the origin story of Git was that Linus wanted to recreate the
workflow he had with BitKeeper after the Linux project lost access to it. I've
never touched BitKeeper so have no idea how similar they actually are.

------
7532yahoogmail
I find these kinds of near-journal-article-for-self fairly useless. If you
think our stuff is boring where'd you leave intel/amd etc doing statistical
process control in the domain of mother nature that's got the standard model
in her favor? More boring? Less? Or dumb question?

Abstraction is a sort of entropy / Shannon / Kormogorov issue. So let's
discuss it there not semi-liberal-arts school fogginess.

Folks let's please keep science in science. One day if QC gets commercial all
these flowery articles will disappear. QC is math based. We'll need to deal or
get left behind, and by then all this handwaving won't matter in the least.

Now, the other bad of software dev is that today's work is generously semi-
formal at best in commercial settings. Not because CS is art, but because
requirements gathering, human factors, corporate culture are strongly reactive
in the software realm, where mother nature is directly absent.

Here we could help each other to understand management and management us to
move this whole ediface along. And here less technical articles ala HBR work
well.

------
zabzonk
IMHO, alert() should be called at a higher level by something that calls
check().

------
tjchear
A bit tangential, but since OP mentioned abstraction, I'd like to add this:
One of the marks of a readable piece of code is that it does not mix different
levels of abstractions.

Here's a contrived example:

    
    
      if (a < b && c == d)
        createUserProfile();
    

Instead, do this:

    
    
      if (userIsAuthenticated())
        createUserProfile();

------
notsag-hn
When the developer is inexperient, programming is similar to art. You see
hacky stuff and sometimes "innovation" that a senior engineer would just call
dirty code. Senior engineers however don't do art unless they are explicitly
doing it like with computer graphics or other kinds or computer-based art
generation, or through movements like hacktivism that are certainly quite
poetic. Otherwise it's so far away from art, regular APIs aren't art,
databases aren't art, operating systems aren't art. Many engineers have the
need to call themselves artists, you should have taken drawing lessons if you
wanted to be artists because regular engineering for business is maintainable
just if it's as standard as possible and let me tell you that is the opposite
of art.

------
willjp
I was a commercial artist for 10 years. The same is true of art. In the visual
art world everything boils down to contrast. It may be colour, composition,
sequences of shots, silhouettes, animation, or otherwise - but at the end of
the day everything boils down to contrast. There is nothing mystical or
romantic about art. At the end of the day, it is just a set of rules of
manipulation/communication. I would say the same about programming. I find
programming more interesting and engaging, but that's just me.

~~~
sneilan1
Hey! I’m a person who’s really serious about transitioning from programming to
art. Can I pick your brain?

------
spicyramen
In college a teacher asked us if programming was an art. There is the element
of creation, copying and some may say beauty. The artist or programmer in this
case use their knowledge, creativity and experience to create something new
intangible and subjective appreciation but results can be life changing or
solve a really complex problem. In terms of boredom this is subjective
sometimes I find it really fun try to solve a problem or fix a bug

------
euske
I think that when you look at things at a microscopic-level, everything looks
boring and unoriginal. For example, every phenomenon on Earth (and beyond) is
just an interaction between atoms. Looks pretty boring.

As the OP mentioned, beauty is created by abstraction; an ability to look at
the bigger picture and make sense of it. So I agree that abstraction is the
most interesting thing in writing software.

------
alexashka
Life itself is boring art. Everything else is just an extension of that.

~~~
7373737373
Depends on your Serotonin level

~~~
alexashka
Does it? The only people I know who don't lead a boring life if you look at
what they do minute by minute, day by day, are fictional characters in books,
movies, etc.

That's why we like entertainment - because it cuts out the boring bits :)

The art part is more interesting. Is there art to someone's life? I'd say yes,
but that's because I'm artistic.

If you ask most people, they'll probably be confused by the question. Is your
life 'boring art'? 'Huh' is the answer I most expect :)

~~~
7373737373
I'll quote someone

>I can sympathize with a lot of nihilist outlooks on existence, but just
because a lot of these might be true, they're not the only ways you can view
your flesh or your place in these patterns, as an animal or as a cog in a
machine. There are other elements to existence, like imagination, that is a
good example. Emotions are a great vehicle for building your own universe and
reality, where your function as an animal or cog in a machine doesn't force
you into some rote role that drags you into this stripped down reality of
raison d'être being purely utilitarian and unchangeable. You mentioned
imagination, but emotions make things real. Does it really matter if your
imagined reality isn't concrete or factual? What matters is your happiness,
right?

------
cutler
Good Clojure and Ruby code, in that order, is the closest to art. Structure
and Interpretation of Computer Programs (SICP) also deals with abstraction so
elegantly you could consider it art.

------
DyslexicAtheist
programming isn't art. it's "life imitating art imitating life"

------
gorpovitch
When I hear people talking about programming as an art, I usually assume that
the decisions they make about their code tend to be about how elegant and
beautiful it is, not efficient and valuable. It's fun and satisfying to write
elegant code, but your company hired you to produce value, not art.

~~~
saagarjha
Elegant and beautiful things are often also efficient and valuable.

~~~
combatentropy
Paul Graham agrees:
[http://www.paulgraham.com/taste.html](http://www.paulgraham.com/taste.html)

~~~
MaxBarraclough
> what does Hardy mean when he says there is no permanent place for ugly
> mathematics? He means the same thing Kelly Johnson did: if something is
> ugly, it can't be the best solution. There must be a better one, and
> eventually someone will discover it.

I don't think Hardy's take really stands up today. There is at least one
mathematical fact which has been proven through exhaustive computerised tests,
and which no-one has (yet) been able to prove without using computers.

Ugly? I suppose so. Is there a 'place for it'? I don't see why not.

[https://en.wikipedia.org/wiki/Four_color_theorem#Proof_by_co...](https://en.wikipedia.org/wiki/Four_color_theorem#Proof_by_computer)

