I’ve been lucky enough to have just finished two weeks working with the BBC Knowledge & Learning web developers as part of my attempt to change career from an editorial role to a more technically minded one. It also happens to be Computer Science Education Week, so I wanted to share some of my thoughts on what’s been happening, as well as really useful advice I’ve been given.
First, a little background. When I left university in 2005, having completed three years studying Multimedia Technology and Design, I had sampled a bit of everything the world of “multimedia” had to offer, having enjoyed the modules on graphic design, video editing and most of all web design. This what had originally attracted me to the course in the first place – playing around with rudimentary tools such as CompuServe’s Homepage Wizard back in 1997, learning the basics in HoTMetaL Pro, experimenting with CSS and learning some PHP in Dreamweaver. The web at the turn of the millennium was an exciting place, a digital playground where hundreds of companies such as GeoCities would happily lend you a bit of space for you to experiment with this fantastic new publishing medium.
However, unlike most people fresh out of university, I didn’t immediately jump into the job market. I chose instead to purse three years in the JET Programme, teaching English in Japan. A fantastic experience, to be sure – and one that certainly helped shape me as a person, but altogether a far cry from what I had previously been studying.
Fast-forward to 2008. My three years in Japan were up, and I returned to the UK hoping to start a career in web design, or at the very least, computing. The landscape that greeted me on my arrival was however rather different from the one I remembered.
I realise I’m simplifying this situation somewhat – but the main point is that only 10 years ago the barrier to entry into the world of web design was incredibly low. Think of this – one of the best ways of learning HTML is to simply view a page’s source code. Back in the day of plain old HTML and CSS, this would reveal exactly how the page was made. Nowadays though, the page’s source code is only half the story. Not to mention that wading through a modern website’s source code can be like trying to read Finnegans Wake.
Now, the basic fact that you still code your page in HTML and CSS hasn’t changed. But if you are of a less technical nature, I imagine most of that previous paragraph was basically incomprehensible. Yet, these are all things a modern web developer must contend with. The barrier to entry seems much higher. And yes – the role has shifted from web designer to web developer. The designer’s role is now more closely filled by a UI or UX designer. It’s quite rare in a modern commercial environment for one person to work on the planning, design and implementation of a single website. At least, that’s what my experience has shown.
So here we are, in the 2010s, with a veritable explosion in available web technologies. They all sound fantastic – download this, set up that, and you have a basic skeleton of a web app in no time at all. But with all the cacophony of frameworks, libraries, helpers, just where are you meant to start?
I am not complaining about the current state of web development, nor am I yearning to go back to the days of notepad and HTML. My main point is that it’s daunting. For a neophyte the world of the web appears impenetrable, incomprehensible. “Where do I begin?” “What do I need to know?” “How can I learn all this?”
Although there are some great online resources that I would recommend to anyone aiming to start in this exciting field (namely Code School and Codeacademy), the best answer I can find is the same one I found back in 1997. These are things you need to teach yourself. If you have the passion or even just an interest in turning your ideas into reality, you will have to do a lot of legwork yourself.
My current projects – MétEX, Crater, and the yet unnamed “Project CQ” have all provided me with a clear goal and an incentive to study the web technologies necessary to make them happen. I want to study because I want to make these projects, these ideas a reality. I want to make them a reality because I want other people to enjoy them. When it comes to such a creative activities such as coding, there really is no better driver than your own ideas and personal projects.
Having spoken to various people around the BBC’s Future Media department, I started to get a clearer picture of what companies want when looking for developers. Or better: what developers need to learn in order to be successful. Test-Driven Development, knowledge of working in an Agile way, familiarity with PHP frameworks such as Zend. These were just a few of the things I was advised to concentrate on.
Armed with some clear instructions and short-term goals, it’s somewhat easier to draw up a plan of action and think about how to incorporate these things into existing projects. “Instead of starting my project from scratch, I’ll write it inside CakePHP.” “I’ll make sure to write unit tests before writing any code.” “I’ll try to write my features as user stories, and break each one down into the smallest task possible.”
But here comes the trap I fell into. I was trying to concentrate so hard on “doing things the right way” that I’d end up coming across a problem, trying to research the “best practise” way for several hours, before realising that I hadn’t written a line of code all night.
When you’re learning something new, you’re bound to come across a problem none of your tutorials, manuals or notes can help you with. But in my obsession to learn the “one, true, correct solution”, my projects came to a standstill.
Here’s the advice that saved me.
@PkerUNO Seriously, though: 1) if it feels like there should be a better way to do something, there probably is.
— Aaron (@cloudymusic) November 26, 2013
@PkerUNO 2) despite #1, sometimes "it's not elegant but it solve the problem" is good enough. "Perfect" code is usually unattainable.
— Aaron (@cloudymusic) November 26, 2013
I like boiling this down to two words: Just Code.
This doesn’t mean “write the quickest, easiest solution that you copy and pasted from a random website”. Neither does it mean “ignore the problem and apply a series of hacks to sort of fix it”.
I take it to mean: “Write the best solution you can find right now. There will definitely be a better solution out there, but you’ll find it eventually. For now, if it works, it’s fine.”
It seems obvious, but a good solution is always better than a “perfect” solution which isn’t there. A thing that exists and works is always better than a thing that doesn’t.
I’ve put off so many projects because I didn’t believe I had the necessary skills to do them “properly”. My plan was to do projects A, B and C first so that I learned how to do X, Y, and Z, which would then enable me to do this project “properly”. And since I made that plan 5 years have passed. Five years that my ideas have existed only on paper. And all because I didn’t have the guts to “Just Code”.
I realise this post got rather long and, so in summary:
If you’re looking to get coding, the best way to do it is to just give it a shot. Don’t worry too much about the “best” way of doing things, that will come with time. There are plenty of places on the web where you can get started learning how to code, but it really, really helps if you have a pet project you want to make. Plan it well, talk to people and ask for advice on how to build it, but the most important thing is that you just get started. Nobody gets it right the first time, and that’s OK. Because learning while doing is better than regretting not doing it at all.