Must read for all front-end people

Peter Svensson at Script Uncle has written a very good article on what to expect and how to define a front-end developer.  I have myself worked as interface developer, front-end developer, gui developer, front-end architect, web developer etc etc and I am willing to agree with Peters view on the topic. Today working as a front-end X could be anything, it all depends on what the people hiring you have in mind for today. I really appreciate Peters view on what the expectations are on front-end people when you look in the ads:

Looking at the skill set that the front-end developer should have we find that he or she must be a veteran of all major US armed conflicts since WWII, be able to design, build and fly a commercial airliner, have discovered at least three different cures for cancer (of which at least should have received the nobel price in either of Medicine, Physics or Chemistry) and also be the founder of two or more major schools of painting, including cubism.

It is important the the front-end gets its focus in large projects, and that we do not generalize to much thinking that person A can carry the role of the designer, coder, developer, architect and usability specialist and still do a good job. But on the other hand, front-end stuff is for people who do not understand the complexity of things happening in the back-end of a system. We only do this because we hope that one day we also may write generic server side solutions with xml configuration for creating value objects independent of data source.

The Front End Guy is the Go To Guy – Human Interfaces

I do not know how many of you who work with front-end related tasks on a daily basis, but I sure do. One thing I have learned is that working with front-end related entities makes you connect to a lot of different departments within an organisation. Often this is a good thing, sometimes it is not as good.

A lot of different requirements must join forces in any tier within an architectural solution, but in the front-end, the closer we come to the end-user, more people belive they have a saying on any matter that may arise. This is very positive for the people who have dedicated their daily efforts into working with front-end development and other entities of the front-end (graphical design, interaction design, information architect, etc), because these people tend to get more insight into the product they are working for, because we all know that information is king, and with all these requirements from different departments, the front-end is the place to get to know and learn the core business. One not so good thing about being a human interface for user interfaces is that you sometime have no clear mandate and have to take on the role as a mediator, trying to tie the data-model-requirements together with the business requirements for time-to-market for promotional materials.

I stress that in larger organisations where there are a lot of people working with tasks and issues that effects the front-end, there should be some kind of position with a clear mandate making decisions when too many requirements from different departments start to mix and needs resolvment. This mandate could either be a person, with some kind of service architectural role, or a group of people combining different types of competences within the front-end area touching all involved stakeholders such as IT, marketing, operations etc etc.

Being the front end guy/girl is a good way to get insight into what is happening within the organisation, something that is sought after from a lot of people, but also a pretty quick way to headaches and frustration when you realise that you are sitting on all the information and no clear mandate to do the best out of it.