How to Use CodeMentor.io More Effectively

I dedicate this post to my friend who graduated from the same programming bootcamp I completed, one cohort before me. He was also in way over his head. Unfortunately, he did not discover how to leverage live programming help. He failed miserably in the programming opportunity he got, and has not found work as a programmer ever since. I was also in over my head. I leveraged live programming help. I am still a developer. I hope this post saves many junior developers who are in over their heads.

I wish I had this post when I started. I would have saved even more time and frustration than I saved because I learned how to get live programming help on my own. I would have achieved even more thrilling and impressive results. I am so thankful that I discovered these lessons though. By reading this post, you are more likely to survive and thrive as a coder by learning from my 304 live, on-demand, programming help sessions.

Overview of CodeMentor:

Experts from around the world see and control your computer through Zoom while you watch, speak, listen, and learn. Experts choose their own rates. CodeMentor charges for 15 minutes at your expert’s rate for every session no matter how long it takes to solve the issue, then charges your expert’s rate per 15 minutes afterwards. For that reason, I suggest that you use CodeMentor when you think it might take awhile to solve an issue.

You get to choose which mentor you work with. In general when you create your issue, always write a description of your issue which describes the work you’ve done so far since this increases the likelihood that experts want to help you. I also recommend that you set your maximum budget at $15 per 15 minutes because I generally paid more in total each time I resolved an issue when I chose higher-priced experts.

In fact, my go-to PHP expert name Razvan charged only $9 per 15 minutes, and my top Objective-C mentor CodeChanger (real name Dhanesh) charged $8 per 15 minutes. These lower-priced mentors are more likely to work in different time zones and have accents, but they can still solve your issues.

First Session:

Even if the expert has other screen sharing software installed and asks you to install and use it, don’t. Insist on Zoom. If your expert asks you to start the session right away, you can refuse and explain that CodeMentor allows a five minute preview period to make sure the mentor can solve your issue. Then politely mention that other experts offer five minute preview periods.

Tips and Payments:

Also, when a mentor resolves your issue well, I strongly suggest writing a positive review and tipping. If an expert pauses a session and forgets to unpause the timer, and if you forget to mention that the timer is paused, you can use a tip to cover the difference. I haven’t found conventions on tipping, and in general I suggest always tipping something and erring on the side of generosity. You can also send direct payments through the chat window in your dashboard page.

Repeat Use:

If an expert, like Razvan for PHP and Ibrahim for React, repeatedly solves your issue quickly and cheaply, I suggest that you reach out to them through a chat window, briefly describe your issue, and ask if they want to do a session in the near future. Then I suggest working on other tasks until they’re available again. This saves time and money overall because you don’t have to explain your code to other developers.

Getting Bids:

If the solution for an issue can wait and you’re posting a new type of issue on a new project, or if your primary expert isn’t available, post your issue, then step away from your computer for awhile, even if just to use the restroom. When multiple experts express interest, you can choose the mentor with the most experience related to your issue at the lowest price and in an optimal time for your expert.

Closure:

If an issue has been resolved and multiple experts expressed interest in helping you, it is nice to thank them for their interest in helping you, say that the issue has been resolved, and explain why you went with the expert who solved your issue. Treat others the way you want to be treated. I would rather get closure than no response.

Zoom:

I suggest that you install Zoom before your first session. It took me it little longer to join my first session because I had not yet installed Zoom. If a Codementor expert has not yet installed Zoom, perhaps because it is their first or one of their first sessions, exit the session. Otherwise the session will generally be frustrating for both of you.

Before Starting a Session:

Google the error messages, log variables to the console, use debuggers, try to solve the issue on your own. If this fails, get help.

Always have the app running and your code open during the session. Otherwise you pay as you get set up.

Familiarization with Your Code:

Try to use the same mentor whenever possible because different mentors need time to understand how the code works, and this costs money. Also, many software developers seem to think that everyone else’s code sucks, and might try to rework parts of the code.

Time Differences:

According to the the book “When: The Scientific Secrets of Perfect Timing” by Daniel Pink, some people prefer to go to bed and wake up at different times than others, but some preferences are more common.

The majority of people experience a slump in the mid-afternoon, say around 2:00 pm to 3:00 pm. Mentors might do worse in the mid-afternoon of their time zone. Similarly, we don’t think as well when we get close to bed time. I don’t advise working with mentors around 2:00 am to 3:00 am their time. Some mentors also have “day jobs,” and become available after certain times. Razvan became available after 11:00 am Eastern, and CodeChanger (Dhanesh) became available after around 12:30 pm Eastern.

Be Ready:

Be specific about the problem and clearly communicate the desired outcome. Show wireframes, or the app, or a simulator with the app running if possible. Try to understand the code you have if possible.

