Women Who Broke the Code: Ada Lovelace

For the next few months, we’re going to be celebrating women in programming past and present. And you can’t talk about the history of women in programming without honoring the woman who essentially started it all: Ada Lovelace. 

"Ada Lovelace," by Angela Thomas is licensed under CC BY 2.0.

"Ada Lovelace," by Angela Thomas is licensed under CC BY 2.0.

Born in 1815, Ada had a famously passionate poet for a father (Lord Byron), and a mother who threw off the conventions of the day and insisted that Ada be schooled in mathematics and science. The marriage between Ada’s parents was not a happy one (her mother left her father five weeks after Ada’s birth), but their dual influence is perhaps at the heart of Ada’s programming origin story. Despite her mother’s best efforts to shield her from her father’s influence, she still inherited his romantic spirit, which when fused with her passion and aptitude for mathematics, formed what she would come to call her love for “poetical science."

Ada’s ability to combine the two seemingly dissimilar subject matters of poetry and science eventually primed her to see the beauty and the vast potential in Charles Babbage’s calculating machine, the Difference Engine. When she attended one of his legendary salons at the age of seventeen she was captivated by its possibilities, and she set her mind to convincing Babbage to become her mentor. When he consented she not only became a champion for his work, but an amplifier, pushing the potential for his Analytical Engine beyond what he had visualized himself.

In 1843, Ada supplemented Babbage’s Analytical Engine with her own notes that essentially envisioned the modern computer, a machine capable of being programmed and reprogrammed to execute a virtually unlimited number of operations. She also noted that the machine could be used for far more than just mathematical calculations; any form of content such as pictures, symbols or sounds, could be expressed and manipulated digitally. In addition, her notes offered a step-by-step outline for what we would now call a computer program or algorithm.

Ada died in 1852 at the age of 36. Over 150 years later, The U.S. Department of Defense developed a language named after her. Ada's prescient thoughts on computing have had a profound impact on technology, infusing our digital age with “poetical science." 

Flipping the Equation: From Software Support to Software Development


Self-proclaimed recovering Twitter junkie, and newly-minted Ruby/JavaScript/Rails student, Jesse James was eager to learn how to program before he came to Epicodus. After working on the support side of software at Marketo as the Team Lead for the Portland office’s Premier Support Team, Jesse knew it was time to flip the equation. “I have always been eager to not only utilize my analytical skills but also my creative skills in tackling new problems and creating new software. I’ve dabbled in HTML, CSS, and JavaScript over the last few years, but nothing I’d consider beyond a beginner level, which had always bugged me,” he said.

Making Adjustments

Now a full-time student, Jesse is tackling coding head on and adjusting to pair programming. “I’d have to say, the most surprising thing about code school so far has been interacting with other students from varying backgrounds. At my last position we selected for a certain personality and skill set for our employees, so while there was some variance in personality, everyone was more or less on the same page when it came to work style. Having to be able to adapt, sometimes on a daily basis, to changing personalities and work styles has been very eye opening and rewarding on a personal and professional level. I look forward to taking these new interactions and applying them in the workplace alongside my previous experience in dealing with people."

Advice for Future Students

Jesse’s best piece of advice for someone considering going to code school? “Be open to new experiences/personalities as well as be willing to throw away things or habits you may have learned and start with a clean slate. In my own experiences thus far, and those of my fellow students whom I’m spoken with, the singular constant source of problems or difficulty has always been preconceived notions of how things ‘should’ work or how people ‘should’ act. Being open to different ways of doing things and letting someone else ‘take the reins’ are paramount to making the most of the experience."

You can find Jesse on Twitter, LinkedIn and GitHub.

Announcing Break the Code: Supporting Women in Tech

Supporting women has always been a top priority for Epicodus. Our student body has always been about one-third women, but we want to do better. And we know that many other companies do too. That's why we are incredibly excited to announce the launch of Break the Code, a collaborative initiative aimed at starting a productive dialogue and creating a more supportive environment for women choosing careers in programming.

Break the Code Partners

We've asked several companies and nonprofit organizations to help us spark that conversation and join Break the Code. Many have pledged their support and voices including: The Clymb, Columbia Ultimate, CrowdCompass, DevelopmentNow, GlobeSherpa, Jive, Simple, Smarsh, Thetus, Uncorked Studios, App Camp For Girls, ChickTech and Girl Develop It. Over the next few months we will all be celebrating and sharing the experiences of women in tech. This is a huge challenge, and we are excited that so many companies in the Portland area have signed on to help us tackle it.

