Live data from Hacker News

The Hubris of Front-End Developers

allenc.com

11–20 of 27 posts

Re: The Hubris of Front-End Developers

#11
post #9

The negative comments about this post by others are interesting; perhaps it's because I'm also a FE Engineer, but I thought much of what you said was spot-on. I've managed to specialize in FE only because I can also do back-end work; I have a hard time hiring other FEs because so many only know jQuery, and a spot of html and css, and I simply don't have room on my small engineering team unless they can supplement mor…

To be an effective FE, you need to understand the whole stack I completely disagree. There are a lot of organizations that completely abstract the front end from the rest of the stack and have only UI developers work on a very focused piece. It doesn't help a UI developer to know the DB schema or the middle tier components. They need to know where they can get the data they need and where to send updates. That's abou…

They don't need to have the schema memorized, but they do need to know the path the data takes from the database to the front-end to appropriately optimize how the front end receives and displays the data; for example, to properly implement Backbone, you want a RESTful API. Is this available (or achievable if not)? You have to know your capabilities in order to appropriately choose a pattern or framework.

You're involved- or should be involved- in coordinating with back-end developers on the interface from the front-end and the back end. The implementation of that interface depends on the structure of the underlying system; different databases, such as document-based vs relational, can have subtle differences in how your interfaces are implemented and effect the flexibility of said interfaces.

Re: The Hubris of Front-End Developers

#12

The negative comments about this post by others are interesting; perhaps it's because I'm also a FE Engineer, but I thought much of what you said was spot-on. I've managed to specialize in FE only because I can also do back-end work; I have a hard time hiring other FEs because so many only know jQuery, and a spot of html and css, and I simply don't have room on my small engineering team unless they can supplement mor…

> .. how the browser rendering engine works, since you mentioned, could anyone point me in the direction of good resources for learning exactly this?

I have enjoyed reading through this resource http://taligarsiel.com/Projects/howbrowserswork1.htm

Re: The Hubris of Front-End Developers

#13
post #9

Earlier quoted context omitted.

To be an effective FE, you need to understand the whole stack I completely disagree. There are a lot of organizations that completely abstract the front end from the rest of the stack and have only UI developers work on a very focused piece. It doesn't help a UI developer to know the DB schema or the middle tier components. They need to know where they can get the data they need and where to send updates. That's abou…

They don't need to have the schema memorized, but they do need to know the path the data takes from the database to the front-end to appropriately optimize how the front end receives and displays the data; for example, to properly implement Backbone, you want a RESTful API. Is this available (or achievable if not)? You have to know your capabilities in order to appropriately choose a pattern or framework. You're invo…

You only need to coordinate inputs and outputs. If you need to coordinate more than that you've probably got a very coupled system. Especially with web services - REST, SOAP, etc. - who cares if the front end is connecting to a Java application or a .Net application? Who cares if what the FE dev is building is IOS, Android, JSF, Spring, Flex, etc.?

If it's done right, all the details can be (and should be) abstracted away from the FE.

Re: The Hubris of Front-End Developers

#14

The negative comments about this post by others are interesting; perhaps it's because I'm also a FE Engineer, but I thought much of what you said was spot-on. I've managed to specialize in FE only because I can also do back-end work; I have a hard time hiring other FEs because so many only know jQuery, and a spot of html and css, and I simply don't have room on my small engineering team unless they can supplement mor…

Pretty spot on. I'm constantly bothered by people who are "Front End" Engineers and only want to slap some html/css around or only do DOM manipulation.

Sure, you should do that stuff better than me (back end), but knowing how you are getting your data, where it's coming from, etc will only make you better.

Re: The Hubris of Front-End Developers

#15

The negative comments about this post by others are interesting; perhaps it's because I'm also a FE Engineer, but I thought much of what you said was spot-on. I've managed to specialize in FE only because I can also do back-end work; I have a hard time hiring other FEs because so many only know jQuery, and a spot of html and css, and I simply don't have room on my small engineering team unless they can supplement mor…

Pretty spot on. I'm constantly bothered by people who are "Front End" Engineers and only want to slap some html/css around or only do DOM manipulation. Sure, you should do that stuff better than me (back end), but knowing how you are getting your data, where it's coming from, etc will only make you better.

but knowing how you are getting your data, where it's coming from, etc will only make you better.

How will it make any difference if they aren't actually making changes to the backend?

Re: The Hubris of Front-End Developers

#16
post #15

Earlier quoted context omitted.

Pretty spot on. I'm constantly bothered by people who are "Front End" Engineers and only want to slap some html/css around or only do DOM manipulation. Sure, you should do that stuff better than me (back end), but knowing how you are getting your data, where it's coming from, etc will only make you better.

