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 “git@github.com:mccarronmollye/codenewbiepod.git” 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@github.com:username/project.git”)

git remote add origin git@github.com:mccarronmollye/codenewbiepod.git

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 'git@github.com:mccarronmollye/codenewbiepod.git'

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 https://www.codenewbie.org/podcast. 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 learn.co as an editor. Learn.co 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 https://www.youtube.com/watch?v=RrAOlk6qoiM 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 https://www.youtube.com/watch?v=_lDExWIhYKI, 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: https://www.youtube.com/watch?v=R9I2uvkwKhc. 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!