The vast majority of the participants are not up to the task. They are paid professionnals, but they consistently overestimate they level, skills and needs. They often are not very good, and of course, they don't know what they don't know.

So I always check for that first, and rewrite my course on the fly to include the untold pre-requisites I identify. I don't tell them I do this to avoid making them feel bad. Nobody wants to hear "dude, you wanna learn react and you never used an arrow function, wtf ?" even if being comfy with JS is a listed requirement on the site.

Bottom line: most devs are not experts, and don't have the ability to assess that. But more importantly, it's enough for them to be productive and most industries don't need more.

You can get kinda far without really understanding what's going on, but if you stop and have to learn something really fundamental the "good" kids just seems to manage. Once things pick up they can excel because the have truly moved on. the previously "good" ones are still copy/pasting from past work or tutorials and get brackets wrong whereas the "slow" ones are now perfectly happy writing from scratch and thinking for themselves.

Today, most JS devs don't know how "this" works, most python devs never used pdb, most git users picture a branch like a diverging chain of commits and not a moving label, etc.

Again it's not the people's fault: they are required to be productive very quickly. There is competitive pressure. So they aim for what's good enough to make things that looks right. Can you blame them ?

Few jobs pay devs to update their skill on company time, and not everyone will spend an hour a day learning new things instead of playing with the kids, doing exercice or going out with friends.

Ok, I'll bite: can you explain that little more please?

A "branch" doesn't really have any special status in git. All it is is a pointer to a particular commit. Literally, that is all it is, even in the data structures. It has no additional ontological existence beyond that. When you make a commit to a "branch", all that happens is that git moves the branch marker along to the next commit. All of the "specialness" of a branch is what is in that behavior.

You can do anything you want with that branch marker, such as yanking it to a completely different part of the tree via "git reset --hard $NEW_COMMIT", and while you may confuse humans, you haven't confused git in the slightest. On the flip side, since branches don't actually "exist", it is perfectly sensible to "merge" with a direct commit hash, because that's all a branch is; a pointer to a hash. You can pick up that pointer and drop it down where ever you want.

(A tag is the same thing as a branch, except that when you're "on" a tag and make a commit to it, git does not advance the tag. But almost all it is is a pointer to a commit. Technically it can carry a bit more data, like a signature, but as far as the core structure is concerned it's just a commit.)

I am not the original poster, but I have a training I give at work for git, and it is heavily based on making sure this understanding is presented. (The other reason I wrote my own training rather than reusing any of the many other existing ones is mine makes sure to walk the trainees through the confusing states you can get into, then we explain what happened, why, and how to correctly get out of them. They follow along as we all manipulate a repository, and the training actually spends quite a bit of time in a "detached head" state, checking out, merging, and resetting to commits directly.)

  >> makes sure to walk the trainees through the confusing states you can get into, 
  >> then we explain what happened, why, and how to correctly get out of them

- you don't where somewhere and you moved and you can't go back: "git reflog"

- local repo and remote with a different history (e.g: you rebased on a published branch): the whole team to sync with remote except you, then hold. Export your remaining changes as a patch. Reclone. Apply patch.

- remote has a different history than the rest of the team (e.g: you forced push a different history): Delete remote, recreate, repush from one of the team mate, then apply previous solution.

- your messed up your merge and wish to never have done that: "git reset --merge"

- the last commit is not published and you messed it up: "git commit --amend"

- the last commit is published and you messed it up: "git revert HEAD"

But rather than solve problems, better not get them in the first place. Always "git status" before anything, always get a clean working copy before checkout/pull, create a fat gitignore, etc.

In git, a branch is NOT like a wooden branch on the trunk of a tree, although it ends up being at the top of one, which makes the analogy ok.

A git branch is the same thing as a git tag, except it moves automatically when you commit from it.

You can see it as a lightweight label attached to a commit. If your HEAD is itself attached to a branch (HEAD is also a lightweight label, but this one is like a red sticker on a map saying "you are here"), when you do "git commit", the branch label is moved to the newly created commit.

Hence, you can have several branches on a single commit, and you can move branches around: they are just labels. You can also have branches with different names locally and in a remote, or have a branch with the same name, but on different commits locally and in a remote.

A branch is like a reference, it's useful to tell git what place in the history you are talking about, without referring to a commit in particular. It is a moving reference because the place in history you talk about is always changing: it's the top of a chain of commits, the ever changing last thing you worked on for this particular part of the history.

We want branches because they are a convenient way to say "I'm going to do something on the latest commit of this part of the history":

- "git checkout branch_name" => I'm now working on this part of the history, gimme all the latest stuff you got and consider everything I do is now related to it.

