How I pivoted from designer to developer

No bootcamp. Not a listicle. Just the guts of a year long journey.

Why I transitioned from design to engineering

I’ve worked and designed for dozens of startups. I’ve started so many side hustles I’ve lost track. But they were software ideas, so I relied on an engineer to execute. That’s when things fell by the wayside.

So many times, the project fell through due to a lack of motivation to push through the last 20%. Since I couldn’t help execute, it was enormously frustrating. I’d already dumped so many weeks researching and designing, but ultimately the creation has yet to see the light of day.

Some projects I designed that were never shipped (or are in progress)

Even in my designer jobs, only a portion of my designs ever saw the light of day. Priorities often shifted between design and code, but more often there was never enough engineering velocity to execute. Why was I spending so much time designing something that would never be built?

Also, there was a lingering hunger for something new. I’d been designing full-time for three years now, and it no longer gives me the adrenaline rush it used to. When I first started designing, everything was really fucking hard. Every design choice is deliberate. Why a vertical navigation and not horizontal? Which shade of blue should I choose? Every micro-decision was something new I had to research and problem solve. Now, I had a general intuition for what needed to be done, and as a result I’m not growing as quickly as I used to be.

I want to mother useful, beautiful app babies. But hey, boredom and a hunger for autonomy were great drivers too.

I realized that I never thought of myself as a designer. I might never really think of myself as an engineer either.

I thought of myself as a maker.

So, I need to learn how to code. I need a new life challenge.

Planning the attack

Now that I had a goal, I needed to plan carefully. I still worked as a designer in my fulltime job, so I had to be very disciplined and deliberate with my approach.

Should I do a bootcamp?

- Fast learning
- Grow my network
- Forcing function

- Expensive (although I had the savings for it)
- Would have to quit a job I just started
- Would have to learn things I’m not that interested in 
- Potentially long period of unemployment

Ultimately, greed got the best of me. Since I was in San Francisco, was surrounded by engineers, and already knew some code, I decided to hustle for a year rather than taking a bootcamp. I already had all the resources I needed at my disposal. I just needed to reach out and seize the opportunities.

How do I start learning how to code?

I already had a solid understanding of HTML/CSS, and took some coding classes in college. The next obvious step was learning Javascript, since that was the language of the web — and increasingly, even the native environment thanks to React Native. In terms of frontend React won pretty easily, being one of the most marketable skills out there.

Everyone assumed that since I was already a designer, I’d be focusing on frontend. That wasn’t the case at all. I wanted to be able to make something start to finish, and I didn’t want a lack of backend skill to limit me in any way. Node was an obvious choice. I asked around to see if I should choose a second language and learn that too, but most assured that quality was better than quantity, so just one language was fine.

My mental checklist
1. A disciplined schedule
2. Projects I’m excited to work on
3. Code mentors and personal stack overflows

That’s really it. Those three things were the launching pad to a year long journey into a career transition.

Month 1–3: Tutorials and Introduction

Oh man, the first few months were by far the toughest.

Every minute — literally every single minute of coding was fucking hard. And I loved it. I loved the crazy challenge of learning something totally new. It was like being a kid again, where everything was new. Everything was hard.

I’d practice basic interview questions, learning for loops, recursion, and basic functional programming. I did tutorials. I dreamed about MDN JS documentation. Every few minutes, I’d get stuck. Sometimes it’d be as simple as a syntax error. The worst were infinite loops, and since I practiced in the browser it’d be a painful process of force quitting Chrome.

When I got stuck, I had a 15 minute rule — I’d struggle with it for 15 minutes on my own, googling and racking my brain and feeling like a total idiot. If I still couldn’t figure it out, I pinged my engineering friends for help.

Throughout my journey, I realized that there’s two philosophies to learning how to code:

1 — Learn by building. Be entirely pragmatic with results. #yololife

2 — Learn by first principles. Learn computer science systematically.

Most people believe in somewhere between the spectrum. I tried learning by #2, by reading documentation and doing exercises in books and recreating utility functions.

For myself, I realized that #2 just didn’t work that well. It was too slow, and things didn’t stick. As soon as I built my own reduce function, I immediately forgot what it did again. That’s when I really understood the difference between computer science and software engineering: learning the theory doesn’t mean you can execute.

For me personally, #1 worked 10x better, and I gradually mixed in #2 more and more as I went. I stopped doing interview questions as much, and just started building stuff.

Figure out what learning method works for you. Try, test, and iterate. How your mentor learns is not how you learn best.

One huge blocker that I did not foresee was learning how to handle build issues. At first I had little patience for build issues — I just want it to work! People never talk about it when they discuss learning to code, and it can be a big roadblock. The answer to this is really just time and persistence. Eventually down the road, I studied Webpack and Babel, but just starting out I highly recommend that people use tools like Create React App or just downloading boilerplate.

The first project I built that I was proud of demoing was a Hangman game built in React. I downloaded a list of SAT words, and I have to admit, it was actually really challenging to play!

Month 3–9: Building a real product

Three months in, I still felt like a total imposter at coding. One of my best friends, Grant, approached me: “You should work on my project!” I was like “Noooooo I too nooooobbb. But ok.”

And man, that was one of the best life decisions I’ve ever made.

Working with and learning from an experienced coder on a real project with real users was a tremendous learning accelerator.

