Back to the Drawing (White) Board

The project I built using Ruby on Rails is a private group class tracker for a yoga studio.

Sounds like a mouthful, I know, but I noticed that the yoga studio I work for has a niche problem. Local organizations such as universities, non-profits, corporations etc. request for a yoga teacher to come onsite to teach a class. Most of the time, these requests are inconsistent. For example, an organization will want a class for their “Wellness Week” which only happens a couple of times per year. Since requests are inconsistent, the same client will have a different teacher each time. The teacher assigned for this offsite class has no idea what kind of class to plan. What kind of practice do the participants want? What is the space like? It would be nice if they could take a look at the class plan from the previous class, that was perhaps taught by a different teacher! That’s where my web application comes into play!

My enthusiasm for my idea fueled the creation of the project, however this was the toughest project yet. Here’s what I learned:

The importance of having a clear vision for your project before you get started.

I had to restart my project twice! I had to restart my project because both times my domain was not clearly defined from the get-go, which made building complicated (lesson learned!). However, each iteration of my project led to my final product, which I’m very proud of. While I shared with my friends and family about my tribulations, I compared my process to something they were familiar with, writing a thesis paper.

The first step is to clearly construct a thesis statement, in coding world this would be constructing our domain models and defining relationships. The thesis statement steers the ship as you’re writing the paper. Similarly, your models and relationships can create the backbone of your Ruby on Rails application. If you write a thesis paper without properly researching a topic, as you’re writing, you may have a change of heart with your beloved thesis statement. Now that you’re reading additional sources and are really diving into the topic, perhaps you want to change your stance. So you go back to the drawing board and rewrite a thesis statement that better represents your positioning now that you have new information. You have to start your paper all over again. Similarly, as I began to bring my project to life, I realized there was a better way to represent my project— different from the models and relationships than what I had set up. Since I wanted to change the infrastructure of my project, I had to restart my project.

Knowing when to let go if a certain idea isn’t working out.

It’s tough to abandon a project after spending a lot of time on it. I spent 4 days on my first iteration, knowing most of the time that I wanted to restart it and take it in a different direction. I was so resistant to restarting, but once I took action and restarted, I felt a surge of momentum because I knew it was aligned with my vision. To make myself feel better about my situation, I thought about how artists record entire albums that never get released and fall to the wayside. Authors write novels that never get published. Although these pieces never make it to the public, I bet these creative pursuits influenced other pieces that eventually did reach a broader audience. Similarly, my failed projects influenced the success of the final version of my project.

Get to know the gems you’re using.

Since I restarted my project twice, I can now set up Devise and enable Omniauth using Facebook with confidence. This was my first time using both Devise and Facebook Omniauth. Typically when I use a gem for the first time I find a blog or video to guide me through step by step. The downside of this method is that I blindly follow step my step without internalizing or completely understanding what’s happening. For this project I was able to set up Devise and enable Facebook’s Omniauth three times, so now it’s solidified in my brain. It got me thinking, that for future projects when I’m using a new gem I should make sure I really know what the gem is doing, so when if I run into a bug I’m better equipped to resolve the issue.

Nested resource show page

A feature of the app I was excited to implement was to view the history of classes by client. This would help the user zoom in on which templates to research and take ideas from.

Each class would be represented by a link that would then take the user to a nested resource show page, which would have all the available information about the class.

The code behind this feature was fairly simple, yet important to break down.

<p>History of Classes:</p>
<% @client.yoga_classes.each do |yoga_class| %>
  <%= link_to yoga_class.title, client_yoga_class_path(@client, yoga_class)%>
<% end %>

In my client model I defined the relationship that a client has_many yoga_classes. This then gave me access to call on an instance of a client and a list of their associated yoga_class objects which are assorted in an array. Then, I called an iteration on each yoga_class to create a link for the specific yoga_class. With link_to, the first part of the link is what the name of the link is, and the second piece is the path the link takes. So, I named each link the title of the yoga_class. Then, I used the route helper (route helpers are a piece of magic given by Rails) client_yoga_class_path(@client, yoga_class) so that a specific class would be nested underneath the client. @client was the first argument of the path because the helper needs to know which client_id will have all of its associated yoga_classes listed. Then, the url needs to know which yoga_class to route to based on the yoga_class id attribute. This helper is constructing the following template of the url: /clients/:client_id/yoga_classes/:id. As you can see in the screenshot above, the yoga_class has a client_id of 5 and an id of 4.

