Jennifer Dewalt is an artist that taught her self how to program by creating 180 websites in 180 days. She has been featured in publications such as Fast Company and Ars Technica. In this interview we talk about the days leading up to the project, how she made it through, and what is next.

Jennifer Dewalt, who are you? Tell us a bit about yourself.

My background is in fine art. My focus was on sculpture and performance art.

Five years ago I started getting involved in technology projects. Mainly iPhone apps and websites. I was mostly doing wire framing, and other non-technical things.

My artwork was heavily focused on how people communicate and project their identity. So about this time, I was becoming more interested in how we use technology to communicate.

At first, I wanted to start using the technology in art. Slowly I became interested in building things, and that is when I decided that I wanted to learn how to code.

 

“There came a point where I couldn’t imagine not building a website in a day. It became a total habit.”

Silly Kitty 180 Websites
Feed the cat fish. Its eyes get big and mouth opens when the fish gets close. Silly Kitty was website number 30 of 180.
Color Jam 180 Websites
An interactive music player, Color Jam lights up and plays a sound when a color is clicked.
 

Although I had worked on projects that involved code, I had never coded before. I poked around a few initial tutorials and never got far.

I decided that in order to learn how to code, I needed to sit down, take time out of my life, and focus exclusively on programming.

I didn’t know where to begin, so I decided to start small. That is where the idea for 180 websites in 180 days came from.

I have to ask—when you were a kid, what did you want to be when you grew up?

That is a great question!

I actually wanted to be a neurobiologist. I entered undergrad as a biology major with the intent of doing research in neurobiology.

But when I got to college, It just didn’t feel right for some reason. I don’t really have an explanation other than it didn’t seem fulfilling.

I understand. When I went to college I thought I was going to be an architect.

Let’s talk about the 180 websites project. What was the week leading up to that project like?

Intense.

The whole 180 websites project is housed in a Ruby on Rails application. I didn’t want to start with Rails, but I needed to set up the structure. That way I could focus on Rails later in the project.

Fortunately, I had a friend give me some notes about how he set up his website. I was pounding my head against the desk, because I had no idea what was going on. I eventually worked through it.

Why Ruby on Rails? As someone who was non-technical, how did you decide that was where you needed to start?

I had worked on some projects in the past. The last project I worked on was a social news website that was built in Rails. Plus, I live in San Francisco, and am surrounded by tech and startup culture. My friends that program know Rails, so it seemed like the best option.

I also spent a good time looking at other websites and seeing what technology they were using. The ones most interesting to me were using Rails.

Between those two things it seemed like a natural fit.

That is fair.

Did you leave your job to start programming? You said you wanted to focus completely on this.

I knew that I was not going to work. I saved up some money, and organized my life so that I could focus 100 percent on this project.

I took a year off to do this.

Where did the concept for 180 websites in 180 days come from? Why 180 websites, and why 180 days?

At the time I didn’t really know anything—HTML, CSS, anything. I thought I would do a few small projects first just to get my feet wet. So I decided to do a few projects that would only take a day.

One day I was talking with a friend, and she said, “Well, how many websites can you do?” We started joking around, but then I realized that it was a really great idea. I could keep building a little bit every day and work my way through the stack. Plus, it would give me the opportunity to touch different technologies.

I also wasn’t sure where this whole coding thing was going to take me. I didn’t know if I was going to be an artist that knew how to code, or if I wanted to get into startup scene, or become a software engineer at Google. I wasn’t even sure what part of the stack I’d be interested in. It just seemed like a nice way to get a taste of everything.

 

“I started with virtually no programming knowledge, and realized that I just needed to get something on the screen.”

 

Why 180 days? Well, three months seemed to short, and a year seemed too long.

Tell us about those first few days, and first few websites.

As a side note, I started on April 1. Saturday night I was busy putting the last few pieces of structure in place when my old laptop, a 2007 MacBook Pro, died. Everything was on there. I was all set to rock ‘n’ roll, and it just totally crapped out.

Sunday I was able to borrow another laptop, not a MacBook, but a PC. I got everything on there, and was able to use it until I got a new computer, which arrived early in the week.

It was a really stressful and exciting way to start things.

Luckily, everything turned out OK. I was able to push everything up and get a little bit of extra practice before the project started.

So you were set on starting on a specific day. You’re awfully persistent—well, of course you are. You built 180 sites in 180 days.

