A Proposal: Renaming Backend/Frontend to Application/UI Developers
theothersideofcode.com
theothersideofcode.com
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'.
“The border between the server and the client has faded”
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 against being pigeon-holed, not embracing it by voluntarily saying you belong in one category and not another.
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).
Good luck with your ambition though, I'm sure if you can make it popular the industry won't care about how I feel .
I think if anything we're less tightly coupled than we used to be. So many projects now have a clearly defined backend API and a separate front-end project. The problem though is that these front-end projects that used to be HTML/CSS with some JavaScript are now becoming almost full-stack applications themselves, with all the nuts and bolts you'd associate with backend projects (routing, controllers, application logic, complicated event handling) now also in the frontend.
In terms of how we describe roles in software, as long as it's from a genuine specific need (e.g. "frontend JavaScript developer") and not just some mix of buzzwords, I don't really see the problem.
The responsibility has less to do with titles, as a responsible developer can and will take several roles in the project if one's capable to do so...
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.
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 engineering (like, what people who build rockets do, where attention to code quality is critical and people actually consider proving 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.
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.
Their jobs have as much corporate-ism and debilitating big management as ours. Perhaps more, since there's a distinct lack of startups in those arenas.
Sure, what they do has a boatload of ethics and standards that apply to it (unlike software, which is still very much fly by the seat of your pants), but they sure as hell don't have a lot of autonomy. Most traditional engineers also answer to managers, and build the equivalent of CRUD apps to pay the bills and get promoted.
I suppose by your sentiment no one is a professional.
Because people who build rockets don't have to answer to middle management...
Read Mike Mullane's book [1] if you genuinely believe that
I know you usually have good comments on HN, but is it just me or you really have something against "management". Anyway, the fact is that everyone answers to someone in some ways when it comes to money which we need to make to survive in this world unless you have family inheritance. Having said that, I am not saying that managers are necessarily the best thing in this world but i don't understand how you can get away without answering to someone. Even if you are a superstar entrepreneur who is his own boss, I have one word for you: customers.
"people who build rockets do, where attention to code quality is critical "
So are you saying that code quality is not critical elsewhere ? I agree in general that many companies have shitty code but there are many places which actually do care about code quality and code reviews are actually important.
"build CRUD apps to support their careers rather than your own, then you're not a professional."
Just think about what you said here.
Essentially, "manager" is a conflation of several corporate needs: (a) mentoring junior hires, (b) protecting the company from bad-faith employees, (c) protecting good employees from bad ones, (d) setting project priorities, and (e) putting a public face on the company (e.g. CEOs). Some of these jobs are more fun than others. There are huge conflicts of interest within what is called a "manager" and ultimately, employees get shafted.
Managers ultimately end up as the internal police force, because they're the ones who make firing and promotion decisions. However, there are a huge number of dirty cops. Most of them, in fact, are dirty. There are a few sadists who enjoy using the badge-and-gun just to fuck with people. There are others (much more common) who go full-on extortionist and use their power to build an image of outsized performance so they can hop out of cop work and into an executive or high-level strategic position. Rare is what police are supposed to be: principled public servants.
I don't have a problem with police. Society needs them. However, if the police started acting like the mob (with them making most of their income "on the economy") then I would. Corporate management is mostly dirty cops.
He's saying safety-critical. Like NASA software. As in, if the code hits an NPE or array out-of-bounds or int overflow, people die. They actually use formal methods which is an exhaustive testing of every possible state the program could possibly enter.
We don't do this for business applications because it's extraordinarily expensive--can cost $100's per LoC.
And yeah, I think the several times daily I see "Microsoft Excel has encountered a problem and needs to close" is evidence that most major software shops have very poor quality control.
Pretty amazing statement from someone whose comments are otherwise among the best here on Hacker News.
1. CRUD apps run the world. They were here long before all this sexy unnecssary stuff and will be here long after these fads pass.
2. Whether you want to admit it or not, everyone answers to someone.
3. Make no mistake about it: if you build anything, you benefit, often more than those you built it for. In fact, to become an excellent programmer, there is no better way. It doesn't matter who you built it for, it just matters that you built it.
4. Literal definition of "professional": earns money. There's probably no better way to be a professional programmer than to build corporate CRUD apps. Looser definition of "professional": someone I would want to march into digital battle with. I would most certainly pick someone who has written many corporate CRUD apps over someone who has recently embraced some sexy new technology from the conference and community du jour.
Fair point. "CRUD" is a straw man. Actually, most apps should be simple. That's just good design. If CRUD is enough to solve the problem, then one shouldn't do more if it compromises simplicity or conceptual integrity.
2. Whether you want to admit it or not, everyone answers to someone.
Sure. What I like about Valve's model is that, yes, employees answer to the company. What isn't there is the middle-management extortion of "since I can fire you, you invest in my career, and you're lucky if I give you a 2-week 'plum' project".
Everyone answers to someone, but the terms are widely variable. We're a lucky set, being programmers. We have skills whereby, if we can solve the leverage problem (as a group, we're poor negotiators) we can deliver so much value to society as never to be poor. Unfortunately, because we are so critical to operations, and because we're terrible negotiators, there's a class of people (VCs, tech managers) who spends as much time devising ways to hack us as we spend coming up with ways to hack computers.
It's the fact of answering to a careerist middleman-- often for little in return, resulting in long-term career stagnation-- not the abstract "answering to someone" of having to deliver value, that makes corporate engineering so humiliating.
3. Make no mistake about it: if you build anything, you benefit, often more than those you built it for. In fact, to become an excellent programmer, there is no better way. It doesn't matter who you built it for, it just matters that you built it.
I agree, but at least in my experience, programmers are lucky if they get to spend 10-20% of their working time on building, and it's rare that we actually get to own and to finish a project.
Most of us get staffed on fourth-quadrant ( http://michaelochurch.wordpress.com/2013/01/01/fourth-quadra... ) maintenance work that's largely evaluative in purpose, while the company decides whether it trusts us enough to give us real work. Of course, the managerial gatekeepers who proctor and grade this years-long dues-paying/testing period use it for hard-core extortion.
I think this problem (of long slogs on evaluative make-work, and projects never getting to be finished) might be the visceral appeal of game development. Sure, it's a horrible industry if you look at the conditions, but unlike much of software, you actually finish and ship a product.
I'm 29 years old and I'm starting to have the experience of getting genuinely rejected for jobs that a top-talent person of my age should be able to get (and that I would be able to get, with better work experience). This is not a case "they're idiots" rejection (a pathetic defense mechanism) or "lost in the shuffle" bad luck, although that happens too. It's genuine rejection that occurs because the quality of my work experience is mediocre. There are a lot of jobs that I would be able to get at this point, had I not drawn a string of bad bosses and shit projects. Now, some of that's my fault: I should have shown initiative and started open-source hacking five years ago. Some of it is not my fault. If I had landed on a machine learning project when I joined Google, I'd be spending a lot less time ranting on HN and more time building awesome stuff.
4. Literal definition of "professional": earns money. There's probably no better way to be a professional programmer than to build corporate CRUD apps. Looser definition of "professional": someone I would want to march into digital battle with. I would most certainly pick someone who has written many corporate CRUD apps that someone who has recently embraced some sexy new technology from the conference and community du jour.
Disagree. The defining trait of a profession is a set of ethics (that one professes) and processes to which one subordinates. For programmers, "don't build logic-bombs and back-doors" would be an obvious first commandment. "Never compromise on quality to gain rapid career progress", i.e. "don't launch and flee", would be a more controversial second one.
When you're a professional, there are ethical principles which you have the right and obligation to place above managerial authority. To make sure this works, the profession controls the economy (a controversial process, for sure) in order to make sure you always have work and your boss never has you by the balls. Professionals can't use the "just following orders" defense. If a doctor's boss tells him to kill a patient, insubordination (against that boss, subordinate to the higher authority of the profession) is a requirement. He loses his license and possibly goes to jail if he fails it.
We don't have the right to tell our bosses, "I won't do that, because it's unethical". Nor do we have the right to expect our bosses to invest in our careers-- and, most often, they don't. Ergo, I'd say that we're not professionals.
In fact, the major reason why I switched out of mechanical engineering into software was because my experience is very much the opposite of how you seem to think traditional engineering works.
> "The defining trait of a profession is a set of ethics (that one professes) and processes to which one subordinates."
This is reasonable. This is what separates accountants, lawyers, doctors, and yes, traditional engineers from software engineers.
The question is how well these ethics and standards are enforced in actuality. The sad reality is, for traditional engineering, not well at all, to the point where the ethical bar for software is frequently higher.
I left the field after working at an automotive parts maker (who shall rename blissfully unnamed) when I saw, first-hand, sub-standard products being shipped deliberately, extreme managerial incompetence, safety standards being compromised, willful disregard of the public's safety, and fraud. And none of this was particularly unique to where I worked.
There are many interesting stories here. Including one where the company shipped a large batch of motors to an automaker knowing full well that all failed QA standards in some way or another, and many were completely defective. When the automaker eventually returned the shipment, instead of replacing them with good parts, the company knowingly and deliberately hired minimum-wage workers to test and pick out the "best" parts from the defective pile, to minimize the amount of manufacturing the company would have to do.
I was also asked, at one point, to find "proof" that a series of car fires were not caused by the company's defective design. At this point it was already obvious to everyone that we were the culprits. Management spent weeks, if not months, ducking this while people continued driving those cars on the road.
I was also involved with a project where radiators were literally falling out of the cars due to cutting corners and the use of substandard materials. The solution to which is not replacement with good parts, but rather shipping dealerships strengthening screws and endcaps, the notion being that as long as the incidence rate was low enough the company can simply afford to settle whatever lawsuits came out of it. At no point was actually fixing the defective parts on the table.
And here we thought we learned a few things from the Ford Pinto.
Mind you, this is a regulated profession, with a well-stated code of ethics. It did no good here - management had employees over a barrel. People were dangerously overworked, both on the factory floor and in the design office, and the state of the auto industry meant that no one could afford to speak up. The whole place stank of the very thing you were originally railing against - people working on meaningless things, working for horrible managers, looking out for their own survival more than the public welfare.
So yeah, traditional engineering does a nice song and dance about being ethical, making it possible for employees to blow the whistle on abuse, that an engineer can just tell their boss to fuck off when something unethical is asked of them.
In reality, none of that truly exists. Traditional engineering, in actual practice, is closer to software engineering than you think.
We don't have the right to tell our bosses, "I won't do that, because it's unethical".
That's not a straw man. It's not inventing a silly example and pretending that it's representative for the sake of argument. It's using negative connotations of something that is actually representative.
Programming belongs on the cutting edge, the place where we build things that were never possible before. CRUD apps are about collecting data, but that problem has been solved already. Now the problem is we have too much data and aren't sure how to make sense of all of it. So the cutting edge is now at building machine learning algorithms on top of MapReduce processing, to automate high-level decisionmaking based on massive, diverse, distributed sets of data. That's where the important "engineer" jobs are going to be.
You may not be a real engineer, but a professional you are.
An extreme DWTF-style example I've seen was a 'CMS' in this style. The CMS was clearly modelled on phpMyAdmin - if you wanted to create a new content type, create a new table and it would be right there in the UI. In this CMS, news articles were the main content type - and they could be linked to other news articles and other content types in the system such as celebrities and events, which was implemented as a simple drop-down for each referenced item when you were adding or editing an article. However, this drop-down for selecting referenced entities was of course reused everywhere - meaning that you had a global setting on whether the items were ordered in alphabetical or most recent.
(Obviously you could code around this particular case, but it illustrates a general problem with the approach. And god forbid you should ever want multiple pluggable storage engines or service-based data sources.)
The only issue with the universal CRUD tool is I have no idea how to market it?
> The only issue with the universal CRUD tool is I have no idea how to market it?
The dynamic reporting thing can be sexy. It would be a great way to sell such a tool. It's like pivot tables, but entirely graphical. It was based on a Smalltalk web plugin when I wrote it. I was going revive this project and make it an iPad app.
This has always been. There is no single Douchebag Invasion. It's just when it hit your particular part of the programming world.
- Product developer - implements the functionality, from the database to the functional UI. Lives in Ruby/Python/PHP/etc. AND Javascript
- UI designer - creates and implements visual designs. Lives in Photoshop and HTML/CSS
- Dev Ops - maintains the infrastructure, optimizes resources, manages deployment. Lives on the command line
Of course, all these rolls have crossover. And hopefully that's a good thing, your team shouldn't be segregated by knowledge barriers.
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 certainly know if/when this project I'm on gets some legs and money behind it and we are hiring, the designers I hire will be writing HTML/CSS ;)
If find to write good JS view code, you need to be able to write html/css yourself. If you are implementing something like auto-suggest, a designer's html isn't likely to be much help. To write the view properly, you need to know how to position the suggest box relative to the input or cursor without interference from the rest of the DOM.
I don't think you can claim to be a good front end JS developer, and suck at HTML/CSS. I constantly find situations like: "how am I going to make this design work if the user name is 20 characters long?... Okay I'll float this, right text align this, overflow hide this, then a long-title plus a long username will automatically push the content down a bit". It is clearly a programming puzzle that needs to get solved by someone other than a designer.
Backend has nothing to do with HTML or any presentation logic. Backend is services.
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.
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.
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.
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.
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.
True Frontend is about making appropriate decisions about which things live on Client and which live on server.
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.
Code is code. At the end of the day it's all 1s and 0s. Don't limit yourself.
I don't disagree with all of your points however. People should just make up their own title that fit them best.
Thanks for your comment regarding labeling, though... I agree that sometimes it's inappropriate, still sometimes it's useful to figure out the kind of work being done under such a label
There is a data-gathering (tier-1) and -mutation (tier-2) backend and a HTTP-front-end to gather this data (tier-3).
And then there is the GUI (tier-4), which is an application itself, with the HTTP-frontend as backend.
The back-end developers work in tier-1/2 The front-end evelopers work in tier-3/4
Also, interfaces are designed in Markup for the time being only, not as a rule for eternity.
Also, UI seems to exclude UX, which is typically also something frontend developers do.
What comes first is "Web App Developer", "Android Native App Developer", and so on.
The post talks about "application logic" as being the backend, but we have plenty of "application logic" in our rich web UIs, so I just don't see it.
EDIT: Changed "rich UIs" to "rich web UIs" to clarify that I actually am talking about the article's domain. Not that the comment isn't relevant in other domains too, though.
Needs more thought.