The One Who Expresses Herself Through Code
Charlie Gerard is a senior developer at Netlify, a Mozilla tech speaker, and a Google developer expert in the field of web technologies. She also likes to spend as much of her spare time as possible producing creative code and building interactive prototypes that combine science, art, and technology. While at the 2019 edition of dotJS, she made time in her schedule to talk further to Behind the Code about her work—find out why she has no hesitation in likening coding to art, where her inspiration comes from, and what advice she would give to those looking for ways to fit in personal projects alongside their day job.
Kick-starting things at boot camp
Building a portfolio of creative projects
Code = art
To me, the link between programming and art is they’re both a way of expressing yourself. A lot of the time when people think about programming, they’re really only thinking about functional things, like, “I need to build a piece of software or a website to sell something.” But I think that anything can be a way of expressing yourself, coding included. There are so many things you can do with code—you can create music and visuals, you can create little robots or, now with machine learning, you can also generate works of art. And I think it’s definitely a way to express yourself, because before you write those lines of code, there’s nothing. And then, all of a sudden, you write some code and it’s not only just… There’s also a lot of thought process involved, such as, “What am I going to write? What am I going to try to generate?” And I feel like creating art is similar—you just get inspired by a lot of things and you express yourself, and whatever you use to create your art is up to you.
Searching for inspiration
I have a list of things that I want to explore, but I don’t always just think about tech. I spend a lot of time looking at what research centers are doing—sometimes it’s work that has nothing to do with technology. So, sometimes, I check out what the Disney Research lab or the Google Creative Lab are doing, for example. And I look at what they’re doing because a lot of the time they concentrate more on research. They don’t always build a prototype, but they sometimes explore certain areas of even just physics, and then I think about it, and I’m like, “Oh, I could actually mix technology with that.” Something that I was looking at recently was to do with plants and how they actually use electrical signals as well, and I was kind of like, “Well, I could actually get that data with Arduino and build something with it.” And I don’t always know where an idea might go, but I like that moment when I look at something totally non-related to tech and find a way to mix it with tech. Otherwise, what I do is, when I know that I want to learn something new about a certain technology—for example, machine learning at the moment, I’ve been working on that for the past year—and I know that if I just read a tutorial about how to predict the price of Bitcoin, for example, that’s not really something that I want to spend my time on. It’s like, “Well, maybe it would make me rich, but that’s not really my goal.” So I like to look at a certain technology or a certain framework and spend some time thinking, “OK, what am I excited about?” And then things progress slowly like that and I just try to think about different ways of using technology. When I built a prototype around the Beat Saber game, I remember I was just watching a video of somebody playing actual Beat Saber and I was thinking, “Well, I can’t because I don’t have the gear, I don’t have a VR headset, and I definitely don’t have the space, I don’t have the game.” But then I began thinking, “Well, wait, maybe I don’t have [an] actual saber, but I know that you can enable 3D in the browser and I know that, with machine learning, you can detect the motions of the body. So, well, I can just pair that and make my own little prototype.” And so, little by little, it’s a thought process.
Don’t expect to know everything straight away!
I think that picking challenging side projects has helped me to understand that I’m still learning—I’m not supposed to be immediately good at something I’ve never done before. I can’t know how to fix a problem I’ve never seen before. I’ve got better at understanding that it just takes time. I’ve gotten a lot more patient and a lot more resilient about keeping going even when I feel like I’m failing. Or if I don’t understand something, I make sure I don’t feel stuck. So if there’s something that’s too big and I feel myself starting to give up, I try to break it down into pieces and find the time, maybe an hour each night, and try to tick the boxes to finish that project. When I started, I wish people had talked a bit more about the fact that you don’t have to know everything straight away. Especially when I started my career, I was looking at senior developers and thought they knew everything. I thought that, after five years of experience, you’re supposed to have all of the answers. And I wish that more people were open about the fact that you’re not supposed to know everything. Maybe you have a better understanding of how to get somewhere, but you don’t know everything by heart.
Finding a work-work balance
I often get asked how I find the time to do all of this. And I think that, over time, it’s become a bit easier because I’ve accumulated a certain amount of knowledge, so I don’t have to spend as much time on things as I used to, but I also try to be very organized about how I spend my time. So, for example, I like to have this… I was going to say work-life balance, but it’s probably more a work-work balance! What I mean is that, for example, I try to keep my work hours as 9 AM to 5 PM. If we’re not releasing, or if we’re not fixing a bug or something, or if there’s no real reason for me to stay at work longer, then I won’t, because I know that, when I get home I still have my own work that I want to do, and I know that it makes me happy. And if I don’t do it and if I focus too much on my day job instead of the things I do during my own time, it doesn’t make me happy.
Demystifying the technology
One of the purposes of my blog is to remind me how I built something. Sometimes I spend a lot of time building something, and if I don’t write down a tutorial, six months later I will probably have forgotten exactly how I did it. So there have been a few times where I’ve gone back to a tutorial to remind myself how to do something. My other main goal is to demystify some of the technology that I play with. I know that if I try to explain things properly so that people don’t end up struggling the way I did when I started a particular project… If I want people to get more creative and to not be scared to play with technology, it’s important to show them, “Hey, I started like this and maybe this word seems hard to understand, but all it means is that.” And I try to find examples that people can relate to, so that, with machine learning for example, instead of just throwing out the names of algorithms, I’m like, “OK, you don’t have to care about how they’re implemented, you just have to care about how to use them at first, what they’re good at. And then if you want to dive deeper, you can do that.” What I love is some of the feedback for my blog posts is people saying things like, “I tried it as well because I could see that it wasn’t that hard,” and then I’m like, “OK, I win!”
This article is part of Behind the Code, the media for developers, by developers. Discover more articles and videos by visiting Behind the Code!
Want to contribute? Get published!
Follow us on Twitter to stay tuned!
Illustration by WTTJ
- Ajouter aux favoris
- Partager sur Twitter
- Partager sur Facebook
- Partager sur Linkedin