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.

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.

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).

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.

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...".

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.

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.

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.

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

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.

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.

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

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.

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

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!!!

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

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` :( .

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

Isn't that full stack?