The capitalization of the word "university", and missing the capital H in GitHub. The "Artificial Intelligence" bullet has a formatting error. Missing articles ("work on project").
Not to mention it is vague. The "Learn other programming languages" bullet lists several options, but doesn't say anything about how unrealistic it might be to try and learn all of those languages (it says "and" instead of "or")
Meaning someone can't see passed what is in front of them (trees/treeline) to see the bigger picture (forest).
One of the (many) problems with this page is that it is geared towards computer science students (see header or URL). Listing 10 languages (with an "and", not an "or") may give a student the impression that he/she needs to add these 10 languages to their repertoire in order to be a successful engineer.
I'd be less critical of the page if it listed "or" instead of "and".
> Academic Learnings
Dead give-away.
I loathe this kind of thing. To me it evokes an image of someone who only knows computer science, and is entirely ignorant of other topics (say, history and literature) that a person needs to know to be a successful human being.
That said, there's actually a tremendous amount to learn on this list, and there are only so many cells to hold information. While it's always nice to say "and yes, also learn history and literature", truth is, eventually you have to not learn something in order to learn these things.
This may be a case where where the extreme rigor of the interview process and tolerance of false negatives may hurt large companies and create an opportunity for small startups and individuals. Here's why - a candidate who is very very talented at CS but also learned history and literature might come in at 90%ile, but let's say it's nearly impossible to come in higher than that without neglecting those other topics. However, the interviewers are all demanding a 95%ile+ performance. As a result, they pass on the more well rounded candidate.
It's even more insidious than this - because they select for the 95%ile, and it is very very rare to be able to achieve this feat without a single minded focus on CS, the people doing the interviewing will be at best faintly aware, and possibly completely unaware, of what they are missing.
Before getting too irritated, though, remember that any blind spot on the part of a large company is an opportunity for a small, nimble one. This is largely what is going on, I think, when you read those stories about talented programmers getting rejected by google and Facebook and coming back 5 years later to sell them a company for 100 times what their salary would have been. Of course, it's a much higher risk path that requires being broke for a while, and may just not be an option for people with other substantial life obligations.
There's this story I really liked about Andre 3000 (sorry, no link, just something I read, may be apocryphal). During an interview, he was asked how he chose the three chords for the song, and his answer was that he was learning guitar and those were the three chords he knew so far. So he took just the slightest bit of knowledge and turned into something great.
I read this at a time when I went to a music store and saw an incredible guitarist doing such impressive things with his instrument that he drew a small crowd. He wasn't just showing off, he was the local instructor. I believe he was also available for small gigs, weddings, parties, that sort of thing.
A lot of companies would pass on Andre 3000[1], and hire the awesome guitar playing dude, because Andre 3000 wouldn't be able to play a Bflat scale on demand or explain the circle of fifths or sight read a medium complexity piece of music at at least 150bpm. And I'm not knocking those skills, if you're a musician, by all means, yes, learn those things. But if that's all you focus on, to the exclusion of more creative things (and there's enough complexity that you could easily do so), you will starve other important things.
[1] prior to the hit. eventually, accomplishments do speak for themselves.
> I loathe this kind of thing
I meant "academic learnings." "Learnings" is not a word in the English language.
When I see writing that is this bad, it evokes, to me, an image of an Indian student who effectively only learned math/computer science/engineering, and does not have a sufficiently broad education to think critically and independently about anything else.
Additionally, Indian students do the best they can given the limited resources (we have). And even when they do have broad education it's not going to be about Mozart and effect of WWII on the western nations - they will always be out of context when it comes to western culture. It's the same kind of lack of ability to think (or express without getting eyebrows raised) about everything else that you might be showing here.
Actually, what it evokes to me is someone for whom English isn't a first language (at least not a mainstream American dialect of English) of but who has domain knowledge writing a guide in English in the domain in which they have knowledge.
It could certainly use editing, but the awkward word choice you point to isn't really something that suggests to me anything about what the person's knowledge of history and literature might be.
This is a reasonable explanation to me.
Its layout is reasonable, and it seems to have a fairly comprehensive coverage of the topic. Its not overwhelming like w3.org. I can find what I want to know with relative ease (unlike w3.org)
I have seen a couple of articles pointing out that their implementation details are bad, but I don't think I have ever gone on there with the intention of clicking "view source"
w3.org is the W3C, the actual organisation that publishes the CSS and XML specs (and the versioned snapshots of the HTML spec).
At the same time, anything I do at that level is probably going to be the exact opposite of portable: it's going to be something I intend to be specific to the exact system I'm writing for (namely, it's meant to run on a specific version of a specific Linux distribution, and possibly even to specifics of the installation on that machine). While I'm not likely to take advantage of many bash-specific features just because anything I write in shell tends to be so simple as to not need them, I'd also be an idiot to eschew useful features like arrays just because they're bash extensions.
In my experience shell scripts are fine for starting (and restarting) various programs and daemons or as thin wrappers around other apps. Beyond that I don't see the point. There's nothing other languages won't do better.
I've seen many "small bash scripts" grow up to thousands of lines, adding features one by one. And then you have to maintain that mess that catches fire every time an unexpected condition occurs because error handling in shell scripts is a joke.
That's not to say I wouldn't use it... it's actually my preference, and I've used npm for stuff that isn't strictly even node, but ymmv.
Please, stop thinking like an "expert" and put yourself in the mind of an 18 year old who is unfamiliar with all of the stuff. Yes, the author could be infinitely more pedantic, precise, and helpful for one specific career outcome (being exactly like you). This means precisely jack for a confused 18-year-old looking for guidance on what areas to spend their time learning programing topics while being medium-ly effective.
Please can the pedantic nonsense and try to focus on the goal.
The reason for it's success is declarative languages are great for data-compression. All the low level gore of reaching across the internet from one remote computer to another is reduced to a pair of <a> tags and a little text.
I know lots of brilliant people who don't write well. If Google doesn't run posts through 10 levels checkers, fine.
Excluding non-turing-complete languages is probably a bad idea technically, as perhaps one wants to promote a toolkit of appropriately-powered languages. (I've seen arguments over "HTML isn't a programming language" before, and really don't care about the of precision when it's unwarranted in the context. Concepts like mathematical functions weren't all that precise until precision was needed.)
That Turing completeness is a property of some programming languages does not imply that all programming languages are Turing complete or that Turing completeness is an essential property of computing languages. The assumption that the extents of Turing Complete languages are identical to the extents of Programming Languages requires some evidence in support.
Programming languages for describing state machines need not be Turing Complete and their implicit avoidance of the Halting Problem make them useful in practice
In terms of things to know, a programmer should know HTML to some extent in this day and age... Requiring a separate bullet point separate from "programming languages" for HTML specifically is absurd, considering the knowledge and concepts are indeed tightly related in the greater context.