I felt that the author kind of mixed up front-end engineer and graphic designer. Good front-end engineers(developers) are not necessarily good graphic designers and vice versa.
I am a computer science graduate and front-end developer with four years of industry experience and I started it around 10 years back as a hobby. I do some graphic designing too but my strong domains are html,css and javascript. All of them are self-learned as the author has mentioned.
Wherever I worked, I hated the fact that people kind of undermine the importance of front-end. They bring in some software engineers and make them work with me. Everyone thinks they know html and css and its pretty easy.
Since there are no way of measuring the quality of their code, I get really frustrated seeing people undermine my domain. Even with this much of experience I feel there is so much to learn and so much improvements can be made.
It was more in reference to large enterprise apps, the one in mind combines 4 formerly separate, disparate apps, a mail server and a file manager into a single install, and doesn’t have any bearing at all to what an actual workflow is. Each Ext tab basically dumps the contents of a database out, or loads an iframe that contains a different install’s instance.
As an front-end engineer, it pains me to see some pixel perfect thing of beauty that a graphic designer has whipped up in Macromedia, with the most $deity-awful pile of auto-generated crud backing it up, with no considerations for usability, or feasibility of making it work on multiple different browsers.
Even getting something close to looking the same across multiple browsers and resolutions is a herculean task.
So yeah, you pooped out something pretty. Well done and all that. Now the hard work begins, polishing that turd until it is dynamic (i.e. loads the appropriate data), usable and accessible.
Get yourself some potty training (e.g. roll the html by hand) and then we'll talk about respect.
I agree with how you assumed he got the two "fields" messed up. I learned adobe first, then html and css, now im learning ruby(programming in general too) and rails / javascript.
There is so much to learn. I am learning the "stack" out of necessity in the "do it or shut up" startup world but I really am amazed how a small amount of others seem to tackle all of this with a high quality level. There really is so much to learn. Not to say that serious coders don't have their work cut out for them but the depth and time and SKILL necessary for even less than great mastery is astonishing. I salute you all who seem to flow gracefully in this "expect everything" world.
I think it was pretty clear he was not talking about graphic designers. Why would a writer or musician make a good graphic designer? They may or may not, which is not the point. What makes your artist types good at front end are the things that come with the practice of any art: rhythm, composition, juxtaposition, etc.
Article is funny in a funny way: it kind of gets the gist right, but every single point is debatable.
#1: same applies to back-end too.
#2: why not? And why is that front-end is specialist and back-end is generalist? This point is very weak, and I'd say that the main problem with back-end specialist coming to front-end is the tendency to dismiss it as "easy".
#3: I have both. And prototype. Good JS developer does not make good front-end engineer. Experience with popular frameworks is a plus. Also, if you know jQuery you will know your CSS selectors—that's a plus.
#4: Author has a point there. I'd not say good F-EE must be an artist, but a good taste and design sense is a huge plus:
with those qualities one can see misalignments, broken rhythm, stray font, etc. without the need of designer to point at that.
#5: Wrong. A good front-end engineer must be able to operate those three separate layers: structure (HTML), presentation (CSS), behavior(JS). There is very little of that in print, not to mention other qualities that fundamentally differ.
>>#5: Wrong. A good front-end engineer must be able to operate those three separate layers: structure (HTML), presentation (CSS), behavior(JS). There is very little of that in print, not to mention other qualities that fundamentally differ.
Nah. The original point of #5 was
If you want to find good front-end engineers, look to the newspaper and print industry.
This is because every design -- print or graphic-- needs a logical FLOW, visually. People who migrated from (or started in) print know this, and it ultimately makes the end user experience better. Knowing the three layers is obviously necessary, but I don't think that's the point the author was pointing out with respect to that data.
You are welcome. Must stick up for print people; my design career technically began in middle school, on the yearbook staff. It is hard to forgot those basic fundamentals when they are drilled in so young. Even today I spend far more time pondering pixels, margin widths, font sizes, fonts, padding, etc than any normal person should.
CSS (presentation) - InDesign has style-sheets as well but they are different in some fundamental respects.
JS (behavior) - Using fundamental design rules a designer can have a measure of control over how the viewer "behaves". Dynamic white space, focal points etc.
I think any print designer can be a good front end engineer if they have enough desire to do so.
A div with an id of 'slideshow' contains five images, the first of which is shown and the others are hidden using a display style of none. Using Javascript, create a simple slideshow that cycles through the images, displaying each image for three seconds at a time, looping back to the first image when the end is reached. You cannot use jQuery or any other library.
Instead of asking something easy, with a completely unrealistic caveat that makes it tricky for people who think that the "library" was actually a positive invention, why not ask something not easy.
It sounds like you're looking for people who spend their time writing garbage like
The point of understanding the fundamentals of DOM means being able to adapt when the library abstraction you are using leaks. We are not in a state where libraries have effectively or completely abstracted DOM and BOM, so sometimes seeing past the library is necessary.
With developers who can't tell the difference between jQuery and JavaScript + DOM, that is a barrier to being an effective developer.
I agree with Chris here - I wince a little bit every time I see a candidate start off on the whiteboard with a dollar sign.
However, this article emphasis on Javascript at the expense of the other technologies and soft skills that make a truly excellent front-end engineer - HTML/CSS, solid understanding of SEO, Accessibility (WCAG/508/WAI-ARIA), etc.
I've interviewed plenty of front-end engineers who breezed through a similar no-framework javascript question, but fell to pieces when I had them hand-code a three-column, fixed width, centered layout in HTML/CSS (nav/content/sidebar) with the stipulation that the content column appear first in the HTML source.
These candidates also tend not to know:
- What rel="nofollow" means
- What WAI-ARIA is.
- What browsers were affected by and how to trigger Quirks Mode.
- The difference between PNG-8 and PNG-24
Front-end engineering is a holistic discipline that demands a wide array of skills across a big chunk of the spectrum between back-end developer and visual designer.
Overemphasizing Javascript skills at the expense of others is a dangerous precedent.
Proper front end engineering PRODUCES measurable, testable, predictable, reproducible and stable solutions. If you're calling yourself an engineer, you should be able to build a full application client side with separation between the business logic, communication, and display code. If you're writing untested spaghetti jQuery all over the place without at least writing custom extensions, I object to you calling yourself an engineer even if you can bang out a marketing site in no time flat. Call yourself an expert front end developer with my blessings.
I know plenty of people who, even with an engineering degree, call themselves a front-end developer. I think to a lot of developers, whether you call yourself a a developer or an engineer or whatever else, is a personal preference.
If you go work with some real engineers (mechanical or electrical) you will be quickly disabused of that notion.
Engineering is a mindset. Engineering is a more mathematical approach to the coding (e.g. thinking in terms of theorems and proofs, and being aware of what your fundamental assumptions are (and being able to challenge them)). Engineering is someone else being able to pick up where you left off if you get hit by a bus. Engineering is kicking the tires before you give that live demo. Engineering is beating your own code to within an inch of its life. Engineering is about divide and conquer. Engineering is referring to problems with the code as defects and not bugs (calling it a bug is distancing yourself from it, as though it crawled in there by itself; calling it a defect is taking responsibility).
Engineering is best in life. Engineering is crushing your defects, seeing them driven before you, and to hear the lamentations of the testing team (because they're bored because everything works perfectly).
Engineering is listening to someone talk about the wonders of TDD, Unit Testing and Automated Testing and thinking to yourself, "that's a nice start but you've got a long way to go kiddo".
====
To be a developer is to sit in a circle, giving each other Dutch rudders, and go on about how Agile you are.
====
I'll take one Engineer, or someone who is keen and teachable, over a dozen 'developers' any day of the week.
While I understand your point, I feel like mine was missed. Perhaps I should have worded it differently. The fact is, the web is a constantly evolving ecosystem that as a front-end engineer, you do not get much control over. Yes of course the code YOU produce should be predictable and stable and so forth. However, at any time, the rug can be pulled out from underneath you by a browser update, the uptake of a particular device (e.g. iPhone), etc. When you are working on a website where the WebKit nightlies compose more of your traffic per day than most of the sites on the rest of the Internet get in their lifetime, you have to be extremely flexible in your interpretation of what a successful feature looks like when applied across the board. I do not feel that one faces this same level of constant uncertainty in backend environments where the engineers have much more say in what is running their software.
The wonderful and terrible thing about front end development is that it's hacks built on hacks. Really pushing what browsers can do requires the acceptance of this and the willingness to put in even more hacks so you can package a relatively leak-free abstraction. It's that creation of abstraction that marks front end engineering and what we should be striving for. I work at a web shop of 30 where we have a dozen people who fit the criteria in your article more or less exactly...and they're our designers. What separates our front end developers is bringing algorithmic efficiency, knowledge of browser internals, separation of concerns, development methodologies, testability, etc. to the code our designers write. It's accepting and working with the instability while knowing and building towards the stable that makes front end engineering what it is. That and the intricicacies of how browsers interact with the standards and a working knowledge of the design disciplines.
I think the point where we can meet is that it's easier to teach a good web designer+beginning programmer enough software engineering to be useful than it is to teach an expert developer browser quirks and design.
I think a big part of the reason hiring for the front end is difficult on top of the wide skillset is the discipline didn't even have a name three years ago. I spent years ('03-'06) trying to figure out a job categorization for myself that wouldn't have me doing graphic design or writing stored procedures (I can do both competently but not well). For a couple years, just the fact that I knew "Ajax" opened doors and it took quite a bit of work to wrangle through the various browser quirks but as tools advance the discipline--and people expand their skillset--a much wider set of people have the page scripting skills that were cutting edge in 2005. Similarly, the rise of the second level of javascript libraries (KVO, MVC, MVVM, Modules, etc) will allow more people to build more stable solutions and the general practice will be what's cutting edge today. I expect this second stage will make it easier for the back end developers to transition over, though I suspect the dedicated static language people will continue to have trouble.
Alas, not in the US. I'd at least like to hold to the reduced standard of practicing software engineering if you're going to call yourself an engineer.
jQuery is not good for individuals who want to start out with JavaScript. I recommend people who want to work in the world of JavaScript to know JavaScript, read The Good Parts, read the Rhino Book, etc. Once you've got it down then use jQuery. In addition I recommend reading the source code of whatever library you use to see how it does things.
You could learn a couple of things just by looking the code of others. If you use jQuery you can see the source and find this kind of code in many places. Also:
var x = a || b || (function(){ /* stuff here */ })()
% is the modulus operator. It's the remainder when you divide...so 0 % 4 == 0, 1 % 4 == 1, 2 % 4 == 2, 3 % 4 == 3, then 4 % 4 == 0 again. It's useful in that the result cycles through 0 <= x % n < n.
These are very good points. I fit those requirements almost perfectly.
Self-taught: check
Some college, no CS degree: check
Play an instrument(several): check
Artist of type X: pseudo check (I'm an amateur photographer)
I think it makes sense under those guidelines where when I interviewed with Facebook in 2009, I ended the conversation after 10 minutes with one of their engineers. Completely the wrong fit for a frontend engineer worth their salt.
If I had been more definitive, I would risk making the same mistakes that the people who inspired this article were making. That is, to rigidly define what a front-end engineer is in terms of completely arbitrary constraints. I wanted to provide a set of commonalities that I have found through my experiences, but not to explicitly say "this is what a front-end engineer has to be." A good front-end engineer can come from ANYWHERE and I state that by saying that there are clearly going to be exceptions to whatever I write.
recruiter told me the interview would be just like google's. And i should study classical algos and python/java/C++
Studied it for 4 weeks until the day they wanted to call me. first question was a javascript one where the interviewer wanted me to remember the getElementsByTagName(*) solution. Heck, 4 weeks watching MIT algo classes and reading TOC and doing the exercises in python or C, i couldn't even remember proper JS syntax on the spot!
Think that was one of the most awful interviews i had. got so nervous on that 1st question that i blanked out trhu all the rest :)
back on topic, i got 5/5 on this list :)
1. degree in design related area
2. learned FE before BE (could do a little desktop and embeded before the web tough)
3. Still prefer pure JS for my personal projects (at work it's YUI, and open source contributions are mostly jquery nowadays)
4. Who aren't? :)
5. first job was at a newspaper
Asking people questions that they could look up the answer to online in a couple of seconds is pointless unless you expect them to be doing critical patches to web code when the internet is down or unavailable.
Fundamentally the interviewing process is not a solved problem. So we have flaws in the system. I agree that playing trivial pursuits is annoying, but what else will they do?
Chris Zacharias worked at Youtube right? The hilarious thing about this article is that where he says Front-End Engineers he actually means web designers, and Google doesn't have them. It seems obvious to me that to have a good looking website you need good artists, and that #2 and #4 are such revelations speaks volumes to Google's overall lack of respect for that kind of thing.
Though Developer/Test Driven Design seems to be working out for them.
Web designer != Front-End Developer. For me the distinction is in the use of graphical tools. If you spend your day working in Photoshop for part of the time and you're not just slicing - you're a designer.
The front-end developer takes the design and builds it in code. All of it - code, styles, interaction, etc. There are web designers who are also front-end developers and vice versa, but the roles are not equivalent and they require different skillsets.
I mean what I said when I use the term Front-End Engineer. The people who have built the parts of YouTube that you touch on a daily basis fit very nicely within the traits I have outlined and I would most certainly call them engineers through-and-through. They sometimes have to design elements on a page. They sometimes have to code back-end services and infrastructure. They have to run the gamut between the disciplines of web design and computer science on a daily basis. I would NOT say that Google lacks respect for web design. I am saying that finding people who are hybrids of web design and computer science IS extremely challenging, even for Google.
And who never needs to search for information on Google to develop a feature. I want my whole platform written on the whiteboard first please. No Googling for you.
I am a computer science graduate and front-end developer with four years of industry experience and I started it around 10 years back as a hobby. I do some graphic designing too but my strong domains are html,css and javascript. All of them are self-learned as the author has mentioned.
Wherever I worked, I hated the fact that people kind of undermine the importance of front-end. They bring in some software engineers and make them work with me. Everyone thinks they know html and css and its pretty easy.
Since there are no way of measuring the quality of their code, I get really frustrated seeing people undermine my domain. Even with this much of experience I feel there is so much to learn and so much improvements can be made.