but knowing how you are getting your data, where it's coming from, etc will only make you better. How will it make any difference if they aren't actually making changes to the backend?

Requires you to have to ask them less questions when you run into a blocker. Helps you debug issues.

it helps you help them design the interface or design an API.

Are you just missing the fundamental point of why anyone learns anything? You learn more so you can do more and make more effective/informed decisions.

Re: The Hubris of Front-End Developers

#17
post #9

The negative comments about this post by others are interesting; perhaps it's because I'm also a FE Engineer, but I thought much of what you said was spot-on. I've managed to specialize in FE only because I can also do back-end work; I have a hard time hiring other FEs because so many only know jQuery, and a spot of html and css, and I simply don't have room on my small engineering team unless they can supplement mor…

To be an effective FE, you need to understand the whole stack I completely disagree. There are a lot of organizations that completely abstract the front end from the rest of the stack and have only UI developers work on a very focused piece. It doesn't help a UI developer to know the DB schema or the middle tier components. They need to know where they can get the data they need and where to send updates. That's abou…

I'd argue in theory, no, but in practice this is often helpful.

For example, I was working on a multi-step activation system where I had to get the user in a certain state no a specific UI element showed up. That required spending 5-10 min. every time to set up that user, which would go away once you use that button, and development would have taken days.

That is, until someone showed me what the Activation schema + model looked like and how to just toggle the boolean or attach an expected relation. You could maybe argue that there should be an admin interface for manipulating model state, but nobody else really would need it: BE devs can already change the models, and business types don't care about this particular state of the user.

Re: The Hubris of Front-End Developers

#18
post #8

I could not continue reading after the author started apologizing for the computer-science-heavy interview . Simply put, if computer science heavy questions bother you, you are not an A player.

Simply put, if computer science heavy questions bother you, you are not an A player. And herein lies the problem - the hubris of a SW Dev. So often the more artistic-leaning FE Dev is interviewed by the more pragmatic-leaning SW Dev. The software dev starts asking questions about recursion and collections and then labels the FE as a terrible developer. What you have to understand is that FE Devs don't care about that…

It's not worse, it's just different.

Many SW Devs are great at creative front end work. Many FE Devs used to be amazing back end Devs. Many Devs don't care what end or language they work in. Those are A players.

If you've just never worked with a single particular technology, that's fine. If on the other hand you have never touched a lot of technologies.... probably not an A player. If you don't know anything about recursion, you are definitely not an A player.

Frankly, I find saying that FE Devs shouldn't care about recursion insulting to FE Devs.

Watching a good FE Dev sling HTML/CSS/JS is a thing of beauty. It's not as easy as a lot of SW Devs think it is.

If they mess up fundamental computer science concepts while slinging JS around, it's gong to be painful rather than beautiful to watch. And I make no claim it is easy. JS in particular is lovely programing language liked by many SW Devs.

Re: The Hubris of Front-End Developers

#19
post #13

Earlier quoted context omitted.

They don't need to have the schema memorized, but they do need to know the path the data takes from the database to the front-end to appropriately optimize how the front end receives and displays the data; for example, to properly implement Backbone, you want a RESTful API. Is this available (or achievable if not)? You have to know your capabilities in order to appropriately choose a pattern or framework. You're invo…

You only need to coordinate inputs and outputs. If you need to coordinate more than that you've probably got a very coupled system. Especially with web services - REST, SOAP, etc. - who cares if the front end is connecting to a Java application or a .Net application? Who cares if what the FE dev is building is IOS, Android, JSF, Spring, Flex, etc.? If it's done right, all the details can be (and should be) abstracted…

My entire point is - who defines this REST / SOAP / "who cares" layer? If it's strictly back-end engineers, front-end interoperability is not represented. A FE engineer involved in the development and maintenance of this API layer ensures that concerns are effectively recognized - which requires an FE engineer who knows the whole stack. Yes, these details should be abstracted away from the strict implementation of the actual FE code, but that API has to be created in concert.

Re: The Hubris of Front-End Developers

#20
HTML/CSS is a small piece of a stack that is fairly easy to pick up. There are hardly ever reasons to hire someone who is FE only (at small companies) and I often find that people who are FE only don't have the kind foundation that would allow them to venture into complicated JS code.

The author seems to be implying that SEs given front end responsibilities will struggle with them but that's only true in the way that they struggle with anything else new (the struggle is short lived because we're talking about markup with quirks).

Also, OP, if you read this, your footnotes link to the original text but it's covered by your huge fixed header.

Post reply on HN