The Flatiron School

Make yourself useful.

ManhattanJS: Alumni Announcements, Presentation Slides, <3’s

Every month, we’re really happy to host ManhattanJS, a group of JS enthusiasts (including a bunch of our alums!) who bring great programmers together to talk about their work, passions, and sometimes cats. Yesterday evening marked the latest of these gatherings—and we had a blast. Here’s proof! All photo credits go to the talented Matthew Bergman.

Alumni News

Sara Gorecki, who recently graduated from our Web Development class, announced the very first QueensJS meeting, taking place on August 8. There are only a few spots left. Snag one here! All ticket proceeds go towards charities that work to increase code literacy among NYC youth.

And Ruby alum Saron Yitbarek gave a non-technical talk about her passion/talent for drawing.

…in which she shared the drawings she made for her Flatiron School application (it was awesome), including one our CEO Adam’s face.

Pretty good, right?!

Presentations and Slides

Nicholas Ortenzio, a developer at the NBA, spoke about using D3 and Angular to visualize data. Here are his slides for your perusal.

Steve Klabnik of Mozilla talked Rust for Rubyists. You can find his slides here.

Finally, big thanks to the ManhattanJS folks, Zahra, Rushaine, and Brenda for showing us such a good time. The next meeting is on August 27. Visit their site to learn more!

Flatiron School + Fog Creek

Sweet! Today is the day we get to tell you about the new Fog Creek Fellowship.

We’re so excited to announce our brand new partnership with Fog Creek Software—creators of Trello, FogBugz, and Kiln. As part of a two-month fellowship program, Fog Creek will host and mentor a select group of freshly-graduated Flatiron women. Paired with a Fog Creek engineer, Fellows will get to spend their time honing their new skills with dedicated pair programming and full access to all of Fog Creek’s resources. Together, we hope to help awesome Flatiron School women land programming jobs they love.

Fellows will be spending time at Fog Creek’s offices in the Financial District.

Develop Great Talent

The Fellowship will give great talent a place to grow. Fellows will spend two months hanging out with Fog Creek’s team and participating in a structured mentorship and job training program. They’ll get interviewing practice and resume reviews with top-tier tech recruiters, a chat with the company’s founders Joel and Michael, and of course, a designated Fog Creek mentor.

Mentors will join Fellows for a weekly 1:1 lunch, a mock coding interview, a bi-weekly pair-programming session and more. In the end, Fellows will become even more talented programmers, bolstered by long-lasting relationships with both their mentors and with Fog Creek.

Encourage Amazing Women

Programs like our NYC Web Development Fellowship allow women to start closing a massive skills-gap in tech. Fog Creek’s Fellowship will pick up where we’ve left off and provide women who have just learned a new skill-set and are eager to kick off their careers in tech with the tools they need to get their first programing job.

We know how great the women who come to Flatiron School are. Unfortunately they are sorely underrepresented industry-wide—including at Fog Creek, where in the last six months just 14% of technical applicants were women. With the Fog Creek Fellowship, we hope to encourage even more great women to start programming, grow into senior positions, enrich the tech industry, and excite future generations of female programmers. Our goal is to ultimately see these efforts reflected in a higher percentage of women in applicant pools at Fog Creek and across the tech industry.

Our alums are great—we know they’ll help inspire even more women to start programming.

Why Fog Creek

We spend a whole lot of time making sure our grads get the best first impression of the tech industry possible. We want them to love their new gigs, and we’re pretty sure they’re going to love spending time at Fog Creek. They’ll get to experience what it’s like to work at a company built by developers for developers. They’ll also get to immerse themselves in a company culture that really values their people—so much so that every developer gets a sustainable workload and a private office.

Fog Creek’s culture in action

Fog Creek’s focus on people and collaborative learning has so far helped them attract some of the smartest folks around (their acceptance rate for full-time developers is .4%). We could not be more excited that Fog Creek’s exceptional people are donating their time to mentor and support our incredibly talented women—and encouraging even more to apply.