Just getting started….

Building the private group class tracker application taught me A LOT. I have a lot of ideas about what kind of future implementations I want to build for the app- like duplicating a template, since there should be a template representing each time a teacher taught a yoga class. Also, I’m looking forward to learning JavaScript and React to enhance the UI of my application. This is just the beginning!

The Halfway Mark!

Last week marked the halfway point for completing Flatiron’s Online Software Engineering program. The program moves so quickly that it’s hard to stop myself and think, wow, I can build entire web applications when two and a half months ago I was learning the elementary basics of Ruby. The minimal coding experience I had coming into the program (I have taken some courses on HTML, CSS and began teaching myself Javascript) as well as previously working on the tech team of a startup gave me sufficient context as to what I was getting myself into. However, the program’s curriculum is so curated that what I’ve learned in the past 2.5 months probably would have taken me years to learn on my own. Since I’m at the halfway mark, I thought I would share the obstacles I faced and my method of overcoming them.

When to Stop Working

I love the flexibility of learning on my own terms. However, with this comes an undefined start and stop time. You can never be finished with learning how to code. This concept of limitless knowledge is what attracted me to the subject, but as a human being who has relationships, other responsibilities, and a desire for a hefty self-care practice, I had to draw a line with when to stop coding. I make sure to stop learning by 8 p.m. each night. I drew this line because I am unable to sleep well if I have screen time late into the night. I have found that when I cross this boundary, I wake up several times throughout the night and I don’t feel as well rested for the next day. I also set boundaries for when I start in the morning as well. I don’t start coding until 9 a.m. after I have my morning routine of activities that sustain my coding practice— like meditation, yoga, and journaling.

Getting into a Routine and Schedule

This is related to my learnings above, but it’s important to identify when and where you get your most work done. When I first started the program, I stuck with the 9-5 routine I was familiar with. This was problematic because I was rushing to get to my computer by 9 a.m. to begin learning for the day (note: a racy mindset is not good for learning…) and some lectures were getting scheduled post 5 p.m. I learned I had to be less rigid with my schedule. I learn best during the day, so I made sure to do schoolwork for 11 a.m.-4 p.m., and threw in learning time at other parts of the evening depending upon when the live lectures were or how I was feeling.

Also, I learned to be less rigid with where I decided to do my schoolwork. As part of the program, Flatiron gives you access to a WeWork space. I take full advantage, I spend 30 hours a week there. However, if I have an hour and a half lecture to watch or am feeling unwell, it doesn’t make sense to force myself to remain in an environment that isn’t supportive to my learning. Also, on weekends I got to coffeeshops to work as a change of environment and to be around different people.

Meeting with Others to Talk About Code

Flatrion gives you great resources to meet with others. 1:1’s with your cohort lead, pair programming sessions, and organized Study Groups. However, it’s up to you, as the student, to take advantage of these resources. I was on top of creating agendas for my cohort 1:1’s to best make use of the time and was meeting with my partner for pair programming. However, in the beginning of the program, I wasn’t attending Study Groups live. Since the Study Groups were recorded, I figured I could learn just as much at a time that was more convenient for me. But as I was watching the recorded versions I realized I wasn’t experiencing the ‘magic’ of a live lecture. The possibility of getting called on to answer a question, or having an opportunity to ask questions you have are components of what makes a Study Group truly special. This type of interaction helps cement concepts. I stopped perceiving Study Groups as optional and started fitting them into my daily schedule. To enhance my communication with code, I also began meeting with a classmate outside of who I was paired with for Pair Programming. Having additional practice with sharing what I was learning has been super helpful since this program is primarily self-driven.

I’m motivated to take on the second half of this rigorous program. I’d like to think that I’m a bit wiser about my plan of attack to finish up the program strong. Whenever I feel stuck and like I’m going nowhere (I feel this AT LEAST several times a week…) I watch this video by Flatiron’s CEO and founder Avi Flombaum:

I love this video because he doesn’t believe his bootcamp is an easy quick fix to learn how to code (wouldn’t that be nice if that actually existed??) but he does believe that continuous small steps will lead to progress and success.

