In this blog post, Teclado student Chris Nyland shares with experience working a full-time job while also learning programming on the side to develop tools to help his job!

It began - as it often does - with an act of desperation.

I had quit a job as a tax lawyer at an organisation that I loved, simply because there was one dreadful task that became too great a price to pay for staying put: stamp duty land tax ("SDLT") lease calculations. No need to go into its vagaries much, beyond saying that when (in the UK) a tenant takes a lease, they must pay a tax. There is a far more complex suite of conditions, counting rules, and formulae than is really proportionate to the tax liability.

The UK tax authority (HMRC) built their own calculator but, by their own admission, anything that deviated from the (very narrow) norm meant building, from scratch, time-based spreadsheets. That was fantastic for learning Excel; but it is hard to build a safe, automatable, testable and delegable time-series calculation suite on Excel, let alone a practice. I began to dread a calculation coming in.

So I left the law and moved to an accountancy firm where SDLT was off the menu; and where one of my colleagues was using data analytics tools on reams of time-series data, searching for the anomalous patterns that would help a client to spot VAT fraud. That approach was something that stuck with me as I returned to my old firm, inspired to have another crack at the SDLT 'challenge'.

I wish I could point to some sort of Hollywood montage, where a flash of insight was followed by a manic flurry of creativity, and ends in a mind-blowing product. But I can't. Because I couldn't code; and whilst trying to correct that shortcoming, I had a full-time legal practice to run and a young family that needed my attention. Plus, I just wanted a nifty little app that did sums for me. Nothing world-changing.

What followed, and what this article is about, is the slow - and continuing - path towards learning to code whilst holding down another job. Its aim is simply to offer some pointers and support that busy aspiring coders who might want to do the same: it can be a lonely path to walk, and my own experiences might help. And maybe (if it is not too conceited) I might venture to suggest that it isn't the worst way to go about things.

GETTING STARTED: from 'Eh?' to Zed

I tried a few different books, but most I found pretty dry. The one that leapt out was the (then) freely-available book written by Zed Shaw "Learn Python the Hard Way". I cannot recommend this book highly enough. I was extremely impressed by the pedagogical approach of the book, its candour, its humour, and its encouragement to make and even 'break' your code.

I bought the paid version, and worked through the book pretty quickly. I found Zed taught an approach as much as he taught code, and that approach works. I would contrive a way to add a "taxy" spin to every one of the mini-challenges, even if it was as forced as printing the string "The tax liability is ...", and appending a fixed number.

Black and white answers: Pandas

