How Our Front-end Team Learns by Doing

in Front-end

At Code School, courses aren’t the only thing we focus on — we also devote time toward building tools and applications to improve internal efficiencies, which ultimately enhance the overall Code School experience. Besides creating something to improve the company, it gives us the opportunity to use a new technique or technology to grow our skills as developers. And that growth in skills not only enhances our role as front-end developers, but also allows for a heightened understanding that we can learn from and apply to future projects.

On the front-end team, we have a rotation for working on internal tools. We all work together to create the end project, but we also each have our own individual strengths and input. So today we wanted to give you a little insight into what we learned while building these tools and applications from the perspective of each front-end Code Schooler. We’ll each answer the following questions, and I’ll kick us off.

  1. What application or tool did you build?
  2. What did you learn?
  3. What was your biggest takeaway?

Drew Barontini — Front-end Director

What application or tool did you build?

Drew Barontini

I built an application that uses Basecamp’s API to display calendar events in an alternate format. The goal was to condense the multitude of events on our company calendar into a focused view. The traditional monthly or weekly view lacked hierarchy and priority — all events sit on the same level. For our purposes, we need certain events, such as course launches, to be displayed with a higher priority, and this application aims to solve the problem with a better visual hierarchy.

What did you learn?

Drew Barontini

I learned about Sinatra, a DSL for creating web applications in Ruby. Since I didn’t need a database, I chose Sinatra to handle routing, and to provide an easy interface for custom Ruby classes and modules. Not only did I learn about Sinatra, but I learned a lot of Ruby, particularly dealing with external APIs and parsing dates. I also discovered API calls can be slow, so I integrated Redis, a key-value cache and store, to speed up the application.

What was your biggest takeaway?

Drew Barontini

The cognitive load of focusing on the back-end system was such a mental drain, I had no energy to focus on front-end or design. It solidified my belief in true separation with design, front-end, and back-end teams — they are all specializations with sub-specialities within, and each area deserves its own attention. With that being said, I still find it vital for each area to understand how each team and role functions.

Dan Denney – Front-end Developer

What application or tool did you build?

Dan Denney

My curiosity about Code School, combined with inspiration from the book A More Beautiful Question, led me to build an app that would allow us to ask and discuss questions. It’s like an internal Quora, but with only about 5% of the features and almost no visual design.

What did you learn?

Dan Denney

For the past 4 years I’ve been working in Rails environments in what can only be described as a trial by fire. In building this, I gained a much better understanding of how database and data relationships work, how models and controllers work, and gained an appreciation for why things aren’t always as flexible as you want them to be. I also lost any desire or motivation to write CSS for it once it was working. It was such a gigantic shift in process and thinking that I was drained by the end of it.

What was your biggest takeaway?

Dan Denney

By default, Rails applications are not complex. It seemed that they were, so I had avoided creating my own for a long time. I now understand that the complexity comes from the code that we put into them.

Jordan Wade — Front-end Developer

What application or tool did you build?

Jordan Wade

I worked on an application that keeps track of all our current employee information and departments here at Code School. It’s the place where Code Schoolers can go to find specific information about a fellow coworker, like an employee’s name, email, bio, interests, etc.

What did you learn?

Jordan Wade

This was a great way for me to further my knowledge of Ruby on Rails. I work day-to-day in a Rails environment, but rarely touch anything besides HTML, CSS, or JavaScript. It was awesome to get the chance to build an application from scratch. Throughout the entire process I was learning something new — everything from the initial setup of an application to generating models, controllers, and migrations.

What was your biggest takeaway?

Jordan Wade

I was really surprised at how simple and quick it was to get a Ruby on Rails application up and running. In no time I had all the functionality working on this application, and now I feel that I have a stronger understanding of Rails. So, when I need to request something from one of our awesome back-end developers, I’ll be better at speaking their language. I can’t wait for it to be my turn again to create another internal tool!

John D. Jameson — Front-end Developer

What application or tool did you build?

John D. Jameson

I’m building an internal dashboard to help our front-end team monitor website performance over time. Tools like WebPageTest and PageSpeed Insights make it easy to measure performance right then and there. What they don’t do is provide a way to compare data recorded over the span of several weeks or months. We think it’s super important to know how a website’s current performance compares with earlier benchmarks, so we’re building an application to help us out.

What did you learn?

John D. Jameson

I’m learning a lot about Middleman. I knew I loved Middleman before, but working on this project has given me the opportunity to use features that I didn’t even know existed.

For example, I knew about Middleman’s data object before starting on this project. Put a JSON or YAML file in the data directory and Middleman lets you get values from that file via the data object. Seems simple, right? But what I didn’t know is that the data object includes any nested directories, too. This means we’re able to convert an entire file tree into a single JSON object just by calling data.to_json anywhere in the code. Once I figured that out, I was able to solve 1 of the hardest problems I ran into while building the application.

What was your biggest takeaway?

John D. Jameson

Find ways to automate everything.

Early on, we gathered our data from DevTools, WebPageTest, and PageSpeed Insights. We’d run each tool in the browser, and then manually copy the results into some timestamped Google Docs and YAML files. It was a tedious process that would’ve required developers to format the data perfectly each time around — so of course that had to change.

After discovering command line tools for both WebPageTest and PageSpeed Insights, we’re now able to run a Bash command and have multiple JSON files within minutes. Not only is this faster, but it prevents us from making any errors in our data entry.

Wrapping Up

As a team and individually, we each learned a great deal through this process. The most important (and sometimes scary) part is diving right into a technology you’re not comfortable with. Spend time asking “why,” encounter problems and solve them, reach out to subject-matter experts to pick their brain, and, most importantly, talk about what you learned. When we communicate the things we’ve learned, the industry as a whole benefits. Jump in and start building something new. And, as always, know that Code School is here to help you through the process. Let us know what you think about the projects we covered above in the comments section below (tip: click “View Discussion”)!

Code School

Code School teaches web technologies in the comfort of your browser with video lessons, coding challenges, and screencasts. We strive to help you learn by doing.

Visit codeschool.com

About the Author

Drew Barontini

Front-end Director at Code School. Internet introvert, real-life extrovert, and an obsessive-compulsive developer who diligently rages about spacing, organization, and all-around cleanliness of code (and also anything).

Might We Suggest