Elaina Polson

Musings of a Beginner Programmer

Who's Down With TDD?

Kent Beck is down with TDD.

Naughty by Nature feat. Kent Beck

My first introduction to test-driven development was not exactly a pleasant one. It was my first week at the Flatiron School and knowing little more than how to iterate through one-dimensional arrays and puts “Hello World” to the screen, I found myself attempting to write code to pass seemingly abstract tests written by the Flatiron labs team. Little did I know that test-driven development is a prominent and hotly debated (because what in the programming world isn’t?) software development process used in some capacity by thousands of programmers across the world.

As my time at Flatiron winds down, and I begin my job search, I am reminded of something a guest speaker once told us. He said he would never work at a company that didn’t write tests for their applications. At the time, I didn’t feel strongly one way or another about tests, but now I know what he means. Neglecting to write tests leaves your code vulnerable. It’s risky – like skydiving without life insurance.

So, what exactly is test-driven development? Simply put, it is a programming paradigm that requires developers to specify an application’s features and design before writing any functional code. Any proponent of TDD lives by the “red, green, refactor” mantra, which follows this process:

The TDD Process

  1. Before writing any feature into your application, write some code to test that feature.
  2. Run that test, and see that it fails.
  3. Write the necessary code to make that test pass. It doesn’t have to be beautiful code; in fact, you should write the least amount of code necessary to make the test pass.
  4. Run the test again, and see that it passes.
  5. Refactor your code. Go slowly when refactoring, and keep testing along the way to make sure you aren’t breaking any functions of your application.

Sounds pretty simple, right? The idea is that neglecting to practice feature-first development can leave your code open to vulnerabilities you may not have foreseen. Here are a few other reasons why many programmers swear by test-first development:

Benefits of TDD

  • It forces a team of developers to thoroughly think through the purpose and requirements of an application before diving into building it
  • It ensures each feature of your application is working as expected
  • It acts as an effective means of communication between project managers and members of a team. A new developer who comes onto a project at a later stage will be able to understand tests (assuming they’re well-written) much better than she will be able to understand hastily-written, comments explaining what several lines of code should be doing. Ideally, your tests should be a clear and concise way of communicating across your application.
  • It allows you to take small steps when writing large applications. When you write several lines of code and find that your tests are failing, it is relatively easy to find your errors and debug them, as opposed to searching through hundreds of lines of untested code.

It sounds great right? Why wouldn’t every developer want to write test-first software? It may surprise you that not all programmers feel this way. Now that I’ve covered the benefits of test-driven development, let’s look at some of the limitations.

Limitations of TDD

  • Writing code is time consuming, especially when you’re continuously adding new features and aren’t entirely sure how they will fit within your application or whether they will remain in the code base at all
  • Having many tests can make it more difficult to make any changes to the functionality or design of your application. Even simple changes can become too difficult or time consuming.
  • If your team members aren’t skilled at writing tests, you can end up with a lot of unclear code that doesn’t effectively communicate the features of your application. Furthermore, your tests might be testing the wrong thing or testing something the wrong way. Either way, poorly written tests are expensive to maintain.
  • If other members of your team aren’t committed to writing tests, the application can fall apart.

At this point you’re probably wondering: what are the alternatives to feature-first development?

One alternative supported by DHH, the creator of the Rails framework, is system testing. Whereas unit testing involves testing small pieces of code, like class methods, system testing (as you may have guessed) tests how the entire application works together.

“The current fanatical TDD experience leads to a primary focus on the unit tests, because those are the tests capable of driving the code design (the original justification for test-first). I don’t think that’s healthy. Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that’s ‘slow’. Like hitting the database. Or file IO. Or going through the browser to test the whole system. It’s given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse.” DHH

So really, the question is not “to test or not to test”; most programmers can agree that testing is a fundamental aspect of software design and development. But how to implement those tests – that is where opinions diverge. While not all programmers worship traditional TDD and test-first development, most will agree that some kind of testing framework is necessary to prevent exposing your application to vulnerabilities. What kind of framework you decide to implement is ultimately up to you and your team. To me, the most valuable aspect of writing tests is ensuring that you and your team members are on the same page every step of the way while building an application. For maximum effectiveness, all members of a team should agree what kind of testing framework to use and how to implement it.

