Hi! I’m Yeli.
During the day I’m a software engineer at LinkedIn working on the design systems. A lot of my day job is figuring out people’s pain points and solving for them. But I’m not here to talk about that.
At night, I’m what people like to call a creative coder.
It’s a term used to describe people who use code as a creative tool - to create art. I first got started with this in college. In one of my classes I was introduced to Processing: an open source language built on Java for learning to code in the context of the visual arts. From there I decided to create a concentration titled “Art and Code.”
In school I was toeing the line between creative programming & traditional tech.
Looking at my current position it’s pretty easy to assume where I ended up.
While I do not create creatively for work, I do a lot of artsy projects in my free time. I think I benefit a lot as a programmer from my experiences as an artist so I wrote and gave a talk about what art can teach us as a community of programmers.
1. To embrace our work as human
While it has its prodigies, art is generally made by ordinary people. "It’s difficult to picture the Batman throwing pots. The flawless creature wouldn’t need to make art."
So art is inherently human. What can we say about code?
Although code and art require many of the same inherently human traits (problem solving, communication), when we talk about programmers we say things like ‘coding ninja’ or ‘rockstar’ or ‘hacker’ or ‘god.’ That makes it seem like programming is out of reach & superhuman, which it isn’t.
"Companies may say they are looking for a rockstar or ninja to join their team, and white men are more likely to identify with or aspire to such descriptions."
Embracing our work as human allows us to:
- Make coding more friendly to all.
- Since error is human: bypass perfection.
- Bypassing perfection allows us to create more.
One of my favorite internet artists Darius Kazemi in a talk he gave about small projects said:
"In 2009 I released two creative projects that were the culmination of about 200 hours of research and work and bug fixing and collaboration. It got on a few blogs, and he estimates about 10,000 saw either one of those projects."
"In 2013 I released 73 projects. He spent about 350 hours total. He reached 500k to 1M people, and received coverage from all sorts of major news outlets."
What he did differently was that he started “making short, silly games in the course of 3-6 hours.” While he said the games were “kind of crappy,” he “got to finish something instead of staring at a design document wondering where to start.”
And the key here is that for him finished !== perfect. He continued, “I’m not saying “don’t finish your work, just radically alter your idea of what “finished” means.”
The projects we make, whether crappy, riddled with errors, or failures, have the added benefit of teaching us how to make the small fraction of our work that soars. You learn how to make your work by making your work.
2. Things don’t have to be so complicated
You don’t have to make for every edge case. Another great quote from my favorite artist Darius Kazemi goes: “I like to make things as computationally simple as possible. Simple because I only have so much time on this earth and I’d rather put out one project every week than every year. I don’t have time to write code that’s incredibly performant when it doesn’t have to be.”
The key words here are when it doesn’t have to be. I recently read an article titled You Are Not Google by Ozan Onay and it said: “Software engineers go crazy for the most ridiculous things. When we have to choose a technology, we end up in a kind of frenzy – bouncing from one person’s Hacker News comment to another’s blog post until, in a stupor, we float helplessly toward the brightest light and lay prone in front of it, oblivious to what we were looking for in the first place. This is not how rational people make decisions, but it is how software engineers decide to use MapReduce.”
Artists don’t fish for complexity where there doesn’t need to be and we shouldn’t either.
3. The tool serves the function / what’s important is the idea
With code and art: The whole point is to bring an idea to life. The tool doesn’t matter more than what you made but I think in tech we get trapped in the discussion of this vs this vs that (way too often). And that kind of competition leads to hierarchies. Python developers > Ruby developers e.t.c. And comparisons like that are stupid. Whatever skills others possess is something they need to do the work they want to do. It wouldn’t help you in your work even if you had it. Like in art, we should try and reframe conversations to be more about the idea and what needs to be created.
how > what + why ↠how it is
how < what + why ↠how it should be
4. How to make something useless
When I would demo my projects at tech fairs, some of the questions I would get are “How can this be monetized?” And “What are the commercial applications of this?” even though I frequently made projects without answers to any of these.
Artists make a lot of stuff simply because they want to see it out in the world. They’re not always ‘solving’ for ‘real’ problems. As developers we have the same power of creation but we seldom make useless shit. Instead, the current in Silicon Valley is to reframe its business interests as “changing the world” and /or disrupt things not in need of disruption under the same premise.
This approach to creation is what prompted the Stupid Shit No One Needs and Terrible Ideas Hackathon, which is a “one-day event where participants conceptualize and create projects that have no value whatsoever.”
Some of the projects include a Chrome extension called NonAd Blocker that blocks every part of websites except for the ads. Shakie, "a camera app that will only snap a photo if you shake your phone vigorously." Unfriend the Poors helps you find and unfriend your poor facebook friends. Outcognito Mode is a Chrome extension that publicly tweets every website you visit and everything you type.
You may be asking why talented people would waste their time doing that? One of the founders shared a story of how they would be invited to “24-hour hackathons, where the goal would be to end water crisis.” A lot of time and energy is spent creating solutions that claim to be changing the world but aren’t actually doing so. Rather than that, "when you produce something that has no value on purpose, what you're really creating is a critique."
If we spent more time making work exploring spaces and critiquing, we’d be closer to knowing how to making solutions. Also, in a place where metrics and monetization are most important, being able to make useless shit can actually be quite empowering and subversive.
5. To embrace uncertainty
In programming and art, we often start with a blank slate. But often, before we get to the end we have a clear idea of what it looks like. We have a spec sheet, if you’re doing test-driven development, maybe you’ve even written your tests.
But it’s said about art that "Art is like beginning a sentence before you know it’s ending." For example "Many fiction writers, discover early on that making detailed plot outlines is an exercise in futility; as actual writing progresses, characters increasingly take on a life of their own, sometimes to the point that the writer is as surprised as the eventual reader by what their creations say and do."
Of course the freedom art allows you is dangerous. "You may never get to the end of the sentence at all or if you do, you don’t say anything meaningful."
But it gives you is freedom to move and to surprise yourself.
Code, like art happens between you and something – a subject, an idea, a technique – and both you and that something need to be free to move - to respond authentically to the subject and the tools.
What’s necessary for success in a lot of cases is a knowledge of the problem you’re trying to address, a strategy to approach and a willingness to embrace mistakes and surprises along the way.
Thanks to / inspired always by ~
- !!Con - Keynote: The Creative Programmer By Catt Small
- Jenn Schiffer, Engineer/Artist - XOXO Festival
- Darius Kazemi
- Stupid Hackathon by Sam Lavigne & Amelia Winger-Bearskin
- You are not Google
- Processing
- Art & Fear: Observations on the Perils (and Rewards) of Artmaking: David Bayles & Ted Orland
- Kieran Snyder
- Try to be Good Podcast
Top comments (5)
Great post! I myself grew up doing things that are perhaps more on the "art" spectrum than engineering, but for what it's worth I really think of all my code in these sorts of terms. I really need a lot of creative freedom in my process, and it's probably why I needed to make my own thing instead of falling inline.
Lately I've been using more artistic metaphors in my own code-discussions. Think of your project constraints as a blank canvas. Sure you need to keep within these parameters, but you have freedom to be yourself in the process. Paint something great.
As I become better at the craft, I feel more and more artistic because I have a handle on the tools. Kind of like how you have more freedom to express yourself on paper if your sketching fundamentals are developed.
On a side note to note for folks, @peter and myself worked with Omayeli briefly a few years ago before she got into software development at all. It was amazing to hear that that she was slinging code at LinkedIn out west. So awesome Yeli!
Where can I find your talk?!
No video out yet, will let you know! :)
It is indeed true that an artist can do almost everything since their minds are playful and ready for new ideas. I am an accounting student, ad I also love art. So, for just a few months, I decided to explore more about art, and I find it to be my stress reliever from my studies. My mom recognized my mood changes, and I got all her support. She gifted me my first set of art supplies since I had just borrowed my materials from my cousin.
Awesome post! I think as software development becomes more "mainstream" and the barriers lower, we will eventually end up having people who use a lot of creative energy when developing software.