 trying to understand it. In my introduction, I'd like to explain the significance of that phrase, the impact it had on my education. And then the main body of my talk, I'm going to look at three main areas from my training in fine art, and how those processes might relate to our work as programmers. So that phrase, stop trying to understand it. That was the guidance given to me by my lecturer when I attempted a formal education in programming. He was trying to teach Pearl, and apparently I asked too many questions. And I quickly learned in this formal education approach to programming that they weren't interested in the processes we followed, or even particularly the quality of the end result. It was very much a paperwork exercises. The lecturers wanted to tick the correct boxes. And this was a completely alien concept to me, because my initial training had been at an independent art school in Glasgow, where we were encouraged, if not instructed, to question absolutely everything. I looked up the prospectus recently and found that the use of words that they used to describe the official course description talks about how in the first and second year you do maybe some more general core skills. And then third and fourth year, students undertake a self-directed program of study leading to the creation of a self-initiated body of work for assessment and exhibition. We were absolutely left our own devices. We were very aware that our education was our responsibility. And so we made sure we asked the questions and that we understood what we were meant to learn. So with that background, I found my experience of formal education and programming just completely bizarre. And it was completely alien to how I wanted to learn. So my response to that was just to reject it and leave. But then I find myself in this kind of limbo situation, because I had already stepped away from the fine art world. I knew I didn't want to be a fine artist. And I was still curious enough to want to become a programmer. So I were to go from there. So I did two things. Firstly, I went online. And I was delighted to find online communities where I was welcomed as a complete beginner. And pretty moved, actually, that I could go on there and share a problem that I was having. And the next day, maybe somebody in Australia, someone in America would have offered a solution to my problem. That generosity of information, I found just amazing. And as well as all the technical support and learning, there was a lot of learning through play. Games like Photoshop tennis where the players would bounce digital files back and forth and develop in their skills through that game. And even if you didn't have the Photoshop skills to take part directly, other people in the community took part just by offering critique on the work. And that fueled the players' next serve. That sense of community and support I got in the online communities really helped my motivation and encouraged me to pursue my learning as a programmer. The second thing I did to learn was just traditional learning through books, as well as technical material. I really enjoyed looking at the work of designers, interactive designers like Hillman Curtis. He talked about really getting to the core of a project. He used the phrase you needed to eat the audience, which I loved. So I tried to bring that thinking about getting to the core of the project and understanding who it was for and what the point was to my business work, solving problems for my clients. And that kind of need to solve problems just gradually led more maybe from front end development work into action script and then into PHP is just as my clients needs developed or demanded. And that worked sort of OK for a couple of years. But I saw it more as a means to an end. I didn't really think of myself as a programmer. And I didn't see the process as a particularly creative endeavor. That started to change when I heard about Ruby because I heard people talk about this language with an enthusiasm and an enjoyment that I just hadn't heard before. It sort of hadn't occurred to me that people had fun programming before. So I saw learning Ruby maybe as a new opportunity for me to take a fresh look at how I learned and just kind of start again properly. So I went to the States and took a couple of the pragmatic studio courses. And the experience of learning within that environment was completely revolutionary to my learning because those studios were led by people like Mike Clark, Chad Fowler, Dave Thomas. And here were people that not only cared about the processes we followed and the decisions we made, but were passionate about encouraging that dialogue and questioning why we did things a certain way. Could we do them better? And there was a lot of group discussion in all directions in the studio between peers and between the trainers. So that was my kind of introduction to my education into it. And I'd just like to look at these three key areas that I think are relevant to us from that background, from that training. Firstly, how we approach our work. As an artist, in fine art, usually the approach, the starting point is to look inward. Who am I? What makes me tick? What are my fears? What are my motivations, my memories, my passions? And that dialogue with myself informs the product, the artwork that I create. As programmers, as designers, for the most part we're creating work for other people. We're solving other people's problems. So it benefits the work if we pay attention to what are their fears, what are their motivations, their distractions. Look beyond the technical towards the more human factors as well in your projects. When we were approaching new work, we were very much encouraged to embrace the unknown. One example of this, at one point I was interested in installation artists like Bruce Nyman who used materials like neon light bulbs. And I really wanted to have a go at doing something with a material like that. The only slight hitch was that I knew absolutely nothing about electronics. And I had even failed my how to wear a plug practical exam at physics in high school. But luckily my tutors listened to what I wanted to try and do and decided that it didn't matter at all, that I had no idea how to do that or was possibly going to pose a danger to myself and the rest of the building if I attempted it. And brought in somebody who could show me, who could educate me about circuits. And learned enough that I was able to construct this piece which was essentially a timber frame suspended off the ceiling with circuits running across that, suspending all these light bulbs down. That created these passageways that you could walk through the piece. And it wasn't wildly successful or interesting really as a finished piece of art, but as a lesson in just learning that it didn't really matter if I knew how to implement the idea, that I would be able to find out how to do that if I wanted to follow it through. And that's one thing I definitely take away from that training is just that it's good to just preserve that sense of the unpredictable. We don't always need to know exactly how to implement something. If you want to do it, that'll be enough. You can always find the support that you need. But obviously if we're going to venture out and deal with the unknown, we're going to come across maybe some difficult challenges. An example of this towards my final examination, I wanted to create a piece, an installation that was essentially a very long timber frame. It needed to look as if it was part of the architecture of the building. It needed to look professionally made and convincing, otherwise it just wouldn't have worked at all. And I had some joinery skills at this point, but I had no idea how to make something on this scale without essentially this would need to be made in sections. And I didn't know how to do something on that scale without maybe it twisting and looking on convincing. So how I dealt with that challenge was kind of to put it to the side and think, well, how do people deal with a bigger challenge along a similar line? How do people build houses out of timber? And I managed to persuade my college to let me have the time off and pay for me to go on a course to learn how people build timber frame houses. And on that course, we learned about really quite basic joinery methods that enabled people to build timber frames out of maybe slightly cheaper, shorter sections of wood that they could join into with these particular types of joint into long pieces. And obviously, if these pieces were strong enough to support a whole building, they were definitely going to work for my frame. So I was able to return armed with that knowledge back to my initial challenge. And it now seemed totally easy how to figure this out. And I knew exactly how to plan the construction of this piece. So the second area, how we implement, how we execute our work, I think primarily as creative makers, we have an inbuilt desire to be making, to be in development all the time. And that's a real healthy thing to keep alive. One example where I learned how strong a feeling that was for myself, and I had my first gallery show where we were given this gallery. It was a group show, and we had to install a piece of work that would run for a week. My installation for the show, I built this tar bricks. And when it was installed and I was meant to leave and walk away and let this thing run for the week show, I just felt kind of uncomfortable walking away from it. I wanted to kind of continue engaging with the work. So I decided that what I would get around this feeling was I would sneak into the gallery every morning that the show ran. And I rearranged the bricks into a slightly different formation every day. And looking back, it's almost like a reverting to that childhood sense of play, literally with building blocks at this point. And at the time, I justified it with kind of already farty nonsense about what this symbolized and what effect it was going to have on the people coming in and out of the gallery space. But really, it was just for my own pleasure of playing with these pieces. And the next natural step from that was being aware of the limitations and the connotations of these bot bricks was, hmm, I could make my own bricks. And if I make my own molds, then I can have bricks in whatever shape I want. This photo, I wish I had a wider shot of this photo. It cracks me up because like three feet in any direction or all the other students that I had to share a studio with possibly quietly working in a sketchbook. And I must have been an absolute nightmare with my cement mixer. A good friend of mine, Gailie, reminded me that we met her in this studio space. And she reminded me that my first words to her were, hi, my name's Keevee. Do you mind if I build a wall between us? Or if you did. And I wanted to show you this quote by Brendan Dawes. All I want to do is make stuff. I don't care whether it's in flash, objective C, or fuzzy-filled. So I would just say, if you've lost that kind of sense of play in your own work, I'd recommend you figure out a way to get that back because that desire to be making and having fun in that process is pretty critical to us as creative makers. And really, in our world, it's pretty easy for us to do that, to experiment and to play with our work. I can assure you when your materials actually weigh a ton in weight, it's really hard work to do daily iterations of that. But our work as programmers, it's super easy and lightweight for us to have fast iterations and to experiment and to play. So the other big lesson that we learned when we're about implementing our work is just being open to change. Partly not letting our personalities stand in the way of that change. So going back to this final installation was in the Charles Rennie Macintosh building, in this quite famous corridor at the top of this building where I was installing this piece that essentially split the corridor in two. And it was designed to try and mimic the existing architecture, except instead of panes of glass, it was this special kind of plastic panes. So it just played with the light in the corridor and whether people could see a reflection of somebody on the other side as you walk through down both sides of the corridor. And there was a hell of a lot of work went into putting this in place, like literally working through the night to get the installation in place in time. And when it was finished, my tutor here walked up and down to inspect it. And he said, actually, we'd like you to move it. And of course, my initial emotional response was, are you kidding? I'm exhausted, like, what? But the training kicked in and I was able to engage in a conversation about why would he think that and what would be the advantages of having it in this position, what exactly would work better or worse. But basically the suggestion was the better idea. And I stood on the side and had a heart attack and a group of people moved it. But really, that I was able to be open to that change led to a successful outcome, a more successful outcome for the project. And with something like that piece, or a lot of work in fine art, really, the artist has one shot at making that with that piece, at presenting that piece. So actually being open to big change in that world can be pretty terrifying, can be kind of heartbreaking. Whereas in our world, as programmers, it's no big deal. We really have such a luxury of the tools to our disposal for allowing us to experiment and make changes as long as we're obviously open to that possibility. Oh, I put this into remind myself the other thing that happened with that project. I realized about two days before the final assessment of that project that I had completely miscalculated the materials that were required. My math is absolutely terrible, as anyone who's had to split a bill in a restaurant with me will know. But I don't know if you can make out in the photo, but essentially there's large sections of timber, and then these little thin sections that are pinned on to create the detail. And I basically only allowed for one side of the panel to have these details. So two days before the final assessment, I had to phone the timber merchant, my supplier, and say, hands up, I've made a total mistake in my calculations. Can I get the same quantity of timber again, delivered by tomorrow? And I've no money left to pay for it. But luckily, because I had built up a relationship with that supplier over these four years of ordering all sorts of cement and timber, they kind of just laughed, to be honest, and said, OK, and we got it sorted out. So it's good to know that even in those relationships, just honesty is the best policy, I think. And the final area, reflection, a massive part, focus in our training and fine art, was about group communication within the group. Group critiques was a massive part of our process. Not just from the staff, but with your own peers. You had every single project or experiment you dealt with, you had to explain to your peer group what your ideas were, why you'd chosen the materials you'd chosen, how you'd implemented. And everybody in the group was to offer their critique on what they thought of each of those areas. And I noticed as well, looking back at the official course material, that that's actually written into the course description, that under assessment, that the main area of assessment in the art school is on students and staff working together to provide critical feedback on both the art and its context. And I think in our world, that's maybe an area that we're not so good at, especially really actually giving critical feedback, maybe feedback discussions within our world are a little bit more superficial, and even just judgmental, rather than critical, helpfully. But it's in everybody's interests for us to create an open atmosphere that that constant group critique does actually develop, because you learn to put your egos to the side and really learn that that is how you develop your skills, how you develop your professional practice by taking on that critique. And would help us, I think, not have any kind of culture of blame when things go wrong. And so that as well as business and technical reasons for maybe having well-written tests or thorough tests, that you also just are aware of the human factors in that. You don't want to be the person in the team that drops the ball. So reflecting on tools and materials is another helpful area. Certainly in my fine artwork really drew on issues. And my upbringing in Belfast where there was a large security presence, and we didn't really have freedom of movement in the city. And my choice of materials maybe far too literally for the first few years reflected that inspiration. But it wasn't until I took a serious look at those choices that I made that the work started to really take off. And this piece in particular, I decided to have a complete change of direction with the materials and approach that I took. I don't know if you can tell in this photo what that's made of, but it's sawdust. So I had this gallery for one night because it took forever to install this. And then it was wrecked as soon as the gallery was opened. And so people could walk across this basically. And my interest was in how they would negotiate that space across this sawdust floor. But just that decision to take maybe a more subtle approach to my choice of materials just really transformed the success of the work. So as programmers, it's a good idea for us every now and then to reflect on what tools and materials we use. Is it just out of habit? Are we aware of the options available to us? Would we be able to justify the choices we're making, in particular libraries or gyms, against all the other options available to our group? And finally, I think it's worth reflecting on our community as a whole. I mentioned at the start how when I was trying to learn, trying to get into programming, that the real main thing that kept me pursuing that goal was that sense of community and feeling like I was welcomed into that. So I think it's important for us in the Ruby community to be aware of who we reach out to. Are we encouraging a diverse mixture of people into this community? Do we enjoy what we're doing? Do we enjoy the community that we're part of? What do I, myself, get out of it? And what do I, in turn, put back into it? I love this quote. I don't want to be a product of my environment. I want my environment to be a product of me. Slightly less good-sounding when you realize it's Frank Costello from The Departed, who really was a complete evil crime boss, but when I was in the teaching, talk upstairs briefly there, and I know that Sarah Allen mentioned just taking on that responsibility to make sure you create the world that you want to be part of, essentially, which I wholly agree with. I don't remember what that was. And I just wanted to end by showing you this. This piece of work I bought recently, some of you may have seen it, called Dirk Poster, where, essentially, the poster comes folded up in an envelope, taken out of this packet, and it's got, sorry, somebody else could probably correct me what the substance is, but some kind of dust all along the back end of it. So you open it up. You have to get your hands dirty by taking this out of the envelope and unfolding the poster. And on the other side, initially, it's a blank poster, but you rub your naid dirty hands over the poster to reveal the words. And the message is, the future belongs to the few of us still willing to get our hands dirty. So on that note, thank you.