Sources: http://agiledata.org/essays/tdd.html#PartingThoughts http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

Exploring jQuery Alternatives

It’s hard to believe I wrote my first line of JavaScript code less than two weeks ago. Now, just days after learning the fundamentals of the language, we’ve jumped right into learning how to use JavaScript to interact with the DOM and alter the content displayed on web pages.

If you wanted to, you could traverse and manipulate the DOM with plain old vanilla JavaScript, but doing so can cause some issues with browser inconsistencies. Some older browsers may respond differently to certain vanilla JavaScript code. For this reason, most developers choose to use a library that extends the functionality of JavaScript, makes it easier to interact with the DOM, and offers cross-browser compatability.

In class, we’ve been using the library that most developers use for this purpose, and the most popular and widely used JavaScript library in the world: jQuery. jQuery is a cross-platform (meaning it works on all browsers) JavaScript library that simplifies the act of navigating a document, selecting DOM elements, creating animations, handling events, and developing AJAX applications.

“jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and AJAX interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.”

(jQuery documentation)

Some of my favorite days at Flatiron so far have been spent working on the jQuery and AJAX labs. I’ve found it thrilling to select and manipulate DOM elements so simply and conveniently. It got me wondering what other JavaScript libraries exist, and what kind of functionality they provide.

After some Googling, I discovered that there are many alternatives to jQuery and there is some debate in the developing world over which library is optimal. Here are a few alternatives to jQuery I found particularly interesting, with a specific focus on one of jQuery’s biggest rivals, MooTools.

MooTools

“MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API.” (MooTools documentation)

I quickly discovered that the largest dispute involving JavaScript libraries is the jQuery vs. MooTools debate. So what exactly are the differences between these two libraries, and how do you choose which one to use? I’ll explain.

MooTools, or My Object-Oriented Tools, is a popular object-oriented JavaScript framework. With MooTools, you can accomplish all of the things you can accomplish with jQuery, but with a different syntax and approach. Just like jQuery, MooTools allows developers to interact with the DOM, animate elements, and build powerful Ajax applications. But the most interesting difference between the two libraries is their inheritance models.

MooTools extends the functionality of JavaScript to allow for an object-oriented approach to traversing and manipulating the DOM, whereas jQuery doesn’t really deal with inheritance at all.

So what does all of that mean? First, let’s quickly review how objects are created and used in JavaScript. Pure object-oriented languages are class-based, meaning that objects are instances of classes. In JavaScript, objects inherit directly from other objects. So, when you try to access a property of an object that inherits from another object, JavaScript will look for the property on the child object, and if it doesn’t find it there, it will look on the parent object. This makes JavaScript a prototype-based language.

MooTools aims to make JavaScript more closely resemble a class-based language by supplying developers with a Class constructor. Proponents of the library say that this makes the prototypal inheritance model of JavaScript easier to use, and most importantly, makes it easy to define patterns and reuse code later in your application.

Let’s take a closer look at how this works. To make a class in MooTools, you pass an object to the Class constructor. That object then becomes the prototype for every instance of the class. Here’s how we would create a new Animal class that initializes each animal with an age.

1
2
3
4
5
var Animal = new Class({
    initialize: function(age){
        this.age = age;
    }
});

So now we have an Animal class. But what if we want to create a new version of an animal that has additional properties? We can use the “Extends” functionality of MooTools to create a subclass that has access to all of the properties and functionality of the parent object, Animal, but won’t affect the base class at all.

1
2
3
4
5
6
7
8
var Cat = new Class({
    Extends: Animal,
    initialize: function(name, age){
        // calls initialize method of Animal class
        this.parent(age);
        this.name = name;
    }
});

Now we can create a new instance of a cat that will have the properties name (from the base class, Animal) and age (from the subclass, Cat).

1
2
3
var myCat = new Cat('Micia', 20);
alert(myCat.name); // alerts 'Micia'.
alert(myCat.age); // alerts 20.

As you can see, this code reads more like a pure object-oriented programming language.

This approach makes reusing code easy in MooTools. Anytime you want to define a pattern, you can use these Class constructors. jQuery on the other hand, does not give you a system for extending instances into subclasses.

