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.
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.
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.
Thanks Steve, these are wonderful points. I agree about the style and like the way you mention the conversation style interview. In a company I used to work for, we'd make sure to invite the candidate to team lunch too to feel out the group chemistry, and instead of using conference rooms, when we had time, we'd take them to a nearby coffee joint next door to give it a more casual feel. I'd personally prefer a non-Q&A oriented method and feel coding challenges can only uncover so much. Thanks for sharing your thoughts!
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've suffered years of non-stop spamming from linkedin.
"Your friend Bob from India wishes to connect with you". "Reminder, your friend Charlie from Canada recently invited .."
I've received hundreds of unsolicated mails, each of which was junked, binned, and reported.
Recently I started issuing DMCA-takedown notices for content I'd produced which was copy/pasted into their forums/groups.
I will be happy when linkedin ceases operations.
To keep this vaguely on-topic; most of the local friends I know who mention linkedin regard is as a ghetto, something they used to use before they started receiving connections from people they'd never met, in countries they'd never visited.
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 have a very good network, but I only update my profile, I don't write stuff or generate content. I suppose this is where I go wrong. (and what I am supposed to put in content there anyway?)
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."
"crockford himself" has done great things fo Javascript but he's also not the last word on it. He himself admits that some of his ideas about JavaScript were wrong and resulted from his pre Javacript baggage. E.g. The model he suggests for conventional inheritance in "The Good Parts" does not, iirc, actually work as advertised and in any event isn't needed.
The interesting thing to me about JavaScript is that insofar as it lacks "crucial" language features it turns out to provide the necessary tools to build them yourself. Exactly gow do you want inheritance or modules or whatever to work? E.g. While JavaScript doesn't impose a module structure it's very easy to come up with one, and because you build it yourself you can tweak it to deal with your exact needs rather than adhering mindlessly to "patterns" developed for working around the shortcomings of more tightly defined languages (Java, cough)
Java programmers moving to JavaScript seem to write horrible code because the freedom to actually just do stuff rather than build boxes with tiny weird-shaped holes cut in them to package pieces of functionality is so alien.
I wish Python, with its (fewer) warts were as ubiquitous and useful as JavaScript, but it's not, and Javascript is pretty darn good.
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.
The author's attitude really doesn't make it easy to get on board with him either.