Expect more announcements in the coming days and weeks on the official program page. In the meantime, if your company would like to get involved and mentor Flatiron grads, get in touch.

We can’t wait to start making it happen!

Canyon of Heroes

Or a lesson in Financial District history, from Ruby student (and archivist!) Ashley Blewer, originally posted here.

When walking to and from class every day at the bottom of Manhattan, I’ve noticed plates of text on the ground with a date and name of a famous person. I didn’t realize what these signs were about until I was walking out of the southmost Bowling Green stop and saw the initial plaque on the ground:

After that, everything clicked! They are commemorating every ticker-tape parade held on Broadway, starting with the first to commemorate the dedication of the Statue of Liberty in 1886.

Before I came to the Flatiron School, I was working as a moving image archivist. I primarily worked with collections of newsreels from the 1920s and 1930s. My job was to catalog them and put them online for access. When I realized what the text on the ground stood for, I immediately ALSO realized that I recognized so many of the names because I had seen some of the actual parades happen (on film)! The text that struck me the most while walking up the street was this one:

I’ve definitely watched this footage. I ran to the (digital) archive and sure enough, there it was.

Footage identification can be difficult when you don’t have a lead, but this connection was pretty easy to make. I watched the footage, paying attention to the structures of the buildings, and then pulled up Flatiron School’s address on Google Streetview. Boom! It was a total match!

Here is a screencap of the Amelia Earheart ticker-tape parade superimposed on top of Google streetview.

Pretty cool!

Bonus: The building that the Flatiron School is located in used to be the office building for the White Star Line, which built the RMS Titanic (and many other, sturdier ships). Cool!

A Better Git Workflow: A Better World AKA My Induction Into The Git Police

Originally written and posted by Web Fellow Edward Leon Jasper right here.

I can’t possibly think of anything more joyous than a great Git workflow. What I thought was once so easy has proven to be not easy at all. Working with Git in a group has been a scary monster: hours of work lost in a single key stroke, app breaking bugs appearing out of thin air, forms that render twice! It’s enough to make you want to scream! I wanted to finally explore a better way to work with Git in a group setting.

So we all know that when making a new feature we should be working on a separate branch. It’s important to understand that the master should remain deployable at all times! No one works off the master once the app is fully functional. This is one of the reasons I love pull requests with Github. It allows for features to be discussed before they are integrated with the master. This also allows you to ask for help on a feature without touching the polished copy.

Tip: Feature branches should have descriptive names of their purpose such as movie-form-view.

Tip: Commit often. When doing labs, we would often wait until the end to commit and push. This is a horrible practice where we need to be committing changes very often, such as when we’ve made a measurable change. The Picklebacks(soon to be link to their project) had it right when they played Salt-n-Pepa’s “Push it” everytime they where ready to commit a change.

Once we have a feature that is ready to be merged, the two parties should discuss the changes made. Once that is ready we can run:

It’s pretty simple but important to have a firm grasp on.

Merge conflicts are easy, even a few lone line breaks can make an issue.

Tip: Work on your files only! If a grammatical error needs to be made on your home page and that is not part of your feature. LEAVE IT ALONE. Let the developer in charge of maintaining the master make those changes THEN pull those changes to your branch and continue to work. Feature branches are as simple as changing what you want when you want it. Each branch and pull request should be for its own individual issue and nothing more.

Following these simple steps will help your work flow drastically but if you need some help…just call Git-1-1 and the Git Police will be right there!

Project Recap: Kickammender

Like so many of our alums, Michael and Joe both applied to Flatiron School at points in their lives when they weren’t sure what was next: Joe was an economics major turned Marine, and Michael was shirking questions about applying to PhD programs. Now full-time developers, they used their time at Flatiron to level up their programming skills and work on a project called Kickammender—a recommendation engine for the ridiculously popular crowd-funding site Kickstarter.

How They Got Here

