What the heck is a front end developer?
January 14th, 2009 by Tom 17 CommentsRefresh Philly is a new organization aiming to bring the local creative community together both to broaden our skills and to work toward the betterment of Philadelphia. Or something. It’s a great mission but it’s a little fuzzy. Narrowing that down is what the other guys’ presentation was about. My presentation, definitely in the first category, was about the Symfony framework.
My slides are available for your amusement. They’re a bit dry by themselves. The presentation itself was definitely on the dry side for the very large percentage of nonprogrammers present. But that’s one of the things we’re still learning as a group. This was our first “real” meeting, not counting the organizing meeting back in December.
I knew there would be quite a few nonprogrammers present. But I pictured designers who work side by side with coders all day and have absorbed some of the lingo and have a need to understand this sort of stuff on the same level a good manager would.
My coworkers have since explained that this is actually a bit uncommon. Many people designing for the web stick purely to design and don’t actually write HTML or CSS, so they are not teetering on the brink of learning PHP by looking over somebody’s shoulder.
Who writes the HTML and CSS code then? Apparently “front end developers” do. “Back end developers” write PHP, ASP, Java or whatever is in vogue on the server side.
You might wonder how I could have lived in ignorance of the distinction until this point. The answer is that I’ve mostly worked in small shops, or with independents. So specialization in pure design wasn’t really an option for most of the designers I’ve known in the past.
I’ve also known a lot of “web designers” who lived in the Bay Area during the dot-com crunch years, and they reported that there was no such thing as a job unless you could plausibly claim to know design, HTML, CSS, and PHP. And possibly reiki as well.
I’m not crazy about the terms “front end developer” and “back end developer.” These terms mean something very different when we start talking about web applications.
A “front end application” is something the public gets to play with. It has to be pretty and bulletproof and fast and easy and generally perfect in every way, requirements that require lots of attention from “front end designers,” but unless it’s a static site it also has moving parts on the server end, requiring plenty of attention from “back end developers.”
Meanwhile a “back end application” is something used by editors, administrators and other power users typically employed by the client you’re developing for. The public can’t see it. It has to be moderately bulletproof, depending on the number of people allowed to play with it and the skill level they are expected to have. It doesn’t have to be pretty. Depending on how frequently used it is, it may or may not need to be super-efficient and easy to use. So “front end developers” are still involved in building it… just to a lesser degree… while “back end developers” are all over it, although they may be using tools like Symfony’s admin generator to create basic, bug-free, boring interfaces in a hurry so they can get back to debugging the publicly visible front end application.
Still, terminology aside, there are far more pure designers in the world than I’d thought. And when I look at the web sites I’ve been involved with professionally in a development role, versus those I’ve attempted to design on my own, I have to admit that makes a lot of sense.
So what could I have done differently, to better address a room in which more than half of my listeners aren’t developers of any stripe? Well, not a whole lot, to be honest. Symfony’s direct relevance to a pure designer is pretty limited. I made as many references to monkeys, kittens, bathtubs and salsa dancing as possible without going completely off the rails. And for my part, I’m cheerfully committed to listening to the occasional presentation on design at future Refresh Philly events. After all, it’s only fair.
But I do ask that they throw in an occasional reference to monkeys.
January 14th, 2009 at 5:45 pm
“It doesn’t have to be pretty.”
It doesn’t Tom? Then I’m sleeping in tomorrow because, well, who cares if Duke has to trudge ten miles uphill in the snow to access their advanced admin features.
January 14th, 2009 at 5:48 pm
Good point… but that’s a discussion for another day: which “back end” features should really be natural extensions of the front end application, and which really do belong in a simple back end app.
January 14th, 2009 at 5:52 pm
I don’t see a distinction between the public and signed-in experience of a website. That is why we spend so much time working out the interfaces for all aspects of a site.
I think this post needs to be followed up with screenshots of some of the thoughtful design solutions we have implemented in the “back end”.
January 14th, 2009 at 6:05 pm
Back-end / front-end aside, I think the best developers are ones that have at least a working knowledge of the entire landscape of the application they’re working on. Designers are better equipped to design if they know what impact their work flow will have on the architecture needed to support it. Likewise, developers who have a passing understanding of user interface philosophies will be more likely to consider the implications of their own architectures.
It’s fine to have a concentration but to be completely devoid of skills or at least the understanding in one or more areas makes it tough to see the forest.
January 14th, 2009 at 6:31 pm
I agree with JP. As a jill-of-all trades, I’ve experienced firsthand the value of being able to do a little bit of a lot. That being said, specializing in a skillset is also very valuable. So, I think if you’re a programmer, you should have some understanding of usability and design concepts. And vice-versa, people who design for the web should understand the contraints of code and a little about IA and standards.
In any field it’s extremely valuable to understand the impact your decisions and creations have on those who work in tandem with you. To specialize but have a generalist’s view. In the end, it’s all about collaboration. And monkeys.
January 14th, 2009 at 7:37 pm
After doing a lot of jack-of-all-trades work and then discovering the enormous relief… er, productivity… of working with folks who are better at certain things than I am, I agree with Lauren about the value of being a specialist with a solid understanding of the big picture.
January 14th, 2009 at 7:47 pm
In an ideal world back end apps would be as pleasant to use as front end apps, and in many cases completely integrated into the front end app, seamlessly enhanced for logged-in users.
And we do that, a lot, as y’all are pointing out. Things like in-page editing on Study Abroad are used heavily every day by a significant number of people. They should be 100% smooth as a monkey’s bottom.
But we don’t live in an ideal world, and when budget concerns come to the fore, it makes sense to be glad there are straightforward solutions when a relatively large amount of relatively rarely used functionality is required. After all, no client wants to hear that you spent $10,000 worth of time on a set of features they need to have but will only use twice a year.
Accessing a separate page and filling out a somewhat utilitiarian form is appropriate technology for that sort of thing, so long as it’s understandable and functional.
January 14th, 2009 at 8:21 pm
My IT-centric definitions are a little different: Any human-facing component of a system is front-end. The back-end deals with data and system integration. Think view and controller for the front-end, model for the back-end. That breakdown is a luxury in small projects or those not plugging into complex data systems.
I haven’t worked much in the general web world, but I do remember programmer friends having trouble with designer coworkers when both tried to play in the code, especially early ASP and JSP with Dreamweaver. Think “when all you have is a hammer”. Have designers stopped doing that and gone “UML” with mockups and wireframes? That’s the better solution than playing in the same sandbox. Common language that both sides can speak, then realize in their own spheres. Agile also solves this in a less formal way.
Designers might not need much more detail than you gave in your presentation, but they should have some. They should be aware of the kinds of technologies out there and what their long-term impact on a system may be. Like you said about general CMS features everybody wants later, the designers need to be aware enough to know what to ask for (now and later) and know the smell of BS when the tech side gives it to them.
I don’t think you went too techie; RefreshPhilly may want to provide “tracks” if people aren’t getting the right level of whatever they’re into in future meetings. Never enough monkeys, but perhaps a few too many database queries!
January 14th, 2009 at 10:55 pm
Tom – I didn’t think your Symfony walkthrough was too technical. In fact, I was actually hoping for more hands on examples of building a site in Symfony. But given the mixed level of techie-ness at Refresh I thought you did a good job of selling the benefits of the framework.
Presentation aside, I agree with Kominetz on the front-end/back-end developer distinction. A back end developer specializes on building a framework like Symfony. He/she focuses on the lower level, technical architecture nuts and bolts of building *systems*.
A front end developer uses back end systems to build web sites. This person is focused on browser side interactions, adherence to web standards, and user experience.
As JP said, any web developer worth his/her mettle needs a working knowledge of all the layers of a web app from front to back. And most can hack JavaScript just as well as they can server side code.
But there’s so much room between the concerns of browser side interactions and database/model architecture that specialization can certainly be a resource on large scale projects.
January 15th, 2009 at 12:28 am
This discussion reminds me of one of the original principles in the founding of P’unk Avenue. I have always said that we all can’t be working on every aspect of each project (organization, design and build), but we all ought to be jealous of the person doing the parts that we are not doing.
In other words, on the projects where I am designing, I really should wish I was also developing it, as well. (And for the most part, that is the case still for me.) This grows out of our tradition of all being designers and developers (coming out of the Multimedia Department at UArts).
Hence, we are a design/build studio. I personally believe that the design and build process is one integrated flow when done best. Design decisions are made throughout the process of creating a website or web application. In my mind, agile development processes acknowledge that you are going to discover things throughout the entire course of the project, and therefore need to make new design decisions and adjust development process.
Probably one of our best kept secrets is that Alex is a very good designer, even though he primarily leads up development. Yet, his design skills are not wasted. They manifest themselves most obvisiouly in his feedback of our designs, and more subtly they allow him to make good design calls on the fly while developing.
I think it all boils down to the necessity for all members of a team to respect the work of the other members. I know we do that, but it is interesting to see how much passion your post brought out.
___________
In terms of the definitions, people often refer to the front-end and the back-end of a website, but that does not mean that a front-end developer works on the front-end of the website and the back-end developer works on the back-end of a site. Back-ends (or signed-in states) of websites have front-end (or user interface) components to them. And modern front-ends of websites are dependent upon the back-end infrastructure. All parts of the site, therefore, needed to be created in collaborative way using a whole range of skills, including what is often divided between designers, front-end developers and back-end developers.
OK. Now I sleep.
January 15th, 2009 at 10:05 am
[...] Boutell What the heck is a front end developer? Posted in recap [...]
January 15th, 2009 at 10:59 am
Tom,
I’m one of the design presenters the other night. I don’t think there’s anything you should have done to your presentation – the right people were engaged. Maybe separating tracks would help refreshphilly, but it would also encourage the barriers that currently exist.
No need to echo many of the statements in the comments above. Many years ago I walked in the shoes of a developer, but at the insistence of colleagues with more talent in that arena, I stepped away. I do think it’s important for anyone in the design world to have some experience in the development world so they can understand the constraints behind what they’re doing.
I believe that good UX design focuses on users, but good UX designers HAVE to learn the Whys and Hows of the systems they’re designing for. Otherwise, they’re perpetuating this stereotype that designers and developers have to be in conflict.
Thanks for a good presentation and for the insight above.
January 15th, 2009 at 11:07 am
Here’s front-end/back-end from a QA standpoint: if the bug deals with things that you, the tester, can see displayed (or a program crash, which is typically a display crash on your computer alone), it’s a front-end problem.
If the front-end is displaying as it should and you an interact with it as you should, but the data it is displaying is a problem/wrong, or if the whole network crashes, then the problem lies with back-end or with the content people. Usually content. But the best people to determine if the issue was truly a front end problem, or a problem where the back-end wasn’t sending info properly to the front-end, are the front-end people. Ah, process of elimination. So yes, they all need to have at least a basic understanding of all the layers of a site or program. That said, in a really large project, no one person can do everything, and there’s a large difference between a site designer and a maintainer, and what they ultimately do.
January 15th, 2009 at 8:40 pm
I’m a Front End Developer! A Senior one, even
Every company that has hired me to do front end development, freelance or permanent) has expected me to do the following, at minimum, *exceptionally* well: HTML, CSS, JavaScript.
I am also required to be proficient in PHP, ASP.NET, JSP and/or ColdFusion at any given time. This includes writing original code, not just modifying it.
Very Very Often, I am required to at least know how to modify graphics using Photoshop or QuarkXpress.
I have also been employed as a Designer, specifically because I have the skills to take into account the constraints of actually creating the layout as presented on top of creating kick-ass UI.
I have also been employed as Programmer, which involves no UI, graphics or DHTML. This “programmer” definition is actually what gets me, because while I can code, I can’t code C or C++ or any of the more traditional programming languages commonly associated with a CS degree. I do not actually call myself a “programmer” despite knowing the more in-vogue programming languages.
front End Development entails “skinning” back end code as well.
Just my view. Been at it since 1999 professionally, after graduating frm carnegie mellon with an ART degree. though taking a break since having my babies
January 16th, 2009 at 10:22 am
[...] friends to talk about where we fit into the Philly design community. The next day, Tom posted an entry on the P’unk Ave blog that began a discussion over the difference between front-end, back-end [...]
January 16th, 2009 at 12:35 pm
Backend would mean to me handling the server and data logic; frontend would be the UI. Whether it’s the admin’s UI or the public UI is, in some sense, a false distinction but ends up being relevant because we’re all going to take the path of least resistance and do little more than tweak the existing admin UI to the extent necessary for a given site’s functions.
In the case of the PHP-based sites you and I build, runtime is effectively whenever somebody loads a web page so there’s little backend possible that’s not tethered to the frontend. In other frameworks there’s more accommodation for decoupling things like data management from page building, and that’s what I think of as backend development.
I’ve been on projects where I develop the UI based on the designer’s direction and programmer’s input, but it’s an unsatisfactory relationship. When I can work directly with the template during development of the framework, the site tends to work a lot better.
The projects I’m involved with tend to involve close collaboration with the designer, editor and developer; the designer gets frequent feedback from the developer while the design’s in progress to ensure we don’t collide over what’s offered and what’s possible within the budget. I can do design, the designer can do some dev, and I think shared backgrounds of that sort are vital to make good, usable work, but at the same time it’s also important for team members to have deeper specialties and clearly differentiated tasks.
January 23rd, 2009 at 10:00 am
Definitely agree with Art, Allison, et. al. that a front-end *developer* builds and designs things used by humans, and back-end developers build how data gets from one place to another so those humans can get stuff done.
But if that front-end developer or designer (usually I refer to this as the presentation layer, rather than front-end, particularly with the advent of asynchronous data exchange) doesn’t know how to handle state changes or meaningful alert or notification messages, or the right way to lay out a form, the whole app can be hosed even if those gradients look like lickable candy.