So now that we understand the primary difference between the two libraries, how can we conclude which one to use?

If your goal is solely to interact with the DOM quickly and easily, jQuery is likely all you need. It’s simple to use and very effective, which explains why thousands of programmers swear by it and it is present on millions of webpages. The large and active community means it’s easy to find great support and documentation.

But if you love object-oriented programming, and think that JavaScript’s prototypal inheritance model is frustrating and cumbersome, MooTools might be for you. MooTools utility goes beyond just manipulating the DOM; rather, the library aims to extend the functionality of JavaScript and make it more closely resemble a pure object-oriented programming language. As Aaron Newton (a MooTools contributor and author of a great blog post on the subject) poignantly says:

“Rather than focusing exclusively on the DOM, MooTools takes into its scope the entire language…If jQuery makes the DOM your playground, MooTools aims to make JavaScript your playground.”

When it comes down to it, MooTools and jQuery can be used in different ways to achieve entirely different things. You should decide which library to use based on what tasks you are trying to accomplish – and if you like some aspects of both, there’s no reason why you cannot use both libraries. After all, you’re a developer – you have endless tools at your disposable to utilize how you please.

Other Alternatives

The following libraries are similar to MooTools in that they aim to extend the functionality of the JavaScript language beyond basic interaction with the DOM.

Dojo Toolkit

“Dojo saves you time, delivers powerful performance, and scales with your development process. It’s the toolkit experienced developers turn to for building superior desktop and mobile web experiences.” (Dojo documentation)

Dojo is a much larger library than jQuery. Like MooTools, it offers solutions for object-oriented programming. It also provides a large collection of user-interface widgets. It is often criticized for its incomplete and unorganized documentation.

Prototype

“Prototype takes the complexity out of client-side web programming. Built to solve real-world problems, it adds useful extensions to the browser scripting environment and provides elegant APIs around the clumsy interfaces of Ajax and the Document Object Model.” (Prototype documentation)

Prototype is similar to Dojo and MooTools in that it also supports a class-based inheritance model. One of the largest complaints about Prototype is in regards to namespace pollution. According to JScripters.com, “Prototype adds several top-level names to the JavaScript global namespace, and adds numerous new methods to built-in JavaScript classes. There is a potential for namespace collision, either with other JavaScript libraries or with new JavaScript features.”

Another interesting note is that early versions of Rails shipped with Prototype as the default JavaScript library. Since Rails version 3.1, jQuery has been the default JavaScript library.

Ext JS

“The most comprehensive JavaScript framework for building feature-rich cross-platform web applications targeting desktop, tablets, and smartphones. Ext JS leverages HTML5 features on modern browsers while maintaining compatibility and functionality for legacy browsers.” (Ext JS documentation)

Like the aforementioned libraries, Ext JS provides a class-based system. Ext JS is similar to Dojo in that it provides a comprehensive collection of customizable UI widgets, as well as charting and grid packages that allow you to visually represent data in a number of ways. Ext JS is commercially licensed, meaning it comes at a price.

Sources:

Definitely read Aaron Newton’s post jQuery vs MooTools for a much more detailed analysis of the two libraries: http://www.jqueryvsmootools.com

JScripter.com on Popular jQuery Alternatives: http://www.jscripters.com/popular-jquery-alternatives/

Nested Attributes, Strong Parameters, and Escaping the Threat of Code Injection

If you’re building applications in which you allow users to input data, you’ll undoubtedly have to deal with parameters at some point. Parameters are a way to access data sent in by the user, either as part of the URL or through an HTML form.

For example if you had an application that allowed users to create a new user profile, your HTML form might look like this:

1
2
3
4
5
6
7
<%= form_for(@user) do |f| %>
    <%= f.label :name %>
    <%= f.text_field :name %>
    <%= f.label :email %>
    <%= f.text_field :email %>
    <%= f.submit Create New User %>
<% end %>

The code above represents a form building object, created by the form_for method. It binds a form to a model object – in this case, to a user. The name and email address attributes passed to form_for by the user set the keys used in params to access the form’s values. Since the model object we’re creating is a user, params[:user] will be a hash with the keys :name and :email.