- "git checkout branch_name /file/path" => Get the latest version of the file from this part of the history and bring it on my hard drive

Of course, you can put a branch at a commit that is not yet the top of a chain of commits. But soon this commit will become the top of a new chain of commits because when you'll commit from this branch, a new commit will be attached to the previous one, diverging from the original chain, and the branch label will be moved to it. You now have a fork of two chains of commits, both of them having a different branch label at their top:

"git checkout commit_hash && git checkout -b new_branch_name" => I'm going to consider this commit as a new starting point and work from that.

In fact you can move a branch pretty much anywhere, create one or delete one at anytime, including "master", which is not a special case, just one created automatically on the very first commit.

This is also why if you "git checkout commit_hash" instead of "git checkout branch_name", git warns you you are in a "detached HEAD" (the "you are here" label is attached to a commit directly, not a branch label). Indeed, a chain of commits (the stuff that looks like a wooden branch on a trunk in graphics) can exist without a branch label. But it won't be convenient to reference: looking for the hash of the newest, latest commit, every time you want to mention it is tedious. Besides, git will run "git gc" automatically once in a while, deleting diverging parts of the history with no branch or tag, so you may lose this work.

This makes it clear that tags are labels like branches, only they don't move. They serve the purpose of having a static reference to a fixed point in time: both allowing you to easily talk about it, and let git know you want to keep this around.

All that stuff is way clearer with a visual explanation. For my Git training, I bought a fantastic toy for 10yo with magnets that let me build a 3D history tree and use post-its to represent branches and tags. It's instantly obvious. It's really fun, you can move stuff around and show what each command does to the tree. After that, git seems much more accessible, and you just grunt at the terrible UI ergonomics.

So, there's an isomorphism between (1) a commit node; and (2) the chain(s) of commits ending in that node.

Why then is it important to think of "branch" as referring to one rather than the other? As evidenced by the isomorphism, they're the same thing.

A branch is a separate concept, it's not even stored in the history DB but in a different dir. See it as a label attached to a commit, since a commit can have several branches attached to it, or none. A branch will be moved across the history, while a commit will keep his place in the history.

A branch is designed to be easily created, deleted, and moved around, freely, from anywhere to anywhere.

A commit is designed to feel immutable, and unmovable, and although this is not strictly true, this is how you will mostly use it.

A chain of commits is like a rail track, it goes in one direction, each commit composing it never changing (again, conceptually), and never moving. You stack commits, you grow the track, piece by piece.

The branch is more like a flag you put somewhere on the rail track (most often at the end), to let the workers know where to put the next piece.

Picturing it that way let you best use its properties:

- branches cost nothing. They are very lightweight, unlike in SVN, you should create as many as you want.

- moving to a branch is cheap. Apart from moving the files to the working copy, it's just a matter of changing point of view on the history. Switch to branches often, it's fast.

- you can put a branch anywhere you want. You like an old commit and wanna try something new from it? Plant your flag here and start working.

- deleted a branch by mistake ? No worry, it's just a label. You can recreate it in a blink.

- this branch is so good it should be master? Sure you can. Just swap the labels. But let everyone knows :)

Etc.

Ahhhh. So the distinction matters if you bring in a bad assumption from SVN. It had never occurred to me that a labeled branch would be noticeably more expensive than the weight of the commits making up the branch.

> you can put a branch anywhere you want. You like an old commit and wanna try something new from it? Plant your flag here and start working.

Well... yeah. That's how you create branches. You go to the commit you want to branch from, and you run `git branch`. The fact that you can do this is immediately implied by the way you have to do it. I don't understand how someone could believe something different.

> deleted a branch by mistake ? No worry, it's just a label. You can recreate it in a blink.

This one's a little weirder; if you delete a branch, you _can_ recreate it, but it's only blink-of-an-eye easy to do if there's another branch containing the head of the old branch. Otherwise you're mucking around in the internal data.

> this branch is so good it should be master? Sure you can. Just swap the labels.

This is another one where I don't see how you would believe something different. Even if branches were huge, heavyweight objects, they have names, and changing the name of something is generally not so hard to do. There's a command solely for the purpose of renaming branches. (`git branch -m`)

> moving to a branch is cheap. Apart from moving the files to the working copy, it's just a matter of changing point of view on the history. Switch to branches often, it's fast.

And in my mental model, a checkout is indeed a (potentially mass) update to file contents (and, if applicable, file existence). Saying "apart from moving the files to the working copy" sounds -- to my ears -- kind of like the chestnut that "controlled for height, taller men earn no more than short men do". Setting up the working copy is the thing I'm looking to accomplish in a checkout.

I can imagine two types of people who want git training:

