On Authorship and Style (1860)(ebooks.adelaide.edu.au)
ebooks.adelaide.edu.au
On Authorship and Style (1860)
https://ebooks.adelaide.edu.au/s/schopenhauer/arthur/essays/chapter1.html
12 comments
I like this essay a lot. But the hn title is incorrect. Article title is "On Authorship and Style" (1860). OP, if you want to discuss this as it applies to programming, it would be much better to leave a comment to that effect than to mislead with the title.
Submitted title was "Difference between ordinary and top programmers according to Schopenhauer". That of course broke the site guidelines, but the submitter has since corrected the problem. Let's get on topic now!
The discussion seems to have dried up. Change the packaging and you change the quality of the product, it seems. At least the perceived one.
I was afraid that this might happen. It happened in the past. So I thought about a good title that would summarize why I though this essay is relevant for this community and I was hoping for some discussion and impressions about it. It did generate some controversy but for the wrong reasons (i.e. the title). At least it was read and taken into consideration. I still think this is a very nice write-up from ~200 years ago about what it means to create something from basically nothing (from pure thought, that is), which programming is clearly a sub-field of.
Searching through HN, I'm seeing this exact link posted a week ago, with zero comments and upvotes. It gathered 10 comments and 20 votes in half an hour with the modified title, none with its original title.
Thank you for your quick response and for unflagging this post.
I was afraid that this might happen. It happened in the past. So I thought about a good title that would summarize why I though this essay is relevant for this community and I was hoping for some discussion and impressions about it. It did generate some controversy but for the wrong reasons (i.e. the title). At least it was read and taken into consideration. I still think this is a very nice write-up from ~200 years ago about what it means to create something from basically nothing (from pure thought, that is), which programming is clearly a sub-field of.
Searching through HN, I'm seeing this exact link posted a week ago, with zero comments and upvotes. It gathered 10 comments and 20 votes in half an hour with the modified title, none with its original title.
Thank you for your quick response and for unflagging this post.
I am in favor of people using titles that reflect what they think will be of interest to HN readers. I know the line between that and editorializing is not always clear, but that's a fact of life.
Often an interesting article will have a misleading title for SEO reasons. Seems like those are appropriately rewritten for HN submission.
Or imagine (I'm making this up) an article in the NYT entitled "Senator presses tech firms to supply encryption keys". Yawn...I've seen that for literally decades. But it turns out that the senator drew their analysis upon specifically bad info by relying on an article in wired or maybe a non-law enforcement-specific lobbying group, but one that turns out to have been funded by google. Then a title that called out the specific reason its relevant to HN would be useful.
(This is a totally made up example; I don't mean to diss wired nor google in this post).
Often an interesting article will have a misleading title for SEO reasons. Seems like those are appropriately rewritten for HN submission.
Or imagine (I'm making this up) an article in the NYT entitled "Senator presses tech firms to supply encryption keys". Yawn...I've seen that for literally decades. But it turns out that the senator drew their analysis upon specifically bad info by relying on an article in wired or maybe a non-law enforcement-specific lobbying group, but one that turns out to have been funded by google. Then a title that called out the specific reason its relevant to HN would be useful.
(This is a totally made up example; I don't mean to diss wired nor google in this post).
Agreed, I thought the link was incorrect.
That's about authors, and using that metric, most of what we code is "half-true, perverse, forced, and vacillating".
I don't disagree, I just think it's a stretch to apply it to code - and not the good kind of stretch, more like the kind of stretch where you really want the german philosopher to have written about you so you'll go through all sort of lexical excercises to make it happen.
I don't disagree, I just think it's a stretch to apply it to code - and not the good kind of stretch, more like the kind of stretch where you really want the german philosopher to have written about you so you'll go through all sort of lexical excercises to make it happen.
This hits hard based on my experience in academia.
In graduate school I was strongly advised to set aside "big" problems and focus on safe low-hanging fruit--derivative projects or incremental improvements to existing work--that will result in a steady stream of (mediocre) publications. The situation is the same for postdocs and even tenure track faculty at research-focused institutions. Only after you get ~15 years into your research career (and receive tenure) are you really free to focus on original work, which tends to be high risk and high reward.
(Of course you can do that earlier, but there's a high chance your career won't advance on schedule, which is very bad.)
In graduate school I was strongly advised to set aside "big" problems and focus on safe low-hanging fruit--derivative projects or incremental improvements to existing work--that will result in a steady stream of (mediocre) publications. The situation is the same for postdocs and even tenure track faculty at research-focused institutions. Only after you get ~15 years into your research career (and receive tenure) are you really free to focus on original work, which tends to be high risk and high reward.
(Of course you can do that earlier, but there's a high chance your career won't advance on schedule, which is very bad.)
It's a huge stretch to retitle "On Authorship and Style" to "Difference between ordinary and top programmers according to Schopenhauer"
I would argue that writing code is equivalent to writing, in general. As in prose, you're exploring a subject known to you. You've though about the problem at hand, you've come up with a solution after a lot of going back and forth, you're now trying to impart this knowledge to other humans. As such, you have to be clear about what you're saying, going straight to the solution and not go round the thought and cover it up. That is, if you actually do have something interesting to say about it, and you're not thinking about gaining likes or money or fame from it.
I've seen some projects lately with many people involved and months or years of development time invested in them, that I, an average programmer at best, was able to solve with a few days work and with at least an order of magnitude less paper used.
[..]they put what they have to say into forced and involved language, create new words and prolix periods which go round the thought and cover it up. Moreover, they write down words, nay, whole periods, which mean nothing in themselves, in the hope, however, that some one else will understand something from them.
I've seen comments and READMEs, for example, that have the exact same attitude to them, that is, they are written in the hope that someone else will understand them but the writer actually didn't, he doesn't understand why the project might be useful to someone else. I've seen big frameworks used, tests conceived, build methods and CI implemented but where the actual substance of the project was missing. Dozens of git branches and complex merging good-practices for projects with at most a few thousand lines of code and 2 or 3 developers only because someone else might look at it and see what a good job we've done. These projects usually don't solve much, but they sure talk a lot about how nice it is and how it will solve lots of problems for its users.
Nothing else is at the bottom of all such endeavours but the inexhaustible attempt which is always venturing on new paths, to sell words for thoughts, and by means of new expressions, or expressions used in a new sense, turns of phrases and combinations of all kinds, to produce the appearance of intellect in order to compensate for the want of it which is so painfully felt.
As years go by, I really feel that one, if not the most important skill in this field, is knowing how to write, how to cleanly and clearly express your thoughts that you yourself have about the problem and your ideas about the solution.
I've seen some projects lately with many people involved and months or years of development time invested in them, that I, an average programmer at best, was able to solve with a few days work and with at least an order of magnitude less paper used.
[..]they put what they have to say into forced and involved language, create new words and prolix periods which go round the thought and cover it up. Moreover, they write down words, nay, whole periods, which mean nothing in themselves, in the hope, however, that some one else will understand something from them.
I've seen comments and READMEs, for example, that have the exact same attitude to them, that is, they are written in the hope that someone else will understand them but the writer actually didn't, he doesn't understand why the project might be useful to someone else. I've seen big frameworks used, tests conceived, build methods and CI implemented but where the actual substance of the project was missing. Dozens of git branches and complex merging good-practices for projects with at most a few thousand lines of code and 2 or 3 developers only because someone else might look at it and see what a good job we've done. These projects usually don't solve much, but they sure talk a lot about how nice it is and how it will solve lots of problems for its users.
Nothing else is at the bottom of all such endeavours but the inexhaustible attempt which is always venturing on new paths, to sell words for thoughts, and by means of new expressions, or expressions used in a new sense, turns of phrases and combinations of all kinds, to produce the appearance of intellect in order to compensate for the want of it which is so painfully felt.
As years go by, I really feel that one, if not the most important skill in this field, is knowing how to write, how to cleanly and clearly express your thoughts that you yourself have about the problem and your ideas about the solution.
> I've seen some projects lately with many people involved and months or years of development time invested in them, that I, an average programmer at best, was able to solve with a few days work and with at least an order of magnitude less paper used.
Are any of said software projects open source or otherwise well known? I've often gotten the same feeling but haven't gone so far as to reimplement and prove out my intuition.
Are any of said software projects open source or otherwise well known? I've often gotten the same feeling but haven't gone so far as to reimplement and prove out my intuition.
My first take on opening the link is "Wow! What an amazingly readable page."
(This on a mobile tablet.)
If but that more of the Web were like this.
(This on a mobile tablet.)
If but that more of the Web were like this.
The essay itself is also, of course, excellent. I've not previously read Schopenhauer, my error.
For those interested in the German original, this is "Über Schriftstellerei und Stil". It can be found at http://aboq.org/schopenhauer/parerga2/stil.htm (not as beautifully rendered, though).
big, brimming smile This essay reminds me of Emerson's essay "Character" and lecture "The American Scholar."
The article describes Management books, startup guides, and self help books to a tee! Wonderful read and should be read by all students.
I think that programming is a bit more complex. You see I get the difference between the "coder" and the person who cares about adding value and creating something that others will use. The industry needs both "good coders" and "creating thinkers" to move forward and its hard, ofc, to find someone who is able to use all of those parts of the brain. Probably there is a 3rd category of people who are here just for the $ :)
The linked article is not about programmers or programming
> Everyone who does things I don't like is bad
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newsguidelines.html