I tried calling myself an 'Application Developer' once before, and it lasted about 5 minutes, because I suddenly started receiving requests to build people's iOS/Android app ideas.<p>I never called myself a back-end developer anyway; if people ask me what I do I just say 'I program computers—and yes, it really is that general'.
No.<p>“The border between the server and the client has faded”<p>So why continue to use distinct job titles? I think ‘web developer’ suffices; the specific skills you can bring will vary from person to person, but you should be fighting <i>against</i> being pigeon-holed, not embracing it by voluntarily saying you belong in one category and not another.
Yeah, I'm not really feeling the persuasion here. I really don't know many "frontend developers" or "backend developers" to begin with. I know plenty of people struggle writing maintainable, well structured applications or who don't grasp front end concepts/technology enough to really produce anything production worthy. Those people are still "my peers" first and I typically consider their title to be "software engineer" or possibly "web developer". The individuals lacking a grasp on front end technology probably need to <i>learn</i> just as well as an individual with great front end skills needs to learn the rest of the stack. We're so heavily coupled now, in terms of squeezing performance out of an application and the ability to iterate rapidly, that throwing a bunch of backend logic and/or API's over the wall to "UI Developers" is probably not only a waste of time, but detrimental to the process. Throwing code over a wall is usually what happens when two distinctly different types of engineers are in the same product and avoiding it is tricky.<p>All this opinion of course is coming from someone who has managed to develop design, UI/UX, and a programming skill set and I'm probably pretty biased when it comes to pidgin holing people into a single role. Having said that, this proposal really smells like an easy way to "be lazy" out of a responsibility in the project. Dismissing a UI issue by surrendering, "But I'm the Application Developer, I don't really do UI" sounds like the more common scenario in the roles you're proposing. The reality is, if you want to keep working on web-oriented applications, you might need to grasp a bit of both, or at least some of each and a lot more experience in either direction(e.g. learning the full stack and then taking a deep interest in hardware performance WRT application profiling).<p>Good luck with your ambition though, I'm sure if you can make it popular the industry won't care about how I feel .
Nope. OP proposal corresponds with nothing i have done last 3 years. I'm and was a front-end developer and i code everything in browser - UI, logic, architecture, everything to the last drop. The other's in team are back-end developers and they code everything at the server, whatever the server then outputs, also to the last drop. There was and is a very clear line between of us and the titles explain exaclty the roles we play in team.
Zed Shaw already solved this problem: <a href="http://programming-motherfucker.com" rel="nofollow">http://programming-motherfucker.com</a> .<p>What made programming great (before the Douchebag Invasion came in and we were divided into these stupid warring camps) is now what makes "data science" attractive: the generalist flair and the ability to pick your projects and move around the economy by your own sail.<p>By the way, I personally hate the term "software engineer", at least as commonly used. It sounds Corporate and I feel like I need a shower after I say it. Genuine software <i>engineering</i> (like, what people who build rockets do, where attention to code quality is <i>critical</i> and people actually consider <i>proving</i> code) is actually very important, but you're only an engineer if you have professional autonomy. If you answer to managers and build CRUD apps to support their careers rather than your own, then you're not a professional.<p>Right now, most of us live under a worst-of-both-worlds regime where it's not clear whether we're genuine professionals, entre- or "intra"preneurs, or glorified labor. Of course, this allows management to frame-change freely among all of the possibilities depending on the specific negotiation, leaving us with the bottom of each possibility.
I personally would prefer to see this divide:<p>- Product developer - implements the functionality, from the database to the functional UI. Lives in Ruby/Python/PHP/etc. AND Javascript<p>- UI designer - creates and implements visual designs. Lives in Photoshop and HTML/CSS<p>- Dev Ops - maintains the infrastructure, optimizes resources, manages deployment. Lives on the command line<p>Of course, all these rolls have crossover. And hopefully that's a good thing, your team shouldn't be segregated by knowledge barriers.<p>A big problem I see is that "front-end" is right now defined as "HTML/CSS/JS". Being good at the first two is a completely separate skill from being able to write and design software in a programming language like JS. I see much better results from designers who can deliver built templates than I do from those who can just deliver photoshop files
I feel so many articles on hn have a myopic view of software architecture. You see this with "full stack" engineer job postings. The desired skills are usually something like RoR, ember, and backbone. I'm sorry, but from my perspective, that is all frontend development. This article refers to backend developers as "sending only a HTML document as a result to the browser." Again, in my world, if your sending HTML, mostl likely that is frontend.<p>Backend has nothing to do with HTML or any presentation logic. Backend is services.<p>I know this is a rather unfair judgement but so many articles seem to indicate RoR+JS/CSS+DB is the "full" picture of software architecture. But really, that's frontend. There is a whole beautiful world of backend distributed services missing.
Eh. I just say "developer". I don't just work on back-end stuff; I don't just work on web stuff either. Nowadays you end up being "full-stack" (or "jack-of-all-trades-master-of-one-facet") for the most part, at least here in Brisbane.
I don't think that "UI developer" is actually all of what the front end people do. There is often a good bit of application code going on that they take care of.
If only it were so simple. And if you think it is that's probably because you don't understand.<p>Frontend often is WAY more than UI. When you are building a client/server application frontend can be far more than UI. Take Call Of Duty for an example. UI is not appropriate for all of the Client side development.<p>Take Google Now as an example. While most the heavy lifting is on the server, the Frontend is also doing data gathering, and calls to the Database on the phone that stores contacts. So a lot of the frontend is not UI.<p>For our TLDR Plugin for chrome we started out using Readability.JS and when that needed tweaks we ended up moving to server side readability. But before that, much of the Backend logic that we had been using for our search engine was being put in to the client ported from Python to JavaScript. That was not UI, but was very much frontend.<p>I think the people who want to name Frontend developers UI Developers tend to be the people that think that Building HTML is development rather than Design and Implementation.<p>True Frontend is about making appropriate decisions about which things live on Client and which live on server.
My own opinion - If you can't write code for the frontend OR the backend then it's not the frontend / backend part that is a problem with your title, it's the developer bit....<p>And that's not meant to be a criticism of anyone - if you are a good programmer you _can_ write frontend OR backend code in any language - maybe you just haven't done it yet. So why is it part of your job title? At best it should be in the prior experience section of your CV.<p>Code is code. At the end of the day it's all 1s and 0s. Don't limit yourself.
I hate titles, sure, it does look more fancy. Besides, you can have frontend only applications written in javascript. Would that make me just a 'UI Developer'? I can go on and on, but just stick with a title that explains your skills the best. I can't stick a label on myself. I dabble in a lot of fields.<p>I don't disagree with all of your points however. People should just make up their own title that fit them best.
My employer uses the term "UI Developer" for front end roles, and I've seen that become increasingly common. But I think there are a different set of expectations that come with that title than "Front End Developer." The most prominent being greater facility with JavaScript.
UI is an extremely important part of applications. In that sense, frontend developers are building the application as much as backenders.<p>Also, UI seems to exclude UX, which is typically also something frontend developers do.
Learn them both ... otherwise you're either tasting electrons with C or you're a graphic designer.<p>{{ <a href="http://i.imgur.com/pG3q7.jpg" rel="nofollow">http://i.imgur.com/pG3q7.jpg</a> }}
I'm down. I also hate saying "frontend" and "backend" too much. It sounds kind of dirty. "She's working hard on the frontend while I try to find these holes in the backend!". I always have to pause before using these terms to see if the sentence will be funny.
In some cases all the intelligence is behind the RESTful interface, and, so, that's what you could call "the app." In other cases, like synthesizing traffic and bus location data to predict when the bus will arrive, the "app" can be in the device, especially when there is no Web interface presenting the same synthesis. Games can be entirely in an endpoint device, as can any complex application that cannot depend on pervasive connectivity.<p>Needs more thought.