Learn To Code the Jedi Way

TLDR: If you’re going to be a Jedi, you need to know how to construct your own lightsaber. If you’re going to learn to code, you’ll need to know how to setup your programming environment.

When a recent change to an API we relied on for providing in-browser exercises dropped support for creating user accounts, I was left without a seamless way for providing you with programming exercises. Next to the plush, effortless and glossy e-learning websites out there, what chance would I have to promote my own on-line courses?

I was worried that without interactive repls, I’d lose some of the new members who’d sign up for the site. But apart from being very easy to get started, coding within an iframe running in a web browser is actually not much fun. Even the best repls don’t stand up next to a good text editor, and no doubt you've experienced the frustration of a crashing exercise, losing our work.

The deceptive simplicity of many interactive coding exercsies tends to be for very beginner, very basic tasks - nothing like the real world. In providing something immediate and visually appealing, all too often interactive repls over simplify, teaching you how to type; rather than how to code.

“If you choose the quick and easy path, as Vader did - you will become an agent of evil”
Jedi Master Yoda

Truth is, unless you work with the same dev tools that developers use, you are not learning how to become a developer. No amount of interactive exercises will convince an employer to give you a job, if you don’t know your command line shell commands, some basic UNIX administration and how to install software on your machine.

It’s sometimes painful to watch novice developers fumble around with a text editor. I’m used to it – I’ve been teaching for five years. But there’s nothing that says ‘newbie’ more than holding down the → key for 10 seconds to reach the end of a file, where an easy keyboard shortcut exists. That’s not to say that you have to be some Vi ninja before you apply for your first job; just that being spoonfed exercises on-line robs us of the chance to get our hands dirty with our programming environment.

Now that we’ve chosen coding as our career, there is also something deeply personal about our programming environment. The operating system, text editor, web browser, even our shell prompt says much about us as programmers, and it needs to be a comfortable and safe space for us.

A New Hope

After some mad refactoring and a lot of work, I migrated onto our existing git provider, and brought the exercises in line with how I was delivering the assignments. In the end I found that many ways my lessons are now simpler: everything is delivered via git, encouraging you to learn some basic git concepts and commands, and becoming accustomed to the dev tools you will be using in your next programming job.

Learning to run the test suite before you commit your work, learning to make small, regular commits, rather that committing everything at the end; these apparently innocuous things make a huge difference to the ease with which you can be absorbed into a development team, and they are difficult to teach, becuase they're really a habit that you have to practice more than a concept.

The way my assignments are structured on my courses is the same approach that I’d take to any client or open source work. I create a git repository, with a README that explains how to get going. In the case of an exercise, the README is a walkthrough guide that you can follow, making the changes as you go. There are also assignments that are more open-ended and challenging, allowing you to tackle a more protracted task, knowing that is achievable, whilst giving you some room for creativity.

Each exercise has some sample code to get you started, and a test suite to check that you got the result that I was expecting. In this way, you’re also implicitly practicing the git workflow used by all the best software companies in the world. Your journey would therefore go something like this:

1. Fork the repository - This obtains your own version of the exercise, so you can make edits without affecting anyone else.
2. Clone the repository - This brings down a copy of the exercise to your local machine.
3. Open a terminal in the cloned directory – This is where a bit of shell programming comes in handy, using cd to navigate your filesystem to the right place.
4. Reading the instructions – perhaps with less to paginate through the README. How many developers skip this step ;)
5. Make an edit to the code – in your favourite editor (I recommend Sublime text for beginners)
6. Run the test suite – making sure that your recent changes made something pass. Otherwise, what was the point of adding it?
7. Save your progress - git add and git commit to selectively add the files that changed, and logging your progress as you went along. Why did you need to make the changes you did? Writing good commits and committing often is a great habit to get into!
8. Repeat steps 5-7 - until you’ve completed the exercise
9. Upload your work for review – with git push
10. Reward yourself - with a tasty snack or a piece of fruit

While I accept that for someone entirely uninitiated, this process requires quite a bit of going sideways before someone can focus on the actual coding, I would argue that this will make you a better coder in the long run.

Learning to deal with this frustration is also part of the daily routine for developers. Not being phased when task A depends on task B which depends on task C, but learning to set realistic expectations of yourself is a big part of developing a good coding temperament. Just like Luke Skywalker, we must learn to deal with our anger if we're to avoid turning to the Dark Side.

A padawan must learn how to construct a lightsaber, as part of their training to become a Jedi. In the same way, learning how to setup your environment is an essential part of becoming a coding Jedi – and if you’re up for the challenge, that’s exactly how I approach the learning on this course.