- Never used version control.

- Used subversion heavily; trying to update to the new new thing.

In your opinion, how many of these points are "git gotchas" that the first group need to be trained in, and how many are "subversion gotchas" that only really come up for the second group?

Many years ago, SVN users coming to git were indeed a huge source of head scratching.

Not anymore.

Now we just have a lot of people that just don't think in a way that will lead them to say "So, there's an isomorphism between (1) a commit node; and (2) the chain(s) of commits ending in that node.". In fact, they don't know what isomorphism means, nor that the word exists.

Personally, I like to picture git as applied graph theory. One command = a bunch of operations on the graph.

But there is an old git joke that says:

"Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space".

It is nonsensical (it's a meta reference to a Monad joke), but I think it gets the point perfectly: we need to bring git to the people that needs it, not to ask the people to come to git. I don't care what level of abstraction they are comfortable with, I want them to feel like they can trust their ability to be productive with the tool and feel their project is safe.

And I find that this way of explaining branches is the most universal way for people from all sorts of background to have a decent model of how git works under the hood. So that when fall in a trap, they can use this model and find a pragmatic way out by themself.

Being right used to be my objective when I was younger. Now I just want to be helpful.

git reflog is very useful for this. Also, when you delete a branch, git helpfully prints

Deleted branch foo (was da2bb5d)

so you already have that information, right there.

When I started using git, I checked out back in time, then git logged and was baffled to not see my most recent commits in the listing. I panicked, though I lost my work.

Git terrible UI didn't help there: who though it was a good idea to just hide everything with no hint of how to get back at it?

Of course, I could have just git checkout master to get back where at was, I just didn't know it. But that's the point of reflog: if you are not sure what you did or where you are, it's always there for you, it has your back.

The problem is that they are easy to spot only for somebody with experience in the field. This is why companies sometime pay good freelancers to help with hiring: they can assess what the company can't.

And once they do, they realize quickly that:

- there are few experts

- most resumes are bs

- experts are expensive

- they probably don't need them for most tasks and the bs resume dev may be ok, given the price and skill constraints

- they had one expert internally all along, doing half the job of the rest of the entire team and they should make sure this expert stays

I have a friend that had some home remodeling work done, poorly. The friend said to me, "But, they were professionals!" I responded, "Well, that's the problem. A professional is someone who will do the least amount of work in the least amount of time for the most amount of money. If you want someone who actually cares about the work, hire a craftsman instead of a professional."

At least in the early days, using React was the first time most people would be exposed to webpack/babel, so it was also their first exposure to the newer JS features.

Besides, it's alright to learn es6 and 7 with react if you have time, but if your company pays a $10k react training in a 3 days session, you better have the pre-requisites right.

And at the very least, don't pretend to be "an expert" in 2019 if you don't know es6. Every tutorials for beginers include them now. Every docs of every libs use them.

You don't have to be an expert. It's legitimate. I don't advertise myself as a JS expert despite being pretty good at it.

But it looks better on the resume, and once you are hired on that assumption, you can't go back. Next time the company asks, you say expert again.

So I asked the uni to borrow a classroom and hold my own courses, a summary once before every exam. The grades went up and I felt useful for the first time in my life.

I kept explaining things to friends and colleagues after that, while being a full time dev. That's the only thing I was consistently better at than most people. There were better devs, but I could explain python decorators to a junior like if it was the most obvious thing in the world, and I felt proud of it.

I also still was regularly irritated by the terrible state of teaching. Why do people explain react by first installing webpack + babel while you can just drop a script tag and start playing? Why do nobody tells you what a bloody env var is, like you are supposed to be born knowing that? Why no beginner course ever include an intro to a debugger, do you enjoy having your students suffer? Why do they keep using the confusing reverse arrow in git history schemas, as if technically correct where the best kind of correct?

One day, I decided to do charity work in West Africa. I ended up stayed there for 2 years, eventually created my own company. Things where good.

Then the war started. My company went down, my bank account was frozen and I was forced back home, in debt. Fun times.

I looked for missions to quickly make cash, but in France dev doesn't pay that much. So I dug, and noticed that training professionals was incredibly well paid, thousands of dollars for a few days of work, which for the country is insane. It felt like stealing. It still does sometimes.

But I needed the money, and I though I was good at it, so I spammed dozens of entities. After a few courses, in which everybody was surprised there were no slide and the program kept changing, the phone started ringing.

Apparently most professional trainers suck too, and companies were astonished that not only the trainees could enjoy the session, but that they gained productivity afterward. Why did they paid so much money before, then? It's a mystery to me.

But I kept at it every since.

I usually do training once a month: JS, Python, Git, lot of web, a little bit of data analysis, best practice or design patterns.

But I still dev the rest of the time, otherwise I would always go from planes to hotels and that's no life. Besides, a trainer who doesn't code becomes obsolete very quickly.

Yet I try to get remote gigs for American clients: french customers never pay as much and they are very risk adverse so the projects are less interesting. I do have a few, because we know each others very well and working together is a blast: we can have drinks, say offensive jokes and still get the stuff done. Money is not everything.

All in all, I like training people. It's frustrating, infuriating even sometimes. And exhausting. But when I'm fed up with computers, I get to see people. And when I'm fed up with people, I go back to my computer.

I miss being able to focus for just 2 hours on a task that would then give me a clear view on how well I knew the important mental models of a topic.

"Expert: Being able to style an entire front-end from scratch following a consistent methodology"

Meanwhile, "Advanced: Mastering animations, interactions, transitions, etc."

I can certainly "style an entire front-end from scratch" without "mastering animations".

CSS architecture (for a lack of a better term) is completely different from its more playful aspects. Stacking on on top of the other is just silly.

Knowing how to actually build things from scratch in a way that survives the beating of time is something else. It’s much harder to quantify though. Also, these days you have the css in js solutions, which means you can build the app by dropping in the css where you need it, so you get to tick that box, but if you tried to do it the “traditional” way you might not even know where to start.

EDIT two of my more common phrases at work are “you could just use css for that” and “you don’t need to use flex box to do that”. I’ve found that there’s a lot more using css to style things in isolation without understanding the power and performance it brings to the table. I spend more time trying to stop react renders from happening because css should have just been used than I do on the micro detail of ordering things a certain way to avoid repaints.

As others have mentioned, getting people to assess themselves accurately is very difficult. We always seem to skew towards the overly-confident side - not least because this what is usually rewarded in the job market.

Although it might be worth considering a simpler heuristic in the future as the distinction between Advanced and Expert is somewhat vague and perhaps ultimately not very informative.

At that time I was leading a small Node.js dev team and I would maybe rate myself 3/5 in Node. We didn't end up hiring them.

So 4 - 5 stars in an area just means "this is what I'm most comfortable working with and/or have the most experience with", not "if you rank yourself a 3 then I'm better than you at this" or "I'm a world-renowned expert at this". Otherwise, I'm not sure what you would expect from a fresh graduate who'd decided to use this format; 1 star for everything, or fractions of a star?

Your question is essentially a proxy for server-side architectures and applications, not nodejs itself. It invites misrepresentation.

I feel like you guys think I asked them to rate themselves 1-5 on the subject. I did not, I got their resume, where they themselves rated them on the subject. With my question I was just checking whether that self-assessment was correct. I don't see how that is a bad question... Should I just believe their resume? Should I give them some programming assignments? Should I ask them to write a complex algo on a white board? I feel like just asking is a good way, personally, but maybe I'm wrong.

Of course this falls apart the moment they ask me any Go question during the interview, but not when I’m actually asked to build a web application in it after being hired.

(the one time this happened people thought I’d been working with the new language for years, but no, it’s just a whole lot of transferrable skills)

Asking them to self rate themselves is useless however, as their answer showed.

That's how I interpreted the comment and I'm pretty confident that's correct.

I ask for a 0 (never heard of it) to 10 (you made the thing or wrote a book on it) ranking and most people that have worked a couple years answer no higher than 5 or 6 but recent grads will say 8-9.

Pure anecdata but supports other comments about not knowing what you don’t know until you’ve been around different subjects for a bit.

Example: frontend design is self rated to a 6 but the person can not articulate the difference between raster and vector graphics (or doesn’t know what an SVG is or when to use one or not use one and vice versa).

At first I was put off, but now I interpret it as their own personal scale, with 5 being what they the best at, and not as "I know everything about this".

But even then, the best candidates are usually the ones who rated themselves the lowest.

"You have selectors and styles, and I can just can look them up, so I guess I know all there is to know about it."

The "expert" category would rather be "having a deep understanding of what the browser does with styles and how the concepts of display etc actually work" for me.

But it's really hard to draw a line, css allows for awful hacky solutions that end up looking like they work, and many people "able to write a full frontend project" will produce rather bad CSS irl.

I think the best CSS compatibility across the board was during the time of ACID series tests, and has declined since.

But I know what you're saying. I also noticed a few percentage points of people saying they have 20+ years or React experience at this point.

Wikipedia puts it well:

> It's a cognitive bias in which people assess their cognitive ability as greater than it is. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of ability. Without the self-awareness of metacognition, people cannot objectively evaluate their competence or incompetence.

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect