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 Edgar Developer

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.

Edgar Code
What a section of Edgar looks like as code…
...and what it looks like inside the app.
…and what it looks like inside the app.

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.

Developing Edgar
Team Edgar members Chris and Matthias working on an early build of the app at our 2014 team retreat.

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.


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.

Kristina, Customer Experience Manager

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.

Edgar Schedule Editor
Updates like this one are made in iterations, rather than all at once.

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!


Social Share

Get Actionable Social Media Advice (And Not Too Much of It!)
Get The Dash, your weekly social media to-do list, delivered straight to your inbox.

Never Run Out
of Stuff to
Post on Social

MeetEdgar scheduling software automatically pulls posts from your content library to keep your social fresh everyday, on repeat.

  • Jake

    Hi Lail, I know this is a couple years old, but thank you for this great post! It’s very insightful on your development process. I was wondering how MeetEdgar selects developers to join your team? How do you interview developers specifically and what makes someone standout as a good candidate? Asking for a friend…(okay, I’m asking for myself).

    • Lail Brown

      Hi Jake!
      Good questions. First, the interview process – it’s comprised of a few separate steps, and we’re generally evolving and tweaking our hiring process all the time. Right now, a successful developer candidate can expect to meet with various team members at least four times before we’d send them an offer.

      If an application looks promising, the first thing we do is schedule a video chat intro meeting. At that meeting, we talk with candidates about their experience and what they are looking for, tell them about MeetEdgar, and answer questions for them.

      We’ll usually do a more traditional skills interview next. Usually, this means you’d be talking to a couple of developers from the team you’d potentially be working on in the future. The goal of this conversation is to figure out what you know and where your skills are strongest. We tend to ask questions to will allow you to demonstrate a lot of specific knowledge, but we generally don’t ask you to write code on the spot.

      Then we’ll do a cross-department interview where you’d meet with a couple non-developers from anywhere in the company. The goal for this conversation is to establish more broadly what it is that’s important to you, how you work, and how you collaborate with others.

      If all of that goes well, we ask developer candidates to spend a couple hours pairing with a developer on our team. This lets you continue to get to know team members, and demonstrate how you would solve the actual sorts of tasks you’d face every day.

      If all that goes well, we’ll make you an offer! It’s a long process, but it’s important. We’re very focused on building great teams, and once you become a team member, everybody tends to appreciate all the work that went into the process upfront to make sure they get to work with great teammates.

      When it comes to what we look for when initially selecting candidates for development roles, generally we value experience over where you might have gone to school or what your degree might have been. We look at teams you’ve been a part of and how you’ve contributed. We also like to see evidence of a passion for programing, like open source contributions or involvement in a developer community. And of course, we like to see that you’ve worked with the sorts of languages and tools you’d be working with at MeetEdgar.

      I hope that’s helpful. Thanks for the questions!

      • Jake

        Yes Lail, this is very helpful! I can tell based on your responses that you and MeetEdgar share the same values regarding transparency and building great teams. I read through your employee wiki, and loved the values that MeetEdgar holds while maintaining a remote team. I have remote work experience for 5+ years and with pair programming, and I applied for the full-stack developer position. Thanks again!

Leave a Reply