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.<p>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:<p><pre><code> response = HTTP.get('https://www.example.com/');
if (response.status !== 200) {
email('someone@example.com', 'something is wrong');
}
</code></pre>
Instead of abstracting this into more general functions, I might simply move the literals to the top of the file:<p><pre><code> 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);
}
</code></pre>
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.<p>Is there a name for this kind of refactoring?
> 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.<p>It does one well-defined thing, and does it well! That's the good kind of 'inflexible'.<p>> A skillful programmer looks at the problem and says, hey, why don't we build an abstraction layer to make it more flexible?<p>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.<p>> 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.<p>You've just introduced an exponential explosion into your testing burden. The pay-off: additional functionality that <i>might</i> be useful later.<p><i>edit</i> On reflection I suppose it's not a 'exponential explosion', it's merely a 'multiplicative explosion'.<p>> Enjoy your programming life. It's a fun art!<p>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]<p>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.<p>That said, I'm a sucker for elegance (a famously subjective commodity), so maybe I'm a hypocrite.<p>[0] <a href="https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it" rel="nofollow">https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it</a><p>[1] <a href="https://www.fastcompany.com/28121/they-write-right-stuff" rel="nofollow">https://www.fastcompany.com/28121/they-write-right-stuff</a>
These articles reliably confuse art with craft and technique.<p>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.<p>The more unusual, original, and insightful the experience, the more interesting the art.<p>Doing something difficult with elegance is not art. Solving problems is not art. Complex but comprehensible systems that have "beauty" are not art.<p>If there's no emotional or sensual content, there's no art - just technique.<p>There's nothing wrong with technique, and art isn't better or worse than technique on its own terms. But they're <i>different languages</i> with different goals.<p>Calling software abstraction "art" is like watching someone who has discovered a for loop trying to persuade you they're an expert developer.
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).<p>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.<p>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.<p>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.<p>The same applies to programming, both in the small and in the large.
One of the most beautiful pieces of code I've ever read is this:<p><a href="https://github.com/solvespace/solvespace/blob/master/src/srf/ratpoly.cpp" rel="nofollow">https://github.com/solvespace/solvespace/blob/master/src/srf...</a><p>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.
> A skillful programmer looks at the problem and says, hey, why don't we build an abstraction layer to make it more flexible?<p>No he doesn't
I don't disagree with your title. I pretty strongly disagree with your content.<p>You started with a simple solution that nicely handles the current needs.<p>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.<p>You went from simple enough a junior dev can make meaningful changes, to bloated enough the original author is fucking it up.<p>Don't do this. Wait until you actually have a REAL use case for adding complexity.
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.<p>The consensus was that I'm a writer.<p>Also there's one thing I ask everyone seeking to get into programming: "are you resistant to boredom?"<p>This appears to be a good predictor of future success.
> A skillful programmer looks at the problem and says, hey, why don't we build an abstraction layer to make it more flexible?<p>A skillful programmer doesn't add layers of abstraction unless there's a good reason or need to.
> <i>How boring is it to produce something of the same shape over and over again.</i><p>Same applies to any text written. Yet, few people would argue there aren’t any artists among novelists, screenwriters, and poets.
Any skillful programmer will tell you this is horrible. The 3 rules of thumb of programming are:<p>1. Paradigm purity is worthless
2. You ain't gonna need it.
3. Less complexity is better.<p>You just broke all of them.
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.
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?<p>Abstraction is a sort of entropy / Shannon / Kormogorov issue. So let's discuss it there not semi-liberal-arts school fogginess.<p>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.<p>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.<p>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.
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.<p>Here's a contrived example:<p><pre><code> if (a < b && c == d)
createUserProfile();
</code></pre>
Instead, do this:<p><pre><code> if (userIsAuthenticated())
createUserProfile();</code></pre>
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.
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.
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
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.<p>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.
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.
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.