When Joe left the Marines, he felt like he needed a new skill to join the workforce and started learning to program. “I never really considered myself a technical person,” he said, “But it was gratifying to write code and have it actually do something.”

After graduating university with a degree in Electrical Engineering, Michael worked for a hardware company with 2,000+ employees. He had a lot of ideas he wanted to bring to life at a smaller startup but felt he like he needed to know how to program in order to get a job. “Programming gives you the power to make your ideas,” he explained, “By the end of the program [at Flatiron], I was able to do stuff that I wouldn’t have dreamed of before.”

“By the end of the program, I was able to do stuff that I wouldn’t have dreamed of before.”

Why Kickammender?

As students, Michael and Joe worked on Kickammender to apply their interests, grow what they’d learned, and fill what they perceived as a gap in Kickstarter’s user experience. Although Kickstarter users can follow their Facebook friends’ activity, preference-based recommendations don’t really exist.

“It’s hard to find better, more personalized recommendations,” Joe explained. “If there’s a new project out that you might want to check out or back, there was no way to know or be notified.”

Their solution? Just a few weeks into the program, Michael built an engine that used machine learning to make dynamic product recommendations. “I was just going to write a blog post about it,” he said, “But I got kind of obsessed.” They decided to use the momentum and excitement from this initial project to make something bigger.

How it Works

Kickammender uses machine learning and the k-means clustering algorithm to compare users to the thousands of other people on Kickstarter. When the app finds a group of users with similar preferences, it recommends projects that real people in that group have backed.

Users simply log in through Facebook and receive dynamically updated recommendations based on what they’ve liked before. They can also tailor their recommendations with feedback, save projects they’re interested in, and find Kickstarter users outside of their Facebook network with similar preferences.

Challenges and Highlights

Challenges ranged from having to go through the process of scraping Kickstarter’s infinitely scrolling site in the absence of an API to disappearing data points. “Disappearing clusters,” Joe explained, “we’d have 100,000 data points, process them through the algorithm, and at the end of that process, half of the them would be gone. It took some refactoring to fix.”

In spite of technical challenges, they still point to Kickammender as a big achievement in their learning process. “It was the first software project that I ever started and finished,” Michael said. “Everything about it was challenging, but I’m really proud we did it.”

“It was the first software project that I ever started and finished. Everything about it was challenging, but I’m really proud we did it.”

Although Kickammender was developed independently, it got a shout out from a Kickstarter Product Manager on Twitter. Still, the real praise is in the product itself. Even as fresh-out-of-the-box Rubyists, Michael and Joe took a great but little-known feature on a popular website and made it even better.

The Stack

Built with Ruby on Rails
PostGreSQL on the backend
Javascript Bootstrap on the frontend
Served up by Digital Ocean

Um, so we have these chairs…

… and Ruby 005 student Ben Serviss has cleverly used them as an analogy for learning to program. Who knew! Here’s his post, reblogged from here

The first time I walked into The Flatiron School, I thought to myself: “What are these crazy orange things?”

I had come to one of the weekly NYC on Rails meetups in December of 2013 to check out the vibe and decide if I wanted to apply to the school’s web development program. Strewn about the main meeting space were knee-high, accordion-esque bright orange… things.

Were they chairs? Were they stools? Were they the missing business ends of giant toddler-sized toy hammers?


Spoiler: They turned out to be chairs. Ergonomic chairs, in fact, created by designer Alan Heller. The ErgoErgo chairs (as they’re officially called) were designed to encourage active sitting, relying on the sittee’s core muscles for stability as you rock gently back and forth.

Once I had gotten used to the concept, using the chair turned out to be fun in its own novel way. Figuring out how to best use the chair added a playful dimension in talking to the other meetuppers, helping ground the evening in a more open-minded mood.

Now that I’m a full-time student at Flatiron, I’ve noticed how easily my classmates have incorporated the chairs into their routines. Since they’re so modular and light, it’s easy to grab a few and turn any table into a lunch spot or meeting area, use one as a footrest, or even corral a bunch into a nifty nap corner. In just a matter of weeks, the ubiquity of these strange little chairs had become a given.

