A few days ago I wrote a post on sharing your hobbies with others. I gave some examples which weren't related to programming, using my hobby of board gaming, but I wanted to follow that up with this post - where I want to give more specific examples to ensure that you can enable budding programmers to be as awesome as possible.
I've helped lots of new programmers on their journey to learn and build, doing so in lots of different settings - mentoring at hackathons, running coding clubs aimed at beginners, facilitating workshops and sitting down with friends to give them primers.
While each situation is vastly different, there are some similarities between them - our aim as developers helping others is to enable those we are helping to go away and explore further once we are finished, and become DO-ers, writing code for their own projects.
Like my other post, my main message remains the same - if you screw up your first exposure, the person you're helping may go away just as confused as when they started, never wanting to return to the discipline.
Here are some tips to make sure that you make your limited time with a new programmer as impactful as possible…
Try to never take control of the keyboard or mouse. You are trying to show someone else how to solve a challenge in a way where they could attempt it themselves in the future. It may be challenging as you're just wanting to get the problem fixed, but narrating how to fix it and allowing them to type that critical code is important.
Not only is it important for solidifying knowledge, but also shifts the focus away from you as 'that person to fixed my problem', to them feeling like they have fixed their own problem, which comes with a confidence boost that would otherwise be missing.
Simply writing a snippet isn't the most helpful without explaining the logic behind the solution. It may be explaining function scoping, or the CSS box model, or the DOM and why it looks different to the code they've written.
The more knowledge you can impart, the better positioned they are in being able to solve their own challenges, and knowing how to search for solutions for the best results.
Picture this - someone approaches you with a problem, you sit down to show them how to fix it, and your solution doesn't work. I'm sure this has happened to us all at one point, and it's not always easy to recover from and can cause a whole heap of confusion.
The way I generally prepare for this if I don't know that my solution will 100% work is to ask them to take control of their machine for a minute to test out the solution, then remove my work and talk them through what I did so they can do it for themselves.
There is never anything wrong with going 'I don't know for certain, but I have an idea - give me a moment to test it and then I'll show you what to do', although try to only do this if you are unsure as your aim should be to never take control of their keyboard or mouse.
There are always multiple ways to approach a challenge, and developers will choose a way that suits them. Most people who write software as a profession will opt for whichever solution is most standards-compliant, but I am suggesting that this isn't always the way to go for introducing new developers.
This is an extension of a point in my hobbies post:
Sometime you may have the opportunity to approach a challenge in a slightly easier way. Sometimes these easier ways aren't the 'proper' solution, but help your friends get started and see results quicker.
This is the most important thing - you want your friends to see some return on the investment (time) they've given you as quickly as possible. Don't drag it out, don't make it more complicated than it has to be, and be nice.
Remember, everyone prefers a different set of tools to make them as productive as possible. Don't be that person who changes other people's settings or workflows.
If you feel a tool will help in your audience's exact situation, then by all means show it off, but don't make anything more complicated than it has to be.
One of the biggest skills developers much have is knowing how to ask for help - how to phrase search terms, the terminology to use, and the sites to look at first.
When you leave someone, make sure they know the related terms to the help you've given, and leave some links open where they can search for further help. Your aim is to get that person to a place where they don't need your help, or at least not as much. That said...
Make sure your audience feels like they can come and ask you if they need - make sure they know that they're only a shout away from help. Generally, this will help them feel like they can experiment and get things wrong, and still have your support if required.
Try and make sure that you impart as much knowledge as possible, not through just talking, but demonstrating and narrating the solution. While you’re trying to level-up your audience as much as possible, you should also take steps to not to confuse them by introducing new tools sparingly, and sometimes opting for simplicity over standards.
The most important thing is to remember that you’re trying to make your limited contact-time as impactful as possible, empowering your audience to take the next steps, while remaining as approachable as possible in case they do need your help in the future.