Designcamp is over.

If you could go back in time,
What advice do you give yourself?


When I was starting Designcamp, I asked a few former Designcampers what kind of advice they had for newcomers coming in to the studio.

I always phrased my questions differently and then I started using this as my default question:

What kind of advice would you give yourself before starting Designcamp?

I’m asking myself this question now and I definitely learned a lot from this Designcamp experience. It’s a three month bootcamp that really helps to prepare you for the work experience that we’re now in.

So if I could go back in time…

Back to three months ago when I was starting Designcamp for the first time, here’s some of the advice (or insight) I would give to myself.


Failing Fast.

Learning fast.

You’re gonna fail a lot and it’s gonna feel terrible.
Embrace it.


This is my studio team.

Every week for six weeks, we wanted to quit our project and move on.

It’s true.

We were working on a project that got us to explore an open technology called Docker — our job was to find out how we could integrate it into Bluemix.

But we’re a bunch of designers, most of us have only coded in school, let alone, deployed an app — to get familiar with Docker and the workflows it could be used in made us feel like we were cramming to become Cloud Engineers or Solutions Architects.

A weekly existential crisis

Is this really the right solution we should be designing for?
Isn’t this a job for an engineer?
Should we be doing something else?

Our project lasted six weeks.

Every week we would attempt to design a solution.

We would present our solutions and we would be forced to start over. One week we had a gang of IBM engineers crap all over our early ideas. We did more research to restart and design a more refined, useful solution.

Another week we learned about a bazillion different ways that Docker was powering innovation in the open source community. Docker was becoming the technology that was showing us possibilities for what our solutions could be capable of doing. The scope of our project was growing in a lot of unexpected ways no matter how hard we tried to keep a focused scope. So we restarted again, ideated more, and refined some of our current solutions.

So every day and every week we were throwing more insights into the mix, more research, more opinions, more possible solutions, and we were just a team of new hires drowning in an ocean of possibilities.

All of this was iteration.
Very uncomfortable iteration.

Like I said, we were forced to change the work we did very frequently. But it was all necessary.

If I were to go back in time to talk about this whole situation with my past self, I would say:

  • Failing doesn’t make you a failure. You fail fast and you learn fast.
  • Don’t expect to get anything right on your first try. Solving complex problems will be a bumpy road. Get comfortable with being uncomfortable.
  • Don’t allow your failures to make you feel like shit; that’ll just get in the way of your work.

Ultimately, the perspective I had for the large majority of this project was a very negative and pessimistic one. It was only in the final days of our project that my group had the presence of mind to see a design opportunity that we could really passionate about.


Make time to code.

Research will be unending.
Meetings will be all the time.
Less talk; more hack.


The practical advice

I know myself, and I know that I’m still a very junior developer. I don’t expect (or aspire) to be the best developer here. But I was surprised to learn that being a fast developer counted for a lot too.

There’s a lot of time spent in meetings.

There’s a lot of time spent in the design process.

There’s a huge amount of time spent away from computers because of the work we do here.

On a typical day of Designcamp, there are very few opportunities for developers to code.

The proactive devs would have to sneak away from their groups to get their coding time in.

The better devs were fast enough to be coding in parallel with the visual and UX designers.

Now it’s not so much about finding the time to code, it’s more about making the time to code. Luckily, working with code is a lot more enjoyable now because the time that is used for it is so valuable.

The practical advice I would’ve given myself before starting Designcamp would’ve been:

  • Level up your JavaScript skills.
  • Get really familiar with Node.js and Express.js
  • Build an Angular app
  • Practice your Sassy CSS

But that advice has been obvious since the beginning of my career as a developer.

Just. do. you.

When I was first learning how to code, I constantly had to tell myself to stop comparing myself to the other developers — both my peers and mentors.

Seeing all the things that the other developers were capable of doing that I wasn’t able to do made me feel like an imposter. I didn’t feel like a real dev and that kept me from actually learning what I desired to learn.

And here I was at Designcamp: same shit all over again.

I wasn’t fast enough to prototype with the designers.

I lacked the programming skill to collaborate with the other developers.

At the very least, that’s how I felt.

So if I could go back to my past self and drop some knowledge on me, I would have to say,

“Just do you. Focus on yourself. You have nothing to prove. IBM hired you and if you need to step up your dev game, go do it. Make the time and do it.”
Show your support

Clapping shows how much you appreciated Brian Han’s story.