Where and When:

In general, I suggest that you get programming help during business hours when possible because you’re getting paid for those hours. I conducted business hours sessions in my boss’s office when he wasn’t there, or in the small, private quiet rooms. If no one books a larger open room, you can conduct sessions there too.

Technical Difficulties:

If you and/or your expert experience technical difficulties related to sound, internet connection, screen sharing, etc, pause the session timer and if need be, end the session.

Make sure the expert can hear you and you can hear them. End the session if both conditions aren’t met, otherwise the session will be frustrating for both of you. Also end the session if you can’t understand what the mentor is saying.

Failure:

If an expert fails, ask them how much you owe them. My most common response has been “whatever you want.” In such cases, I’ve paid for half the time used, and that seemed acceptable so far. Experts can refund you all or part of the amount if need be. In cases where the session has been awful, you can always ask for a refund. If they refuse, you can reach out to CodeMentor, HackHands, etc. I’ve never had to do so, and most of my sessions have been beneficial.

Experience:

Only work with mentors who have experience with all the languages, frameworks, databases, etc. that you’re working with. I once worked with an expert JavaScript developer who couldn’t figure out a React issue.

Small Talk and Thinking:

Sometimes small talk with the expert can be fun while things load, but in general it pays to give the expert some time to think because they’ll likely solve your issue more quickly when they can think. Experts often lit up when I used their native language at the end of the session, which I think made them want to work with me again. You can find their native language by viewing their profile.

Check that it Works:

One of the best students in the bootcamp class helped us with image upload functionality. He was super confident, and said things would work. The first of several times we tried, the app didn’t work as expected. Until we tested and it did. Always test the solution before exiting a session.

Once I assumed that a mentor on hackhands.com had finished a solution because he said it would work, and it didn’t. He had joined a session with someone else afterwards. It may cost another minute or so, but testing a solution which the expert in the session assures that you won’t have to familiarize another expert with the code, and lets the expert see your joy when everything works which I think makes them happy to work with you again.

Getting Reimbursed:

Ask your boss if you can be reimbursed. Some states offer tax incentives for training their workforce, and leveraging live help might count.

Tax Treatment:

Starting with the 2018 tax law in the US, we can no longer deduct unreimbursed expenses we pay as employees.

What Goes Around Comes Around:

Leave a favorable review when earned, otherwise leave no review. You could quite possibly will work with any mentor again. Abdul, who couldn’t help in with one issue, helped me solve a critical issue with expert skill a few months later.

Make notes about your favorite experts. I’d ask Ibrahim about his girlfriend Diana, knew that Razvan liked mountain biking, knew Ezra’s consulting projects, and more. Keep note of when you have sessions with someone, perhaps in a Google Sheet, and say things like “great to see you again.” Ask for how to pronounce names you’re not used to saying. First though, Google “how to pronounce [whatever-name-your-expert-has]”. These experts are your employees, and you want them to be happy and motivated to kick ass on your behalf.

Tips build goodwill. It might be awhile before your favorite experts get sessions. I once visited Razvan’s CodeMentor profile and saw that I provided the majority of his recent reviews. And these experts don’t get health insurance and other employee benefits you do. You want experts to carve out time to help you, want to help you first, and respond quickly when you post issues or request help.

Expensive Experts:

Super-experienced, super skilled, expensive experts are worth using once or twice for learning lessons you can apply to writing code in general instead of for specific issues, and when architecting an application.

From my mentor Jimmy, who fits into this category, I learned how to write cleaner, more maintainable code through Functional Programming. He also introduced me to things like the Prettier Visual Studio Code package which automatically formats code, which has saved me lots of time and made my code look better.

Most importantly, Jimmy taught me how to estimate how long projects might take to complete. I learned the hard way that in software development, things generally take longer than we expect because we run into unexpected challenges.

Jimmy suggested that we should avoid giving estimates of how long things will takes whenever possible, and when we absolutely must give an estimate, we should estimate the worst case scenario amount of time, then triple that amount. In my experience, this method has been surprisingly accurate.

Conclusion:

Once you leverage live programming help, philosophically you are no longer an employee, you are a business owner. You hire contractors. You are an entrepreneur. As long as you keep delivering good results at work, you’ll have more time to do whatever you want.

Leveraging live help allows you to survive as a developer while learning through watching the solutions unfold. I had to pay for live help less and less as time went on. Speaking of learning, the best way I’ve found to learn is to find something you want to build, and learn what you need to learn in order to make your idea a reality. Live help can help you get past roadblocks and remember those solutions when you do.

Congrats on finishing this article, and I wish you lots of success as the business owner you now are.