How to Make an App: Under the Hood with an Edgar Developer

Edgar is our team’s baby - and today, we’re going to talk about where babies come from.No, wait. Let’s try that again.

Meet Lail.

Lail Brown is Edgar’s front-end developer, which means every day, he’s writing the code that defines how Edgar looks and feels. We sat down with him to learn a little more about how an app like Edgar gets created - and what we can look forward to next.So what does it mean when we call you a front-end developer?Well, everybody divides up coding responsibilities differently, but here at Edgar, we do it front end and back end, which is actually fairly common.The front-end developer is responsible for all the code that ends up in your browser, so it’s kind of equal parts design and development. All the interfaces you use on a daily basis inside Edgar are built by the front-end developer.And what does the back-end developer do?The back-end developer does a lot of heavy lifting on the server, shaping the data as it comes in, making sure posts are going out, all that fun stuff. They do a lot to make the app faster and more functional.Sometimes that means we’re working together on a particular update, but a lot of the time, they’re making changes that don’t affect the front end at all, and that the user never even knows are happening. They’re doing things like changing where the images that users upload get saved - that’s a change that’s completely invisible to the user, but makes a big difference in how Edgar performs. And sometimes I make changes to the interface that don’t really affect the back end, like a tweak to an interface. It goes both ways.You’re both writing code, but different types of code.Exactly. One of the things I like about front-end development is that you get the opportunity to work with a few different things. So for example, I spend maybe 20-30% of my time in Ruby on Rails. Our back-end developer probably spends 90% of his time in it.Ruby on Rails?Rails is what we call a framework. In development, it’s a layer you build your code on top of, so you don’t have to start from scratch every time. Another one I use a lot is React.js, which is for JavaScript. I spend a lot of time coding in JavaScript, CSS, and basic markup, just building out pages and interfaces.So when you’re writing code, it doesn’t look anything like what the user sees. How do you know what it’s going to look like? Is this like The Matrix?Honestly, the single button you press the most is the refresh button in your browser. When I’m writing code, I have two separate monitors - there’s a browser open on one, and a code editor on the other. And you just constantly go back and forth, hitting refresh, seeing what it looks like as you go.[caption id="attachment_1649" align="aligncenter" width="750"]

What a section of Edgar looks like as code...[/caption][caption id="attachment_1650" align="aligncenter" width="750"]

...and what it looks like inside the app.[/caption]You know how much we love feedback from our users. When someone submits a feature request, what happens to it? Does it go to you?It actually does. We keep track of feedback and requests, and for every single one we ask ourselves a few questions:

1. Is this something we’re hearing about a lot?
2. Is it something that people seem to really want?
3. Does it make sense for the average user?
4. Does it line up with our own goals for what Edgar can and should do?

Once it’s clear that something can and should become part of Edgar, we move it to our roadmap, where they all get sorted and prioritized.How many things are on that roadmap?A lot. We actually take that roadmap and break it down into smaller lists, so we know the difference between things we want to get done sometime, and things we want to get done now.How’s that process go?It’s really collaborative. Which as a developer, is amazing. Some places, development is a top-down sort of thing, where you don’t really give feedback on whether something is a good idea or a bad idea, or if it should be a priority. Here, you have a lot of individual say, and can feel as though you’re really helping shape the program. That’s a critical difference, especially because sometimes one developer can have a really unique perspective on a particular feature. Once we agree on what we’re going to work on, we divide up the work between front end and back end.[caption id="attachment_1651" align="aligncenter" width="750"]

Team Edgar members Chris and Matthias working on an early build of the app at our 2014 team retreat.[/caption]Once you know what feature you’re going to build, then what?Each individual developer codes using a version of Edgar that’s saved locally on their computer, so you basically download all the code and edit it offline, instead of editing the one that’s live for our users.Once the coding is done, and I feel like it’s working well, I’ll write something called tests. Tests are actually like robots that test the feature....robots.They’re like robots. When you introduce new code, you want to make sure that it doesn’t have unforeseen consequences elsewhere in the application. It wouldn’t be realistic to have someone go through and manually click on every single button inside the app every time we introduce a change, so tests do it automatically, and make sure nothing is broken.And then it gets uploaded and you’re done, right?Not exactly. Once I’m convinced it does what it’s supposed to do and has been tested, then it goes to code review. This is when you get another developer to look over your work, and see if there’s anything you could have done differently, or better - just like you would with pretty much anything else you might write.Okay, and THEN it gets uploaded and you’re done.First it gets reviewed and tested one more time. At this point, we actually upload it to a special server for quality assurance (QA). We tell Kristina (our customer experience manager! -Tom) what the feature is supposed to do and how it’s supposed to work, and she tests it. She has great insight into what our users are looking for and how they’ll use a new feature - sometimes that means sending it back to me to make changes, and sometimes it means that it looks great the way it is.

And then…Then it’s ready to upload! Depending on the nature of the change and how it affects the database, actually deploying the new code can take as little as 30 seconds or so, and then the new feature is online.So all in all, how long does it take for us to implement a new feature?Well, that depends. Because even once we know something is going to be coded and implemented, we can’t just do it immediately - we have to wait until it makes sense to revisit the code for that particular part of the application.So for example, we recently added a feature to the schedule where you can click anywhere to add a timeslot, instead of clicking a static button. Once I started actually writing code for that, it only took a few days, including all of our testing. The part that takes the longest is when we already know that we’re going to do something, but it doesn’t line up with other changes we’re making.How often does Edgar’s code change? All the time. We’re writing updates constantly. They often aren’t huge, noticeable updates, though - we split our time between creating new features, implementing small improvements, and fixing bugs.We don’t like to drop huge features and new sections all at once - we evolve things, and iterate things. So the new schedule interface launched a few months ago, for example. And from the beginning, we’ve had a lot of ideas for scheduling features we want to add or change, and we’ve been building and releasing them over time, in iterations.[caption id="attachment_1653" align="aligncenter" width="700"]

Updates like this one are made in iterations, rather than all at once.[/caption]Ultimately, that means we get to create the best user experience possible. When you make decisions in a vacuum, there’s a good chance you’ll mess something up. But because we do things in iterations and evolve Edgar over time, we get to learn what our users like and don’t like as we go.Sometimes they ask about features that are already on our roadmap, and sometimes they suggest things we hadn’t necessarily thought would be useful. I know for a fact that if I’d just built whatever I wanted from the start without any user feedback, the schedule wouldn’t look the way it’s going to end up looking. It’s way better off this way, with us having the benefit of hearing what people think as we go. And that’s how it is with every major feature.

Got a question for the Edgar developers? Hit us up in the comments below!