All-Women's Class

Since one of the primary goals of Break the Code is to provide a supportive environment for female programmers, on August 10 we'll be starting our first ever all-women's class on Android development. We're excited to provide this opportunity for 30 students who feel that they will thrive in an all-women environment. All women (cis- and transgender) and people with non-binary gender who feel they are a part of women's community are encouraged to apply.

In the coming weeks, we will be announcing even more exciting Break the Code initiatives. Stay tuned...

Why You Should Learn Drupal

When I’ve told people that Epicodus is adding a new course on PHP and Drupal, I’m often met with surprise:

  • “Isn’t PHP a bad language?”
  • “I thought Rails was better than Drupal.”
  • “Aren’t you moving backwards, going from Ruby to PHP?”

I’ve previously held these misconceptions myself, so I wanted to share why I’m so excited for Epicodus to start teaching Drupal alongside our existing Ruby/JS/Rails class.

I often think of web development as falling primarily into two categories: building sites that are primarily about content, and building apps that are primarily about interaction. Content websites include sites for restaurants, movies, schools, or anything else where the primary purpose is to provide information. Interactive apps include airline booking sites, social media, photo sharing, and anything else where the primary purpose involves user-provided information. 

Much of my development experience is in Ruby on Rails. There are a common set of problems that interactive apps need to solve - such as separating business logic from presentation, saving information to a database, logging, and security - and Rails (and other server-side MVC frameworks) is a framework that provides solutions so that you can focus on building the things that are unique to your site. And for common problems that aren’t common enough to justify being in Rails itself, there’s a huge ecosystem of Ruby gems so that you don’t have to re-invent the wheel.

Content-based websites have their own common set of problems - such as separating content from structure, authoring static pages, and providing a way for non-technical administrators to edit content - and MVC frameworks like Rails doesn’t provide many tools or guidance. But content management systems (CMSs) do, and Drupal is one of the most popular and powerful CMSs. Drupal is like Rails for content websites - it provides a framework that solves these common problems so that you can focus on building the things that are unique to your site. And just like part of Rails’s popularity comes from the gem ecosystem, much of Drupal’s popularity comes from the enormous number of modules that let developers easily extend Drupal. (There are CMSs built on top of Rails, but they lack the robustness, the availability of modules, and the community support that Drupal has.)

As for PHP being a “bad” language, nobody will argue that PHP is a work of beauty. Any language can be misused in the wrong hands, though, and PHP has seen an awful lot of misuse. Its dominance as the most popular web server language shows that its “suckiness” doesn’t matter, and in recent years, the situation has improved dramatically. On this note, I’m especially excited for Drupal 8, which will be coming out in the next few months. D8 is a big rewrite of Drupal and embraces object-orientation, REST, and modularity - it’s based on re-usable components from the Symfony web framework that are also used in the popular MVC framework Laravel and the popular forum software phpBB. As a result, it will be much easier for PHP developers to transition into D8 projects, and for Drupal developers to transition into other PHP-based stacks.

So if you’re interested in learning the language that powers 82% of the internet, and the framework that powers sites like WhiteHouse.gov and Sony.com, don’t let the rumors scare you away! For content-based websites, PHP and Drupal are often the right tool for the job.

Eat Your Spinach

By Diane Douglas, Epicodus Instructor

As you learn how to code, you’ll spend your time grappling with the languages, libraries, and frameworks that make up a programmer’s tool belt. But far more important than any particular tool is learning how to be a problem solver. You need to learn how to teach yourself what you need to know. Companies don’t just want experience with a particular tool: they want to hire people who learn quickly and don’t shy away from figuring out a problem.

Learning how to learn is much more rewarding than learning any particular tool. You’ll get a feeling of “I can do anything!” and an amazing sense of self-confidence. It’s also much harder than learning any particular tool. You have to do your part, and you have to hold yourself accountable. If you get a gym membership, but you only sit in the hot tub, don’t be surprised if you don’t lose weight.

As somebody who learned how to program relatively recently, I want to share with you some of the lessons I learned along the way, and make some suggestions for you. I’d suggest follow these guidelines even if they seem tedious at times, because that is how you are going to get the most out of your learning. If you decide early on that you are going to try your best and not be lazy, then you will master this material and you’ll be impressed by how much you can do.

1. Keep calm

