Hacker News Reader

Comment by chrisabrams | Hacker News Reader

What I find most interesting is that the majority of these technologies did not exist or were in their infancy ~7 years ago when I first moved to Silicon Valley. Looking at this chart must be much more intimidating for a young developer today.

I remember a decade ago when a front-end developer meant you handled HTML/CSS/JavaScript/Apache/PHP/MySQL. Today, there are 15 forks in the road all leading to different paths as a front-end developer.

View on HN

And you can never be sure what questions will be asked from you during an interview, especially, since the only thing job description says is "Rockstar frontend Engineer"

*rockstar frontend engineer with 10+ years of experience.

How many of those have you done? It's usually basic JavaScript / CSS / HTML / responsive design, performance, accessibility. You don't hire a plumber by asking him about the make of his hammer.

You don't hire a plumber by asking him about the make of his hammer.

You might if all the nails you have could only be used with a certain make of hammer and if learning how to use a different hammer efficiently could take several month.

Let's not get carried away, but that's the result of your own choice to accept vendor lock-in. Like having to hire only authorised service providers. Most companies I've known are smart enough to avoid that and just hire good generalist developers, and the interviews will be shaped accordingly.

I've been using this exact analogy the other way around about hiring in IT. First screening is usually some HR drone scanning your resume/cv for buzzwords.

HR: So, I see on your resume you have been building houses for a decade. This is a good foundation for the work we are doing. Applicant carpenter: Yes, all sorts of houses. Done both interiors and prep for concrete pouring. Fiddled a little bit with wiring on a job where the electrician needed some help. HR: Uhu. Yes. What vendor did you use for your tools? AC: Pardon? HR: Well, we have secured a really good deal on tools from Stanley. Are you familiar with their hammers? AC: (puzzled) uhn, sure. I'm not too sure what I used on my last site. For me a hammer is a hammer. It has to be a really crappy tool not to do it's work. HR: Thank you for coming in. I think you should expect a call from us sometime next week. (marks the checkbox, Not familiar with tools)

Coding is usually based around learning the solution we are employing. It's a very boring problem if the solution is known beforehand. It's now knowing the tools that make you effective, it's being able to learn them that is valuable about a knowledge worker.

> I remember a decade ago when a front-end developer meant you handled HTML/CSS/JavaScript/Apache/PHP/MySQL.

Wait a minute. If front-end developers handled Apache/PHP/MySQL too then what did back-end developers handle?

I used to think front-end means client-side (HTML/CSS/Javascript) and back-end means server-side (Apache-or-nginx/PHP-or-Python-or-Ruby/MySQL-or-PostgresQL).

Check out HN search for "front end development" from 7 years ago:

https://hn.algolia.com/?query=front%20end%20development&sort...

Three pages of low vote threads with the occasional mention of front-end development.

There wasn't much of a term of front-end development 7 years ago. It's a new thing.

You had back-end devs who would do some funky front-end stuff with often atrocious UIs and a bunch of designers who would hack together some jQuery plugins badly.

The highest voted story from 7 years ago is talking about converting PSD to HTML/CSS, which many of us back then would have sneered at being called development.

Yeah, I feel like the notion of a dedicated front end engineer as oppossed to an engineer working with a contract designer is relatively new. A few years ago, I was working contract at MS, and they had this concept of DevOps which seemed so weird to me. It was like a marriage between IT and engineering. Only in the last few years has DevOps come to stand on its own as a dedicated discipline.

which actually gives me some perspective for the speed at which FE tools seem be iterating. I'll have to keep that in mind moving forward.

Seven years ago when I was starting my current job that is what I was doing; which was all of it. From taking design's PSDs to turn them into markup, to programming the back end, and occasionally traveling to the data center to setup servers and networking. The "Full Stack developer plus SysOps" of trades.

My job was not labeled as front end, back end, DevOps, or SysOps. We did not really use those terms that are much more common place today. Just an engineer who was wholly responsible for various web properties from end user experience to server up time.

Thanks.

In which case OC is still wrong. It's not that "a decade ago when a front-end developer meant you handled [X, Y, Z...]" but "a decade ago there was practically no such thing as front-end development, only web development...".

It can get quite confusing on the terminology as the landscape has changed so much :O

what did back-end developers handle?

Making sure Apache/PHP/MySQL didn't fall on their face under load and yelling at the front end guy to optimize his bloody SQL queries. At least that is what I did.

As a young'un myself (u/g senior), I think the more disturbing thing is that I see stuff that's missing (from front-end alone: ES5, ES7, Babel, Selenium, service workers, deferred dependencies, accessibility, Backbone, UI/UX, polyfills, and generally YAGNI/KISS to remind people that there are few things on the web that actually need to be SPAs).

Fortunately I have no desire to do front-end work.

As a young developer, it really is intimidating. Hard to know where to even start these days, it's overwhelming.

Does 28 still count as young? I've been doing some form of web programming for 8 or 9 years now and it's almost impossible to keep up with JS/Node/NPM/100 different poor re-implementations of 'make'. Luckily there are big enterprises that provide job security without chasing every new framework.

I'm 28 myself, with experience primarily in web and ETL. I'm finding that even the big orgs are doing buzzword fishing on their jobs descriptions. MV* frameworks for largely static sites and data sets, served up to small, internal audiences, etc.

Strongly weighing my options for moving into another space such as embedded systems or DSP, where the problems are a bit more tangible.

These days I made a project as a test for a job.

It required a SPA framework, I am pretty much used to Backbone but wanted to use this opportunity to check how are the new shiny things these days. So I picked up Vue.js

