‘Easy to code doesn’t mean easy to use’ and other lessons learned in web app development
“I have no idea what I’m doing.” – Me, on my first day at MediaMath
While I had worked on dozens of software development projects for my computer science classes, I didn’t bring any web development experience to the table when I joined MediaMath’s Global Business Systems (GBS) team. GBS builds and maintains Knox, an internal-facing web app whose purpose is the standardization and automation of MediaMath’s financial processes. I needed to get up to speed on web development pronto.
The biggest surprise to me was learning how multifaceted and multidisciplinary the field of web development is. Just wrapping my head around all the different components was challenging.
But like anything, once I broke web development down into its most basic components, I was able to get up and running. Here are the three main things I needed to learn to start building features on the Knox web app.
First order of business was to learn Rails, the underlying programming language behind Ruby on Rails (Rails), which is GBS’s preferred web application framework. Ruby is especially notorious for throwing programmers for a loop. I was already familiar with imperative and functional languages and object-oriented programming, so the main challenge for me was learning Ruby’s gotchas. Once acclimated, however, I found that Ruby was great for expressing complex ideas with relative brevity.
For example, consider this short Ruby expression:
This generates the entire alphabet (‘a’..’z’), puts it to an array (to_a), randomizes the array (shuffle), grabs the first 10 letters ([0,9]), and combines them into one string (join). That’s a lot to accomplish in just 33 characters.
The web dev environment
Moving from Ruby to Ruby on Rails was relatively painless for me, but making the jump from GUI-less software development to web development was somewhat more involved. I had to learn a lot of important framework principles, like model-view-controller (MVC) and test-driven development (TDD).
MVC governs delineation between front-end and back-end code, while TDD involves writing tests for your app before actually implementing new functionality. TDD might seem like a backwards way of building, but it actually helps ensure that code is built exactly to specification.
The web dev environment must also include a database for storing and managing data. Thankfully, I was already familiar with SQL and relational database concepts from a previous internship, so I was able to get up to speed quickly. You can perform many of the simple database tasks using a graphical management tool, but more complex problems require using actual SQL.
What I learned in building UIs is that what’s easy to code does not coincide with what’s easy to use. Building a good UI means catering to the needs of the user, rather than the needs of the programmer.
Putting in all together
Developing a new feature for Knox required using all of the above tools together. Once I felt comfortable enough to start puttering away on my own, I was able to build a number of features.
One of my favorite projects was improving the usability of Knox’s Statement-of-Work (SOW) table. The table had nearly 400 rows of entries to display, each divided into about 40 different pages of 10 rows each. Finding a specific entry was time consuming. I modified the table so that the user can filter out irrelevant entries, sort the table based on any column, and display anywhere from 10 to 100 rows at a time. It took a lot of work to get everything configured correctly, and the overall improvement to user experience was phenomenal.
Over the course of my internship, I built many features of Knox and absorbed an astonishing amount of material. I certainly have a lot more to learn, but I went from a novice with zero web dev experience to a developer with dozens of features running in production.
Not bad for someone who had no idea what he was doing on Day 1.