To this day, I have nothing but tremendous appreciation and gratitude for his mentorship. (He built VSCode Vim and is now working at Dropbox.

Together, we worked on Chips Compo, a website for amateur songwriters to compete in weekly competitions to give and receive the best feedback you can find online.

Reddit style voting for competitions themes, my first project!

He was working on it fulltime. I contributed as much as I could whenever I could.

I built vertical stories, so I learned frontend, backend, basic coding, fancy coding, deployment, all at the same time! It was a gigantic crash course if there was any.

But it was exactly what I needed. I learned how to build large projects from conception to deployment.

Through Chips Compo I learned:

  • Javascript fundamentals
  • How to create a robust type system with Typescript
  • The “React way of doing things” and component based architecture
  • Routing (React Router) and middleware (e.g. axios)
  • RESTful architecture (Express), SQL queries, and database design (Postgres)
  • Realtime messaging with
  • SSHing and deploying for the first time

Looking back on it, those days were tremendously rewarding. I was very busy and growing super fast: working a day job, then going to my friend’s apartment in the evening to work on Chips Compo. But since we were friends, it was extremely fun. 11/10 would recommend and do again.

When I’m excited about working on something with a friend, it isn’t work. It’s just something I’m excited to get off work to do.

At first, it took maybe 3–5 rounds of code reviews until my code was ready to be merged. Now, it only takes a round or two.

At one point, probably around the 6 month mark, I had some tremendous wins. I was helping others with their code. I was actively helping other people debug their Javascript. It was such a reversal of roles that it felt super rewarding.

Month 9–12: Alexa Project and Interview Prep

At first I was planning to have three projects on my resume, with Chips Compo being the first.

After getting a lot of advice from other developers, they reassured me that two solid projects was enough, or even one. Quality over quantity. But since I already had a project with someone more experienced, I needed a solo project.

Yodify: An Alexa app

I could continue to work on the games I had started at the beginning, but I decided to go for something more niche and marketable. If I put on another web project, I’d just be competing with all the other web engineers out there.

So I built an Alexa app.

Yodify your sentences! Who doesn’t love Yoda? I also made a web version.

I used an existing NLP API and then took the Udemy Alexa course. If you’re interested in learning Alexa, I highly recommend the Udemy course. Alexa was surprisingly simple to pick up. You input and output JSON.

I tried to submit it to the Alexa store, but unfortunately there are trademark infringements. :( Maybe I should call it “Talk like fuzzy green master” instead.

I also dabbled into writing unit tests. At my job, engineers strove for 100% test coverage. Test driven development was an important philosophy for so many engineers. I understood that in a complex or large code base, tests were extremely important for maintainability, and serve as living documentation. In my short experience, it turned out that the hardest part is just setting up the testing infrastructure with Jest and Enzyme.

Preparing for Interviews

Oh, interviews. The algorithm questions. As the year mark soon approached, I dedicated myself solely to practicing algorithm questions. At first, it was extremely painful. I developed a system:

  1. Pseudocode a plan of attack. Understand time and space complexity.
  2. Get the code working. Don’t worry about optimization or fancy syntax.
  3. Optimize the code. If the runtime sucks, try a different approach.
  4. Get code reviews!

I went to a meetup where I practiced whiteboarding algorithm questions every other week.

I also really enjoyed system design questions. They were more open, and there was so much I could learn if I wanted to deep dive into it. For Chips Compo, we weren’t concerned with scale (yet) and so all the crazy infrastructure that is required for developing at scale was a whole different world to explore. The famous Netflix microservice presentation was particularly inspiring.

I iterated on my resume and got feedback on it. Then I updated my Angelist profile and discovered A-List.

Landing the Job

The moment I opened my A-List profile, I was pretty overwhelmed with requests. I also went out and cold contacted some folks through email. It was meant more as a dipping my toes to calibrate my abilities with what I needed to get a job.

But hey, I ended up landing the job from my very first interview!

I never would have guessed in a million years.

Funny enough, I basically did zero algorithm or system design interviews. I did one that was really simple, and that was it. It was pretty anticlimatic, to be honest. This was also due to the fact that I was focused on startups, which tend to have more practical interview questions than established companies.

Now I work at Mira, a machine learning beauty app (React Native on iOS, Python, Flask, Postgres, Lambda backend) as a fullstack software engineer.

I’m two weeks in and I couldn’t be happier. It’s a young, hungry startup with talented people who I can be myself around. I’m engaged every hour, coding away and learning new stuff all the time. We’re also hiring for a data scientist!


I am extremely blessed and lucky to have a support system and people who were willing to respond to my constant pestering. Thank you all so much! Shoutouts also to Drew, Sam, Andrew, Bowei, and many others for your help.

If I were to do something differently, I would’ve focused less on the interview prep and whiteboarding practice, and more with just experimenting with different tech and building small, time blocked projects. (However, the opposite might be true if you are interviewing at established companies rather than startups.) This would’ve allowed me to get more familiar with the sexy technologies that are out right now, and build out proof of concepts for future projects. Since my interviews turned out to be very practical, this would’ve provided much higher return. I could’ve also made more of an effort to contribute to open source. I tried, but it was awfully intimidating.


Balance learning how to build things with theory and fundamentals. Find out what learning style works for you. Do real projects, ideally with mentors working alongside you. Relish the challenge, but know when to ask for help.

Any questions? Ask below, or reach out.