Resonates. The concept is basically that written word may inspire or produce joy, but code is about producing results, so no results means no real value.
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.
Heard definitely. I guess I was trying to liken "building product" to "writing a passion piece". Definitely not all writing vs all coding should have been more clear.
Yeah… I’m both a software developer and an author. This is crap.
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.
> I’ve fallen into this trap so many times (Grapevine, Venyu, etc). But now, I think I’m finally out. There’s one key change I made to escape this cycle: I remind myself that I’m not an artist, and coding isn’t creative expression. There should be no huge emotional investment or pursuit of beauty in shipping SaaS, so I need divorce myself from the end result.
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.
> The objective metric for value is varying degrees of “was my problem solved”.
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.
I appreciate measuring productive when profit is the objective. Still, there exists code that does resonate and evoke emotional response. Quines, code golf, adding a paradigms to a lisp in a few lines of code, categorical haskell or the Doom wtf algorithm.
Beauty is something to strive for, it is just not the purpose of business programming. Unless you are Dijkstra.
I get that this is beside the point, but it might make the author to feel better to know that writers are no less prone to same character flaw of becoming overly attached to their own implementation of an idea, often to their detriment in the marketplace. Hence the common advice to writers that you must "kill your babies".
I disagree. It's not a matter of whether a problem was solved or not solved. Problems can be approached in different ways. What structures and design patterns someone used, what approach they took to solving a problem can certainly be expressive.
The annual Genuary art project is a great example of code as expressive writing.
Shallow interpretation. The difference is merely in the number of steps in between the words, and the impression they make. Code has a couple compilation steps before it reaches the brain.
Readit News
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.