The architecture is pretty clean, minimalistic and well thought. Soon I realized how terrible documented most of the tools on js land are these days, it was very frustrating to see that most of the options are not well documented, so that you must find a suitable blog post or tutorial from someone that is used with all the quirks.

This is not to say that the issue is with JS itself or it's ecosystem, it may be or not, but this little anecdote is what I can share from this experience. I hope this is just an exception.

It doesn't really matter very much where you start. Pick something and dive in. Once you feel very comfortable with that, add another skill.

Personally, I'd suggest learning a programming language first: Python, Javascript, and Ruby are all good choices. Find a book you really like in one of those languages and read it cover to cover.

PS: https://eloquentjavascript.net is great, and free.

If you want to go with python, http://openbookproject.net/thinkcs/python/english3e/ followed by http://chimera.labs.oreilly.com/books/1234000000754 are both free and teach good habits on the way to backend web development.

I think this is the link for the site of the last edition of the 2nd book you mention http://www.obeythetestinggoat.com/

What a wonderful name for a programming book.

I actually bought a plushie goat and keep him on my desk.

You don't need to learn everything on there. Also, while some company may use/follow x (especially CSS methodologies), from what I've seen it's usually a poor attempt making it a lot easier to pick up.

I highly agree, and have strongly voiced "keeping things simple" with:

1. HTML4 (no special/new tags) Edit: CSS, of course (unfortunately, CSS is a pain to learn though, so get a lot of experience/experimenting)

2. Pure ES5 JavaScript (don't waste time with build-steps/compiling JS, that defeats the point/purpose - or if you want to, learn a language like ClojureScript or Elm/Haskell)

3. jQuery to manipulate the DOM (skip frameworks and stick to libraries, this will force you to actually understand JS rather than being a copy-paster. Once you have this down, build your own personalized framework to abstract things away, only then should you try experimenting with Angular/React, etc. others)

4. Notepad++ or Sublime (avoid using any terminal tools, including NodeJS, until you are comfortable with having a browser and an editor open side by side, and refreshing when making changes. Keep it simple: just files!)

5. NodeJS or PHP, GitHub for Desktop (learn basic command line use, but if something takes you more than 20 minutes to figure out, seek out a community/forum/help that is friendly and encouraging to newbs. Don't waste time on channels that make fun of you for not knowing command line.)

6. Heroku (for deploying, and having your page live to show your mom what you built)

I wrote a beginner's tutorial for the first 3 items, it takes between 5 minutes to 30 minutes for people who have only played with a little bit of HTML. It teaches you how to build a ToDo app: http://gun.js.org/think.html , let me know if there is anything I can do to improve it.

CSS needs to be included. CSS is the polish that changes a proof of concept into a presentable product.

There's a number of Show HN projects that I'm hesitant to invest much time in because they look like the author won't bother maintaining them months down the line. Even your nicely made tutorial has CSS. ;)

btw feedback:

* For some reason it wasn't evident to me that the left black box was editable and I actually interacted with the right-side wondering why nothing was happening. Perhaps use something that doesn't have an interaction so I don't try to click the button at first glance.

* Found myself scrolling up and an down a lot to read the next few instructions and updating the code. If things were side by side, this would be easier.

* It'd be nice to step backwards for the instructions

* The pre-formatted code in the instructions is a bit small. Might be hard to read for some people

Oh you are so right, my bad, CSS of course - updating my original post, I just blanked.

Those are good points - I need to figure out how to fit the instructions in while still having space for the editor and others. And yes to the others, I'll try to get them incorporated. Thank you!!!

I would happily pay a consultant $300 an hour to do the CSS for my websites. I imagine someone who specialized in CSS could do in 10 minutes what would take me several hours of googling and hair-pulling frustration.

I wonder how many can work in CSS these days? The proliferation of CSS frameworks/compilers is nearly as bad as javascript.

How can I apply?

I will do this for you in one-hour minimums. Just send me the list of wants and the git URL+creds or tarball/zip. Contact me through any channel, satisfaction guaranteed.

For #3, I say skip jQuery and go with Vanilla JavaScript ala https://javascript30.com

Every green browser have pretty good JavaScript support. document.getElementById will be your friend.

This looks great!! Will have to peek at it more myself.

As you can tell, I'm a vanilla fan myself. Although I do think the DOM is still unnecessarily verbose - that aside, `innerText` still is not cross browser, so for that reason alone I recommend jQuery `$("#id").text("foo")` to discourage use of `.innerHTML` :( .

To my mind, using innerHTML is far better than including a 32K library just to avoid using it.

Why is innerText not cross browser? According to caniuse it's been in every major version of every popular browser for over a year.[0]

[0] http://caniuse.com/#search=innerText

Oh hmmm, I thought I tried it just the other month and it wasn't working. Maybe I hadn't updated IE, but I thought it was the whole Edge/11 split problem. Thanks for correcting me!

This is especially true if you want to apply for a job some day. Programming interviews are going to expect plain old javascript, not a framework-oriented approach. More importantly, jQuery is a tool. Know what you're making before you bother with a tool that makes it easier.

Not the programming interviews I've been in (on both sides).

I agree with you. Though, call it HTML5. CSS3 is OK, but so are Html tables. JS5 is lean and fine, I don't need the class syntactic sugar.

Echoing others here, definitely just pick somewhere and get started. Spending time worrying about making the "right" decision is the worst thing you can do. I made that mistake when I was teaching myself and it cost me a few weeks until I finally just picked a language and went with it.

The most important skill is to brag about using a javascript framework that no one else has heard about in order to make everyone anxious that they are has-been already.

Front end doing MySQL? And PHP?

Isn't that full stack?

Is that a sign that the good kind of consolidation hasn't happened yet or are all of these competing systems justified?

Reply on news.ycombinator.com