The Choreography of Coding
When I was 9 I wanted to be a ballerina.
There’s a scent that flows through a ballet studio, and lingers on the stage.
It’s a mixture of heat and hairspray, salt and steam, tiger balm and old wood.
It’s distinctly the scent of passion.
Not long ago, I had an excuse to network myself to a team of software engineers and jumped at the opportunity to see where and how they work. Walking up the wooden staircase to their office, stepping into the brightly lit room, I inhaled that same scent of passion, of a team with a singular focus on the art they were creating together.
You might think that software engineering and dancing on your tip-toes have absolutely nothing in common, but oh, they do.
Seeing the team working together brought back a flood of memories: the sharp and rhythmic counting of my teacher’s voice, the barre beneath by fingertips, and a million tendus and pliés over and over and over. I remembered all of the frustration and sweat and trying again that happened in that classroom, feelings that could only be matched by the exhilaration of being on stage. And the more I remembered, the more I was reminded.
Developing software is an art with a focus: you. Much like a ballet troupe training in a very specific way, to prepare a show that you find pleasing and more than a little impressive, developers are training in their own way, following a specific structure to also give you something you enjoy and find more than a little impressive.
Any web page or application you load has two parts to it: the part you see and the part you don’t see. The part you see is called the front end; the part you don’t see is called the back end. As you move through the site, your movement causes a chain of reactions behind the scenes, to deliver what you’ve asked for. And this process is end-to-end development.
You are a person who likes to use the internet. The page you load is our stage (and it’s beautiful). You are enticed to select something, lots of somethings. The moment you click our button, everything we’ve prepared and worked for starts to happen.
Step one, the front end (that’s you clicking the button) tells our server that it wants data. The server says “Omg I love retrieving data” and tells the back-end that it’s time to party. The back end processes your request and fetches, or retrieves, that data from the database. Then, the back end tells the server that it brought the goods to the party, and the server delivers your data to you, at the front end.
This is a very simplified version of our dance. To truly appreciate the performance in front of you, we need to consider everyone’s roles and everything that went into getting us on stage. Let’s break our dance down a little further.
Productions can be built in many different ways, with different stages, different casts, entirely different towns. In software engineering, we call this our “stack.”
Recently I built out a full stack application with my peers. Our stack was a React/Javascript front end, a REST API server, a Ruby on Rails backend, and a Postgres database. There are endless stacks that can be combined, but for simplicity’s sake and to help with visualizing, this is the stack I will speak to.
You know that our front end is what is displayed to the user. Sometimes we say UI/UX instead; these are terms to describe the user interface and the user experience, both of which make up the front end. The front end is our stage, with multiple entries and exits, but usually it’s the start and finish. It’s where our whole production comes together.
Our REST API (REpresentational State Transfer / Application Programming Interface) is a hosted server. Servers spend time listening for specific calls, and when those specific calls are triggered (this is you clicking our button), certain back end or front end actions happen. The production manager of a ballet is like our server, directing dancers on and off stage, telling who to take a break, who to get food, who to get back out there and shake a tail feather. The production manager listens to problems that are happening backstage, and determines how to solve those problems. They are our single point for resolving any requests that happen.
When we receive a server call that pertains to our back end, Ruby on Rails steps in. We have predetermined endpoints that have predetermined responses. A GET request to a dancer endpoint may search the database for one dancer that matches the specific criteria. A GET request to the dancers endpoint may return all dancers from the database. Ruby on Rails is special because acts as its own ORM (Object Relational Mapping). This serves to turn our database interactions into easily accessible objects. The ORM is the dressing room, where our dancers start in their street clothes, but become a data object, ready for the stage.
Normally our Postgres database would only listen to SQL (pronounced “sequel”) queries, but our ORM formulates queries for us. Our database is our entire cast, from lighting to writing to acting; it’s everyone that might be able to fill a requested role for our production. Once the data is received (once our cast member is chosen), a stream of readable data is sent back through the REST API. The final step is our front end processing this stream of readable data and saving it for us.
I think one of the most beautiful aspects of any art, is its ability to bring people together. Software engineering is an art that not only brings us together, but serves us, and makes our lives better and more beautiful. There is creativity and passion to be found here, and yes, even dancing.
