All the humming and hawing about how the author of the post is taking credit for someone else's work, etc, is a good example of the problem of reading one-off things on the internet and commenting on them here without understanding the context or the voice of the author.
As a long-term reader of that blog, it is obvious to me this is a little historical anecdote, mostly tongue-in-cheek, from a particular mac-centric community to which both the author and Gruber belong to. He's not being grandiose or trying to take credit.
Someone [1] recently put it very insightfully, that it was impossible to post things candidly on the Internet because your in-group shared background/assumptions aren't shared by randos on the internet that will come across your post and misinterpret it.
(I'm pretty sure this was linked on HN, but it's too vague for me to search/find it)
The theorists call this "context collapse". A huge part of human communication is about what went before, where and when the communication happens, and what the speaker and listener know about each other and what kind of shared experiences they have.
But as the old saying goes, "On the Internet, no one knows you're a dog"
The same thing applies to standup comedy. A good 80% of standup is presentation, delivery and context.
When you take all that out and read what the comic said verbatim with a completely flat newsreader inflection, it will sound really strange and maybe even offensive.
Sounds just like what the author could expect from a discussion in a community which is not the same community they usually find themselves in ("a particular mac-centric community", whichever that refers to).
Strangers on the internet will come across your little random story if it's public, and rather than blaming first-time readers for not understanding the context nor the voice of the author, maybe the author could adjust the article to provide the context or make the voice stronger/more obvious?
Honestly, I'm fine with not understanding everything from communities I don't generally hang-around, it's bound to happen at one point or another.
> Strangers on the internet will come across your little random story if it's public, and rather than blaming first-time readers for not understanding the context nor the voice of the author, maybe the author could adjust the article to provide the context or make the voice stronger/more obvious?
I'm not "blaming" anyone. I'm just pointing out that the commenters here are missing the point of the story because they don't understand the context, and that this is a fairly common phenomenon.
I think it's fine to tailor your writing to a community of like-minded readers rather than a first-time reader from here that is unlikely to come back.
> Honestly, I'm fine with not understanding everything from communities I don't generally hang-around, it's bound to happen at one point or another.
Me too, of course. It just makes a discussion without that context, i.e., what's happening here, detached from what the author meant with the post.
> Sounds just like what the author could expect from a discussion in a community which is not the same community they usually find themselves in ("a particular mac-centric community", whichever that refers to).
The author of the blog post did not submit the article to Hacker News.
Anyway, I wish that HN commenters would apply the same HN guidelines to article authors that they do to each other. It's all too easy to rip on someone who isn't here to explain or defend themselves. https://news.ycombinator.com/newsguidelines.html
That's how the web ends up filled with pablum that offends none but the most easily offended, but draws in the most eyeballs and most upvotes/likes/retweets to become viral.
To be fair, it’s posted to hundreds of people that read a headline expecting one thing, didn’t get it, and don’t understand the humor part of this random blog they just went to. It’s a risky post — almost setup for those kind of comments.
> Anyway, it was during a digression—actually a digression within a digression— that Gruber talks about code blocks in Markdown and how one of his favorite features is that you don’t have to escape anything in a code block. You can paste source code directly into your Markdown document without any changes, and it will appear as expected in the rendered HTML.
True enough as far as it goes but, if you use that Markdown in some static site generators (SSGs), you may still have to massage it a bit so the SSG output won’t be borked. For a couple of examples:
- In Eleventy and Jekyll (and maybe others), you often have to wrap code blocks in `{% raw %}` and `{% endraw %}`.
- In Hugo, if you're including anything that Go initially “thinks” is real code rather than just a reproduction thereof, you must put comment characters around it: `{{< this >}}` isn't OK, but `{{</* this */>}}` is (and will display in Hugo as the desired `{{< this >}}`).
I help maintain some open source projects, and I totally disagree. Filing bugs (or thoughtful feature requests) is absolutely a contribution, and I wish more users would do so.
Edit: In fairness, I think some of the ways the author describes it are grandiose ("my extremely important contribution"), but I interpreted them as hyperbole.
> . You can paste source code directly into your Markdown document without any changes, and it will appear as expected in the rendered HTML. That’s my doing.
It makes it sound like the author of this blogpost actually did the change, while in reality they suggested the change. Of course it's good to suggest something, and even nicer when whoever you suggest it to implements it. But I'd never claim "that's my doing" after suggesting any features/fixes.
A bit like writing an email to Apple suggesting something, then they do that thing and I wrote a blogpost saying "That's my doing, I was there first. And you’re welcome.". It just doesn't taste well.
If a candidate were to say “that’s my doing” when describing the outcome of a prior team project, and language barriers weren’t a mitigating factor, I would consider that a significant red flag for ego. Not a crime, and a reasonable exaggeration in many circumstances. But I wouldn’t want someone communicating that way in a professional capacity on an engineering team.
Well it’s a good thing drdrang was just posting a missive on his blog and not in a job interview with you. But I guess if he does ever interview with you, you’ll remember his tongue-in-cheek missive and be dismissive, even if if never comes up in conversation.
That’ll show ‘em! Never write tongue-in-cheek blogs or else random weirdos who will never meet you will write you off as a candidate for an engineering team that doesn’t exist and that you don’t want to join in the first place.
> If a candidate were to say “that’s my doing” when describing the outcome of a prior team project,
"I made that" is the ultimate statement of pride in work. Taking that away is a really awful anti-pattern in management. Let your people be proud of their contribution, and equally proud of the product of the team. The work of a team is the sum of the contribution of all members.
> a reasonable exaggeration in many circumstances
I find people who take credit for the work of the team to be a lot worse than people who take pride in their contribution to the team.
By no means am I saying that "I made that" is a bad thing when it's true! It's vital to lionize people for the work they individually do, and encourage them to take pride in that work themselves.
But if they use the same language to describe the entirety of a team project, not just their contribution, as "my doing" alone, that often crosses a line into toxicity in the ways you mention in your second paragraph.
I found a bug on a tutorial found in raywenderlich.com and sent a fix proposal. But I wasn’t even acknowledged. I wonder how I should proceed about it. Or this is just normal to open source projects.
Had this one project where I converted it over to python 3 in a fork and they merged the whole thing without a mention of where they got it from. Kind of sucks but ultimately didn’t matter because I was doing it for my own usage. Plus it made my life a little easier because I didn’t have to maintain it separately, just fire and forget a bug fix whenever it came up.
If I was doing Resume Driven Development I would probably care a little more though.
Some credit as the motivator of the fix is deserved. The author very clearly states:
Undoubtedly, as Markdown became more popular, someone else would have pointed out this problem. Gruber himself would have been annoyed by it if he ever needed to write a code block with backslashes in it. But I was there first. And you’re welcome.
I don't think they are trying to take more credit than is due.
But also
> You can paste source code directly into your Markdown document without any changes, and it will appear as expected in the rendered HTML. That’s my doing.
In that sentence, it kinda does sound like they're trying to take credit for it.
There is an entire article. There doesn't need to be just one sentence plucked out of context.
"I pointed this out in the Markdown mailing list, and Gruber agreed that it should be changed. In the next Markdown release—which was, I believe, his last—he made the change, and all the text in code blocks has been treated literally ever since."
What's wrong with that? He said what he did, said who fixed the issue, and stated the result.
It is their doing - they started the series of events. It's other people's doings ALSO. This sentence doesn't imply exclusivity, it just doesn't say others did stuff. Fortunately the entire rest of the document, particularly the part I highlighted above, makes it very clear:
1. what their doing is in more specific detail
2. what others' doings are in more specific detail
I'm going to assume that the author included all that additional detail in the document on purpose, and with the intent of clarifying what "That's my doing" entails. It seems pretty unlikely that your hypothesis of "the person is claiming the whole thing is their doing and accidentally wrote a whole bunch of words undermining that simple sentence" is the right one.
Or maybe the reader can do better than isolate a sentence out of context and assume bad intent. It’s obvious this is not to be taken seriously. It’s a few paragraphs on a blog, FFS.
I personally read it as a tongue-in-cheek boast where the author's intent was to clearly indicate that their contribution was minimal and they just happened to be the first person to point something out to the developers of the library.
It is still a contribution, which is what the title is. It did not say "my feature implementation in Markdown". A good feature suggestion which is thoughtful and genuinely improves a product not just for that one user but for everyone is a great contribution.
Right. That's why I can claim that my biggest contribution to Firefox is suggesting indicating the estimated reading time at the top of an article in reader mode. I'm the one who made the feature request [0].
It took some time, but they finally implemented it and I felt (and still feel) very good about it :)
I think the claim "that's my biggest contribution to X" is fine, if you feel like that was what you think is the biggest contribution you made to X.
Where it starts to feel wrong, would be if you somehow started claiming "I suggested it first. It's because of me it's there. You're welcome", when you merely suggested the feature, not implemented or drove it to be implemented.
> Undoubtedly, as Markdown became more popular, someone else would have pointed out this problem. Gruber himself would have been annoyed by it if he ever needed to write a code block with backslashes in it. But I was there first. And you’re welcome.
I don't see how he's taking responsibility for fixing the bug. To me it just sounds like he's sharing an anecdote and this is not entirely serious.
I've made a few languages in my time, both programming languages and markup languages. One of the most valuable kinds of contributions is spotting design mistakes, suggesting good changes, and being a discussion partner about design-related stuff. I'd bet that in this case, the change to the parser code would be trivial; the hard part is getting the design right.
Isn't that either a presentation issue or a feature? I prefer numbering lists with a sequence of 1., 1., 1., 1., to let the computer automatically increment the number. Makes adding/removing items easier. Being able to arbitrarily change the numbering seems weird, though potentially useful.
> code blocks (4 spaces) over code fences (```)
Not sure why this is a design mistake. When reading technical documentation, indented stands out more. IMO, it improves readability for short snippets (where syntax highlighting doesn't matter).
Did you know you can embed code blocks in HTML without escaping anything? You put them inside <script> tag with type="text/html". Then you style such tags to be visible and preserve whitespace. E.g.:
<script type="text/plain">
> hello world <- this is legal
</script>
I supported an effort to standardize Markdown into an actual common syntax, instead of the nasty variation we see between GitHub, Reddit, Stack Overflow, Atlassian, etc. etc. This became CommonMark, which everyone ignores.
What? No. Writing a well-spec’d feature request with clear outcome and behavior expectations is work. Just asking, “Wouldn’t it be cool if ____?” is not actual work.
If the feature is simple enough, it is possible to illustrate it in a few sentences. I am just speculating at this point, but if the discussion went like "hey, I think in Markdown, if the users enters a code-block, we should treat everything literally and not escape anything. This way users can just copy-paste code and expect it to render exactly like the raw text".
This is clearly spec'd and has clear expectations on how it should behave. No implementation details of course which you wouldn't expect from a product manager in most cases as well.
That little asterix on "without any changes" is doing a lot of work.
> The code block has to be indented, of course, or—in many implementations, but not Gruber’s—surrounded by fences.
Indenting is always a nuisance and can present more complicated problems for Python or other whitespace-significant languages.
CommonMark and most Markdown flavors support 3 backticks or 3 tildes as a fence. Then everything inside is literally unaltered code. Not sure what you do if your code sample itself has the fence in it.
With these things, I always think "but if he hadn't done it, someone else would". Therefore, what matters is the thing that got done; the person doing it isn't special (nor should they feel so).
> Undoubtedly, as Markdown became more popular, someone else would have pointed out this problem. Gruber himself would have been annoyed by it if he ever needed to write a code block with backslashes in it.
People are overreacting to a tongue-in-cheek post. I doubt the author takes himself too seriously with all of this.
What was the purpose of the post? The author wrote a tedious story about listening to a podcast episode in which markdown codeblocks are mentioned and "That’s my doing".
But the rest comes off like mock humility because there really wasn't any information of relevance to anyone but the author.
Had the article been about the importance of user engagement in open source projects and then used his personal experience to underscore the point, then the article is really about raising awareness and might be something of utility to a reader. This article, however, just reads like me, me, me.
It wasn't a personal letter addressed to you so naturally it fails to account for your ignorance. He's writing for long-time readers of his blog who already understand the context, his style, his relationship with Gruber and Markdown, and so on. Perhaps, given that you haven't got a clue about any of that and don't seem to know what irony is, you should reconsider whether your rude comment is justified.
As a long-term reader of that blog, it is obvious to me this is a little historical anecdote, mostly tongue-in-cheek, from a particular mac-centric community to which both the author and Gruber belong to. He's not being grandiose or trying to take credit.
Sometimes a story is just a story.