A creative person’s guide to computing
This year, for the first time, we are running the Raspberry Pi Creative Technologists programme, mentoring a small group of young people aged 16-21 years as they explore using digital technology to enhance their creative pursuits. One of our creative technologists, 21-year-old writer Hannah Burdett, recently published today’s post on her own blog, and when we saw it we wanted to show it to our audience as well: it’s a wonderful and useful piece about what it’s like to enter the world of digital making as a beginner, and why she hopes you’ll want to.
Hannah Burdett, Raspberry Pi Creative Technologist, by Sam Alder
It’s been six months since I started with Raspberry Pi. To begin with, I was terrified and felt like I didn’t belong, but I’ve reached a point where I’m truly enjoying what I’m learning. People think of arts and science/technology as polar opposites, but I’ve always thought that the two can be merged in diverse and constructive ways. Thankfully, Raspberry Pi think so too, and have let me mess around with ways to do this. My hope is that in the future more creative types will utilise technology in their work, and it will be beautiful. So today I’m sharing a few tips to help you get started. Of course, I’m nowhere near an expert, but I do know exactly what it’s like to enter the world of technology as an outsider and beginner.
Treat learning to code like learning a language
There is a good reason why it’s called a coding language. It has grammatical rules to structure what you’re inputting: for example, when to use brackets and quotation marks and full stops and capitals. Coding is just as vast as any other language, and there are dozens of different coding languages to choose from, each with their own idiosyncrasies. And it takes just as long to learn. You can’t expect to pick it up without using it frequently; practice is key. You need to devote time to learning the rules, but there’s plenty of opportunity to get help.
I would recommend the book Python for Kids by Jason Briggs. It is designed for children, but suck it up and it’ll prove it be a useful tool. I use it as a reference guide, dipping in and out, but not necessarily reading it from A to Z. There are also free online courses, and an infinite amount of documentation to learn from.
It’s more creative than you think
If the thought of learning a language makes you want to cry, then don’t despair. Just as creative writers use language to create complex and thought-provoking stories, so does code. When constructed correctly, code forms a kind of linear narrative, telling the computer what happens and when, just like how stories inform the reader. Something equally creative and varied happens too, whether that’s a video game or a dancing robot. It also requires a lot of editing.
Digital making with play dough: light-up models at an earlier Maker Faire UK, an extremely creative event | Photo by Mitch Altman / CC BY-SA 2.0
What’s more, the community of digital makers, hackers and programmers includes lots of people who are just as imaginative as writers in traditional media. When I was at Maker Faire UK, I was inspired by how creative the makers were. The exhibits were full of people who had started out with a question: ‘I wonder what happens when I do this?’ They put two things together (or five, or six), and if it explodes then it’s all the more fun (except when you have to buy another part to replace it; oh well). It’s an open, free way of exploring and creating. The key is to not limit your mind, not to set goals (although tempting) but to focus on experimenting with pushing the boundaries of the technology.
Prepare to change your mindset, and don’t be disappointed when it doesn’t work
I say when because, inevitably, it won’t work. Even if you’re following guidelines or instructions, eventually something is bound to go wrong. I struggled a lot in the beginning because I didn’t know how to make the tech do what I wanted it to, and thought I was a failure. I’ve got into the habit now of thinking, ‘Okay, why didn’t it do that?’ and ‘It’s interesting that it’s done x instead of y’. Let the technology surprise you.
This is not Hannah’s handwriting; hers is probably much nicer
Part of learning is accepting that maybe you won’t be good at it straight away, or you won’t pick it up naturally. A lot of people, especially young women, feel a pressure to be good straight away. Don’t worry about other people’s expectations, just have fun with it. You may learn more slowly than others (I certainly do!) and that is perfectly okay. This is why an open mind is so useful. I’ve had to completely change my mindset over the past few months, but I’m glad I did. Although writing is creative, I’ve been doing it so long that I have a process and routine. I know what I want to write when I begin; I have set intentions and goals, and I set time limits. When it comes to programming, this mindset does not work at all.
Things will not go as you planned. Things will break, or you’ll make mistakes, and the outcome is entirely different to what you expected. This can (as it did for me) lead you to feel like you’ve accomplished nothing. The best thing is to have no expectations of yourself other than to learn something, or try something new.
Steal from your heroes and ask for help
This is a statement that often crops up in the literary world, but it applies here too. I mean, don’t literally steal; always give credit when you’ve used someone else’s code, or a tutorial. But it’s often easier to adapt other people’s work rather than make something entirely original. It also integrates you into the community, and creators will often be really pleased to see their work put to use!
Raspberry Pi have loads of online tutorials which are designed for kids, but suitable for all beginners. I have recently been creating mini projects with Scratch, a programming environment that lets you develop interactive narratives and games. It functions like code, but instead of typing, you drag and drop components to build the script. I even published a mini game which you can play yourself!
Balloon Popping, a game written by Hannah Burdett in Scratch
The best thing about Scratch is that for every project, you can look at the ‘code’ being used. I made my game by finding similar projects and seeing how they work. After doing this for days on end, I got used to the various functions, and now I enjoy throwing bits together and seeing what happens. I’ve spent so much time on Scratch I’ve actually started dreaming in Scratch code!
Hannah’s very playable balloon-popping game, mid-pop
Scratch also has a great community, and users will always be happy to reply to forum posts if you get stuck. This leads me on to asking for help. Do it. Websites like GitHub exist so you can share your code with others, not only so they can use it, but so people can suggest improvements or fix problems. The online community is vast and amazing, so use it!
Remember, if you don’t try you don’t succeed. And I’d always prefer to try and fail than never do anything at all. If you’d like to talk more about this tech world, please feel free to contact me.
At the end of the programme, the Raspberry Pi Creative Technologists will be hosting an exhibition in order to showcase our projects: a culmination of a year’s work. If you would like to know more about my project, or would like to attend the exhibition, then keep following my blog for more information. You can also follow me on Twitter.
We’ll also be talking about the creative technologists’ final exhibition here, of course; Hannah is working on a project that lets players journey through a cooperative, interactive story that engages them in working together. We can’t wait to see what she and our other creative technologists make. Most of all, we’d love to see more people who are creative, but who might not usually consider digital technology as something they can use in their work, giving it a try. We think our Make resources are one good place to start.
11 comments
Homer L. Hazel
Congratulations on becoming a successful programmer. I am old school so I don’t understand all of the new terms like digital maker. There are a few things I have learned through the years that have been helpful to me.
1. You have to be devious. It’s a trite statement, but you sometimes have to think outside of the box. You may need to think of a new way to solve a problem.
2. I find that I have to have something to work on. I have a Raspberry Pi setup, but do not use it a lot since I don’t have anything that I have to do with it. But when I find what I absolutely have to work on, I will be fine.
3. One thing you will probably discover if you have not already done so is that when you are facing a problem, it is nice to talk it out with somebody. That somebody does not even have to know how to code. Just organizing your thoughts and talking about it are often enough for you to see where your problem is.
4. Never give up. If you cannot solve your problem using method A, go ahead and try method B, and then C, and D, and E and so on.
Good Luck, but I don’t think you need it.
Raspberry Pi Staff Helen Lynn — post author
Re (3), a few jobs ago I adopted the rule that I wasn’t allowed to go to my line manager for help with a technical question until I’d already tried asking the plant I kept on my windowsill. My boss was great at finding solutions and explaining things and was always happy to chat, but I started to feel silly about the number of times I’d ask him something and realise as I reached the end of the question that the answer was obvious. The plant approach doesn’t work quite so well in shared offices, unfortunately.
Homer L. Hazel
I never thought of a plant. I guess because I never had one in my office. I knew it would die in about a week. Plants do not do well around me. I am glad it worked/works!
Leo Leibovici
In a previous job, we had a small bear that could sit on top of your monitor, (I would probably use a Tux these days!) if stuck, you explained the problem to the bear and almost always it got solved!
Jack Chaney
The problem with the plant approach is if, you get into a shouting match; when the plant doesn’t agree with your path of logic :-)
elParaguayo
I particularly love this bit: “Treat learning to code like learning a language”. I studied languages at university and have always been interested in understanding how a language works and the relevant grammatical rules and make sure I fully understand this before I need to write an essay in that language.
My approach to learning Python was therefore exactly the same, I started with the basics and worked slowly through it. When someone gave me an answer to a solution, I took time to research why the answer worked.
I am therefore always surprised when people say they’re new to coding and are attempting to do incredibly complicated things without learning the basics first as it’s an approach that just doesn’t make sense to me (don’t worry, I still try to help – I’d hate to deter people from coding!).
I love the feeling of fulfilment I get from learning a new language and when you get to point where the code “feels” right.
Yvan T.
I for myself have the philosophy that a computer will always do what you “tell” it to do. BUT and there is a big “BUT” it may not be what you want it to do.
Also if you apply the KISS principle (Keep It Simple and Stupid) it tend to keep the Murphy’s law at bay.
Caleb Hattingh
I strongly agree with “Treat learning to code like learning a language”. I’ve set up a website to use spaced repetition to teach coding skills, starting with foundational command-line skills. I’ve used Duolingo, the language-learning app as an inspiration, exactly because I think the way we teach coding needs to change to be more like how we teach natural languages. Like Duolingo, I’ve set it up so that tasks repeat, to allow your brain to make the same kind of connections that you need for language learning, and other similar pursuits like learning music.
Great article. I strongly believe we need many different points of view in the tech world, and especially more creatives and designers.
Caleb Hattingh
I forgot to mention the URL, my site is https://codermoji.com
Navyscourge
Well done with this great analogy for coding; such a great explanation.
If I may, can I extend it a little, since you mention that coding is like writing a story. A good story will benefit with a little planning. Just a few lines will do that cover the plot. These will help you to keep focussed on what you are writing. You can discuss your plot with someone to see if it makes sense, even before you have written a word of the story. When you have finished the story, you would check the spelling, grammar and so on, even checking that Henry the dog has not become Henry the cat.
In coding, the simplest design establishes what your code should do. You can identify the ‘tricky’ bits and tackle those first, so if you can’t make the code do what you want, and have to do it differently, you don’t have a lot of code to rewrite. You should probably get into the habit of finishing the code for the design before you start adding new features too.
The checking bit is important; if your code breaks the users are not going to use that code for very long. Pretend you are now your enemy, and that you need to prove this code is rubbish! Try to break it, use it in ways it was not intended and give wrong answers to any questions asked. This can be fun if you do this yourself, or get a friend to do it too if you can accept it when they do break it.
The design and testing of code is not often mentioned when encouraging people to code. If you do design, code and test you might find that your code is better than if you don’t.
Rachel Rayns
This is fantastic advice.