This is a very demanding full-time eight-week course that covers a lot of material in a very short space of time and requires a very high level of commitment. It is probably not suitable for someone who has any other significant commitments, especially if they have no previous programming experience.
Before you start
After you have accepted a place, we will provide you with some exercises to help get you started. These are not compulsory and are not a prerequisite for taking the course, but they will cover material that will be very helpful once we get started. We strongly recommend that you do them.
This course is taking place at Collective, directly above C/159 on Camden High Street, two minutes walk from Camden Town tube station.
Collective is open all day Monday to Friday. Seminars, group activities and code reviews generally take place between midday and 5pm, but we recommend that you make full use of the space throughout the day.
You will need to bring your own laptop computer. If you do not have a laptop, we may be able to provide you with one, but you need to let us know in advance.
You will also need a pair of earphones for listening to lecture material.
Personal study time
We make a lot of use of online video material, for which you will need to make time each day for self study.
The pace at which we get through the curriculum will depend on the pace of the whole group. In order to get the most out of the course, it is important that every member of the group has mastered the material before we move on. So, if you find you are getting through lessons faster than others, use some of your time to deepen your knowledge of topics you have already covered by pairing up with somebody who is still working through it for the first time.
You are encouraged to work together on problems. If you do not understand something, ask a fellow student for help. If somebody asks you for help with a problem, offer to pair program with them for a bit. Always start by giving them time to explain their understanding of the problem. Often just the act of explaining a problem can reveal the answer. Do not be too quick to provide what you think is the solution. Above all, treat another person’s questions as a learning experience for both of you. It is surprising how useful to your own understanding of a problem helping some somebody else with it can be.
In pair programming, one person is at the keyboard typing code and the other is next to them discussing the problem as they work on it together. Paired sessions can last for a couple of minutes or several hours.
Pair programming is helpful because two people will together have fewer gaps in their knowledge than each of them separately, but just as importantly, talking about a problem as we are trying to solve it can have an extraordinary effect on our understanding.
If you are not used to studying or working collaboratively, it can take a while to get used to pairing. Embarrassment at not knowing something or fear of appearing stupid can get in the way. It’s worth the trouble of overcoming those feelings. And if you do not suffer these doubts, pairing is a good opportunity to learn some humility: the problem has not been solved until two people have understood it and had a part in reaching a solution.
Sometimes, even with two people, it is possible to get stuck. In that case, take a break. Have a cup of tea. Go for a walk. Do a bit of Google research or check Stack Overflow. Or close your eyes and try to visualise a solution. And then come back to the problem with a fresh perspective and some new ideas.
Perhaps you might find pairing with one person particularly productive, but make a point of pairing, at different times, with everyone in the room. It’s a great way of getting a different point of view and seeing how different people think about a problem.
A code review is when two or more people look at and discuss a piece of code together after it has been written.
Code reviews can be useful when two people have been working on the same–or different parts of a–problem and they want to compare their solutions. Very often (actually, always) a solution to a problem can be coded in multiple ways. There is always more than one way to do it. A solution might be elegant or easy to understand or short or quick to run or it might use a particularly satisfying idiom, but it usually isn’t all of those things at once. Every piece of code that gives the expected output is doing something right.
Code reviews usually happen when you have finished working on a piece of code and want feedback on your solution. As with pair programming, explaining your code and discussing your design choices with one or more people can deepen your understanding of the problem and give you valuable insights. Code reviews are useful for the reviewers, too, because it cultivates the ability to read other people’s code, which as a programmer you can never do too much of.
Unlike pair programming, code reviews can involve more than two people, they do not often last very long and the reviewer does not usually get involved in the coding of a solution.
We encourage you to blog and tweet regularly about your experiences on this course. It will provide us and prospective students with valuable feedback.
Treat everyone at Collective with kindness and respect. Do not make remarks that are likely to be offensive to others. No subtle sexism (or any “isms”, for that matter). Do not put other people down. Do not attempt to justify yourself when your behaviour is challenged, just apologise and move on.
When working at a computer, it is very easy to forget to look after yourself. Remember to take a short break every 20 minutes or so. Lean back in your chair. Place the palm of your hands on your eyes or slowly turn your head around and focus your eyes in the middle distance or out of the window for 20 seconds. At least every hour, go for a walk and stretch your legs.