As you learn to code, you will occasionally (or sometimes more than occasionally) face difficult, time-consuming problems. More than any specific techniques for avoiding these situations, here are some tips for how to handle them on your own.

  • Quietly understand that you WILL get it eventually. I promise. If there is a solution to the problem, then there’s no reason you can’t find it. It takes patience and a clear head, though. If you get angry, you might miss a solution that’s right under your nose.
  • Break down the problem into the simplest possible parts. Try to do them one at a time, such as in a console, so you can clearly understand what is and isn’t working.
  • If you don’t know what part of your code is causing the error, try deleting things until you narrow it down. You can always put your code back later. Don’t be afraid to tear your program apart to figure it out - it won’t be mad.
  • Experiment. If you can’t see the answer from staring at your code, try things to see how it reacts. For example, say that your program gives you an error whenever you type in a specific sentence. Instead of wondering what’s wrong with that sentence, try typing in one word and see if you get the same result. Then try one letter. Then try a number.

2. Don’t be afraid to dig

As you’re going through whatever books, videos, guides, or other lessons you’re using to learn, don’t tip-toe through the material. Know that you are strong, and you are doing this for you. If you encounter something that you don’t fully understand, or feel like you aren’t good at it, don’t try to avoid it. Practice it. Google it. Ask your teachers and friends about it. Read a book about it. Post on message boards about it. Work on it until it clicks. Otherwise it will continue to be “that thing I don’t like” and you will lack confidence. It feels great when you turn the things you instinctively avoid into strengths.

3. Keep a Mistake Journal

Mistakes are your friends, they are how you will learn. Even Alfred from Batman agrees.

Your Mistake Journal is going to be a set of files that you can refer back to later, one for every week of class. Every time you fix a mistake write it down. EVERY. TIME. The more the better. This is one of those places where it pays to not be lazy. Every time you figure out a mistake you made, write down what the problem was (including any error messages), what steps you took to fix it, and what eventually worked. This has a couple benefits:

  • You’ll stop making the same simple errors over and over. You might be tempted to say “Oh well, I just forgot a semicolon. It wasn’t an important error, I’m not going to bother writing it down.” But, by the third time you write down a note about semicolons, you’re brain is going to say “Hey, I keep doing this and I’m sick of writing it down. I am going to put in the effort to correct this pattern.” Then you will see less semicolon errors.
  • You’ll remember how to fix difficult, obscure bugs in the future. You will occasionally come up against difficult problems that aren’t fixed by semicolons. This is not said to worry you, it is part of life. These problems will seem inexplicable and the error messages will be mysterious and unhelpful, but you will fix them eventually. The temptation after you fix something really cryptic is to move on with your life and be grateful that it’s fixed. But then you will hate yourself when months or years later you come across the same error and have to do all that work over again. Wouldn’t it be great if you could just say to yourself, “Hey, I’ve seen this problem before! I’ll just look up what I did to fix it last time.” Now you’ve saved yourself more time for the fun parts of programming!

4. Practice typing

Learning to code is like learning a musical instrument. You could know all the music theory in the world, but if you never sit down and actually practice scales and songs, then you will never be as good as you want to be. So do these two things:

  • Type code examples without copying and pasting. When you’re working through a lesson, it can be tempting to copy and paste the example code. But if you actually type every word, then the information will sink in better and you will notice more patterns. Ideally, the only time you should copy and paste code is when you are at the point where you can honestly say “I’ve typed this a million times, I know exactly what it means and I don’t need to retype it.” You are the final judge on whether or not you’ve reached this point, but remember you are doing this for yourself! So hold yourself accountable - don’t just go sit in the hot tub. Try not to copy and paste when you say “hmmm, how did this line go again?”
  • Learn your keyboard shortcuts. This may seem trivial and tedious, but learning your way around your tools is important, so just do it. You never see a chef struggle to hold a knife. They have practiced chopping vegetables a lot so that they can do it fast and spend their time on other tasks. Instead of a knife, our tools as programmers are text editors or IDEs, browsers, and operating systems. Spend a few minutes a day learning keyboard shortcuts for each of these tools. Any time you find yourself using the mouse for the same task over and over, check the menus or search online for a keyboard shortcut. It will actually seem slower at first as you get used to them, but if you just try to get into the habit of using a new one every day or two, then before you know it you will look like a wizard when you type. Spending the time on this early on will pay off in a big way after only a couple weeks.