My First Sinatra Application

I built my first web application! That other people can log into and use! Our project’s requirement was to build a web application using Sinatra as our Framework. I felt like a baby taking their first steps on their own. I was slow and wobbly, but with my earnest attitude I persisted.

My application is named My Book Collection. With My Book Collection you can view all of your books in one application. If you’re anything like me, you have books in different places. I have books in my living room, in my bedroom, and even at my friends’ houses. It can be tough to keep track of where all my books are, especially if I loaned them to a friend. You can view all of your books on a single page with My Book Collection and click on a book to review the book’s status (if it’s on loan, read, unread etc), as well as the book’s author and genre.

My Process:

Before I started coding, I wrote out user stories in my journal. How I expected the app to function, what I wanted the app to accomplish etc. This gave me a clear vision and limited the decision making I had to make while coding. Specifically, I only wanted users to interact with the app if they were logged in. Similarly, I knew I wanted users to have the capability to edit their own book collection.

Main Takeaways:

How to deploy an app on Heroku.

Heroku is a platform where users can deploy their web applications on the web so other people can use it. It took some time to successfully connect my GithHub account with Heroku. When I use a new platform I tend to take the process very slowly to ensure I’m not just mimicking steps but rather understand the process. I envision myself using Heroku for many projects in the future, so understanding how to upload a web application this time around is helped out my future self.

Taste of Ux/UI.

Although my main focus with this project was to understand the backend and how my objects interacted with each other, I had some moments of considering the user experience of my application which was new for me. When I am working on my labs, I’m not as focused on the Ux because my name isn’t tied to the project. However, My Book Collection is completely my own! For example, initially, I had a delete button too close to the edit button. I imagine users will want to edit their books often, it would be frustrating to delete a book when all you wanted to do was update its status! Therefore, I increased the white space between the edit and delete button.

ActiveRecord CRUD.

ActiveRecord comes with many helpful methods to call on objects in order to create, read, update, and destroy objects. This documentation here was a great reference. I ran the rubygem Tux so I could create and play around with objects in my terminal to test my application’s onjects to make sure they were interacting with one another correctly. Alternatively, I could have created seed data to have for my app, but I wanted to play around with ActiveRecord’s CRUD methods to get more comfortable with them since I was planning to include them in my code. The method that was the most fun to use was the .where method. Calling .where on an object is the SQL equivalent to saying:

Select * from table where column_name = 'condition'

This was helpful because I only wanted users only see their own books. I then added the .each method in order to iterate over each book so it could be listed separately on the user’s page.