Did you have any ground rules that you laid down for yourself?

There were a few rules for the project. One website every day, I’d have to write a blog post about it, and everything needed to be publicly available on GitHub.

At first I thought I would have to train myself to be more disciplined. I thought I’d have to schedule coding, reading and studying for a certain number of hours each day.

It turned out none of that actually happened. It was almost all coding, all the time. I was spending on average 10 hours a day beating my head into the keyboard until magic happened.

In the early days a lot of it was magic. I had no idea what was going on. I spent a lot of time looking at my code thinking “I don’t know why this works, but that’s OK.”

The project started to drive itself as time went on. There came a point where I couldn’t imagine not building a website in a day. It became a total habit.

It felt weird when the project was over and I didn’t have to build a website in a day.

Were you at a co-working space, or did you work from home? Where did you go each day?

I got a co-working space.

Early on when I was just starting to think about learning code, I realized that if I did any sort of learning project in my house, I would go insane.

 
Jennifer Dewalt Working Late
Jennifer stays up late working on one of her projects.
 

I definitely wanted a place that I could work with out distractions, and a place that I could call home. Plus, if I was gone, wouldn’t have to worry about the dishes or the laundry being done.

Joining a co-working space was actually one of the best decisions I made during the project. It would have been hard to sit at my dining room table and crank away.

You talked about putting your code on GitHub and out in the open. You could have done this project and kept all the files locally on your computer. Why did you want to do it out in the open?

There are a couple of reasons.

One, it definitely gave me a sense of responsibility. It is a nice motivator when you are feeling sick, or hungover, or just not into it.

Publishing code publicly is part of programming. I also wanted to overcome the fear that I might be wrong. There is a lot of anxiety built up around the idea that you can’t put anything out there if it is broken, or that a certain function might look silly.

By putting code out in the open, you quickly realize that nobody really cares about you and your code. Well, unless they are trying to use it.

It is OK to be wrong. Coding is a lot about being wrong.

Most of these projects took all day?

Right.

Some of these projects are pretty elaborate. How did you predict what you would be able to accomplish in a day?

The early websites were easier. I knew that even if they took all day, I could get something done.

Later on I kind of intuitively knew how much development I could do—I wasn’t always right. There were a few days where I worked to 8 or 9 o’clock at night, and I would have to switch projects.

Towards the end of the project I was consistently finishing at about the same time each day.

Those projects that you gave up on at 8 o’clock at night—would you ever go back to work on them? What happened with those?

Usually, if I got to that point there was something fundamentally wrong in how I had approached the problem. I’d keep the code aside, but often by the time I got back around to it, I wasn’t interested in the problem anymore.

There are a lot of half-completed projects that I may revisit one day in the future.

 

“I don’t know why this works, but that’s OK.”

 

I did go back to some of them. For example, I had been working with Rails for a while and was interested in working on some real-time applications, but I didn’t think I was ready to move into Node yet.

I tried to do a real-time Twitter app. I approached that app two or three times, and never got anywhere with it. Finally, at the very end I tackled Node and was able to put it together.

Rails, Node—you know a lot of frameworks. What other frameworks or languages do you learn?

Well, I know Rails, which means I know a bit of Ruby. I’m getting better, and am actually working on a Rails project right now.

JavaScript is defiantly my foundation. I’m working with Backbone and lots of little JavaScript libraries right now.

I try to stay away from libraries, and roll my own as much as possible. Obviously, jQuery is indispensable.

Toward the end I worked with Node.js using Express. I touched on a tons of different things.

The concepts for your project are incredibly elaborate. How did you know what you were going to build each day? Where did all of these concepts come from?

Before the project started, I make a list of every idea I could think of—good, bad, crazy, nonsensical. I got to about 70 ideas. I kept that list throughout the project. I always had something to fall back on.

As the 180 websites project went on, I was being inspired by my current projects. I might be researching on one concept in JavaScript, and stumble upon something else I could use later.

What were some of the bigger challenges of this project?

About every 30 days I would get kind of crazy.

In what way?

Every 30 days I would have this period where I felt totally uncreative, grumpy, and just not in tune with the project. I’d have trouble with an idea for a website, or executing the one I was working on.

On those days, I’d just work on something simple. I’d wake up the next day ready to go, and excited to learn a new concept.