In order to save these attributes to a new user object upon form submission, you might have some code in your controller that looks like this:

1
2
3
def create
  @user = User.new(params[:user])
end

The lines of code above utilize something called mass assignment. It takes all of the values submitted by the user in the HTML form and assigns them as attributes to a user object, all at once. It’s much more efficient than writing this:

1
2
3
4
5
6
def create
  @user = User.new
  @user.name = params[:user][:name]
  @user.email = params[:user][:email]
  @user.save
end

But while mass assignment may seem optimal, there are risks associated with it – namely, something called code injection.

When you mass assign variables without actually specifying what is or isn’t allowed into your database, you are making room for a clever hacker to “inject” some kind of invalid input. The most innocent of hackers might want to simply add a new column name to a table, which would be easy enough to do when you’re allowing anything through your params. But the most malevolent of hackers could wreak havoc. In the worst cases, code injection can lead to data loss or corruption or unauthorized access to a system. We always want to protect our applications from this.

To escape the threat of code injection, we must use something called strong parameters in our applications. This involves “whitelisting” our parameters in a private method in the action controller so that only certain attributes are allowed to be passed through to the params hash. This allows you to specify exactly which attributes you want to permit for mass assigning.

The code below allows a user to input only two specified variables as keys in the params hash. Anything else will be filtered out.

1
2
3
4
private
def user_params
   params.require(:user).permit(:name, :email)
end

The require method identifies the required parameter, which is our user object. The permit method identifies the list of allowed parameter keys.

Then, in your controller, you could mass assign the whitelisted params, like so:

1
2
3
def create
   @user = User.new(user_params)
end

Great! Now we have effectively sanitized our user input. But wait – what if a user has multiple email addresses? How do we allow for nested attributes in our whitelisted params? It’s easier than it sounds! We just need to lay some basic groundwork.

First, let’s go to our model and add the accepts_nested_attributes_for method for emails. This creates an emails_attributes= method on our User model, and sets us up nicely for creating a nested form.

1
2
3
4
5
6
7
8
class User < ActiveRecord::Base
  has_many :emails
  accepts_nested_attributes_for :emails
end

class Email < ActiveRecord::Base
  belongs_to :user
end

Now, let’s edit the form on the create new user page. Fields_for is a method that will help us add nested attributes to our params hash.

1
2
3
4
5
6
<%= f.fields_for :emails do |emails_form| %>
        <%= emails_form.label :type %>
        <%= emails_form.text_field :type %>
        <%= emails_form.label :address %>
        <%= emails_form.text_field :address %>
<% end %>

But there’s something just a little annoying about fields_for. It renders its block once for every element of the association – in this case, for every email address of a user. But if a user has no email address (because she hasn’t added one yet), the block will render nothing. To get around this, we need to do a little housekeeping in our controller and build one or more empty “children” so that at least one block is shown to the user. The code below would result in 2 sets of email fields being rendered on the new user form.

1
2
3
4
def new
  @user = User.new
  2.times { @user.emails.build }
end

Now that our form is set up appropriately, a user can easily fill out a form with two email addresses! When they submit the form with the fields filled out appropriately, our parameters might look like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
  user => {
    'name' => 'Elaina Polson',
    emails_attributes => {
      '0' => {
        'type' => 'School',
        'address' => 'elaina@flatironschool.com'
      },
      '1' => {
        'type' => 'Personal',
        'address' => 'elaina@hotmail.com'
      }
    }
  }
}

As you can see, the emails_attributes key points to a hash, containing an id key, which points to another hash containing our attribute keys – which in this case, are type and address. So how do we allow for this nested data structure to pass through our params and update a new user accordingly? You guessed it – let’s head over to the controller and update our strong params! The following code will allow for our nested attributes to flow easily through our permitted params:

1
2
3
4
private
  def person_params
    params.require(:person).permit(:name, emails_attributes: [:id, :type, :address])
  end

And that’s all there is to it! Now we’ve sanitized our user input, allowed for nested attributes, and are ready to get to work building out the rest of our application.

Sources: Edge Guides Easy Active Record

Bringing It All Together With ActiveRecord

Do you ever feel like you don’t know where you’re going but you’re in a huge hurry to get there? That’s how I felt my first week in New York, attempting to navigate the subway system…and now it’s how I feel most days at Flatiron, navigating my way through the various Learn labs.

I think most of us can relate to this hurried impatience. In a rush to get all of the tests to pass in each lab (and ultimately get those glowing green lights to show up), we sometimes forget to stop and ponder the purpose behind what we’re actually doing.

Take the playlister labs, for example. First we built a playlister application using simple domain modeling; then we abstracted away some of our code using our new object orientation skillset; and finally we refactored our code further, using class modules. For the love of Ada Lovelace, why does Flatiron keep making us build the same application in different ways?

When I saw the playlister application again in the Object Relational Mappers section in Learn this week, my first instinct was to throw my computer against the wall. That simple little playlister application had already given me enough grief during my first three weeks at Flatiron. But this week was different. This time, I had a new tool under my programming toolbelt: ActiveRecord. Thanks to ActiveRecord, I finally understand the purpose behind all of those tortuous playlister labs. In each new playlister lab, we used a new skill we learned to abstract away some of the exising code and make our application more functional. ActiveRecord was another step of abstraction that brought it all together.

So what’s so great about ActiveRecord? I’m glad you asked.

ActiveRecord is an Object Relational Mapping system used in Rails. Object Relational Mapping (or ORM) is a technique that connects the objects of an application to tables in a relational database management system. By using ActiveRecord’s ORM system, the properties and relationships of the objects in our applications can be easily stored and retrieved from a database. And here’s the kicker: We barely have to write any configuration code. Say goodbye to SQL statements and countless lines of repetitive database access code; ActiveRecord writes it for us!

Got the gist? Now, let’s break it down with an example. Imagine we are transported back in time, before ActiveRecord exists. Say we have a database filled with different songs. We want each of those songs to behave as an object. That means we need to define a class Song, and define various behaviors (methods) for our Song class so we can access and interact with the individual songs in our database as objects.

Our database will give us our data (our songs, in this case) in a nested array, where each row in the array is a different song.

Right now, it looks like this:

1
[[1, "Shake it Off", "Taylor Swift", "pop"]]

But we want each of our songs to be an object that looks like this:

1
[#<Song:0x007fadec898090 id: 1, title: "Shake it Off", artist: "Taylor Swift", genre: "pop">]

Without ActiveRecord, we would have to do some Object Relational Mapping on our own. We would need to write a method in our Song class that takes in a row, and turns that row into a song object. That method might look a little something like this:

1
2
3
4
5
6
7
8
  def self.new_from_db(row)
    self.new.tap { |s|
      s.id = row[0]
      s.title = row[1]
      s.artist = row[2]
      s.genre = row[3]
    }
  end

And then if we wanted to find our song in a database by it’s title, we’d have to write a method like this:

1
2
3
4
5
6
7
8
9
  def self.find_by_title(title)
    sql = <<-SQL
      SELECT * FROM songs WHERE title = ?
    SQL

    DB[:conn].execute(sql, title).map do |row|
      self.new_from_db(row)
    end.first
  end

And what if we wanted to find a song by its artist, or by its genre, or its id number? More methods. And then what if we wanted to insert a new song from a given set of attributes and save it to our database? More methods. And THEN what if had an artists database and wanted to create an Artist class that behaves similarly to our Song class? This is starting to feel really repetitive. There must be an easier way to do this.

Enter, ActiveRecord. ActiveRecord is smart. It knows that our rows are objects. It maps one row in our database to one object in Ruby. And it assumes certain behaviors for those data objects – which saves us from writing the same lines of code over and over again.

Still not convinced ActiveRecord is amazing? Let’s look at some of the work ActiveRecord saves us from doing.

First, we need to set up ActiveRecord. The first step is to connect to our database:

1
2
3
4
ActiveRecord::Base.establish_connection(
  :adapter => "sqlite3",
  :database => "db/songs.sqlite"
)

And then, we create our songs table using ActiveRecords migrations (which I won’t get into now, but is another amazing feature of ActiveRecord):

1
2
3
4
5
6
7
8
9
class CreateStudents < ActiveRecord::Migration
  def change
    create_table :songs do |t|
      t.string :title
      t.string :artist
      t.string :genre
    end
  end
end

And finally, we want to extend our Song class with ActiveRecord’s model class.

1
2
class Song < ActiveRecord::Base
end

And now that our setup is finished, we can use all of ActiveRecord’s amazing, built-in methods!

So, if we wanted to insert a new song to our database, instead of writing our own insert method using SQL in Ruby, like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
  def insert
    sql = <<-SQL
      INSERT INTO songs (title, artist, genre) VALUES (?, ?, ?)
    SQL

    DB[:conn].execute(sql, title, artist, genre)
    @id = DB[:conn].execute("SELECT last_insert_rowid() FROM students")[0][0]
  end

  shake_it_off = Song.new
  shake_it_off.title = "Shake it Off"
  shake_it_off.artist = "Taylor Swift"
  shake_it_off.genre = "pop"

  shake_it_off.insert

We can just write:

1
  shake_it_off = Song.create(title: Shake it off, artist: Taylor Swift, genre: pop)

ActiveRecord gives us the create method, which initializes a new instance of our class, assigns it the attributes we give it, and saves it to our database, all in one line!

And our Song class still looks like this:

1
2
class Song < ActiveRecord::Base
end

What gives? Where are our methods? That’s the beauty of ActiveRecord.

Without ActiveRecord, you’re required to write A LOT of configuration code every time you want to treat your data as objects in an application. But ActiveRecord makes assumptions about our data, and gives us almost all of that configuration for free. A quote from the Rails guide sums it up nicely:

“The idea is that if you configure your applications in the very same way most of the time then this should be the default way. Thus, explicit configuration would be needed only in those cases where you can't follow the standard convention.”

Basically, ActiveRecord sees our Song class, and assumes it must map to a database table called songs. Then it looks in the songs table and realizes each column in that table is an attribute so it adds methods for both getting and setting that attribute. There’s no such thing as a free lunch. But free methods? ActiveRecord has got you covered. As long as you set up your models and tables correctly, ActiveRecord does the rest.

 

When we learned ActiveRecord this week, my first reaction was to wonder why on earth Flatiron made us map our database rows to objects ourselves and then make us write out all those annoying getting and setting and finding methods by hand using SQL statements. If they had just taught us ActiveRecord first, that would’ve made our lives WAY easier. But now I realize that if we hadn’t done it the hard way in the beginning, I wouldn’t appreciate or understand the amazingness of ActiveRecord. Everything we’ve done in each playlister lab is still there in the final product - SQL, object orientation, ORM, etc. We’re still using these things, but at a higher level. It may not seem like it on the surface, but they’re there. ActiveRecord has just abstracted them away.

ActiveRecord has made a lot of what we’ve been doing at Flatiron for the last three weeks make so much more sense. While I’m still not entirely sure where I’m going all the time, I feel like I’ve been given a map - sure, maybe it’s a faded, half-finished map, without an end-point in sight, but a map nonetheless. And I can’t wait for more of it to come together.

PSST, if you want to learn more about ActiveRecord, read this guide!

What Nobody Tells Beginner Programmers

“Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit. Most people I know who do interesting, creative work went through years of this. We know our work doesn’t have this special thing that we want it to have. We all go through this. And if you are just starting out or you are still in this phase, you gotta know its normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions. And I took longer to figure out how to do this than anyone I’ve ever met. It’s gonna take a while. It’s normal to take a while. You’ve just gotta fight your way through.” 

Everyone warns you that your first year out of college will be difficult. For me, that was an enormous understatement. After studying politics in school and hoping to begin a career in international affairs, I somehow wound up in an online marketing position, promoting drugstore makeup brands and car manufacturers. I was unfulfilled, uninspired, and unhappier than I had ever been in my entire life. Something had to change.

Everyone has a different reason for ending up at Flatiron. We were searching for fulfillment, we wanted to build something beautiful, or we didn’t want to get left behind by the technological revolution rapidly altering every aspect of our modern lives. Many of us said goodbye to a comfortable life that would’ve been sufficient – more than enough, even, for many people. But for us, it wasn’t.

Two weeks into Flatiron, and about five months since my initial introduction to the world of programming, I currently have a love/hate relationship with coding. I’m trying to embrace the love side of the relationship, but I’m still working my way over there. Right now, coding is a new friend that I enjoy getting to know and couldn’t imagine living without now that we’ve been introduced – but every now and then, she backstabs me when I least expect it.

Let me explain: When you’re programming, and you get something right, it feels amazing – it’s an intoxicating, incredible feeling. You feel inspired, you feel validated, like hey, you are smart enough to do this, you are capable and worthy of being a part of that elite group of people who have the ability to build incredible things, things that millions of people couldn’t imagine going about their daily lives without. But when you get something wrong – when you keep getting something wrong, despite spending hours and days and nights and weekends working through the same problem, it can be soul-crushing. It can make you feel like there’s no one in the world less intelligent than you are in that moment.

As a recent NYC transplant, I find learning to code a little similar to adjusting to life in New York. When the city is on your side, it elevates you; it makes you feel on top of the world and you pity everyone who doesn’t live here. And when it’s not, it feels like the loneliest place on Earth, and you cannot fathom why anyone would choose to make this place their home. The secret to getting past this, (as I’m very slowly learning), is to continuously remind yourself that when you’re struggling, and stumbling, and feeling terribly small and alone, that’s when you’re learning. That’s when you’re growing.

“The turn-of-last-century British artist William Morris once said you can’t have art without resistance in the materials. The computer and its multifarious peripherals are the materials. The code is the art.”

There’s this interview with Ira Glass that I absolutely love. He talks about a gap he experienced during the first few years he began working in radio. A gap between what he wanted his work to be and what it was. It had potential to be great, but it wasn’t. He says a lot of people go through this same experience. And a lot of people quit at this point. They think that because their work is not great, they weren’t cut out for the job or the industry they’re trying to break into. But Ira says the fact that you know that your work is not great, that you know it could be so much better than it is – that means you have taste. You know the difference between Edith Wharton and Stephanie Meyers; between Bob Dylan and Adam Levine; between the first snippet of code below and the second.

1
2
3
4
basket = ["apple 1","apple 2","apple 3","apple 4","apple 5","apple 6","apple 7","apple 8","apple 9","apple 10"]
basket.each do |apple|
    puts "Taking out #{apple}"
end
1
2
3
4
5
6
7
8
9
10
11
12
13
basket = ["apple 1","apple 2","apple 3","apple 4","apple 5","apple 6","apple 7","apple 8","apple 9","apple 10"]

apples_in_basket = basket.size
apples_taken_out = 0

loop do
    if apples_taken_out < apples_in_basket
        puts "Taking out #{basket[apples_taken_out]}"
        apples_taken_out += 1
    else
        break
    end
end

The fact that you recognize these differences means that you are in the right industry. You just haven’t worked enough yet. And the only way to elevate your work from so-so to great is to work like crazy. Work every day. Work through the evenings. Work on the weekends. Produce volumes and volumes of work, and eventually you’ll close that gap.

Ira is likely directing his message toward the more traditional creative-types – writers, artists, and musicians – but I think his advice applies to computer programmers just as much, if not more. We’re not producing symphonies or novels, but what we’re doing requires just as much good taste and creativity, as well as a keen artistic eye.

Programmer Paul Ford recently wrote an article for Bloomberg called “What is Code?” I couldn’t have read it at a more opportune time, at the beginning of my immersion into programming. In the 38,000 word article, Paul takes an incredibly nuanced and complex subject and breaks it down so a non-expert audience (like myself) can better understand what code is and why it is so important. Paul stresses the idea that software is in everything. It’s not just in the games you play on your iPhone or the website you use to book your vacation. It’s in your laundry machine, the elevator in your apartment building, the train you take to work. Code is alive and well in nearly every aspect of your life.

In one of the opening paragraphs in his article, Paul writes the following:

“What I’m saying is, I’m one of 18 million. So that’s what I’m writing: my view of software development, as an individual among millions. Code has been my life, and it has been your life, too. It is time to understand how it all works.”

Everyone has a different reason for coming to Flatiron. I came because code has been my life for the better part of my 22 years on Earth and it’s time to understand how it all works. This is my view, as an individual among millions, as a beginner programmer.