Last Seen Blogs
lefrango
PREGO
gabrielhenrypoesie
Gabriel Henry
postcogniticn-blog
elle me dit
heylittledino
Fangirling is a life philosophy.
doctorlunaliss
For the love of Arceus, stop doing dumb shit.
Photo
So excited to partner with @karliekloss on the #KodeWithKarlie scholarship for high school girls. Learn to code. Change the world.
13 notes
·
View notes
Text
I GRADUATED ONE YEAR AGO.
Today marks exactly one year that I have been a developer. What has it been like?
Read More
14 notes
·
View notes
Text
Flatiron School Partners with the White House on TechHire—a Plan to Expand Access to Tech Education
We are thrilled to have collaborated with President Obama and his Administration on the TechHire Initiative—a multi-sector effort and $100 million in grants to help Americans find technology jobs. As technology has permeated every aspect of our lives, it has transformed the economic landscape, rendering every industry from medicine to publishing inherently technical. Today, there are half a million jobs open in technology fields—many of which did not exist a decade ago—and these numbers are only expected to rise.
Behind these job openings are companies who need more people than ever to fill technical roles. TechHire was developed to give more Americans the education they need to succeed at these jobs, meet employer demand, and create a positive feedback loop between a skilled workforce and a strong tech economy. TechHire was developed not only to help connect people with well-paying jobs but also to support the future competitiveness of our country.
One of Flatiron School’s biggest goals has always been to put our students on the path to better employment prospects, and ultimately, a better life. It has been an honor to partner with the City of New York on the NYC Web Development Fellowship and help New Yorkers launch new careers in tech. As part of TechHire, we have committed to pro bono consulting to expand and improve training programs like the Fellowship.
We can not wait to grow the Fellowship, iterate on its model, and help even more cities and communities train people for fulfilling careers. For more on the TechHire Initiative, read the whitehouse.gov Fact Sheet.
9 notes
·
View notes
Text
Flatiron School Pre-College Academy at SXSW
This week, our Pre-College team is hanging out in Austin, Texas at SXSW. If you're in town, catch us on Tuesday at booth 428 at the Education Expo. We'll be raffling off a drone from 2:00-8:00PM.
Here's what else is on the schedule so far:
What:
Lyel Resner, Director of K-12 Programs at Flatiron School, will speak about the changing role of tech in education. Learn more.
When:
Tuesday, March 10, 2015
5:00 - 6:00PM
Where:
Austin Convention Center EH4 - STEM Pavilion
500 East Cesar Chavez Street
Stay tuned for even more Flatiron School events and workshops at SXSW. Hope to see you there!
1 note
·
View note
Text
Code History Lesson: Edsger Dijkstra
Computer Scientist Edsger Dijkstra shaped his field from both an engineering and a theoretical perspective. Today, he is best known as the inventor of structured programming, a master of tongue-in-cheek commentary, and a former owner of a Volkswagen van dubbed “the Touring Machine.” Despite what he might have said about object oriented programming, Dijkstra is always a part of Flatiron School lectures.
Dijkstra is well known nowadays as the inventor of structured programming—in which programs flow from top to bottom following a hierarchical model. As the terminology implies, this invention has made code more structured, and, more specifically, clearer, faster, better organized, and higher quality.
That structured programming is one of Dijkstra’s central contributions makes sense given his advocacy for simplicity above all and his critical perspective on programming languages. This perspective is summed up nicely in a short, tongue-in-cheek essay called “How do we tell truths that might hurt?” that Dijkstra published in 1975.
The essay is centered on aphoristic “truths” about programming. Most of these “truths” are blunt and biting. For example, “The use of COBOL cripples the mind.” Apart from his harsher truths, one statement resonates in particular:
The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities.
Dijkstra saw the programming languages available in the 70’s as flawed. His work toward improving them was in service not only of faster programs, but also of a more rigorous, innovative approach to programming. As we interpret it: using inadequate tools is damaging not only to programs but also to a programmer’s ability to think of elegant solutions to complex problems—an overarching theme in Dijkstra’s work. As he once said:
“If 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, ‘Dijkstra would not have liked this,’ well that would be enough immortality for me.”
Read more Code History Lessons. Edsger Dijkstra art by Flatiron alum Mitch Boyer.
5 notes
·
View notes
Text
A Flatiron Alum Learns Web Development to Pay off Student Loans
Like almost 70 percent of college seniors, Flatiron alum and Bronx native Armando Amador graduated with student loan debt and uncertain job prospects.
After several years working in editorial design, Armando wasn’t able to make much progress toward paying off his loans—but he did discover an interest in software engineering. When he found that he was eligible for the NYC Web Development Fellowship, he decided to apply.
After graduation, Armando landed a job at Wizard Development where he is currently pursuing a new passion and earning a salary that will allow him to pay off his student debt in just a few years.
Although salary shouldn’t be the guiding force behind switching careers, it does make a difference. “Now I have leeway to pay extra on my student loans,” Amador told credit.com. “And I don’t have to sacrifice going out with friends or buying gifts because of payments on my student loans.”
Read the rest of Armando’s story or check out even more Flatiron alumni stories.
9 notes
·
View notes
Text
Hackers and Theater-Makers: Code as a Creative, Collaborative Medium
Alum, Fog Creek Fellow, and former Lighting Designer Amanda Chang is currently an Instructor in Flatiron School's Web Development Immersive. Now into her new career, Amanda took a moment to reflect on what she's brought with her from her theater days: a collaborative spirit and the desire to create.
When I decided to enroll at the Flatiron School and shift my career from theater lighting design to web development, I worried unnecessarily that I would lose my drive to create. In practice, I constantly meet other developers with creative passions. My mentor, who I met through the Fog Creek Fellowship, is also a musician who keeps guitars in his office. One of my current Flatiron School students used to be a curator. The list goes on.
The fact that I've met a surprisingly large number of creative people in the NYC tech community may be explained by an essay written by programmer and writer Paul Graham entitled "Hackers and Painters," which was one of the first readings assigned to me as a Flatiron School student. In his essay, Graham enumerates the similarities between computer programming and art. He explains:
Development is collaborative
Although programming is often thought of as a solitary activity, I haven't found this stereotype to be true. Working with my peers on final projects was one of the most valuable experiences from my time as a Flatiron School student. Each member of the group brought a unique perspective, as well as a different set of strengths.
The benefits of working with others to complete a task are articulated in dancer and choreographer Twyla Tharp's book The Collaborative Habit. In the book, Tharp explains how collaboration inherently grants new insight:
As a practical reality, let's look at collaboration with a single partner. We bounce ideas off another person. Then the other person volleys them back to us. That exchange makes us hear our ideas with new ears for the simplest of reasons—what our partners say is not a literal repetition of what we said.
Theater at its core is a collaborative art form. Most successful production staffs include a director, a set designer, a lighting designer, a costume designer, and a sound designer, all working closely to realize the same vision. I've learned that a team full of talented specialists creates a spark. As Tharp states, "People in a good collaboration accomplish more than the group's most talented members could achieve on their own."
The open-source movement relies on this philosophy that multiple people working on different aspects of a project creates something greater than the sum of the individual parts. As I'm writing this blog post, Rails has 2,596 contributors on GitHub. Many tech companies have their developers program in pairs, in order to optimize efficiency, learning, and satisfaction and minimize code defects. And just recently, one of my Flatiron students declared, "It's so rewarding to see how others at my table approach a problem. They think about it in completely different ways than I do."
Applications evolve with their users
Unlike most paintings, works of theater continue to evolve even after they are revealed to an audience. What results is a living, breathing work of art that responds to human interaction. In his monumental book The Empty Space, theater and film director Peter Brook outlines an experiment in audience influence, involving an amateur actor reading a speech from Henry V:
The amateur actor was to read the speech again, stopping for a moment after each name: the audience was to endeavour silently in the pause to recall and put together its impressions of Auschwitz and Agincourt, to try to find a way of believing that these names were once individuals, as vividly as if the butchery had occurred in living memory...Now the audience’s concentration began to guide [the actor]: his inflexions were simple, his rhythms true: this in turn increased the audience’s interest and so the two-way current began to flow. When this was ended, no explanations were needed, the audience had seen itself in action, it had seen how many layers silence can contain.
Professional theater productions hold open "previews" before the official opening night. These previews allow the team to continue shaping the show based on audience response.
Similarly, most web applications continue to grow even after they are deployed. Here at the Flatiron School, students present their projects to their classmates and instructors throughout the building process, in order to get feedback from potential users.
But why does it matter?
What I think developers, painters, and theater-makers all have in common is the desire to understand and contribute to the human experience. In order to do that, we must absorb our surroundings and let every interaction influence our work. In "Hackers and Painters," Graham writes:
Empathy is probably the single most important difference between a good hacker and a great one. Some hackers are quite smart, but when it comes to empathy are practically solipsists. It's hard for such people to design great software, because they can't see things from the user's point of view.
Developers can learn about empathy through great works of theater, and theater-makers can uncover truths about humanity through the ways in which people interact with applications. Regardless of our medium or our motivations — to make life more convenient, more beautiful, more entertaining — artists and programmers alike create for a better world.
Stay in touch with Amanda on Twitter or read more posts by Flatiron staff.
3 notes
·
View notes
Text
Make Your Data Meaningful: Announcing Introduction to Data Science
We’re so excited to announce the launch of Introduction to Data Science—a two-week course designed to give students the tools to make their data even more meaningful.
About Introduction to Data Science
This part-time course provides students who are already familiar with concepts in data science with the skills to extract meaning from datasets too large for Excel. Over the course of two weekends, students will learn to gain customer insights by analyzing a public dataset with hundreds of thousands of records using the pandas library and Python.
Why Data Science?
In our connected world, the ability to analyze data and communicate insights is an increasingly valuable skillset. Data science positions are on the rise, but finding a great data scientist isn’t easy. It’s difficult enough for recruiting departments to find adept PhDs and talented programmers to fill their open positions—let alone candidates with both a solid understanding of data and the programming schools to match.
We’re so excited to start helping people who are passionate about data get the programming skills they need to meet the realities of today’s job market—and to make their data even more meaningful.
Prerequisites
All Data Science students should feel comfortable using Excel for basic statistics—including concepts such as mean, mode, median, outliers and normal distributions.
Course Details
Tuition is $1,500. Students who are already comfortable with Python do not have to attend the Python portion of the course. These students can contact us at [email protected] for a discount code.
All courses will be taught in-person at the Flatiron School campus in The Financial District.
Learn more or enroll now!
hbspt.cta.load(69751, 'b3fbe7be-034e-426a-acdb-aa6b51198992');
6 notes
·
View notes
Text
NYC Mayor Bill de Blasio Shares a Flatiron Alum's Story
In a talk at the Ford Foundation, New York City Mayor Bill de Blasio shared the story of Flatiron alum George Taveras—a Bronx native who dropped out of college to take care of his family and who now works as a software developer at XO Group. We are honored to be a part of George's story and a part of NYC's efforts to make technology available to all New Yorkers.
youtube
Watch the full speech or read more Flatiron Alumni Stories.
4 notes
·
View notes
Text
From a High School Computer Lab to Makerbot: a Flatiron Alum Shares the Importance of Mentorship for Aspiring Developers
Keith Williams grew up with limited expectations of success. Although he didn't have a computer at home, he did have a lot of people around who supported him through school and guided him into a career in tech. Now a graduate of the NYC Web Development Fellowship and Web Engineer at Markerbot, Keith chatted with us about mentorship and his decision to start programming.
Can you share a little bit more about your background? What were you doing before you came to Flatiron School?
I went to NYU Poly, and got a degree in electrical engineering from NYU. After college, I worked as an engineer for five years, and left to become a tech consultant at Accenture. I always wanted to be in computer science but I never really had the opportunity. I went from electrical engineering to tech consulting in the hopes of getting more involved with software—but it didn’t end up happening. By the time I left Accenture, I was ready to just go for it and learn on my own.
What made you decide to leave tech consulting and start learning how to program?
There were plenty of opportunities for bad influence, but my parents were really invested in helping me succeed. They knew that if I had an education, I could probably do something good. I focused on learning, but other than that, I knew I loved computers. I didn’t have a computer at home so in high school I convinced the janitors to let me in the computer lab before school started. One of the computer science teachers found me in the lab and gave me a few books. She ended up being a kind of mentor, and guided me into pursuing a career in tech.
That was how it started. Then, while I was working at Accenture, I had basically become a project manager—assigning work and acting as a pipeline between people who needed things done and the people who actually did them. It was fine, but I wanted to be the one actually doing the creating and building. I wanted to feel like I was actually making something that affected people in a positive way. I wasn’t really sure what I wanted to make, yet. I just knew that I wanted to be a programmer and make something positive.
It seems like mentorship and good influences—your teachers and parents—made a big impact. How did they affect your career choice?
Yeah, they definitely did. Having excellent mentors has been a running theme throughout my life. I've had these people who were always very supportive of me and guided me. I was lucky enough to have found positive influences in my parents, teachers, and mentors in high school and to have followed their advice.
The same thing happened with Flatiron School. When I figured out I wanted to switch careers, I found a Meetup geared toward diversity in tech called Black Techies. It was through that group that I met Blake, one of the Fellowship Instructors. Blake was someone like me who wanted to get into technology and made a leap to do it. He told me about the NYC Web Development Fellowship. I applied and thought, “We’ll see.” I’m happy it has worked out—and that other people were a really big part of getting me here.
My classmates and instructors during the Fellowship—we were all from different backgrounds. We grew up differently, in different places with different interests. Whenever I or anyone else needed help, inevitably one of my them would use an analogy to explain the material that made me feel like, “Oh, I never thought about it like that.” Having all of these points of view made a huge difference. I'm just thankful to have even met these people.
"I'm just thankful to have even met these people."
That’s great! So have you gotten a chance to do something good?
Yeah, absolutely. Learning to program opened up a lot of opportunities for me to do good, from teaching to actually building things. At Flatiron School, a classmate and I started working on an app to help connect restaurants that were throwing out food with homeless shelters. We started building it and everything was going well, but ultimately we weren’t in the restaurant industry and we didn’t know anything about delivering food to homeless people. We were just going from instinct.
It turned out that another classmate knew someone running a non-profit that did exactly what we wanted to do—help take food from restaurants and give it to homeless shelters. We were able to meet with them a few times and help them build up to and better understand what a system like this might look like. That made us feel really good—we were actually affecting change in real life.
I can say the same thing of my current job. I’m a developer at MakerBot—a company that’s leading a revolution in 3D printing and in DIY. They are bringing the power of manufacturing down to the consumer level so that anyone can make anything. I feel like I’m learning every minute of the day and I get to be a part of this bigger movement in tech.
Do you have any advice for people who have a background like yours and want to learn more about technology?
Just starting to learn how to program is really overwhelming. This feeling is compounded when you’re a part of a visible minority group. When I first started, I thought that to be a true computer scientist I had to go to school, get a Masters or a PhD, understand ins and outs of algorithms, and be able to write my own libraries. I think a lot of people have this misunderstanding.
People buy into the stereotypes of that it means to be successful as a developer—like they have to be exceptional at math and start writing code as five-year-olds. I never had a computer growing up, so I feel like web development is available to anyone who is excited about technology and willing to put in the effort. It is all a matter of knowing this is an option. A lot of times, it just comes down to someone else encouraging you and giving the confidence to do it.
"Web development is available to anyone who is excited about technology and willing to put in the effort."
I really want to help people reach this point. I’m happy to help them start learning how to code—I’ll give an introductory course to anyone who asks. I also volunteer as much as I can and go back to my high school in Philadelphia once in awhile. I want to help people get excited about technology or even about the fact that their background doesn’t have to define their futures.
Ultimately, I’d like to be an inspiration for people to follow their passions and pursue their dreams regardless of where they came from. I want them to know that they can choose their direction in life. It feels like there’s a ceiling and maybe that ceiling is their financial situation or it’s their own self-confidence—but this doesn’t have to keep them down. They can do it. They can do anything.
Keep in touch with Keith on Twitter or read more Alumni Stories.
hbspt.cta.load(69751, 'd4985497-5ea1-4511-a5e2-73d3cc2aa9b6');
7 notes
·
View notes
Text
Spotify Names the Chloe Weil Scholarship to Help Flatiron School Women Fund their Education
We’re proud and honored to announce a partnership with Spotify to support women in technology. This popular music platform will offer generous scholarships to our Spring 2015 class—and a paying internship for one Flatiron graduate.
Spotify has generously provided $10,000 in scholarships—nearly $600 per student—to be divided among all of the women in our class. Following graduation, Spotify will interview and hire one paid intern from the group of scholarship recipients.
Spotify has named the program the Chloe Weil Scholarship as a memorial to Chloe Weil, an inspiring designer and engineer who took a strong interest in creating opportunities for women in technology. Chloe's path to a technology career wound through art school, a chemistry major and positions at Internet-based companies on both coasts—and when she joined Spotify, Chloe sought challenges that pushed her creatively and required technical exploration and learning.
“We hope the recipients of the Chloe Weil Scholarship use this time to push themselves, study, learn and find their place in an ever expanding tech industry that now more than ever offers opportunities for women with passion to build something they love.”
Increase access to skills
We often discuss ways to increase access to our courses and remove the barriers that prevent great students from applying and attending. Paying for education is just one barrier—and the Chloe Weil Scholarship will help lower it for an entire semester of women.
Support the recruitment of a highly qualified female engineer
The team at Spotify is known for its passion, creativity, and stellar engineering reputation. The woman Spotify hires will have to go through their interview process, qualify for, and ultimately earn her role.
We are proud to include Spotify among the incredible companies who have partnered with us to hire, mentor, and support Flatiron students and grads. We’re working towards a goal we all want to achieve—a more representative tech industry, that’s better for including a range of backgrounds and perspectives.
If you’re interested in partnering with Flatiron School to support diversity within your organization, let us know or email [email protected].
14 notes
·
View notes
Text
How to Become a Software Developer: Lessons in Fearlessness and Fortitude from Fog Creek and Flatiron School
Flatiron Alum and Fog Creek Fellow Vaidehi Joshi originally posted this piece on her path from writer to developer in her blog Words and Code. She graduated from Flatiron School in December and has recently accepted a position as a Software Developer at Friends of the Web.
There are a lot of scary things out there. To start, there are lions and tigers and bears. But if you go a bit below the surface, that’s where you’ll hit the dark stuff—the kind of stuff that I was forced to confront when I started as a student at The Flatiron School.
Most of us have all had these thoughts at some point in our lives, regardless of what we look like or what we do for a living. Some of us have stopped dead in our tracks, sometimes unable to move beyond them at all. But learning to code meant dealing with these fears on a daily basis; at some point, I just stopped listening to them entirely.
The Fog Creek Fellowship
Before I learned to code, I was a writer and a teacher. In other words, I had no background in computer science or software developement. Now, it’s already pretty terrifying to enter a new field in which you have no experience. But it gets even more frightening when you realize that only 25 percent of the industry is female and that 71 percent of your coworkers are white. All these facts combined can be fairly paralyzing—it’s no wonder, then, that so many women and minorities choose not to enter STEM fields.
After graduating from Flatiron, I found myself facing an entirely new sea of questions: Am I prepared for all these technical interviews? How do I negotiate a salary? What offer should I accept? What’s the best job for me? Do I want to be the only woman in an all-male tech team? Luckily, I didn’t have to swim through this alone. Instead, I had a support system gliding along beside me the entire way: The Fog Creek Fellowship.
Forged through a partnership with Flatiron School, the Fellowship is dedicated to creating a more diverse and welcoming tech community by nurturing a select group of female Flatiron graduates as they look for their first programming jobs. Fellows are paired with a Fog Creek, Trello, or StackExchange developer—who just so happen to be some of the best coders in the country—and have the opportunity to create long-lasting relationships through pair programming sessions, interview prep, and technical talks.
Fearlessness
I wasn’t sure what to expect when I started the fellowship. Thankfully, my phenomenal mentor Ian was full of ideas. Thinking back on it now, I realize that all of our mentors helped us to confront the things that we were the most uncomfortable (read: afraid) of.
A lot of us didn’t understand a lot of the computer science concepts that were coming up in technical interviews, so the mentors took the time to review tougher technical topics, and encouraged us to always speak up if ever we were confused.
I always wanted to learn more about Objective C and iOS, so my mentor and I built a simple iPhone app that implemented the New York Times API and showed the top stories of the day. It was undoubtedly hard, but everything that’s new and different always is. Ian helped me face my doubts head on, and nudged me to be unafraid of making mistakes or being wrong.
All the mentors and mentees hung out together, ate lunch, and talked tech and non-tech topics. And when I was trying to choose between a few different offers, they helped me talk through what I wanted out of my job, and which position would make me happy. We talked about everything from what we wanted our careers to look like in five years, to the pipeline problem for women in tech.
Fortitude
It takes a great deal of grit and strength of mind to endure and accept obstacles that come your way. To be a woman in technology, you need ample amounts of fortitude. There’s really no other way to put it: it’s hard to be a woman in tech. It’s hard to be a person of color in tech. But the only way that we can begin to change the reality of the situation is by bringing in more women and minorities into the industry.
Granted, the solution to the problem might come in different shades for various people. Whether that means creating relationships based on trust and openness (such as the ones that we had with our mentors), or providing the resources to build confidence (like technical talks or interview prep), they’re all steps in the right direction. If enough people follow suit, the industry will soon have an entirely new generation of developers and engineers, each of whom will pay it forward.
From my own personal experience at Fog Creek Software, I can definitely vouch for the simplicity of a safe, welcoming space for women. If you’re wondering how you can change the industry, I’d say that this is a good way to start. I suppose that it’s a simple thing, really, but it makes a world of difference. Both Fog Creek and the Flatiron School are communities that acknowledge a problem and then proceed to create an environment that mirrors a world that we want to one day live in.
I’d consider myself one of the lucky few who has been a part of this incremental change. The Flatiron School and the Fog Creek Fellowship opened so many doors for me—doors that I know I could have never opened on my own. As I take my first step and start a new job as a developer, I’m realizing that the fellowship isn’t really over. It’s just that my role in it is changing. Soon, it’ll be my turn to help open the very same doors for someone else.
Hopefully, she’ll be even more fearless than me.
Stay in touch with Vaidehi on Twitter or read more Flatiron Alumni stories here.
hbspt.cta.load(69751, '0d93876e-9890-43af-b462-b96a2133da90');
5 notes
·
View notes
Text
How to Get a Job After Graduating From a Programming School
Flatiron alum Kyle Doherty originally posted this article on his blog. He currently works as a Software Engineer at AlphaSights.
DISCLAIMER: This is just my opinion based on what got me a job and what my company looks for when we’re evaluating junior candidates.
In the past five months I’ve gone to programming school demo days, career fairs, and other recruiting events to help recruit more junior developers to our team. As a recent grad myself, students ask me what they should focus on post graduation to help them get a job.
The problem, I tell them, is you want to get a job ASAP and there is too much to learn and not enough time to do it in. Generally people advise you to, review everything you’ve learned in the past 9-12 weeks, and then give you 30 other things study…oh yeah, and go to Meetups, ask people to coffee, write blog posts, and work on side projects.
Below is my advice for what to focus on, which I think can be realistically achieved in one week i.e. the last week of your program or the week after you graduate.
1. Figure Out What Type of Job You Want
Do you want to be a frontend developer and write JavaScript, are you interested in getting a Rails job, or something else? Whatever it is go review the fundamentals of that language or framework and make sure you know them.
Review Materials
Ruby and Rails Interview Questions
Javascript Interview Questions
These lists might look like a lot, but remember you should pick one or the other depending on what type of job you want.
Also note, if you get a job in one language it doesn’t mean you can’t learn the other later and start working on those types of projects. We use Ember at AlphaSights and I’m starting to learn Object Oriented JS. Once I have that down I’ll tackle Ember and get on an Ember project.
2. SOLID Object Oriented Code
Understand what good OO code is and start practicing (I’m still working on this). Regardless of the language, if an applicant solves our code challenge using one big method, it’s an immediate deal breaker.
Assuming you want a Rails job, I would read and watch the following resources in the given order and then apply what you learn to your code. Hopefully a code challenge from a potential employer.
Sandi Metz’s Rules - learn these rules and try to follow them as best you can.
Refactoring From Good to Great - this is a great talk! All Ben’s advice is super actionable and can be easily applied. In fact I’m going to go re-watch this right now.
SOLID Object Oriented Design - Sandi Metz explains SOLID OO design principles. I’ve watched this a couple of times, took notes, and tried to apply it, and you should too.
All the Little Things - another Sandi Metz talk. This time she walks through applying SOLID principles to some code.
For JavaScript, ObjectPlayground is a good resource for Object Oriented JS. SOLID design principles will also be applicable.
3. Learn Basic Unit Testing
In my last few weeks at Flatiron I studied and practiced basic unit testing with RSpec in my spare time. With several hours of practice, I got to the point where I could TDD simple problems like the first few on Project Euler. This greatly improved the quality of my code challenge for AlphaSights and set me apart from other applicants because most new programmers don’t write tests.
If setting you apart from other applicants isn’t incentive enough, realize you’re going to need to learn testing for any decent Rails job—might as well start learning.
How I learned Basic Unit Testing Below are the simple steps I took to learn the basics of writing unit tests. If you follow them you should become comfortable writing basic unit tests in 2-6 hours of study and practice.
Four Phases of Testing - read Thoughtbot’s post on the four phases of testing. This will help you understand the fundamentals of testing and how to write the actual tests.
Ruby For Newbies - Testing with RSpec - this post is a little old so you need to replace using a before :each block with let. Read about that here, http://betterspecs.org/#let.
Practice on Euler Problems - take what you’ve learned from the first two blog posts and solve several Project Euler problems using TDD. At this point you’ll be on your way to learning testing.
What About CS Interview Questions
In regards to CS interview questions like the ones you find on Interview Cake. You may or may not need to know them. I personally made a bet that any company I’d be working for would care more about my code quality than my CS knowledge and that I could learn it on the job later. My bet was right and I didn’t get asked any of these types of questions. This doesn’t mean you won’t so take this advice with a massive grain of salt and it least be aware of what things like Big O and link lists are.
That’s All Folks
That’s all I got. In my opinion you should be able to complete everything I recommend in 5-10 days if you’re doing nothing else but programming.
Hopefully you’ve found this helpful. Please let me know your thoughts on what you think programming school grads should be focusing on in their first few weeks post graduation.
Stay in touch with Kyle on Twitter. Get in touch if you'd like to hire a grad or have any suggestions on what our students should learn in order to land their first programming jobs.
hbspt.cta.load(69751, 'd4985497-5ea1-4511-a5e2-73d3cc2aa9b6');
21 notes
·
View notes
Text
The Flatiron School Partners with Teach for America to Launch the Computer Science Education Fellowship Program
To celebrate the launch of The Computer Science Education Fellowship, Flatiron School's Director of K-12 Programs Lyel Resner discusses the lack of qualified computer science teachers and explains why we've partnered with Teach for America to help great teachers become great CS teachers.
We are thrilled to announce our partnership with Teach for America and the Computer Science Education Fellowship. Our instructors will train TFA corps members and alumni to teach Flatiron School’s curriculum in their schools—expanding access to computer science education for all students and helping to address the shortage of computer science education nationwide.
Teaching Teachers Code
Although only one in ten U.S. schools offers computer science courses, educators are increasingly aware of the value this education brings to K-12 students—fluency in a relevant skill set that students can take with them to college and beyond. As pressure mounts to expand and improve their CS curricula, schools are faced with a serious lack of people to actually create and teach the material. There are virtually no teachers who have both the technical knowledge and the classroom ability to meet the skyrocketing demand for CS educators.
To help fill this gap, a few forward-looking organizations are experimenting with bringing engineers into the classroom on a volunteer basis. These organizations are doing important work—but there is so much more to do to bring programming expertise into the classroom.
Program Details
Our Summer 2015 Fellows will be talented teachers who are excited to promote and teach computer science within their schools long after their TFA commitments end. The Fellowship consists of three stages:
Learn to Code: Fellows will learn programming skills through intensive online and in-person training.
Learn to Teach Code: Then, they will learn to teach the material as Co-Instructors in Flatiron School summer programs.
Teach Code: Fellows will gain free access to the teaching tools and curriculum they need to help them bring computer science programs back to their schools.
We can’t wait to welcome and train the inaugural group of CS Education fellows! Apply now or learn more.
About Teach for America
Teach For America partners with communities to expand educational opportunities for children facing the challenges of poverty. Founded in 1990, Teach For America recruits and trains a corps of outstanding college graduates and professionals to make an initial two-year commitment to teach in high-need schools and become lifelong leaders in the movement to end educational inequality. Today, 10,600 corps members are teaching in 50 urban and rural regions across the country while more than 37,000 alumni work across sectors to ensure that all children have access to an excellent education. Learn more about Teach for America.
Apply now for The Computer Science Education Fellowship or get in touch with Lyel on Twitter.
0 notes
Text
What Working in Baseball Taught Me about Web Development
Flatiron School Alum and Developer Adam Jonas left his job as a Major League Baseball Scout to pursue a career in software development. Although he thought he left baseball behind him, he found that successful ball players have a few things in common with successful developers—the ability to learn from mistakes, stay consistent, and be professional. In this post, Adam shares what baseball taught him about building software.
Before I was a web developer, I spent my time on baseball fields helping teenagers realize their ultimate dream of playing in the Major Leagues. All of them had talent. Somewhere, someone had seen glimpses of it. Cultivating that talent and turning their potential into performance was the primary purpose of my job. Now, four years removed from the game, most of the players I worked with are out of professional baseball. Those who did succeed found a way to endure the grind and adjusted to the game’s emotional and mental demands.
When I see one of them on TV, it’s hard to not recall their younger, yet unmolded versions. It is why I was never the best scout. The baseball scout’s job is to imagine the possibilities. They envision a future version of a gangly youth whose body and mind has matured and whose flaws have been smoothed away to the point they can perform in the Major Leagues. It is a hard job but one that I wish existed in other industries.
Learning from mistakes
Successful people, in any field, often struggle with making mistakes. This isn’t surprising. We are wired for bad news. We internalize it. We personalize it. Repeated failure is exhausting. Ball players, whose hitting success rate is at best around 30 percent, are forced to cope because failure is an inherent part of the game.
Resilient players’ confidences seem immune to repeated failure. In fact, failure appears to be inextricably linked to their progress. This makes sense. We improve fastest based on negative feedback. The great thing about that big, red, error message is that it leaves an obvious clue. Sometimes these hints are more obscure than others, but bugs and errors inform us where to look and where to improve.
Getting repeatedly beaten by the same pitch provides feedback on where hitters need to improve in the same way that a familiar error in our terminal window instructs us where in the code to start looking for our mistake. As humans we learn through repetition and experience. The goal is to avoid getting beaten again by the same pitch or the same problem.
When I first started learning to program, I focused on never repeating the same mistake twice. This, of course, was impossible, but I recorded most my thoughts and posted them online to create a searchable collection of problems I'd encountered. The frequency of my posts have waned, but I still find myself searching my blog archives when I know I’ve solved a similar problem in the past.
While it was rare to see ball players jot down notes on opponents, most hitting savants can recall previous pitch sequences from past at-bats. Either way, the secret to coping with past mistakes or errors in judgment is to reframe them as valuable pieces of feedback for the future.
Staying consistent
As developers, we know that consistent performance is important. We construct our dependencies on the most stable parts of our applications. The same goes for managers: when Sarah demonstrates that she can meet deadlines on a day-to-day, week-to-week, sprint-to-sprint or quarter-to-quarter basis, Sarah’s manager can rely on her to build the feature to satisfy the high priority business objective.
Consistency also creates the opportunity for measurement. Like the measurement of feature velocity based on a set period of time, comparison of player’s abilities would be worthless without a standard 162 game schedule where the participants play nine innings with nine players on the field. Without a level playing field, comparisons are no longer valid and people can get really upset (see baseball and steroids).
Consistency is difficult because we are wired to break free from it. We are not as perfectly repeatable as the scripts we write. Our brains thrive on novelty. The day-to-day becomes mundane without it. We seek out adventure and variety. We endeavor to learn new things.
But mostly being consistent is just showing up—being there when products ship and stuff goes down. Career defining highlights are created when people are in the right place at the right time. Crashes on the production server and DEFCON 1 bugs are inevitable but these panic moments create opportunities. Under pressure, acting as you always do makes you a hero.
Derek Jeter’s lifetime batting average was .310. A consummate professional, he hit .308 in the playoffs. Just being yourself when the pressure is on and more eyes are on you makes it seem like you are rising to the occasion. No one is perfect, but bringing your best everyday provides predictability to our human unpredictability and separates the amateurs from the pros.
Being professional
Professional baseball is a child’s game played by overgrown men who make millions of dollars. Make no mistake about it, baseball is a grueling sport. The schedule is relentless. Players arrive at the stadium five-plus hours before the first pitch to weight train, stretch, hit, throw, review scouting reports, etc.
After a three hour game, players are expected to hold court in front of their lockers and answer questions that essentially boil down to, “Tell us about your glaring mistake that you made in front of thousands of people across America.” Each major league team plays 162 games in about 180 days—not to mention the the month of spring training before the season starts and, if they are lucky, a month of postseason games. Eighty-one of these games are in other cities, meaning players are switching time zones for weeks on end. The truly blessed ones do this for 20+ years.
While we developers don’t enjoy the fame and fortune of Major Leaguers, we do get to solve the worlds’ hardest puzzles for everyone. The impact of our code has touched the lives of nearly every human on the planet. All of the hours spent implementing a vision—all of the bug-fixing and small victories—are bolstered by a natural builder’s high.
Hacker News is littered with discussion on how writing software can crush your soul, but for many, the job retains its joy. Despite the jeering fans and elusive bugs, there are developers who simply love what they do.
Despite the jeering fans and elusive bugs, there are developers who simply love what they do.
Of course, there are stark differences between baseball and software engineering. Software has been in the hands of laymen for less than a generation and baseball has remained unchanged since before the Civil War. While software’s impact continues to accelerate, we should take a breather and remember that what is old becomes new again. There are lessons to learn everywhere we look and baseball has proven no different for me.
I love what I do. I’ve never been as challenged as I am when muddling through a new concept or totally lost in a self-created code mess. The wins and losses I’ve experienced as a developer are like nothing else I’ve experienced as an athlete or a coach. While I’m still a relatively new programmer, my experiences in baseball have taught me some valuable lessons on coping with failures, reliability, and professionalism.
Not all that long ago my work day consisted of spotting the subtle deficiencies in a pitcher’s delivery and the sound of a shortstop’s feet as he ran a 60 yard dash, but when I watch how a junior dev deftly uses her VIM shortcuts or the ease with which she writes a complex SQL query, I’m reminded it’s not so different after all.
Keep in touch with Adam on Twitter or read more posts by Flatiron Staff.
hbspt.cta.load(69751, '0d93876e-9890-43af-b462-b96a2133da90');
0 notes
Text
Code History Lesson: Anita Borg
Anita Borg dedicated her career to making the tech industry a better place. Although she was a respected computer scientist, she is given the most credit for her tireless advocacy for and mentorship of women in computing. In honor of her 66th birthday tomorrow, here are three reasons to celebrate her memory.
1. She taught herself how to program
2. She created communities of women in computing
In 2015, Borg is best remembered for her work supporting, celebrating, and advocating for women who wanted to impact technology. This work gained momentum when she founded the online community Systers in 1987—years before online communities (let alone global communities of women in computer science) were a thing.
In 1994, while attending a conference with a notable lack of female representation, Borg had dinner with Telle Whitney and started the Grace Hopper Celebration of Women in Computing. Now the world’s largest gathering of its kind, this conference started with 500 attendees and was dedicated to bringing women’s achievements and research in computer science to the forefront.
She also founded the Institute for Women and Technology. According to Borg, the Institute was started to ensure women (regardless of whether or not they worked in tech) had opportunities to shape the technologies of the future.
"There are many ways that women can impact technology without being IN technology. We need both kinds of women… At IWT, we think that women must be involved in every aspect of defining the future of technology, from policy to research to design and implementation. We must be there in order to assure that the technology of the future serves us well."
3. She helped show Barbie that math is for everyone, not just boys
In general, Systers provided a place for technical women to discuss highly technical topics. But on occasion, non-technical discussion was sanctioned. One of these occasions happened in 1992 when a talking Barbie complained about math class.
Mattel’s Teen Talk Barbie was programmed to say 270 phrases including “Math class is tough.” If this doesn’t sound familiar to you, allow us to direct your attention to the recent Barbie: I Can Be a Computer Engineer controversy.
Because girls were playing with Barbies at an age when confidence in their math abilities needed to be bolstered, not undercut, protest stirred among the Systers list. Ultimately, they played a role in getting Mattel to remove the phrase.
The beauty of Borg’s advocacy lied in the belief that rallying women’s voices would add a distinct, yet critical perspective to technology. This diversity of thought would not only make the industry richer in the short run, but would help future technologies make a positive impact. In a time when technology touches people’s social, political, economic, and personal lives, it should serve everyone, regardless of their gender, age, or level of tech savviness. Advocating for women was her part in helping all people secure the power to shape their own futures.
Happy Birthday, Anita Borg! Thank you for making our community even better.
Read more Code History Lessons. Anita Borg art by Flatiron School Instructor Mitch Boyer.
8 notes
·
View notes
Text
From Deloitte to Google: a Flatiron Alum’s Path to Rediscovering What He Loves About Tech
Before enrolling in Flatiron School, Basar Akyelli was an Electronic Discovery manager at Deloitte. Concerned that his skills were slowly becoming outdated and driven by an enthusiasm for Apple products, he enrolled in Flatiron School’s iOS Development Immersive. Now a Product Manager at Google, Basar spoke with us to share what spurred his career change, and how he rediscovered what he loves about tech.
Tell us a little about your background—what were you doing before applying to Flatiron School?
hbspt.cta.load(69751, '0ca01cd0-9b36-4443-a600-f1ea0437c84c');
It sounds like you already had a great, technical career. What drove you to learn iOS?
When I applied to Flatiron School, I was coding around 30 percent of the time. As a software engineer, the more managerial my role became, the less technical I needed to be. I watched my technical skills become out of date—this was the scariest part. I don’t think I would have been qualified to work as an engineer in a tech company because I wasn't really programming for a couple years at that time.
Also, Apple is everywhere, and I love their products. Why not update my skill set with iOS and learn to build apps? At the time, I thought this was going to be my future. So I applied to Flatiron School, got in, and took a sabbatical from work to attend.
What are you up to now?
I’m now a Product Manager at Google. I could have worked as a full-time iOS developer after graduating from Flatiron School, but I had gained a strong background in business and client services that I didn’t want to give up. I thought I had some valuable skills to offer from seven years of experience.
Searching for a mixture of tech and business introduced me to product management. That's how I ended up at Google. I still write code, but not full-time. I get to read a lot of code and work with a lot of fantastic engineers. I'm still new, but it feels like a good solution for me—in tech but also working with a lot of people. And even though I’m not working with iOS directly, I don’t plan to lose it as a skill—my classmates and I worked really hard for three months to gain it. Even if just on the side, I'll continue learning.
What does it mean to be a Product a Manager at Google?
Product Managers are responsible for gathering requirements from a product’s users and translating those requirements into technical requirements for engineers. At the end of the day, Product Managers kind of own the product’s lifecycle, whether they are working with an app, a web site feature, or piece of software. They are the point people between the business team, engineers, and users.
It sounds like an inherently technical position. How does your programming background affect how you interact with the engineering team?
I think it helps immensely. After all, we're not developing chairs—we're developing software. I don't know every language in which Google engineers code, but having the software background, whether from a college or from Flatiron—I don't think it's that different—really helps me speak with engineers in a language they like and appreciate. Now I can dive deep into technical details, which is something all product managers should be able to do.
I also know what's possible—what makes sense to implement and what doesn't. Without technical skills, I could come up with these ridiculous requirements that would take ten times the budget and the resources we originally allotted. Instead, I can predict the resources for a certain feature.
“Flatiron showed me that technology is about innovation and passion and I'll be forever thankful for that”
What was your experience, coming from a technical background, and attending Flatiron School?
It was great. I came for a skill, but I left with a mindset change. Flatiron School taught me a different way to look at technology that wasn’t about business. Even though I was an engineer, I was very business-oriented. Flatiron showed me that technology is about innovation and passion, and I'll be forever thankful for that.
It was like I caught a virus. I wanted to work days and nights relentlessly to make something that reached people and had an effect on their lives. I felt this way a long time ago, right after college, but I had lost it. Then I came to Flatiron School, and I saw people who had caught this passion, too—my classmates, instructors, and the rest of the community here.
I was also able to network with a lot of amazing, talented people through Flatiron School who made me realize that I wanted to work in tech. It helped me look at this industry in a completely new way. I thought, "These are the people I want to work with." Suddenly, I had ideas for apps and businesses I was inspired to pursue.
This was the state of mind in which I left Flatiron School—and attending was one of the best decisions I’ve ever made.
Keep in touch with Basar on Twitter or hear from even more Flatiron Alums.
1 note
·
View note