5. When you have to memorize something, get it over with

Programming does not involve very much memorization, but there are some things that if you memorize them will make your life a lot easier. I’d suggest keeping a regular old paper notebook with you as you code. When a concept suddenly snaps into focus, or when there is a list of exactly 5 things you need to remember every time you do a certain task, take a minute to write it down, with pen and paper, and it will stick in your brain.

So, the moral of the story is, eat your spinach. Take the time. Don’t give in to the temptation to cut corners, because you will only be selling your future self short. You are about to start the training montage that takes place at the beginning of every kung-fu movie. Without embracing your mistakes and trying your hardest, you won’t be able to be the champion.

Treehouse course on Ember.js

We’ve long been big fans of Treehouse - many of our students get their start with Treehouse’s online content before deciding they want to jump into a full-time program like ours. So we’re pretty excited to announce that Treehouse recently released on an Ember.js course with our president Michael as the guest teacher!

Here’s a short rundown on Ember if you aren’t familiar. As web applications gain increasingly rich and complex user interfaces, a new breed of tools called “client-side MVCs” have emerged to help developers be more productive and build these user interfaces more easily. Ember strives to be the best choice for these “ambitious” web applications by providing a framework that eliminates boilerplate, enforces good code organization, and provides tools for common practices.

If you’re interested in build an ambitious web app, check out the Treehouse course on Ember.js!

Epicodus Internship Report


After conversations with all of the employers who participated in Epicodus’s internship program, we’ve come up with some suggestions we hope anybody hosting interns will consider:

  • Integrate interns as closely as possible with permanent staff.

  • Before interns start, run through a clean installation of the software they will be working on. Fix any issues and document the process.

  • If interns will be working on an existing product with other developers, start flagging bugs and features appropriate for the interns two or three weeks before they start.

  • Informally check with interns as often as once an hour.

  • Have interns sit side by side so that they can easily help each other out.

  • Designate one or two staff developers who interns can first turn to when they are stuck.

  • Hold weekly one-on-one, process-oriented, non-technical checkins with each intern.

  • Organize a weekly social event, such as lunch, to bring interns, their supervisor(s), and other staff together.

Setting up an internship program takes work, but the participating employers were universally happy with the outcome, whether it was getting work done on an open source project they had never gotten around to, hiring an intern into an employee at the end, or just the joy of working with excited new developers. We hope our findings and suggestions from this report will make it easier for any company to start a successful, rewarding internship program.

Click the link to head to the full report:


Michael Kaiser-Nyman, President
Maureen Dugan, Outreach Coordinator

For more information: maureen@epicodus.com


from: An Epicodus graduate <epicodus_grad@gmail.com>
to: Michael Kaiser-Nyman <michael@epicodus.com>
date: Mon, May 26, 2014 at 9:46 AM
subject: Feedback

Hi Michael,

I notice that you are constantly asking for feedback and you honestly try to work with them. How do you process feedback that you disagree with? I think it is important for me to be aware of what others are thinking and feeling.  I also need to work with where people are at.


from: Michael Kaiser-Nyman <michael@epicodus.com>
to: An Epicodus graduate <epicodus_grad@gmail.com>
date: Tue, May 27, 2014 at 9:43 AM
subject: Re: Feedback

Yeah, it’s tough. Sometimes I get feedback that I disagree with. Then I ask myself, why did this person give me this feedback? If they asked me to change something, and I don’t think it’s something I should change, is there something else I can change to get them the results they want? For example, in my very first class, many students told me they wanted me to do live coding in class. I did it a couple times, but I didn’t think it was a good use of class time, and I thought they should be spending the time coding. But it did make me realize that students wanted to see more of my coding, so I thought about other ways I could give them that experience. That’s why I started making videos. Nobody ever asked me to make videos, but the feedback about wanting live coding made me realize videos would be a good idea.

Other times, I choose to disregard the feedback. For example, when I started assigning more Railscasts toward the end of this class instead of making videos myself, some students said that they liked my videos better. But I believe that at some point, we have to let students start using the lower-quality material available more generally, since they won’t have my videos forever. Even then, though, I decided that this feedback meant I needed to set better expectations, and let students know that the videos would get harder to follow when I stopped making them, so that they would know what to expect.

So, it’s sometimes not about taking somebody’s feedback literally - often, you have to search for the meaning in their feedback, and find ways for you to address their concerns on terms that work for you.

I hope that helps.