Although there is some solid advice and insight in here, there's also a lot of really questionable stuff. Following a lot of this advice, particularly around self-promotion and navigating within a company, could be very limiting in terms of personal and professional growth.
The author's attitude really doesn't make it easy to get on board with him either.
I know...but there's actually a real gem hidden in there! The whole agile estimation thing is something that seems to trip people up all the time. If you were to blow this out into an article with specific suggestions for improving process, I think you'd help a lot of people.
I've gone through and removed some of the bristly "flavour" language. If you want to scan through it again and look for more offenders I'd be greatly appreciative.
I hear you completely. But understand that my intent here was not to write idiomatic code, it was to write code that an outsider to JavaScript would understand. I worry that the {} syntax, while simple/elegant/preferred, may be somewhat less obvious to a new person who is unfamiliar with JavaScript's object literals. In any event, I've updated the article to include both ways.
Regarding variable hoisting, I am trying to keep this article short, concise, and focused on the big offenders when it comes to gotchas. The only reason I didn't discuss hoisting is because I felt it would introduce too many concepts at once. To me, hoisting is kind of "level 2," whereas understanding why var is required is "level 1."
And on a side note, I appreciate all the feedback you're providing here - I really do. That's why it's on GitHub and not some blog somewhere. But I would suggest that we separate personal attacks from code criticisms. If you don't like my approach with this article or you find something that's flat-out incorrect, by all means tell me. As a human I am prone to make mistakes - maybe moreso than others. :)
But please avoid making value judgments about a person you don't even know, such as calling them an ignorant. It's bad enough when people behave this way on the internet, but if that kind of mentality starts to seep into your "real world" life too, it'll start having serious effects on team relations and employability.
I'm not disagreeing with you in any way, shape or form. JavaScript is an AWESOME language for both productivity and results. But I think we're doing ourselves a disservice if we assume that anyone jumping right into the language is going to immediately understand it.
Like you said, bad code is somewhat inevitable when you drop a classically-trained OOP programming into JavaScript. And that specifically is not a fault of the language. But I think we can all do a better job of pointing newbies in the right direction.
As a UX guy, the prevalence of the Pinterest layout has made me cringe a bit. But I think it definitely has a place, given a few caveats:
1) As others have said, if your site's purpose is more discoverability than navigability, then this layout may work for you.
2) This layout can work if you have the discipline to pare down on everything else. I've found that using Pinterest-style layouts has forced us to really reconsider whether content on our page needs to be there, since everything becomes so prominent. In some ways it's helped us flatten our IA.
Most important thing is to expand your connections. You can only rely on appearing in search so much. Bear in mind that whenever you do something to LinkedIn, it gets blasted out to all your contacts in their activity feed. So the more contacts you have, the more people will see their updates.
I recommend being liberal with adding people you meet on LinkedIn. That's not to say you should be spammy or add people you don't know, but if you meet someone at a conference tell them you'll look for them on LinkedIn.
Once you've grown your network of contacts, be sure to update regularly and with useful content! But not TOO regularly.
Also bear in mind that with LinkedIn, you are catering to working professionals. I prefer to update my profile early on weekdays, because I suspect that'll get my changes to the most eyeballs.
I think if your interview style is very Q&A oriented, or if you are burying candidates under coding challenges, you are definitely in need of some interview training. Sadly, a lot of people choose to interview this way for one reason or another.
I really dislike interviews that rely heavily on academic-type questions that delve into language obscurities. I want someone who can solve problems and explain their thought process. I'm not interested in hiring someone because of their memory for trivia. I have Google for that.
As far as coding challenges go, these can be OK, but most of the time they seem to center around weird logic problems that have very little in common with what a software engineer does day-to-day. They also put people on the spot in a stressful situation, and people will perform quite differently in this light than when they are actually working.
The best interviews I've ever attended feel like a conversation. You are sitting down with the candidate, there is a give and take, and you are talking as if the candidate is already a member of your team. You talk about problems you're facing and how you can resolve them. It's much more comfortable for the interviewee and gives you far better insight into how they'll perform on the job.
I'm a HUGE fan of LinkedIn. You get what you put into it, though. For me, LinkedIn is my online resume - even moreso than GitHub, because the nature of my work prevents me from contributing to open source.
I also definitely care who views my profile, as it can be used as a good icebreaker. Whenever someone interesting has viewed my profile, I immediately reach out to them. Odds are they wanted to learn about me for a reason. Maybe I can help them with something.
I understand where the article is coming from, but I don't agree with this as a blanket statement. There are way too many counterexamples of big companies doing incredible things.
It is kind of funny how responsive design has become perceived as a silver bullet for web design. There are still situations where a traditional m.domain.com approach is better.
Responsive is great if your site is mainly concerned with serving up content, like a news site or blog. But if your mobile users have significantly different use cases than your desktop users (as is sometimes the case with applications), it may make sense to serve up a separate app entirely.
Not to mention that it's still really hard to optimize responsive to the point where it performs as well on mobile as m.domain.com sites
I love JavaScript, but there's no denying that large aspects of the language are somewhat ill-conceived. Crockford himself says this.
Once you know which pitfalls to avoid it's possible to write some really elegant code, but the mere presence of those pitfalls causes a ton of problems when you bring in engineers from other programming languages.
I find it kind of concerning that when someone criticizes JavaScript, everyone's first response is, "he must not have any experience with the language." That's an unfounded personal attack and ignores the crux of the argument.
Look, we love JavaScript, but it doesn't do us any good to pretend it's perfect. It'd be much easier to ramp up new engineers on the language if we admitted its flaws and made efforts to educate "the right way."
I did not put that there because it was the best syntax. :) I put it there because I felt it was most likely to be understood by someone new to the language. I assume you're implying I should have used {}?
I tried not to get too deep into the explanations because I really, really wanted to keep this to a short list that could be scanned and grokked.
Truth be told, if someone wants an explanation of some of JS's weirdness, there are far better articles out there they can Google to meet that need. :)
I really didn't want to write that. Ignorance is never really a good solution. :)
But from my experience, someone who is coming into JS for the first time is probably not setting up a complicated object hierarchy - they're probably just trying to figure out how to bind some events to a DOM element and get some basic UI functionality. And they probably don't need to use the this keyword as much as they think they have to.
I completely agree that this could be a bad decision on my part, or at least a very controversial one. But I'd rather have truly new JavaScript developers focus on things like encapsulation and closures before they get too far into the this keyword and constructor/prototype.
My apologies if I came across this way. The intent was not to whine about var or function declaration, but rather to provide clear direction about a standardized "okay" way of doing these things without causing yourself undue headaches.
So please don't interpret my calling these issues out as whining. Just trying to make new people aware that they are there. :)
If, on the other hand, I am legitimately WHINING and not realizing it, also feel free to tell me where so I can fix it. Thanks!
My only worry is how long it'll take for ES6 to get adopted. It's one thing to write a spec and implement it into the compiler yourself...it's another thing to write a spec and wait for several key browsers to implement it.
The author's attitude really doesn't make it easy to get on board with him either.