Skip to content

Instantly share code, notes, and snippets.

@josh-works
Last active April 14, 2022 01:35
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save josh-works/8d852168a851db7fbf230c8e8c7a3756 to your computer and use it in GitHub Desktop.
Save josh-works/8d852168a851db7fbf230c8e8c7a3756 to your computer and use it in GitHub Desktop.
Process & Workflow for solving programming challenges, Turing

"Process" is greater than everything

Having a good process is how you go about doing anything that takes a long time and is hard. A good process can be a faithful tool to help you learn dozens of things, now, and five years from now. It's flexible and it's powerful.

One of the biggest pieces of "having a good process" is "taking plentiful notes, easily and quickly"


I won't try to convince you. Here's Arique, currently in Mod 1, on how she's made use of this general process:

Arique's Workflow.

It can be super helpful to see other people's examples of this kind of "process". In her own words, here's how Arique has ended up making use of this general process:

My name is Arique and I worked really diligently with Josh two weeks before I started Mod 1.

I hit a point where Josh was probably the ninth person to tell me "You have to reach out. You have to ask for help. You have to. You have to. You have to!"

I told him, "How do you expect me to ask you for help when I don't even know the right words and formatting on Slack is so overwhelming."

In other words friends, asking for help was harder for me because

  1. I had to define the problem.
  2. I had to prove I had tried a bunch of things.
  3. I had to provide it in a format that was easy to read so that others could actually help me.

When you're just learning coding and you don't even know to mention that you have an array that requires an enumerable so that you can iterate more effectively and explain the expected result of all of that. It's not intuitive. Not even close! So the thought of turning around and "asking for help" just felt like more work.

That's when Josh realized where I was struggling and showed me github gists. I worked to add it to my workflow. It needed to be something that I normally did, not an extra step.

It's called a workflow and here is how mine looks like:

  1. Work on code.
  2. Get an unexpected error
  3. Try to fix it
  4. If attempted solution doesn't work...
  5. Open Github gist markdown and start a 30 min timer.
  6. Copy paste the code from my terminal into my gist.
  7. On top of the code block I explain what I was attempting to do.
  8. At the bottom of the code block, I explain/work through/research what I should or could do next.
  9. Try it, run it, let the terminal tell me if I solved it or if it didn't work.
  10. Copy paste the terminal results into gist
  11. Repeat until timer goes off.
  12. When the timer rings, I save my gist, and send the url to three people with a short message that typically says, "I'm stuck."
  13. And I walk away from my computer.
  14. By the time I'm back, one of the people have read it and responded if I tried this other thing that isn't on my doc, and better yet...I LEARN!

Please note: I don't wait to "feel stuck" I let my timer remind me that "I am stuck". Waiting to "feel stuck" will leave you spending double to triple the time you should really take for resolving this problem.


It's me again, Josh! Please re-read what Arique wrote above. Notice how she doesn't wait to feel stuck, she uses a timer to tell her when she is stuck.

To that end, here's how I (josh) use github gists to take notes (I have over 200 private gists, created over three years of work), and I would like you to start regularly making your own gists.

How to use github gists as the foundation of your new process

  1. go to gist.github.com
  2. In the filename including extension field, add your filename. It's critical that you end the filename with the markdown extension, in this case .md.
  3. Change no wrap to soft wrap in line wrap mode box
  4. Add some sort of title. If you place a single pound sign at the beginning (#), it will be a big, attention-grabbing title.

here's what all this looked like

So, here's the "outline" of a new document.

Now what?

Start tossing notes in here! To do that, lets talk a little about markdown formatting.

First, if what you're reading right now is styled text. I'm writing this in "raw" markdown, and it's coming back as nicely styled text.

For example, here's some ruby code I was working on recently:

# lib/tasks/mrspec.rake
Rake::Task['mrspec'].enhance do
  Rake::Task['rubocop'].invoke
end

Or, some Javascript:

describe('Array methods', function() {
  // these tests based on Turing's `ruby-exercises`, specifically:
  // data-types/collections/arrays.rb
  it('test0', function() {
    this.skip();
    // In the line below, create a new empty array
    var empty = []
    assert.deepEqual([], empty);
  });
  
  it('test1', function() {
    this.skip();
    // In the line below, create and array with the numbers 1 - 5
    var oneThroughFive = [1, 2, 3, 4, 5]
    assert.deepEqual([1, 2, 3, 4, 5], oneThroughFive);
  });

Curious to see how to write these code blocks? Use tripple backticks and the language name for the syntax highlighting!

detailed how-to

Sharing and continuing editing this document

Here's some high points of this newly-created gist:

sharable, editable

  1. It can be easily shared (please note how I gave this to you to read!)
  2. It can be continually edited.

Build your own

Here's what I'd recommend putting in your document.

First, grab URLs for the project you're working on. Say it's Iteration 2 of "Battleship".

Next, copy/paste in the code you're trying to get working.

Copy/paste in any relevant info from pry, or anything else.

Share it with me! I'd love to see it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment