Writers can write anything. Programmers can't(mahendraker.com)
mahendraker.com
Writers can write anything. Programmers can't
https://www.mahendraker.com/blog/writing
23 comments
I write stories for fun. They are never read by others, and most of them end up lost forever to old hard drives. I also enjoy programing fun and useless things, even stuff like pathfinding algorithms. I'll never actually use them over a simple library, but I enjoy doing it. This person seems to be more focused on other people valuing their work, in which case the thesis is even more wrong.
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.
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.
Computers can write random text, and that is not considered literature (unless we are in the infinite monkey problem). To be called literature, it must “run”, in the same way as code, but in our brains. It must rhyme if is poetry, must be accepted by an editor, must be liked by its readers, be coherent and so on.
Anyone can write anything, but to be called a program or a piece of literature there are some requirements to be met.
Anyone can write anything, but to be called a program or a piece of literature there are some requirements to be met.
Code with no users seems roughly equivalent to writing with no readers to me. Or possibly unpublishable writing.
There are repos everywhere with code about as useful as this author's writing.
There are repos everywhere with code about as useful as this author's writing.
[deleted]
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.
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.
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.
Beauty is something to strive for, it is just not the purpose of business programming. Unless you are Dijkstra.
Definitely – I guess I was going for "building product" more than writing code.
Requirements are important and some organizations and all kind of engineers struggle to define or follow them. However I don't agree with the article that one has to choose between creativity vs defining and following requirements. There is space for both and the context of the business will clarify the most suited balance.
I think you can make art out of just about anything. Constraints and limitations add to art, not detract. I'm certain plenty of people add artistic flourishes into their work. There's no shortage of code used to create art. The code itself can be artful as well.
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.
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'm with you on this.
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.)
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.)
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.
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 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 was thinking of adding that line! "Kill your darlings" is like kill the weak products that make no value!
> The app isn’t a representation of me, it’s not a measure of how smart, dumb, or successful I am. It’s just an attempt at creating value.
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]
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]
Definitely heard – tldr was absolutely only in the context of "building product".
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.
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.
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.
The annual Genuary art project is a great example of code as expressive writing.
> 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.
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.
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.
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.
There are forms of coding that resemble art, they elicit feelings, but that's true of math also.
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).
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).
> 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.
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.