How to be an effective web development student
Learning how to learn
Are you overwhelmed by the amount of stuff as web people that we are all supposed to not just know but master?
It’s easy to feel like everything is spinning out of control, and that your skills are slipping.
Who benefits from this feeling? Not you. Not your work colleagues.
Part of the problem is that we are not encouraged to step back and plan what we want to learn: there is no structure, apart from whichever blog post gets us excited about the latest new technology. Learning happens best when it is planned and cumulative towards a planned goal.
Why is this? One influential idea for educators is the ‘zone of proximal development’: the idea that we have to reach a certain level in background skills before we can really understand new concepts. This is why it’s not a good idea to learn React without having a good background in javascript already. You might be able to follow a tutorial and get something up and running, but as soon as you stray from the path someone else has planned - what happens then?
How to plan your learning
We all know that the latest, cutting edge explanations and examinations of web technologies takes place on-line. Twitter observations turn into blog posts, turn into influential articles, and then become accepted good practice.
But do we need to start at this point? Would it sometimes be better to really grasp the fundamental concepts, to slow down and be sure that you are able to build on a strong foundation?
Even if books date quickly they have one important advantage: they’ve been checked by experts, and edited so that they introduce the concepts you need to know in (hopefully) a logical order. How often do you just read the bit that helps you with one small aspect of the code? (the page on PHP dates in my PHP book is the only one I ever look at)
This is one way to use books, but actually reading them from beginning to end is another. By all means, skip the bits you know, but look at the way the author introduces ideas and how everything is structured.
Learning by doing
A new discipline can seem overwhelming because there is so muuch to learn. It’s impossible to learn it all at once. So I suggest planning a project, but breaking it down into smaller pieces. Even doing this will help you recognise where your skills are lacking - how do I create this layout? I know where I need to get to but how? Identifying these problems and writing them down will make them seem more attainable. And each milestone you reach will encourage you for the next one. Learning by completing a project, rather than attempting to understand every part of a language will give you much greater insight.
Asking for help
Sometimes the best thing to do when you have a code problem is to step away from the computer. Don’t try another way of doing it, don’t search for another syntax error - just stop. Give yourself time away from the screen. You’d be surprised how often you spot the error when you come back to it, or the solution comes to you at weird times. Another good idea is to try explaning the problem to yourself - go through every step, one at a time. Explain it to yourself (or someone else if you can find someone who’ll listen) and you’ll often find that the flaw in your logic will be obvious.
Copying as practising (NOT plagiarism)
We all know that the original, unique solution is the one everyone remembers. But to get to that point you need to understand your discipline and your medium. So don’t start wanting to create something new, start by wanting to create what has come before - copy. Copying gives you a way of measuring your ability with tools (software, pens, pencils, whatever tool it is) - can you reproduce what’s been done? The amount of brain processing power you need to devote to figuring out what the tool will do generally relates to the quality of what you will produce - mastering the tools means you can think more about the solution, less about how to actually bring it into being.
Knowing when it’s working
If you can predict what the code is going to do before you run it, or view it, and it does that - congraluations, you’re starting to achieve mastery. You’ll also know what you need to learn when things don’t work as expected first time (I’m looking at you, flexbox). Beginners get frustrated when things don’t work as expected, but people who have learned effectively understand when their mental model of how things work in the real world deviates from how the code is implemented.
More generally…
These are adapted from Phil Race’s advice for students.
You’re assessed on what you show, not on what you know. (Of course, if you don’t know it, you’ve got very little chance of showing it anyway, but the problem is knowing it and not managing to show it; just knowing it is far too risky). Whatever form of assessment you’re preparing for, practise giving evidence of what you know — writing it, talking it, repeating it, and gaining speed and confidence in showing it when it matters (such as in exams).
With any kind of assessment, read the briefing properly. You’re measured on how well you do exactly what is being asked. You’re not measured on all the things you might do that aren’t asked for. Even in an exam, keep looking back at the question, and make sure you’re still answering it and not going off on a flight of fancy.
Keep your eyes and ears open for clues and cues. You can work out a lot about what is going to be assessed from things said by tutors, and from syllabus documentation (look at the intended learning outcomes, for example), and from all the information you can dig up about past assessments or exams. When possible, also talk to some students who’ve already succeeded on the course or module.
Build your own question bank. Collect and compose lots and lots of short, sharp questions to practise answering. The more often you’ve answered a question (in writing, in speaking, any way you wish) the faster and better you get at answering it. Exams, for example, really just measure how practised you have become at answering exam questions, rather than how much you know.
With coursework, be your own editor. The mark you get for coursework depends on the edition you hand in. You can do a lot of improving by editing several times before you hand it in, each version getting just a bit better. Editing on a computer is so easy, but save it as something different every time — don’t risk losing something you may want to go back to. Besides, if you’ve edited your material well all the way along, there won’t be any obvious errors left (spelling, grammar, and so on). Such errors would have given the impression it’s a hasty last-minute attempt — not likely to put any assessor into a generous mood!
Get ahead of schedule. Fend off dangers of crises, illness or anything unexpected getting in the way of your progress. With coursework, it can be really good to draft it really early, put it away for a week or two, then edit it all the better by being able to have a fresh look at what you actually wrote, and seeing how much you can improve it to turn it into what you meant to write. This is much happier than wasting a lot of time putting off the evil moment of getting stuck into it.
Talk a lot to fellow learners. Talk about the work you’re doing. Listen to them — you’ll get ideas which will make your own work better. Explain things to them — every time you explain something you become better at explaining it, and can do so better when you come to do your own assessed work. But beware — make sure that (if it’s coursework) when you come to do it in earnest, it’s your work. The earlier talking is to help you get your head around it — but your assessed work needs to be about how well your head has now got round it.
Use all the feedback you can get. Take particular note of previous feedback from tutors. Things they liked may well increase your marks in future work. Things they didn’t like may well be worth avoiding in future. Feedback needs to be used — otherwise it’s wasted. Past critical feedback is really, really useful.
Before you hand in coursework, have yet another good look at the instructions. Check that you’ve followed these really closely. Check any briefings on word count, layout and, particularly, what exactly is asked for. It can even be worth doing a quick spell-check on someone else’s machine, in case (like me) you’ve accidentally taught your own machine some incorrect spellings!
Before you hand in coursework — do one more thing. Mark it yourself! Apply the assessment criteria yourself. You will often find out, in time, about marks you would have lost if you hadn’t done this bit of self-assessment. If you haven’t got the criteria, make some up on the basis of experience. Then make final improvements to your work so that it scores marks against all the likely criteria.