4 ms·

If I've learnt anything from teaching kids it's the ones really good at it when we start are completely dwarfed by the kids who sucked at it. You can get kinda

If I've learnt anything from teaching kids it's the ones really good at it when we start are completely dwarfed by the kids who sucked at it. 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.

BiteCode_dev 7y ago
It's not just the people, some topics leads to that. E.g you can get far with just a few git commands, but one day, you will encounter a situation that is like a brick wall because you have no idea what's going on inside. 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.
- Chyzwar 7y ago
  That ok, but these people need to stop labelling themself as experts. It makes difficult for true experts to stand out.
  - BiteCode_dev 7y ago
    Oh one can identify experts very easily: they are the ones that understand nuances, see and explain things as cost/ratio instead of good/bad and have an up to date view of their ecosystem of choice but are ok with other techs. 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
  - irrational 7y ago
    Maybe experts don't call them selves experts. 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."
    - jermaustin1 7y ago
      Yeah, this expert prefers Guru. /s
    - BiteCode_dev 7y ago
      Well, it is said that a wise man never calls himself a sage. Others do.
- elwell 7y ago
  > most git users picture a branch like a diverging chain of commits and not a moving label Ok, I'll bite: can you explain that little more please?
  - jerf 7y ago
    A git repository is best thought of as a sort of tree, where the nodes can potentially have multiple parents. This technically makes them a graph ("directed acyclic" to show I do know the technical terms), but our human intuition will mostly work thinking of them as a tree. To understand multiple parents use your intuition about human beings, since we all have multiple parents. 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.)
    - blacksmythe 7y ago
      >> 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 Is this something you could share?

BiteCode_dev 7y ago

It's not just the people, some topics leads to that. E.g you can get far with just a few git commands, but one day, you will encounter a situation that is like a brick wall because you have no idea what's going on inside. 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.

Chyzwar 7y ago
That ok, but these people need to stop labelling themself as experts. It makes difficult for true experts to stand out.
- BiteCode_dev 7y ago
  Oh one can identify experts very easily: they are the ones that understand nuances, see and explain things as cost/ratio instead of good/bad and have an up to date view of their ecosystem of choice but are ok with other techs. 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
- irrational 7y ago
  Maybe experts don't call them selves experts. 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."
  - jermaustin1 7y ago
    Yeah, this expert prefers Guru. /s
  - BiteCode_dev 7y ago
    Well, it is said that a wise man never calls himself a sage. Others do.
elwell 7y ago
> most git users picture a branch like a diverging chain of commits and not a moving label Ok, I'll bite: can you explain that little more please?
- jerf 7y ago
  A git repository is best thought of as a sort of tree, where the nodes can potentially have multiple parents. This technically makes them a graph ("directed acyclic" to show I do know the technical terms), but our human intuition will mostly work thinking of them as a tree. To understand multiple parents use your intuition about human beings, since we all have multiple parents. 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.)
  - blacksmythe 7y ago
    >> 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 Is this something you could share?