Hacker News Reader

Comment by grayrest | Hacker News Reader

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.

View on HN

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.

Needed to look up the term 'Dutch Rudder'. Was quite surprised what it meant ;)

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.

In quite a few places if you're calling yourself an engineer you need an Engineering degree.

Just saying.

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.

Reply on news.ycombinator.com