'Debugging Teams' - http://shop.oreilly.com/product/0636920042372.do
'Managing Humans' - https://www.amazon.ca/Managing-Humans-Humorous-Software-Engi...
Using the words, 'cowardly' to describe other people you don't know, and saying 'I'm better than you', to people you don't know, and saying 'my grandmother could write better markup', to a group of people you don't know, probably just made them classify you as a 'troll'.
I saw the markup, and saw they needed guidance (https://news.ycombinator.com/item?id=10489954), you saw the markup and decided they weren't worth helping. That's sad really. No one is an expert in everything.
Try helping out, rather than lambasting.
I was just reading a great book entitled 'Debugging Teams - Better Productivity Through Collaboration' (http://shop.oreilly.com/product/0636920042372.do). Here's a great excerpt:
"In order to reach collaborative nirvana, you first need to learn and embrace what we call the “three pillars” of social skills. These three principles aren’t just about greasing the wheels of relationships; they’re the foundation on which all healthy interaction and collaboration are based.
Humility
You are not the center of the universe. You’re neither omniscient nor infallible. You’re open to self-improvement.
Respect
You genuinely care about others you work with. You treat them as human beings, and appreciate their abilities and accomplishments.
Trust
You believe others are competent and will do the right thing, and you’re OK with letting them drive when appropriate."
Think about those three things.
The "handy rule" from the book Team Geek -- the newer edition is called Debugging Teams[1]. It's from chapter "Offensive versus Defensive work":
[...] After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” Offensive work is typically effort toward new user-visible features—shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the sexiness of a product (e.g., improved UI, speed, or interoperability). Defensive work is effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migra- tion, or improved emergency monitoring). Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them. If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.”
We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.
[1] http://shop.oreilly.com/product/0636920042372.do