Cool, right? There’s something else entirely that explains why these peculiar little chairs fit in so well here – and it’s because the entire process of encountering, evaluating, interacting and experimenting with them is a perfect metaphor for learning to program.


Upon first glance, ErgoErgo doesn’t look like any chair that belongs in an office setting – there’s no back, they’re too short, the shape is wrong, the color is far too bright – and you’re immediately thrown out of your comfort zone, just as someone new to programming is quickly buried in confusion.

Then, as you figure out that it’s just another type of chair, you try sitting on it and gradually learn how it operates – how much rocking you like, how much give each side allows, etc. This is analogous to the long acclimation phase of learning to program – deciphering what error messages mean, how data structures behave, what kind of commands are expected, and so forth.

Finally, as you accept ErgoErgo’s new definition of what a chair can mean, you grow comfortable in its use – turning something that was strange and unfamiliar moments ago into something you totally understand. It goes without saying that the programming equivalent to this stage is rather long, but the metaphor is already complete. Something that once beguiled you as intimidating or impossible is now something eminently knowable, with time and experience the only obstacles to an increased understanding.

The entire process of encountering, evaluating, interacting and experimenting with them is a perfect metaphor for learning to program.

A major part of becoming a programmer is mental. The mental shift from “I need a programmer to help me” when faced with a technical problem to “I can figure this out” is an important one; the transition from being frustrated with code defects to being driven by curiosity to find the problem is critical in staying motivated to improve.

As much as I may be reading into this, and as off-the-wall a metaphor it may seem, having these odd chairs around as I’m trying to mold myself into a programmer is a constant reminder that what may seem unfamiliar and alien one day may become familiar, welcome and fun the next.

Flatiron Students Present

Yesterday evening, we kicked off this semester’s weekly student presentations. Every Flatiron student has to give at least one technical presentation while they’re here. There’s pretty much no getting out of it, but last night’s presenters had the reckless audacity to go first. It’s kind of a big deal considering they’ve only been coding for a month, and, of course, they did an incredible job.

Here’s the evidence:

iOS student Tarik Fayad presented his music player, which played us music.


Ruby students Spencer Tang and Edward Warren used the Yelp API to give us timely restaurant recommendations.


Web Fellows Yaritza Rodriguez and Rebecca Poulson broke down a GET request and explained the Internet. 


And Amber Tunnell and Ben Shore made Ruby gems.


Then when we remembered that they’d only been doing this for a month, we were all like:


We can’t wait to see what everyone else gets up to! A few students will present every Tuesday until the semester’s over and we can’t actually make them do it anymore (though they usually keep presenting at Meetups and conferences!). In addition to Flatiron Presents, we’ve got a lot of free, public events happening soon. Feel free to take a look at our Meetup page and stop by!

Tonight we’re talking Swift. So if you’re an iOS developer, RSVP to come learn with us and get approximately 2 hours of Swift experience.

Thank you, NYC

Flatiron Loves NYC

We are thrilled that The New York Times chatted with recent alum Jahmil Eady about her experience with the NYC Web Development Fellowship. The program is incredibly special to us, and it’s awesome to comb through tweets to see Jahmil’s story excite and inspire people—mostly because of how deeply it excites and inspires us.

The Fellowship is just one of so many amazing initiatives made possible by NYC Workforce1 and the NYC Department of Small Business Services. Both the Bloomberg and DeBlasio administrations have made enormous strides in workforce development in the innovation sector and in making technology accessible to all New Yorkers.

We feel incredibly lucky to be a part of their plans and to help them make our city even better. Thanks to their help, guidance, and foresight, we’ve been able to offer a programming education to great people, totally free of charge. It’s been an amazing experience, and we can’t wait to accomplish even more together. Thanks, NYC, for making this possible!