Skew, The Frontend Engineer's Misery | Hacker News Reader

Skew, The Frontend Engineer's Misery

lethain.com

55 pointstwampss9 comments

AP-style news can be dull, but I wish more bloggers would use a bit of the inverted pyramid [ http://en.wikipedia.org/wiki/Inverted_pyramid ] when writing. I wouldn't have clicked if I didn't want to see what the author had to say. But if I can't tell what the point of the post is about after three paragraphs, I leave.

The inverted pyramid is effective at conveying information quickly, but generally essays are not breaking news, but instead rehashing or adding a new perspective to something old. In the later scenario, I don't think the inverted pyramid is as effective.

I have to admit that I was a bit confused, too. i skimmed the diagrams and pictures--good work!--but the text was just not readable enough. </2cents>

I dunno, exactly when did web apps get so frickin complicated that we needed 4 mutually exclusive parties with opposing goals to build them. The skew line graph is hilarious.

I'm not saying that this doesn't happen. I just don't understand why, in the majority of cases, the front-end engineer and back-end engineer (and even the project manager) can't be the same person. We're not building Amazon, are we?

From someone who has written plenty of complex software single-handedly (like many here, I suspect), this looks like a huge case of over-complication for no good reason.

I take on the role of all 4 parties along with various other ones; I have my entire career. I still think there's something to be said for having specific skill sets. A great designer will usually design a better site than me; a great frontend developer will always churn out more elegant Javascript more quickly. As they say, a jack of all trades; a master of none. It probably doesn't take 4 people to build most web apps, but could 4 people have done it better? I think that's the real question.

i see your point, but i'm often working on 2 or 3 man projects with different front-end and back-end workers (as well as 2 and 3 man projects where i'm the only softwarer).

it depends on the project.

i can do both ends, but i much more enjoy and excel at back-end work that supports an artistic front-end developer. i like abstract design not aesthetic design. those are very different things to excel at.

i don't really get "product manager" or really any manager. effective and efficient and pleasant communication between collaborators is crucial, 'nuf said.

Pretty much nailed it. My official job has been frontend engineer for almost 2 years now and he describes all of the most frustrating things about this job. The perception that the deficiencies of the backend can be easily papered over in the frontend is something I fight about on a regular basis.

Absolutely.

My focus is on front-end engineering (Javascript, markup, and CSS), but I've written plenty of PHP, MySQL, and C++. I can say with absolute confidence that back-end engineering is orders of magnitude simpler and easier than front-end.

A lot of front-end engineers come to this discipline without CS degrees. Maybe they used to be designers or writers who happened to get into building web pages, and found some skill with it. There's a popular conception among front-ends that server-side coding is somehow more difficult or mysterious. That's "real" programming, they think.

That idea is 100% weapons-grade balonium. Client-side coding is much more challenging. If you're a front-end engineer operating under the assumption that back-end coding is hard, start spending some time reading the code for the components that you're interacting with. Pick up a book on OOP patterns. Behind the fancy lingo, you'll see it's actually very simple by comparison.

Agreed. The other misconception the author points out about FE engineering being just implementing a design rings especially true with me. Just the other day I caught myself thinking: "Oh yeah, let me see your .PSD file make that convoluted AJAX call, Mr. Designer!"

Reply on news.ycombinator.com