Jennifer, let’s transition to talking about what happened after the project. I’m curious, what happened on day 181?

I started using Node at the end of the project. Using Node required me to write my own server, which was awesome. I learned so much more—Rails seems magical sometimes. It was like, “Oh, I understand how this works now.”

The side effect is that you have to handle all the things that Rails takes care of yourself—sanitizing links, all sorts of stuff.

My last website was a real-time chat room type of thing. Anybody on the site could type in anything, and it would rain down on the screen.

I ended on a Friday, so my game plan was to party on Friday night, take the day off Saturday, and Sunday I would go in and take another look at the server. I had the feeling there were going to be a few problems with it.

I was planning on writing a nice big blog post about being done later in the week.

Interestingly, someone posted my last blog post on Hacker News. I came home from dinner and the movies to find my website blowing up. The server is crashing, people are writing all sorts of obscenities and ridiculousness.

I spent most of Saturday night trying to hack together fixes until, I could attend to it more seriously on Sunday.

That was a little stressful, but the partying was nice.

It’s part of the story though right? I’ll always remember coming home and going, “Oh, my goodness!”

 
YumHacker Jennifer Dewalt
YumHacker is Jennifer’s current project. It is similar to Yelp, but the focus is on restaurant reviews from friends.
 

What is next for you?

I took some time off, and went on vacation. I got to reconnect with all my friends that I had ignored for 180 days.

I want to tackle a longer-term, more serious project. I started work on a new website called YumHacker. It is a restaurant discovery website—a Yelp for foodies. You can discover restaurants, and follow friends and other people to see what restaurants specific people endorse. You could find new restaurants that will be more tailored to you than Yelp or other reviews might be.

Out here in San Francisco, Yelp is really awesome, but every restaurant is rated about the same. It is difficult to dig through reviews and find something good that is tailored to you.

I find that my friends give me the best restaurant recommendations, so it seemed like a great idea for a little website.

And what are you building that on, Node?

No, it is a Rails back-end and I’m using Backbone on the front-end.

It has given me the opportunity to touch on a few other things. I touched on Backbone during the 180 websites project, but I didn’t have enough time to really digest it. I feel like Backbone has a pretty steep learning curve.

I’m sure that others have asked you to come speak. Are you going to be speaking at any conferences anytime soon?

No. I’ve been really focused on getting YumHacker throughout the door. I want to make sure that I retain the knowledge that I’ve gained during the 180 websites project.

Looking back on all these projects you’ve put together, do you have any favorites?

I do. I mentioned How We’re Feeling, the real-time Twitter app. It is something I tried to do several times during the project, but was finally able to complete it on day 178.

It hooks into the Twitter streaming API using Node. There is a series of discs on the screen associated with different feelings—happy, angry, amazed. Tweets corresponding to those feelings get tallied, and flash on the screen, and that goes to an overall positivity rating.

There is some psychological study that says, on average, people are happy 78 percent of the time (The app says 79 percent at the time I’m writing this). On Monday morning it always dips down, and on Friday it is usually above 80. It is a cool thing to watch the mood of Twitter in real time.

 

“It was almost all coding, all the time. I was spending on average 10 hours a day beating my head into the keyboard until magic happened.”

 

There is another API app called You Are Here, which grabs recent photos from Instagram that are around you. It is a way to get a visual perspective of your place in the world from Instagram.

As I was working on the app throughout the day I started getting others pictures on the app. Around lunchtime I saw peoples food. Around midday people start taking pictures of their pets. There was a San Francisco Giants baseball game that afternoon. People went from work to Giants party mode. They had beers and were dressed in orange and black.

It was interesting to watch San Francisco’s day go by.

We’re close to the end of the interview. Are there any questions I should have asked you but didn’t?

The one thing that people usually ask me is, “How did you do it?”

And that is actually the very last question I have. So, how did you do it? How did you build 180 websites in 180 days?

I started with virtually no programming knowledge, and realized that I just needed to get something on the screen.

Getting over that overwhelming feeling of not knowing anything is really hard. That concept carried over throughout the entire project. You just need to get something small working.

Throughout the project a start small, keep going mantra was in my head. It is important to understand that you don’t necessarily need to understand to get things working. It is just as important to keep moving forward. The understanding will come eventually.

It is easy to get tied up with all the little details. You may just not be ready to understand it yet.