The roles in App Development
I’ve defined my mission as “get more brilliant minds into software engineering”, so I’ve been offering tutoring time over the weekends to my friends!
I find Frontend Engineering the most effective “in” into engineering, so that’s my teaching platform, which led to many asking… What is a Frontend Engineer anyway?
That’s a very good question! Some job roles describe the value they bring quite intuitively, most of the roles you find in your average London startup… not so much. Consider “Yoga Teacher” versus… Well, “Frontend Engineer”. Is it even “frontend” or “front-end”?
Let’s visualise an app like Instagram. You may even open Instagram if you wish, but you’re only allowed to ♥️ #samoyed pictures while I tell the story of the many roles involved to create such an app.
The Summary
I know the below is a lot to go through, so I’ll try summarising every role I’ll be covering, in one cheeky sentence per role!
Designer: Designs how the users interact with the app
Frontend Engineer: Asks for data and displays it according to designs; handles “ephemeral” changes as the user interacts with the app
Backend Engineer: Fulfils requests for data; handles “persistent” changes
Data Engineer: Derives insights on how the app should be interacted with to attract more users / generate more value
Fullstack Engineer: They can do either Frontend or Backend professionally, have read Medium articles about the other side
Brace yourselves and let’s get started with:
The Designer
Everything you see in the app has been… designed… by a Designer. Sure, the dynamic content, like your friend’s latest brunch, was created and uploaded by other users. But it’s the Designer who visualises exactly where those posts go, how much screen-real-estate the picture of every post should be taking, should they have captions, the name of the author, their avatar…
How do you interact with the post? How do you know if you’ve liked it already? Those are questions the Designer is the first to ask and provide answers for. Maybe in writing, maybe with a sketch on a napkin, maybe with a high-fidelity prototype made in a dedicated tool which outputs beautiful pictures… and zero code. Whichever the case, you cannot install what the Designer designs on your phone, or see it working on a web page.
But you can use it in a slide deck as the visionary CEO, to dazzle investors and get the funds to start disrupting the untapped market you’ve identified, to hire the people who will be bringing those beautiful designs to life! These people, we call them Software Engineers, and the first sub-group we’ll examine is the Frontend Engineer.
The Frontend Engineer
A Frontend Engineer may be all you need nowadays to have a real app with real users. It will be lacking in some fronts, even if the Frontend Engineer is remarkably capable, but the value of having something functional you can put in front of users cannot be understated.
Ideally they’d be working hand in hand with Designers, in practice design resource is often a scarcity, especially early on in an app’s lifecycle.
It’s on trend for CEOs to pay handsomely on demand for enough designs to make their slide deck work, then, once the initial funds are secure, figure that’s enough design expense until at least Series B funding. They’d then just point to the idealised material made bespoke for the slide deck and ask the Frontend Engineer to do their best to translate them into code; and just fill in the gaps as they see fit. They are a creative problem-solver after all.
But what do they actually make? They write code which makes your device or browser show something resembling the designs, and respond to your input accordingly to show yet more “screens”.
It’s mostly true to say code is deterministic, so the same screens will be shown in a predictable manner according to user actions. If I’m in the posts feed and I tap the paper airplane, I’ll make it to a list of my conversations, every time. Once there, pressing the back arrow will get me back to the posts feed, every time.
It’s the Frontend Engineer who has linked those “screens”, the state of the app, in such a way where the action of tapping a specific button, results in a transition to another screen.
But consider: I download the same app as you do, the exact same code, and yet my feed is full of samoyeds, beach volleyball, and barbells. It’s likely your feed is totally different! How can that be, when our phones are both “executing” the same code?
That’s because the Frontend Engineer has been asking for the data to display from the Backend! The code which determines what to display and how, the “logic”, is the same for both of us, but the data we get back is different.
The Frontend asks “please give me the latest posts of the people this logged-in user is following”. If you tap the button to go to your messages, the Frontend will then ask: “please give me all the conversations this logged-in user has had, and the latest message of each one”. If you then tap any one, then the Frontend will be asking “please give me all the messages for this conversation”.
In the “single conversation screen”, there is an input field at the bottom. The Frontend Engineer has ensured once you tap there, the virtual keyboard open ups and you can draft a message. You can then tap “Send”, to send your message! But where does it get sent to, exactly?
It will make it to the person you’re conversing with, eventually, and as a user that’s all you need to know!
But, as far as the Frontend Engineer is concerned, that new message is data they need to ensure their code submits to the Backend. Kinda like asking for data from the Backend, this time they need to submit some data to the Backend. That’s so when they next ask “please give me all the messages for this conversation”, that new message will be included at the bottom!
… But what is this Backend I keep mentioning anyway? Well, it’s the realm of the Backend Engineer!
The Backend Engineer
If the Frontend Engineer is responsible for all the things that are in front of the users, the Backend Engineer is responsible for all the things that happen “behind the scenes” for the app to work; backstage!
If you were in a restaurant, Frontend would be things like the front of house you interact with, the waiters, the decor, the table, the chairs, and of course the dishes and drinks you’ll be enjoying.
The Backend is what happens in the kitchen! You don’t need to see it, sometimes it’s better if you don’t, but you’re definitely feeling the results of the hard work put in there. You may stretch the analogy further and say the Backend could be how much capacity there is for meals to be prepared on time, and how fast, and the variety of dishes that are available.
Interestingly, not all apps need a Backend! As a rule, if the app does not need any persistence, it may get away to being functional without a backend.
A todo app that doesn’t sync your todos across your devices may not have a Backend. But if it does to retrieve those todos from another device, so for these todos to be tied to a particular user instead of a particular device, then it does need persistence, so it will need a Backend.
With phones becoming more and more powerful, it’s becoming more and more popular for things to be happening on the frontend. Imagine the restaurant being so big, and having a stage with live music to distract you, that some of the things traditionally done backstage, can actually happen right on the periphery of your vision.
But enough with the analogies and digressions, what does the Backend Engineer actually do?
They are responsible for writing code to handle all questions the Frontend Engineer may ask! If the Frontend could ask for “the latest posts for the people that this logged-in user follows”, the Backend must be able to answer back with the relevant data.
This is where things like databases and authentication and permissions and APIs come into play, but I’d say going in deeper than that is a different blogpost altogether! Let’s instead keep going through our list of roles by asking the question… If the Frontend asks for “the latest posts for the people that this logged-in user follows”, why is the second post always an ad?!
Well, it’s because the Frontend actually also asks for an appropriate ad, but why it is displayed as the second post and why should it be asking for one in the first place… Well, that may have been the work of a Data Engineer.
The Data Engineer
Their role may also appear as “Data Analyst” or “Machine Learning Engineer”, according to how many digits there are on their annual salary.
In practice, most companies collect as much data about their users as they can get away with, and they frantically try to derive insights by crunching that data in creative ways. The most doomed companies do things based on the CEO’s gut feeling, but even those may fill Data Engineering positions at some point; everyone wants to at least appear as if they’re doing “Big Data”.
In any case, the Data Engineer may be the person who validates how feasible a monetisation strategy running ads is. It can be the person to research that the further down the feed we put those ads, the less effective they are, and therefore the less money we can get per ad. The less we can convince people to advertise through us.
It can be the person to dictate the ads should be placed as the second post in the feed! Because even if the CEO thinks placing them first would work even better, and those ads would be getting many more impressions, their effectiveness actually goes down as people blindly scroll through to the first “genuine” post: therefore fewer people tap and convert through those prominently placed adds, and some even actually uninstall the app in disgust of how “in-your-face” it is with its ad placement.
The Data Engineer may also be the person to derive the rule to say: if a person has liked a #samoyed picture, show them ads for pet owners. Or it could be the engineer who sets up a system which takes in all sorts of user actions and then decides which ad would be most likely to convert for a particular user and show that one, without needing a clearly defined path; without need of a “liked a dog picture” -> “show dog food ad”.
That’s what “machine learning” is, in essence: using tons of data to make a great decision, without having hard-coded rules for the astronomical amount of permutations you’d get from all the data you fed into the system.
… Each section above is quite large… Would you believe there is a role that combines all of them?!
The Fullstack Engineer
Etymologically, a Fullstack Engineer is an Engineer who can work “across the stack”. So they can do the Frontend work, and they can do the Backend work. Maybe they can even do the Data work. Maybe the Design work as well? Of course, that’s implied in the Frontend work.
But wait, we name-dropped quite a few things just for the Backend too, and there are yet more we didn’t even mention. Would a Fullstack Engineer have SQL expertise? Would they be able to train machine learning models? Can they integrate with Salesforce? Can they do user research?
I find that the dream of the Fullstack Engineer, who can effectively work on any part of an app at any moment, is hard to fulfil. Harder than finding multiple true experts in each individual field. And even if you do find that great Fullstack Engineer, it’s not like you’ve magically manifested more hours in the day for them to leisurely wear their plethora of hats.
They will still need as much time as the individual “single-role” Engineers would have needed in total, maybe less if they are as skilled as each would have been, maybe more if they aren’t; and what’s for certain, is that they cannot work in parallel with themselves.
Their perceived usefulness to their actual usefulness aside, I’d say an Engineer can be effectively “Fullstack” if they can carry out fundamental Frontend and Backend work. It they need to display the latest posts in a feed, they can do the Frontend work to ask for the data and display it accordingly, and the Backend work for an answer to exist for that request for data.
In practice, you find “Fullstack Engineer” in a CV when there is at minimum work experience in Javascript + one other language, and a weekend of reading about one other language + Javascript.
The Conclusion
There are many roles working hard to make the app of your average London startup, and even after 2000+ words, we’ve only touched the surface of the more “engineering-specific” ones.
The CEO made a cameo a few times, but we didn’t even mention Project Managers / Product Owners: they prioritise how of all the things we could be building next, it’s the little avatar that shows up to where the person we’re conversing with has read our messages, is the one thing to build next. What about marketing and sales? HR?
There’s no arguing those roles are integral in any business, and even in the context of building an app, they are quite directly involved! But much like the best Minimum Viable Products, this article has a defined scope I’ve hopefully slightly over-delivered on.
Reach out with your questions and I’ll be happy to write more and answer them!
