Get the most out of your mentoring session

So you hit the wall in your project and Google has failed you, and thus in despair you turn to Codementor for salvation.

Before you jump into a session with a money thirsty caring mentor, I want you to consider this ...

Having a session is usually a BAD IDEA.

From my experience, a good PR is much more efficient, effective, educational, and some other high value packed words I can't seem to recall at the moment.

Now, I know in many cases the code is hosted on a private repo, and you cannot just give someone access without your entire organisation knowing about it and raising an eyebrow or two.

Fortunately there's a very simple way around that, and it's free!

Bucket to the rescue!

Unlike GitHub, bitbucket is free for private repos for a limited number of collaborators (5 if memory serves, but my memory ain't what it used to be ...). You can easily copy paste your project to a private bitbucket repo and share that with a mentor of your choice.

The benefits of a PR vs session

1. Faster. Much, MUCH faster. There are many hickups in a session, in which one side has to explain to the other side "no, no, look at line 56 ... yeah, yeah, just one more line up. Good, now go right to the XYZ method ... inside the brackets ... no, not the curly ones, yeah exactly ... "
   This is slow and consumes a LOT of energy on both ends. In a PR however, remarks can be easily shared with direct reference to the relevant code.

2. No need to be online at the same time. We all have our busy schedules, and one of the awesome advantages of Codementor is having access to mentors from all around the globe. When working "offline", there's no need to sync availability. Both sides can work on their own time and thus ship things quicker.
   (At the time of writing this I'm in the Philippines, GMT +8, not easy at times ...)

3. Video Companion. When I'm sending PRs to my students, I add (when applicable) a video of my screen while I was working. I also verbalise every little thought that comes to my mind, so the student can tap into my thoughts process, and not just the end solution.
   Imagine we could have access to the brains of top developers, like the creators of languages and famous frameworks like React (my fav!). That would be priceless!

4. Forced Duck Debugging. Having to write a detailed outline of your problem makes you think about it from a new angle, which helps crystalize the situation to yourself. You will be surprised but sometimes that will lead you to the solution and will save you time and money.

5. Cheaper!. My students end up paying waaaaay less for waaaay more when I refactor their code, fix bugs, and add features through a PR. Codementor also made it very easy to pay for that instead of a session.

When live session is the best solution

Of course sometimes a session IS the best way to move forward. In that case, I suggest the following procedure:

Before the session:

1. Download Zoom. And notify the mentor you have it working.
2. Share as much code as you can.
3. Write down the problem in great detail, as if you would post it to Stack Overflow. Sometimes, you will sudddenly realise you can actually ask this on SO instead of paying for a session.
4. Write down what you have already tried.
5. Write down your debugging/research process <--- This is a killer if you wish to get better at debugging and problem solving. DO NOT half ass this, as tempting as it may be.
   I know our impulse is to "get things done" as quickly as possible, but your #1 priority should be improving yourself for the long term, as brilliantly noted in the 7 habits book.
   You don't want to rely on a mentor forever just to stay at the same level as a programmer (same applies to any profession, by the way).

At the beginning of the session:

1. Give succinct background about the project: Is it for your job, a task for college, a freelance project etc ... ? Also mention if others are working on the project, and which parts are your responsibility.

2. Clearly convey your expectations and wants, so the mentor could conduct the session accordingly. Do you want a just quick fix? Or maybe as much refactoring as possible? Those are two different "session mentalities" alltogether.

3. Show the program/app first (i.e. browser, terminal), BEFORE showing the code. Demonstrate what is happening, and what should happen. When possible show an example of an app that have the desired outcome (i.e. "I want the same swipe effect as tinder").

4. Briefly show what you've tried, give an overview of the relevant code, and let the mentor do his/her magic.

Do you have some tips for better sessions? Share below for a dose of good karma.

To better sessions,
Adam Goldman

PS. I also suggest you add the following to each request you post on codementor:

1. Deadline
2. If you tried a mentor already and why it didn't work (i.e. lacked knowledge in AWS lambdas)
3. Example of the desired outcome if possible (i.e. Web based video editing like Snapchat)
4. Succinct information about yourself as a programmer

If you have some requests open already, or some of the above is too sensitive for the public, incorporate these points somewhere along the interaction with your mentor, ideally before the end of the begginig of the session (when the mentor "takes over").