Some cheapskate insists on writing a guide to selfhost <software> on Heroku and wants to add it to the official documentation, promising to maintain it (since none of the other devs are using or planning to use Heroku). I volunteer to give them a chance on grounds of it being high quality and maintained by that person in the future which they both promise.
Our docs are written as markdown files on github.

So here we go:
Starts a pull request: uploads their """guide""" as a docx. The content is completely unformatted, basically just an enumerated list.

Tell them to format it as markdown, suggest using github gists.
They go ahead and copy pasta their unformatted list into a gist.txt "allright i made it into gist for ya"

Tell them that they did not format it as markdown.
"sorry updated it in markdown :P"

I look at the file, it is still raw text in a gist.txt. Maybe a bit more spaced out, not that I would care to notice any changes at this point.

Tell them it is still not markdown and link them to a perfect example of another guide that takes advantage of code fragments for commands etc and is properly rendered since it uses .md

"I updated it to the markdown this time XP Can you give me some suggestions on how it looks?"

"How it looks"... "how it LOOKS"... I click the link for the 5th time and IT IS STILL JUST A RAW FUCKING GIST.

Jfc that person has some serious reading/thinking disability. To imagine them to be proactively keeping their guide up to date in the future is absolutely impossible. At that point I pulled out my support for the request since it was already taking more effort to even get a readable version of guide than I estimated for the whole process of adding it.

Oh, and one of the steps originally suggested in the """guide""" was adding the credentials file into the vcs.

i have been browsing trough my gists and this is what I have found.

HAI
HOW DUZ I PRINTSMILE
VISIBLE "SMILEZ!"!
IF U SAY SO

HOW DUZ I PRINTSMILEZ NUMBERZ
I HAS A SMILEZLINE ITZ ""
IM IN YR LOOP NERFIN YR NUMBERZ WHILE NUMBERZ BIGGR THAN 0
SMILEZLINE R SMOOSH SMILEZLINE AN "SMILEZ!" MKAY
IM OUTTA YR LOOP
VISIBLE SMILEZLINE
IF U SAY SO

VISIBLE "O HAI! NOT MY WERK! LOL!:):)DIS WAY CUZ I LIEK SMOOSH:)"

I HAS A COUNTER ITZ 3
IM IN YR LOOP NERFIN YR COUNTER WHILE COUNTER BIGGR THAN 0
PRINTSMILEZ COUNTER
IM OUTTA YR LOOP
VISIBLE ":)N DIS WAY CUZ QUESTION. LOL!:)"
COUNTER R 3
IM IN YR LOOP NERFIN YR COUNTER WHILE COUNTER BIGGR THAN 0
I HAS A UDDERCOUNTER ITZ COUNTER
IM IN YR INNERLOOP NERFIN YR UDDERCOUNTER WHILE UDDERCOUNTER BIGGR THAN 0
PRINTSMILE
IM OUTTA YR INNERLOOP
VISIBLE ":)"!
IM OUTTA YR LOOP
VISIBLE ":)LOLOLOLOLOLOLOLOLOLOLOLOL!:):)KTHXBYE"
KTHXBYE

I really really hope that no one post this,a friend texted it to me and I wanted to share it because made my day.

Idk where it comes, so feel free if know where this came from to post it:

//FUN PART HERE
# Do not refactor, it is a bad practice. YOLO

# Not understanding why or how something works is always good. YOLO

# Do not ever test your code yourself, just ask. YOLO

# No one is going to read your code, at any point don’t comment. YOLO

# Why do it the easy way when you can reinvent the wheel? Future-proofing is for pussies. YOLO

# Do not read the documentation. YOLO

# Do not waste time with gists. YOLO

# Do not write specs. YOLO also matches to YDD (YOLO DRIVEN DEVELOPMENT)

# Do not use naming conventions. YOLO

# Paying for online tutorials is always better than just searching and reading. YOLO

# You always use production as an environment. YOLO

# Don’t describe what you’re trying to do, just ask random questions on how to do it. YOLO

# Don’t indent. YOLO

# Version control systems are for wussies. YOLO

# Developing on a system similar to the deployment system is for wussies! YOLO

# I don’t always test my code, but when I do, I do it in production. YOLO

# Real men deploy with ftp. YOLO

So YOLO Driven Development isn’t your style? Okay, here are a few more hilarious IT methodologies to get on board with.

*The Pigeon Methodology*
Boss flies in, shits all over everything, then flies away.

*ADD (Asshole Driven Development)*
An old favourite, which outlines any team where the biggest jerk makes all the big decisions. Wisdom, process and logic are not the factory default.

*NDAD (No Developers Allowed in Decisions)*
Methodology Developers of all kinds are strictly forbidden when it comes to decisions regarding entire projects, from back end design to deadlines, because middle and top management know exactly what they want, how it should be done, and how long it will take.

*FDD (Fear Driven Development)*
The analysis paralysis that can slow an entire project down, with developments afraid to make mistakes, break the build, or cause bugs. The source of a developer’s anxiety could be attributed to a failure in sharing information, or by implicating that team members are replaceable.

*CYAE (Cover Your Ass Engineering)*
As Scott Berkun so eloquently put it, the driving force behind most individual efforts is making sure that when the shit hits the fan, you are not to blame.

More from my big black book of ai and neuroscience:

I think if trace theory is true to any degree it would go some distance in explaining phenomenal consciousness, assuming I haven't misunderstood anything.

In fuzzy trace theory (FTT) it is posited that people form two types of mental representations about a past event:

*verbatim traces: detailed representations of a past event.

*gist traces: fuzzy representations of a past event.

People can reason with verbatim *and* gist traces but prefer gists.

*vision was suggested to work similarly in 1999. With human vision, two processes could be used: one that aggregates local receptive fields and one that parses the local receptive spatial field. It was suggested that people used prior experience, gists, to decide which dominates a perceptual decision.

Gist processes form representations of events, semantic details, where verbatim reinstates the context found in the surface details of an event.

__notes__

Parallel storage: asserts encoding/storage of verbatim/gist traces operate in *parallel*, not in serial.

I like to think of verbatim traces as databases, and gists as queries constructed by recognition.

Several studies have found that the meaning (gist) of an item is encoded even *before* the surface details (verbatim).

This might be important as a survival mechanism but should not be taken to mean strictly that gists are formed wholly *without* details or important and recognizable features of the item in question. It may well be for high level el processing and classification efficiency this may be an important reprocessing step, in the same way that many functions of the brain are duplicated throughout.

Am I the only one who loves documenting their work? I mean I just absolutely love making Github gists, man!
It helps in the backend-frontend integration and in communication between teams that is necessary for frictionless progress towards our common goal.

just wanted some help from you people..

if anyone knows some sort of Code Snippet Manager or Gists Manager.

I want to store my code snippets (public and private) with the following abilities:
1. Search the snippets
2. Tag the snippets
3. Code highlighting
4. Cloud Stored Snippets
5. Is free

I've found Cacher and Lepton but Cacher allows only Public snippets in the free version and Lepton lags search ability.

Anyone know a better client for this purpose?

Knowledge management. My last job had notes recorded under closed tickets. Some people use hundreds of gdocs. Others have github gists some people I've seen just have sticky notes everywhere

How do you handle personal knowledge bases?? I want to set up some system for me and maybe my friends

Why??? Gists???