This year has been very rewarding. Students, juniors, and seniors have been sharing their stories and desires. Although it’s heart warming, to to see clinicians learning how to code, I’m aware that the early stages of interest are very delicate. In the early stages, you won’t be able to produce something cool or useful. Like with most skills, there is always a slump that you have to get through in order to get to the part where you can do interesting things with that skill. Combining that with long clinical shifts can easily lead to you giving up. Here’s a few tips to keep going.

Set aside time regularly

This is generic advice that can be applied to most things but it’s still important to consider. When learning how to code you are literally exposing yourself to a new language and a new way to express logic. Because if this you need to periodically expose yourself to this new way of thinking. Pounding through a ton of material  in your week of annual leave appears productive. However, you will forget a lot of the concepts you learnt if you don’t expose yourself to them regularly. I knew one junior doctor who was trying to learn code in an ad hoc fashion. His progression was slow because he had to keep relearning previous concepts every time he committed to another long coding session. He was learning code when he had spare time as opposed to making time. One hour every other day would ensure a steady pace of improvement and will prevent you having to re-learn concepts. This means that you will sometimes have to pass on things. This shouldn’t be news, most things that are worth something take some sacrifice and hard work.

Play with projects 

Think of code like learning a foreign language. Yes, you have to learn the underlying theory, read books and listen to tapes of idealised conversations. However, we all know that the real learning comes from talking to natives, watching films in that language, and generally diving into the use of the language. You pick up on unofficial use, dialects and nuances. The same can be said for coding. Getting your hands dirty with silly toy projects will teach you how to write cleaner, more effective code. You will get sharper at preventing and rooting out bugs. Remember these projects are your projects for your own personal development. Do not intend to solve any major problem. Focus on the concept of code you’re trying to learn. This works on all levels. When learning a new language I still have to wade through the new syntax. I make the process seem less dull by engineering the basic syntax to print out silly statements. This makes me smirk like a school boy who’s pencilled in a beard on a newspaper photo. This doesn’t just work with basic syntax. I recently was practicing with servers. My toy project was to develop a phone directory with an online database so I can update it with contacts. It wasn’t a serious project but it got used to the basics of servers and the django framework.

If you’re starting out you will improve your problem-solving skills quickly if you develop silly basic word games or drug calculators. When you get better, start developing risk score calculators. Before you know it you will be at the stage of developing useful apps.

Find a playmate 

Finding people with similar interests is always encouraging. Whilst this isn’t important in the early stages finding someone to code with later on can be a real game changer. If you share a toy project you can achieve bigger things with the same work. This increases the motivation as the reward is higher. You will feel less inclined to slack as you don’t want to let the other person down and you will be able to bounce solutions to technical problems with each other. Don’t use this as an opportunity to jump into bigger projects straight away otherwise you’re dampening the edge you get with teaming up. Use the two heads to get through toy projects quicker. You will escalate to bigger projects at a faster rate than going at it alone. However, be careful with your playmate choice. It’s tempting to find someone at your place of work and team up with them. This is not a good idea. In my experience, there are always a few juniors who will express interest if you talk to them at your place of work. However, getting them to follow through is another matter. This is because you’ve cut out a selection process. The more projects you do the more you will realise how important selection processes are. When you ask someone at work you show no vetting process. Yes they are hard working, they’ve graduated and pulled through their clinical work, however, are they truly interested in coding? All they’ve had to do is just say “yeah” to you whilst at work. They’ve not had to go out of their way at all. If you want to find a partner spend a little bit of time looking in places where they have to go out their way. Look for blogs where the user consistently posts material on coding. Websites like Eventbrite and Meetup will also provide rookie coding events. They still may not follow through but there’s a higher chance they will.

Remind yourself the full potential of code 

Remember code is a tool/resource. It’s as useful as your ability to utilise it. Consider other resources. Crude oil was useful to come extent, however, when the refining process was mastered and machines were designed to utilise oil it now has a much larger impact. The same is with code. Step by step you will get to the point where you can make great changes. If you’re struggling to come up with a toy idea and you don’t have anyone to code with yet, code along with me and create a DVT risk calculator in these 4 short videos. No previous coding needed.