The part I like is bringing coding back to results.
But the comparison of "coding as results only" vs "writing as expression only" is a strawman.
Professional Writers write to earn a living, persuade, inform or entertain, probably choosing two or three of those as much as possible. If you don't have readers and you don't entertain persuade or make a living, your writing has failed by the same metric your Professional Coder's code has if it failed to solve the problem.
But in the personal / semi professional worked, writing for its own sake is called practice, as is coding for its own sake. Neither of those have intrinsic value, beyond learning, and if something good results, then sharing.
Code is like words. If they don’t make a complete whole, you’re not doing it right. You can have the most beautiful words and even sentences, but if you have no story or convey no information, you have completely failed to produce anything of worth.
For me, it’s the end result, the resilience of what I have made, that matters.
You can get caught up in the elegance of any level. You can have a perfect, beautiful product and miss the market. Maybe something uglier works better than your art piece for a company's purposes.
Agree that we shouldn't invest ourselves emotionally too much in outcomes beyond the code: there are too many arbitrary and non-technical factors that go into the success or failure of a given software project.
However, code beauty is the game within the game of software, and should be pursued for its own sake. Beauty is subjective to an extent, but if you aren't at least trying for beautiful code you aren't fully actualizing yourself as a programmer.
Everything said rests upon this. And this is an incredibly present view of programming.
And it's just so hogwash, to me. There's infinite paths we can take in programming to make something happen. Winnowing our view to only consider whether technically we have checked the box or not, blinding ourselves to how we win, disregarding countless other tangible and intangibles: it's an oppressive curse against the craft.
Craftsmen are capable of grappling with the intangibles; they use taste to pick paths that have internal elegance, legibility. They spawn architectures that perform well, atop a selection of apt tools and libraries from a wealth of known options, and which can be worked and reworked on as needed.
You can ignore every cofactor of production at your own risk, but the intangibles of how we win often matter, are an ever expanding horizontal and vertical depth of systems which will create path dependencies for all work going forward. People who focus only on immediate does it work outcomes rob us of vision and dream and short the real journey, which isn't ticket by ticket, but is something whole and bigger, is many components which to work well together require your skill at thinking and imagining comprehensively.
Beauty is something to strive for, it is just not the purpose of business programming. Unless you are Dijkstra.
The annual Genuary art project is a great example of code as expressive writing.
If someone is paying you to make something, you are almost always creatively limited. You are not making what you want, you are making what you think they want. If you end up being wrong about what they want, it goes in the trash; Code or not.
If you want to code for fun, or code as a creative outlet, code for yourself. Make very small and achievable projects. If you are more of a C/embedded person, try demoscene.
The issue, like more academic writing (or music composition for that matter), is that to be able to appreciate those works, a certain level of specific knowledge is required.
It doesn't have mass appeal, but it is a creative process.
Even when doing for hire work, where the value is clearly on its usefulness, we still have the notion of "elegance" (which is a form of beauty).
Where some truly clever construction solves a problem in a surprising yet pleasing way.
Coming up with that novel way of attacking the problem it a purely creative endeavor (although bound by the constraints of the problem at hand).
Unless you're into code golf or other forms of "art", a software developer is first and foremost a craftsperson, depending on the position maybe even an engineer, leader, or scienctist.
Ideally you build things you're proud of, because they're useful and maybe even beautiful and masterfully crafted.
Anyone can write anything, but to be called a program or a piece of literature there are some requirements to be met.
There are repos everywhere with code about as useful as this author's writing.
Similarly writing can be used for non-artistic and more practical purposes.
I just see so many counter examples I wonder if I'm missing the point.
I'd like to expand your artistic vs practical point by denying that really is a dichotomy, at least not in practice.
I've done lots of creative writing, and most of what matters in that domain is solving really pragmatic problems: is this metaphor clear? In what order should the reader receive this information? How can I get exposition across in a way that isn't distracting? Do these words go together well? Viewed askance, those (and infinitely more) are all constraints (many self-imposed, or at least self-perceived), that allow "art" to happen, and define the terms on which it succeeds.
For my job-job I do lots of pragmatic writing, too - think documentation and technical analysis - and I do my damndest to find "creative" ways to present material. I'll write things like "this next bit is really technical, if you're not in roles X, Y, and Z you might as well skip to the next page. For those of you who have to read this, imagine you're a squirrel", and then name all the variables after a type of nut. It's makes it more fun for me to write, sure, but the actual, pragmatic reason is that more people read and understand it when I put in effort to make material less dry.
(I realize some people on HN would be terribly offended by that last example, and think I'm insulting their intelligence by being "cute", and "why can't he use Σ, like Euler intended?" Well, you're not my audience - or, at least, not the most important among my day-job audience. In other words, if that's you, imagine you're a nut.)
It's a good mindset to have and I absolutely agree with most of the article when it comes to non-recreational programming. I generally think it's a little pretentious to call code "elegant" or likewise.
> Once I internalised this, I stopped caring about clean code, perfection, and judging the value of my apps myself.
I struggle to relate to this though. I believe good code is a means to make it easier to make a product better and ship faster. Hell, I agree it doesn't have to be "clean" but I couldn't bring myself caring about it altogether.
P.S. Well coding might not be art but it can absolutely be used to make art. The tldr (without the context of making SaaS) is incorrect in my viewpoint.
[edited for clarity]
Re: > Once I internalised this, I stopped caring about clean code, perfection, and judging the value of my apps myself.
I think I meant shifting more to customer centric valuation. Should have been more clear.
