On gaining respect as a front-end developer
categories: front-end development, thoughts
Someone wrote me today:
Where I work, design is highly valued with the leader of that group being our Creative Director, back end programmers are also highly valued, but front end ... not so much. Partly I think its that I don't toot my horn but I know there are other reasons. At times, my bosses haven't even understood what it is that I do. Back end programmers look down on front end assuming that its trivial or something that should be relegated to compilers.
I was wondering if this is a common thing or more so something that is happening at my particular company, and if you have any advice or pointers on this.
I thought my response might be worth sharing:
I do think this attitude is common but not necessarily the rule. In my experience, I've found that by having a proven value proposition, you can gain converts and respect.
Front end developers are in a unique position to improve page performance (perceived and actual) by using best practices such as the YSlow tests. Front end developers are also in a unique position to help develop templating systems and to write thoughtful CSS, both of which help enable the rapid prototyping and rollout of new features. A focus on results and best practices -- demonstrating that you aren't just pushing pixels around -- is the key.
Back end developers respect people who think like they do. Be mindful of opportunities for abstraction and reuse. Write object-oriented CSS and JavaScript. Craft solutions that are maintainable and documented. Learn and make use of version control systems. Look for opportunities to participate in developer conversations about new features, and understand what the back end developers are up against. They'll appreciate all of this.
Take the time to teach and to learn. Be sure you have at least a passing understanding of the code the back end developers are writing, and leap at opportunities to share your knowledge. I've worked with more than one back end developer who was surprised to discover what all they didn't know about the front end, and through our conversations about how we approached problems, we both learned a lot.
Finally: identify opportunities for quick victories, execute on them, and make the results known. Benchmark before and after. Can you reduce the number of HTTP requests on a page, decreasing both the perceived and actual rendering time? Are you keeping your JavaScript out of the <head> as much as possible, preventing pages from stalling while rendering? Can you write JavaScript that is primed for reuse, and demonstrate opportunities for that reuse? Has your carefully crafted CSS allowed the rapid rollout of a new feature? Don't be afraid to tell these stories -- they'll tend to strengthen your position by clarifying the important role the front-end developer plays in a site.
Good luck 
April 13th, 2009 at 11:43 am
On one of my current projects, the CDN costs are reaching well past $100k/year. A front-end developer has one of the most direct influences on page weight and can end up saving their employer serious coin.
April 13th, 2009 at 12:06 pm
This is simple. Today, if the value of a client-side engineer is not a known or understood cog in the machine then the machine itself is broken (case study = Yahoo). The most dangerous place to be professionally is working for someone who has no idea the value you bring to the machine/process. What we really should be doing is not educating those who refuse to update their depreciated views (pointless), but educate the clients so that they can hire properly staffed agencies. In most cases hiring an advertising agency (design focused alone) to do web work is like dating a super model with no personality or depth. Yes, she looks hot, but you can’t really take her anywhere or talk to her.
April 13th, 2009 at 1:59 pm
Great article Rebecca!
Excellent points: “Back end developers respect people who think like they do.” and “Take the time to teach and to learn.”
The second point is more important, imho. The more that back-end developers see into what we’re doing, the more they’ll come to respect the brain-power needed.
That said, I don’t think we do enough to differentiate the front-end from the back-end. We get ourselves into trouble using terms like “Object-oriented Javascript” or “Object-oriented CSS”. I guess we do this to try to validate that we’re doing something structured and sensible?
But it’s all a lie.
CSS is so much more powerful and elegant at layout and styling than any OO framework a Java geek could devise in a procedural or OO language.
And those OO Javascript frameworks that mimic classical inheritance are such a shame. Why do we feel that we have to take a perfectly good and extremely powerful model (prototypal inheritance and dynamic scoping) and morph it to the likes of Java nerds? Add optional type safety and the “super” operator to javascript and I might pick it before Java for 90% of the stuff I write on the back-end, too.
Sorry to rant, but I feel that we need to spend much, much, MUCH more time educating the Java geeks. The UI is where things are happening. We’re the ones doing the cool stuff!
Btw, this is similar to the topic I’ll be discussing at JSConf 2009! “Javascript for Java Stoics” Fri 3:30-4:00. Come join me! (Shameless plug, I know!)
April 13th, 2009 at 2:11 pm
I’m going to babble for a moment. Feel free to roll your eyes.
While sometimes infrastructure, available hours, and the demands of the client or employer might defer some of these suggested tasks, implementing best practices as many as possible is a good start to proving your worth as a front end dev.
I personally perch on the precipice of the purportedly picayune front-end programming every day, and very seldom do I feel undervalued anymore.
At a few previous jobs I did feel my services as a JS dev/front-end wiseguy were relegated, an afterthought, an overcoat the dealer really had to push in order to get the client to buy. These companies were focused away from slick Web sites, and that was definitely a large part of the problem. Part of it was that I didn’t care enough about the products/services offered, and maybe I didn’t feel I’d come into my own enough to be forceful when sharing my opinions and making my voice be heard.
I think if you present management with the reasons above why your work needs attention/why you need to be a larger part of the process, they’ll either listen or they won’t. If they don’t, it’s an indicator of poor judgment and you might want to consider moving on to employment where you can make better use of your skills. Only through dialogue will your value be understood.
If reasoning doesn’t work and you are unhappy, consider the alternative and look elsewhere for employment. It may seem drastic, but if your soul as a programmer is at stake and you think it’s an option, that’s what it often comes down to.
April 13th, 2009 at 2:49 pm
That was a great response, Rebecca.
Personal story: Last year I was working at an agency in which one of the owners believed my html/css/javascript work added little or no value and that it could easily be done by anyone. When I discovered his attitude, I promptly left for a better place where the owners respect my work. Now, it could be a coincidence, but my former agency just closed up shop two weeks ago and my current one is stronger than ever.
April 13th, 2009 at 2:56 pm
I think the bottom line is that front-end development has become a much more specialized skill set than it maybe used to be. The problem lies in educating people that it’s more complicated than replicating a PSD with some one-off HTML, CSS and JavaScript. For mom & pop brochureware sites, that might be appropriate, but for sites or applications that will need to be maintained and continuously developed, that route is going to get you in trouble in a hurry.
The thing I find over and over again is that the people purchasing front end development don’t even know what they don’t know; that is, they don’t know the dozens of ways that you can do a front end thing the wrong way, or what the resulting costs of that will be. I’ve been called in more than once to clean up after a project where the front end wasn’t a serious consideration, and I can promise you that the eventual cost of that decision was high.
unscriptable: I think you make a good point that it’s a double-edged sword to start talking about “object-oriented” this and that on the front end. We need a better language for giving our efforts and our knowledge more credibility.
April 13th, 2009 at 4:41 pm
I can echo Karl’s story — many former employers who didn’t value current front-end skills have been suffering lately. Certainly there are other factors at play, but perhaps it speaks to a larger issue when an employer doesn’t embrace *all* of the skills that go into creating a site or application.
April 13th, 2009 at 5:00 pm
Doh! I’d like to retract a statement in my previous post: ” I might pick it before Java for 90% of the stuff I write on the back-end”
I was obviously having temporary insanity.
Javascript needs a heck of a lot more than “super” and type safety to compete with Java on the back-end.
I guess what I really wanted to convey is that Javascript is much more elegant and creative (and dare I say “evolved”?) than stodgy old Java. It’s also much more concise so you can dig right into the fun parts (aka important parts).
Kas Thomas has an interesting article about productivity using more concise languages. I can’t say I agree with it 100%, but it is worth reading:
http://asserttrue.blogspot.com/2009/03/making-one-line-of-code-do-work-of-47.html
April 16th, 2009 at 9:05 am
“Front end” means a whole different thing now than it did even 5 years ago. A client/company perception of the ‘front end’ now includes things like youtube, gmail, flex apps, and such.
In ‘back end’ stuff it’s common to have a distinction between a ‘developer’, and ‘architect’ and a ‘DB’ role. For some reason, all the tech a ‘front end’ person has to deal with still often gets lumped down to one person. A ‘DB’ role only has to worry about one database and one operating system. A front end person still has to deal with multiple OS, resolution, browsers, etc., as well as possibly multiple JS toolkits (or at least learning them enough to whittle them down to one), and may have to be integrating with Flash/Flex apps or dealing with AJAX calls to a back end system. With things like JazzRecord, local ORM may start to be a reality for some projects, yet this still is all getting lumped as ‘front end’, and may still often fall in to one person’s lap.
I was talking about ‘web development’ with a friend the other day, and it surprises me some as to how fluid it can be. On one project, we were discussing XML/XSLT, PDF generation, DB schema and DB performance optimizations, UI considerations, JavaScript toolkits, browser testing, unit testing and a couple other topics. “Web development” as a whole is a fairly broad reaching discipline, and ‘front end’, even as a subset, is rapidly developing enough of an ecosystem to warrant teams and specialists just like the ‘back end’ people have had for a while.
Showing my age here, but back in the days of early 80s computer gaming, there was quite a cottage industry around one-man bands. “FreeFall Associates” made Archon. They were a two-person org, and made a splash with that. Epyx did Summer Games, a landmark game, and it was one of the first, if not *the* first, to explicitly call out the fact that they had a full team of developers, with specialists in sound/music/graphics as well as programming (I think it was 7 people, IIRC). Gaming really took a turn for the ‘team of developers’ model at that point.
Maybe my experience with ‘front end’ development is limited. To those of you who do this more than me, do you typically work with multiple front-end colleagues on one project, or do you handle all aspects of one project yourself (on the front-end)?
April 16th, 2009 at 10:27 am
@Michael Kimsal
IMHO, nowadays “front-end” had spread between client and server in a way that two new parties (with well defined responsibilities) appeared: “client-side front-end” and “server-side front-end”. The “server-side front-end” changed in a way that it has become more Service-kind with main responsibility to bridge “client-side front-end” and “back-end”. Eventually “server-side front-end” can be replaced by a Web-Service (for routing data) and a light HTTP Server to serve “client-side front-end”’s static resources.
April 29th, 2009 at 5:42 am
[...] Loïc le Mercredi 29/04/2009 à 12:42, dans CSS, HTML, POO Via un billet posté sur le blog de Rebecca Murphey (découverte grâce au lancement de JSMag), je suis tombé [...]