At about the half-way mark through Zed's book I got a bit impetuous, and peeked to the end. Zed recommended Pandas for looking into quantative work. And thus I found the second book on my journey: Wes McKinney's "Python for Data Analysis". The first edition had, at the back, a wonderful summary primer on Python (it's at the front in the second edition). I started smuggling examples of Wes' book into the challenges and side-projects that Zed's book was setting for me. And I started trying to replicate the more rudimentary spreadsheets I was building in Excel, but using Pandas.

And very slowly, a very klutzy iteration of files emerged that was the love-child of one of Zed's 'choose your own adventure' pieces of code, and a Pandas dataframe. But it returned a correct number for the first time, and showed some crude workings, when I ran the file in the console. And all of a sudden, it felt like this might just be a viable effort.

I 'graduated' from Zed's book, but he had no other Python books available and so it was time to strike out on my own. He has since written an excellent sequel.

Tooling

The next step was to keep on with my CYOA/dataframe Frankenfile. There was still an awful lot of Python for me to learn, but at this point I paused to learn a develop two more skills of the staple coding repertoire to help me whilst I went solo: testing and version control.

One of key issues when you're trying to learn code on the side is that you want to 'bank' what you have achieved, experiment piecemeal (with the ability to get back to where you were if you get lost), benchmark your progress, and pick up quickly from wherever you left off without having to remember which differently-named file (ex_24_1_a_experiment_b_dynamic.py, or ex_21_1_a_final_experiment_c_static.py?) I had been editing last. That's where testing and version control became important.

As Zed's book drew to a close, it had added testing to my repertoire, and my progress started to accelerate, simply because experimentation became a much more straightforward exercise. Unittest, Nose, Pytest ... the truth is that it doesn't matter what you use - the key thing is that you use something.

Version Control

What's important to add to testing is a rudimentary grasp of version control. Certainly, it is something that lawyers are generally familiar with (albeit we use, almost exclusively, centralized version control systems). But even if the principle is easy to grasp, moving to the de facto version control system (Git) requires a solid hand-holding exercise. And in that regard, to my mind the leading guide (by quite some distance) is Travis Swicegood's excellently-conceived and excecuted book. It has a clever pairing of descriptive and example pages, with great illustrations.

Mastering this gave me the efficiency I needed to build a module ("ORVILLE") that I could import into IPython (or IPython Notebook, as then was), and that could undertake calculations. Things looked great. I even spoke at PyData about it to a pleasantly-encouraging reception. This was at the twelve-month mark from first clicking "Save" on the first exercise in Zed's book.

From project to colleague

And then things sort of ground to a halt in that hinterland between side-project and work-project. I had been working hard on ORVILLE in the spare waking hours that existed between my job and my family to build a proof of concept that I could show to my firm. Impressed as they were, it was a sell to get it into the organisation and running on a work machine whilst I tried to evidence my coding chops. Whilst I waited and pushed, I consolidated and embellished my knowledge by reading handy stylistic or structural guides to Python, gleanings from which I would then wire into ORVILLE, such as those by Dan Bader, Jeff Knupp, Brett Slatkin and Matt Harrison.

It took a merger, and a fantastic IT colleague who came along with it, to help to bring ORVILLE out of that consolidation phase and onto a legal workstation. He pushed for the Firm to give me an Ubuntu virtual machine, with a fresh install of Anaconda Python, and told me to have at it.

From that point on I used ORVILLE every day for work. I also set up logins for the Ubuntu box for the juniors in my team, encouraging them to use it too, via IPython. But, sadly, they balked at the idea of writing even a modicum of Python (even with the readily-comprehensible namespace I had given ORVILLE). They needed a UI - which basically meant turning ORVILLE into a webapp, or adding a GUI. I plumped for the former.

Starting with Lalith Polepeddi's delightfully straightforward "An Introduction to Python's Flask Framework", and moving on through Miguel Grinberg's excellent courses (of which the best current iteration is here, I built a barebones, but perfectly functional, Flask and Jinja2 front-end to ORVILLE (the ORVILLE web layer, or "OWL"). My IT colleagues at Gowling WLG sprinkled some CSS on it, and made a perfectly lovely interface. The code was now an essential member of the team.

From colleague to a trusted adviser

But matters weren't done quite yet. Whilst the most important skill in law is to give the correct answer, the real trick is in asking only the relevant questions you need to get there. The forms, as I had put them together in OWL, had about 20 inputs, and not all of them were always relevant or applicable. That made it harder to pass calculations to a junior, so I decided to have a crack at re-writing the front-end of the app so that it only revealed relevant questions based on what questions had already been answered. That meant learning enough React to build a self-contained web-app ("Yaffle") that would assemble enough JSON to send to a Flask API, which would in turn co-opt ORVILLE for the task.

Flask API

The first, and most essential part of the two-part step, was to ensure that I had a stable Python target to aim my first React app at. That made Teclado's own Jose Salvatierra's excellent guide to building APIs essential viewing. It broke down, neatly, what would be needed to build a solid RESTful API. I'm currently enjoying his follow up course, which is adding further bells, whistles and solidity.

The API being done, it was time to build my React app...

React

First, I had to get my head around JavaScript - for which Stephen Grider's guide to ES6 is an excellent primer if you have a working knowledge of Python (especially when allied with any of the many articles like this one).

Going on to learn enough React was a real pain - not least because of the ongoing changes to it that render many courses out of date far too quickly, so you need something that is kept painstakingly up to date. And in that regard, what ultimately worked for me was Robin Wieruch's fantastic "Road to Learn React", Andrew Mead's comprehensive React web developer course, and the Youtube videos of the UK's own Net Ninja.

Useful lessons

All of which brings us to the present day. It has been five years since I first coded in anger. I have looked in envy at people who've bootcamped their way to full-stack competence in a few months. But, then, I didn't actually want a coding job - I quite enjoy being a lawyer: I just want to build awesome powertools to make my and my colleagues' jobs more bearable.

And I don't regret taking this route either, because I worked hard to make sure it had its own advantages too: I have had more time to absorb and internalise concepts, and the luxury of exploring difficulties. I've had a daily job that inspires my morning and evening coding; and a hobby that provides a functionally useful respite from the job. Maybe I'm making a virtue of a necessity - but that isn't the worst trait in the world.

I don't doubt others could make quicker progress than me even beating their own path, but what lessons can I pass on to someone looking to get into code whilst holding down a non code-related full-time job; ideally so you can get where you need to a little bit more quickly?

  1. When you do a course, do the typing: don't kid yourself - you cannot nod sagely as you consume the information - you have to produce, too.
  2. Begin with the end in mind (and ideally obsess a little bit about it): keep your reticular-activating system on so that when you're reading something, you can sift through for the useful of information. And have a repository you trust to hold that nugget (Evernote, Pocket, a Moleskine, whatever you fancy).
  3. Find the overlap: if you're going to lead, in essence, a double life, then it behoves you to make sure those two lives overlap as much as possible. For me, every second coding is - after a fashion - 'on the job' (not every employer might be as supportive as mine).
  4. Keep things small: if you're doing this in your spare time, then you need to give yourself lots of little incremental wins. A huge part of that is, after learning basic coding, to have version control and testing down: it just helps you to dip in and out as appropriate. Solve today's problem - you might just accrue enough insight to solve something bigger as you go.
  5. Keep things short: it is easy to get up to your neck in an issue. I am naturally limited (by my commute) to two 25-minute bursts of coding a day on the train. It makes for a focussed and results-oriented approach to what you're doing;
  6. ...but don't be afraid to use big solutions for little problems: even Brandon Rhodes endorses that approach.
  7. Once you've gotten hold of the basics, master testing and version control - no foray or exploration is ever then truly wasted (even if it fails).
  8. Bring your skills. It's very easy to overlook what you can already bring to the endeavour. Lawyers: drafting and coding are more similar skills than you might imagine; accountants - your Excel-fu predisposes you to so much cool automation.
  9. Have different modalities of learning. I have a continuum of activities that I will engage in depending upon the situation I find myself in.
    • if it's possible to code, then code;
    • if you can't code, but can watch a Udemy or YouTube tutorial, then watch a video;
    • if you can't watch a video, but can read, then read (whether an ebook or a hard-copy);
    • if you can't do any of those, then listen to a podcast, such as Syntax. If you're not in a code-rich environment, then you miss the 'osmosis' of hearing terms bandied about. Even if you don't fully appreciate the content of a tech podcast, it might well just give you context, or even some useful content.
  10. Avoid the mistakes I made (or indeed sometimes still make):
    • it's very easy to look to Twitter, in particular, to try to find a sense of belonging for your burgeoning new skill. But it is a rabbit warren of unnecessary politics and posturing from which you will glean very little. These days, I try to go on there only to publically thank the creators of good content;
    • it's very easy to run to StackOverflow, but don't bother them until you're certain you have a valid question, and don't be bothered if they come back brusquely - I've peeked at it, I've lurked on it... but I'm yet to post anything on there;
    • there are lots of distractions masquerading as shortcuts - typically in the form of a new bleeding-edge library that you have to try: don't hold yourself hostage to the latest and greatest, while you have the comparative luxury of no-one judging you for using the tried-and-tested - not least because it's likely that there are more established learning materials around; and
    • don't scratch around the web looking for articles about your chosen technology (Hacker News, Medium, etc): if you do want a sense of what is going in a language or technology that you are interested in, then look for the weekly email circular that someone has put together - there are too many to list out, but anything that looks like Pycoder's Weekly is a great place to start, and take no time at all to read.