<h1>Here are all of your books:</h1>
<%Book.where(user_id: do |book|%> 
  <li>Title: <a href="books/<>"><%=book.title%></a>
    <p>Author: <><br>
    Genre: <%=book.genre%></p>

Don’t be intimidated by errors.

The instructors at Flatiron try to reinforce the fact that most of the time code is going to be broken. For the most part, I’ve embraced this and this mentality helps when other things besides code aren’t working projects. For example, I ran into an error with Shotgun, which is a RubyGem that let’s you run your application on your local server and updates changes you make in your code in real time, so you don’t have to stop, code, save, and run the application.

The error caused my browser to look like this:

This was in my terminal:

Set SINATRA_ACTIVESUPPORT_WARNING=false in the environment to hide this warning.
objc[1464]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called.
objc[1464]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

Luckily, I googled my error and found that other people had the same issue and there was a Issue thread on Shotgun’s GitHub repository, link here: I ran through all of the suggested resolutions, and ultimately I had to update my Mac’s software to Mojave and then install macOs’ Xcode which added components to get Shotgun up and running. It probably took me 3 hours to resolve this issue, between the software updates, trying out different resolutions, and talking to my fellow cohorts to see if they had any ideas. However, this experience taught me that I’m not alone with the issues I experience. There are very generous people out there who have run into the same error and decided to write about it! Also, I was proud of myself for remaining level headed and persisting in order to solve my problem.

As always, I learned a TON about ActiveRecord and Sinatra by building my app. It reinforced my foundation which is important for our next section… Rails!

P.S. here’s a walkthrough of the app!

A Day in the Life of a Remote Full-Time Bootcamp Student and Part-time Yogi

While I was researching coding bootcamps to attend, finding an online program was not a requirement on my list. I was primarily looking for a program that had solid reviews, which is why I chose Flatiron. Living in Philly, I wasn’t willing to move to a city which had a Flatiron campus, so I opted for the online program. Doing the course online has its benefits, primarily in the realms of flexibility. As a part-time yoga teacher and yoga studio manager, I am able to balance all aspects of myself with the program’s flexibility, though it isn’t easy. This is what a typical day looks like!

6:15 a.m. – 9:15 a.m. I get up, meditate for 15 minutes, journal, and make myself a hearty breakfast. I do a couple of labs at my apartment before I head out for the day.

9:30 a.m. -11 a.m. I head to a yoga class. Yoga keeps my spirits high, body feeling good (unfortunately coding requires a lot of sitting), and mentally relaxed. I switch between a vinyasa practice (aerobic) and a yin practice (slower pace, poses are held for 3-5 minutes at a time).

11 a.m. – 11:30 a.m. I walk 30 minutes to the WeWork in downtown Philly. I get a WeWork pass as a student of Flatiron, and I take full advantage. With a kitten who is constantly walking on top of my keyboard or playing with my charger cords, it’s best for me to get out of the apartment.

11:30 a.m. – 4 p.m. I eat lunch as soon as I get to WeWork and simultaneously map out what I want to get accomplished for my learning session! I work through 45 minute sprints, and take a 10 -15 minute break. This is the time of day I get most of my work done, doing labs and catching up on recorded lectures. Also the time of day I drink lots and lots of WeWorks complementary tea and fruit water!

4 p.m. – 4:30 p.m. I walk home! An hour of walking a day may seem like a lot but it helps me clear my mind and transition from activity to activity. Plus, I love listening to podcasts! Lately I’ve been listening to CodeNewbie, Yogaland, Seek Treatment and Living Open!

4:30 p.m. – 5:00 p.m. I decompress, meditate again, eat dinner or relax before the 5 p.m. lecture we have on most days!

5:00 p.m. – 6:00 p.m. lecture

6:00 p.m. – 7:00 p.m. tie up loose ends for the day. Finish any labs I was working on, answer emails for my manager role.

7:00 p.m. – 9:00 p.m. relaxation before I fall asleep. I love to read, write, anything that doesn’t involve a screen.

Getting to Know the Command Line

There’s so much to know, and scratching the surface was very much like a bad date. But instead of glancing to my phone waiting for a miracle to get me out of the situation, I was glancing to and from tutorials typing carefully as I was learning how the command line likes to speak.

The Command Line was the topic I met with the most resistance in my coding journey thus far. After all, why learn the Command Line when all of the tasks can be done manually (queue nails on a chalk board)? The user interface is bland, you can’t “build” anything with it, and memorizing commands sounds so boring to me. However, while I was building my first project, I faced the resistance head on and began getting comfortable with some commands that have smoothed out my workflow and I now use every day.

Command Line Basics

The Terminal application on the Mac is where you can have some command line fun. Basically the terminal is an interface you can interact with and displays information about your computer— the files, folders, users etc.

Creating folders from the command line is important because it helps you stay organized. When I began working on my project, I had to create a path to store it that would make sense. From my Home folder on my user account for my mac, I created a folder called Development by typing:

mkdir Development

This is where all my code will be stored.

Then, I went into the folder I had just created by typing:

cd Development

In order to create two more folders, because not all code will be for projects:

mkdir projects; mkdir labs 

I’m going to have several projects and many labs, so it’s best to keep these separate. Also, this is how you can type several commands on one line separating each with a ; so you don’t have to press enter each time you want to run a task!


I didn’t have to do this while I was building my project, but here is how to add a file, remove a file, and remove a directory:

touch kittens.rb; rm kittens.rb; rmdir all-the-kittens 

Back to our regularly scheduled programming…

Next, I had to figure out how to interact with my GitHub account through the command line so my project could go from being stored locally to the interwebs for the world to see (and so I could also download later should anything happen to my local files or if I needed to retract to a previous version of my project…. anyways…)!

First I created a new repository on GitHub which I named after my local project, yay naming convention!

Then, I went back to my terminal to initialize my local directory as a GitHub repository:

git init

I then made sure my new local repository had all the files from my project:

git add .

Next, I had to commit (think prepare to publish) the files I’ve staged in my local repository:

git commit -m"First commit"

Then, I had to set up the path where my local repository will be “published” or pushed. It will be pushed to the repository url I just created on GitHub. I copied and pasted “” per guidance from GitHub, where they explained how to connect your local repository to GitHub if you have started the project locally.

(Note: The breakdown of the path was essentially “”)

git remote add origin

And now the moment we’ve all been waiting for, I get to push my project to GitHub!

git push -u origin master


Say I wanted to work on my project from my friend’s laptop. All I would have to do is go to my repository on my GitHub account, click ‘Clone or Download’, make sure I’m using SSH key, and click the clipboard symbol in order to copy the repository path.

Then, in my terminal I would type:

git clone ''

In order to get the project onto my machine so I could work on it! Voila!

When I’m finished I would run through the following (explained above) in order to have the most up to date version on GitHub:

git add .
git commit -m 'list out some updates you have made'
git push

Note: adding a descriptive message is very important so you can know at a high level what kind of changes you’ve made or features you built.

I can now say I know the Command Line a bit better now, and will continue to make the effort to learn its features! What are some commands you use on a daily basis that aren’t mentioned above? I’d love to know!

I Completed My First Coding (Bootcamp) Project!

The training wheels have been removed…

Building my first project for my coding bootcamp was quite the experience. The challenge was to build a CLI gem and use Ruby to scrape data from a website. I decided to scrape The Codenewbie Podcast is my go-to resource to learn about different topics and different roles in the tech industry. It’s also my #1 resource for coding inspiration when I feel like giving up. Often times guests on the show are career changers and self taught developers I can relate to.

My program lists all of Codenewbie’s podcast episodes with each episode’s relevant information such as the episode’s title, guest, and air date. Additionally, a user can interact with my program through their terminal and retrieve the url link for any episode in order to listen to the interview.

The due date of the project coincided with the holidays, so I had a lot of friends and family checking in and asking me how school was. I repeatedly went back to my bicycle analogy.

I am swerving heavily and am wobbly yet defiant as I ride my two wheeler.

The training wheels which were removed:

  • Using as an editor. is Flatiron’s built in house code editor and is extremely helpful. The platform runs tests and submits pull requests to GitHub using human friendly commands such as learn and learn submit, respectively. However, I used this project as an opportunity to work with building a program locally in order to replicate a more authentic developer experience. I successfully installed Atom and connected my local files to Github using the command line. Getting comfortable with the command line was not easy, as I was following Youtube tutorials and was memorizing what to do. I had to repeat the process several times to truly understand what was happening.
  • RubyGem setup. Prior to starting my project, I never had to set up a RubyGem. Our labs already had a neatly organized library to work off of. Also, we didn’t have a lab to practice how to fill out the relevant info needed to create a gem, but I followed this video which proved to be very helpful! However, like I previously mentioned, the issue with recorded videos is that I tend to go through the motions- copying the instructor without truly understanding what’s going on. I had to watch the video 3 times before I felt like it seeped in.
  • Labs. Before this project, I had a neat container to learn in. Most labs are heavily focused on just a few topics with clearly written tests. However, when I went to plan out my project, I felt overwhelmed thinking about all of the concepts my project had to include. I knew I needed a different strategy. I followed along with Avi’s method on how to build a CLI Gem, and I really liked his method of tackling a project. Avi stresses the importance of only focusing on the task at hand (1 or 2 objectives), completing the task, and then the next step will reveal itself. It was a playful approach to a lofty project, and I was able to make steady progress. It was fun to react to the quick decisions I was making.

I have alluded to this, but the toughest part about this project was everything besides the coding. The coding was a process I was familiar with. Strategy and setup are new and less straightforward topics for me. I was able to talk over my struggles with RubyGem setup with my Cohort Lead in our 1:1, and the strategy to tackle the project with my classmates. Although this was a solo project, having help and support from my cohort made me feel like I wasn’t in this alone. Overall I’m proud of the work I did and am excited that this is just the beginning!

P.S. Here’s a walkthrough of the app!

Beginner’s Tips for Excelling at Flatiron’s Coding Bootcamp

I’ve completed 4 weeks of a coding bootcamp, and although this may seem like a short time, I have learned some valuable lessons which improved my overall strategy for success for Flatiron’s Online Full-time Software Engineering Immersion. See below for some tips I wish I had before starting the program!

Additional resources are recommended!

I enrolled in Flatiron’s Software Engineering program because of the structure it offered, among other things, for my ambitious trek to learn how to code. However, I realized that Flatiron’s content, although very helpful, is not the end all be all for my uphill battle to learn how to code. This makes sense, when learning any type of skill, it’s best to have a portfolio of resources to gain different perspectives or to fill in the gaps.

Not only will Google be your friend, but books will be too. I opted for “Head First Ruby”, although another classmate of mine is reading “Eloquent Ruby”. Both seem accessible to beginners, and cover content that may educate the more seasoned Ruby developer.

Focus on 1 test at a time: learn –f-f.

Labs! A big part of Flatiron’s teaching style seems to be learning by doing, doing many labs! In order to complete a lab you have to pass the tests by writing code. Some labs have a few tests while others have many. I learned that it’s best to tackle one test at a time. This sounds like a no brainer, but it’s hard to work on one test at a time if all of the failed tests are listed out in your terminal. If all of the failed tests are listed, you may be tempted to jump ahead to a different test (I know I am!). In order to show only 1 failed test at a time, use learn —f-f, this will return only the first failed test.

Work in 45 minute sprints, with breaks afterwards.

I got this idea from Avi Flombaum, the dean of the Flatiron School, in a video titled “Learning How to Learn” (highly recommend, it has other great tips and reminders as well) link: Previously, I would sit down and would not get up until I finished the task at hand. This sounds good in theory, but when you are working through a lab that could take a couple of hours, this productivity style can stifle creativity and plummet morale. Instead, now I work in 45 minute sprints, and no matter where I’m at, I stop and take a break. I’d recommend a break which lasts from 5-10 minutes. During my breaks, I grab a snack, check Instagram, take a walk, or meditate in a quiet room AWAY from my laptop (shoutout to WeWork’s awesome call booths which make the perfect meditation spot!).

It’s incredible how much a short break clears your mind and rejuvenates you. I often times have coding epiphanies when I get up and move.

Code every day.

It makes Monday’s much less daunting. In the beginning I rewarded myself by taking the weekends off from coding, after working tirelessly for 5 days. But when I got to my laptop come Monday morning, my motivation was high but wasted on relearning concepts I had previously understood from the prior week. The weekend had washed away my understanding of some concepts and dammed my coding momentum. I spoke to my educational coach (a non-technical coach who helps with time management and offers other non-technical advice for success during the bootcamp) and she suggested that I should immerse in code even on the weekends. I decided that I wouldn’t learn anything new on the weekends, rather I would review code I wrote earlier in the week or research a topic that wasn’t “clicking”. This approach aligned with the easygoing schedule I like to have on the weekends. I noticed this plan of action has helped me hit the ground running on Monday mornings.

Admittedly, I had to learn all these lessons after I started the bootcamp, but wanted to offer my words of wisdom to others so they can start off on the right foot! What other tips would you add? I’m curious to hear your thoughts!

Why I Want to Be a Software Engineer

One of my roommates in college was a Comp Sci major. Since she spent all hours of the night working on labs, I assumed she had chosen the wrong major. I had no idea what she was doing.

Fast forward a few years later and I’m an analyst on the tech team of a cleantech company. I got to learn SQL on the job, and while it’s not exactly coding, I got my first taste into what it’s like to make a computer do what you say. I’ve always been curious about what is going on behind the scenes or underneath the hood, so when our tech team built new landing pages for marketing, sales agent management for sales, or our new products, I was interested in how they were doing this. At the same time, I was managing bugs that our member support team came across. I grew increasingly frustrated that I could help to define both the bugs and its scope, but I had to stop there and pass it off for the developers to fix.

I got my start by taking a HTML/ CSS class with a local non-profit. I knew I was on the right path. I followed up by taking classes on web accessibility, the command line, and intermediate HTML/ CSS. I was equal parts confused and excited. To me, not completely understanding something is exciting because it means I’m challenging myself to learn something outside my comfort zone.

My desire to learn how to code is fueled by my desire to break into a field which fosters an ever learning, flexible, and meaningful career.

Always Learning

In yoga it is said to always be a student, no matter how much experience you have. I like to take this concept in my every day life. I challenge myself to read books across vast topics, attend yoga workshops, learn new skills (stitching being the most recent!) so I can continue to make connections and recognize patterns about the world around me. Like I mentioned earlier, I take not knowing something as an opportunity for growth, and it seems as though there is no ceiling with programming.


As I’m getting older I realize I won’t always want to live in a city, where most startups and innovative companies tend to incubate. Becoming a developer will help to find remote work. I love the flexibility of not being bound to an office in order to get work done. I think employees should be trusted to get their work done, no matter where they are. Another aspect of flexility is the vast amount of roles a developer can fill. There are SO many different types of roles and industries I can break into. I can teach, be a part of a solid engineering team at an emerging startup, or freelance— it’s tough for me to see where I’ll land after completing my bootcamp because there are so many possibilities!

Meaningful Career

What was astounding to me when I first started to research my career transition was that every developer seemed beamingly proud of their job. As I began to learn how to code, I started to realize why. Software developers of all kinds are building our future. Developers can bring an idea to life. Personally, it’s powerful that I will be able to bring my idea of a yoga class plan generator or an app to teach Tarot to beginners to the world!

What also adds to a meaningful career is the community. I’ve received so much support from both strangers and new friends, whether it was through twitter and using the #100DaysofCode hashtag, or meeting people in real life at local tech MeetUps. I know I’m not in this alone.

I find my reasons to learn to code are evolving. I didn’t pursue this career shift because I thought “Hmm, I could certainly use a larger professional network,” or “Let me pick a field where I’ll continuously feel like a novice”, — these are byproducts. The reason why you start on a trek is never the reason why you finish it. I’m looking forward to watch my motivation to keep learning unravel as I go deeper and deeper into a programming career.

Growing Into a Dream

Chase your dreams. Dream big. If you can dream it you can do it. It’s all so exciting and inspiring, but like everything, this concept has both light and shadow.

In college my dream job was to work for a renewable energy company that had a fun company culture— preferably based in sunny southern California. At 21 years old I believed my career was limited to a 9-5 office job, and so if I had to go to work everyday, it might as well be in a welcoming and positive environment working towards a cause I was passionate about. After a series of trial and error, I finally landed my dream job as an analyst at an emerging clean tech company in Philadelphia, PA. My coworkers quickly became good friends, I had semiannual trips to our LA office (!), and I was even teaching yoga to my coworkers after working hours. I was living the dream I had curated and more.

After a year and a half in the role, I wasn’t feeling as aligned as I once had. My internal landscape became quite prickly. I began feeling ungrateful- “…but you had worked so hard and others have helped you so much to get to this point!”

I began reflecting and contemplating – is this what I want for my current self, at 25 years old? It was difficult to admit to myself that my desires have changed.

My desires now demand more flexibility. I dream of living near the beach, working my own hours, and having a schedule that has space to teach yoga. 

I began to gain interest in a career that would compliment the lifestyle I was seeking, programming. I got my start by taking classes with a local non-profit, Girl Develop It. Their beginner friendly classes not only taught me the basics, but left me feeling empowered to learn more on my own. I got into the routine of waking up early before work to teach myself how to code. I was determined. After 5 months, I realized that a coding bootcamp would catalyze my shift in careers, but that would come eventually, I thought — it doesn’t have to happen right now.

I’m not ready. I don’t know enough. Why leave my job now? There’s still space for growth and opportunity in my current role. I fed myself excuses. 

Ultimately, clinging onto an outdated dream was no match in comparison to my zeal to make the leap.

In a few weeks I’ll be starting my 5 month bootcamp to become a Software Engineer. I don’t know what will follow, but I do know I want to build a lifestyle that my soul desires. I don’t feel ready, but that’s the point.

I’m on the other side of all the confusion, resistance, and fear. Through it, I learned that I outgrew a previous self’s dream in order to grow into a dream that fits all the pieces of my current self. And if I’m lucky enough, this will not be the last time I go through this dream cycle.