I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you
I've had similar experiences with git or other tools - not being able to help a junior dev because the GUI they're using is obfuscating whatever it is the underlying tool is trying to do. I think the irony is that we've got this insanely complex version control system that actually could have several valid use cases for what is likely a common path for users in a GUI.
I'm also not sure referring to people as "noobs" is going to help you empathize with their difficulty. ;)
Eh, that term seems to have fallen out of favor compared to when I was a growing up but I don't think it necessarily has a negative connotation.
I remember being in programming and software related IRCs at 10-11 years old having no earthly clue what in the fuck I was doing, asking adults questions and getting called a "noob".
Well, yeah, it was true. (I also made damn sure they had no idea I was a child.)
They could have said "inexperienced person" but that's not got quite the same ring and people are lazy, aye? Haha
My personal experience around noob is covered by the ones I found on ~~most~~ edit: the most high search-ranked online explanations: Mostly negatively conotated, deregatory version of newbie. Often associated with people not sufficiently able to learn or at least not learning on their own.
I've been around long enough and in enough circles that I have seen 'noob' go from mildly chiding to full-on insult. It used to be that in some communities, being referred to as a noob was a sort of "hey check out the new guy" ribbing. A noob was just someone starting out, a neophyte. It was the impatient and rude who later decided that being a noob was a bad thing.
I often see people self-describe as noobs when asking technical questions, for example in programming Reddits. I couldn't say that I understand the reason for it, though.
“Hey can you help me? I stood up a kratr pod and it’s lined to fundle but for some reason when I try to press the bin tree to the overlay layer the reznik instance on my laptop says ‘out of tokens’. Have you ever encountered this?” No, no I have not.
Having been troubleshooting computers since I was literally 8 years old (like I'm sure many of us here have) I feel reasonably comfortable I could at least be helpful solving this problem as well.
Every problem I have to troubleshoot is almost by definition one I've never encountered before.
This is exactly what motivated me to write Learn Git The Hard Way - I was surrounded by people who depended utterly on IDEs and got themselves into terrible states that based on models that were refractions of what the the (universally available) CLI gives you.
The best example of this was when I worked with a project with 12 dev teams that didn't rebase. They asked me where a commit came from, and when I ran 'git log --oneline --graph' the output was all pipes across my (maximized) terminal.
I've never seriously gotten into the 'plumbing' of git, so can't claim to have a 'true' vision of git via the CLI, but I've never yet been in a situation where it's been required.
Any developer demonstrating that level of daily incompetence with their basic tools of the trade should never be allowed to write code. The fact that this level of incompetence seems the rule rather than the exception speaks to the rather terrifyingly pathetic state of software, where badly engineered systems end up killing people. Source: firmware engineering consultant that cleans up messes like these for some of the biggest corporations in the world, who build things that will kill people when they fail. I would love to blow the whistle, if I thought that would have any positive outcome whatsoever.
Who defines which tools are "basic tools of the trade" and which are just bland infrastructure?
And who decides how much of each tool one should know to move beyond "daily incompetence"?
If I'm getting the job done and produce more net value than my peers for my salary, why should there be requirements on how well I know some specific tool?
I'm willing to bet a ton of value has been generated by folks who don't know the first thing about git beyond "commit, push, pull request". Who cares?
Now, of course, whatever my core job role is (perhaps it is firmware development, as in your example), I should know that role inside and out if my output is going into safety-critical places. But that's a different comment all together.
I'll admit as a 20yr c++ developer, I don't know what rebase is or when to use it. I've only been using git for a few years, cvs before that. I commit and push often, then do a merge request via a web portal gui(bitbucket or gitlab), then merge it squashing commits again using the gui.
I prefer merge/fast forward because I want all history preserved. People can rebase their changes in their branch, but rebasing is never done on the main or development branches. Most of the worst merge conflict I’ve had to deal with were caused by someone rebasing changes they didn’t make. I reject all pull requests that change history.
We ask candidates the most ridiculous algorithm and data structure design questions when we should be asking them to describe the git data structures. Let’s fix interviews and kill two birds with one stone.
Huh, how did it get so bad that "blow[ing] the whistle" about "things that will kill people when they fail" "would have [no] positive outcome whatsoever" ?!
I disagree, the point is to get code written that solves problems, and the tools are a means to that end and not an end in of themselves. Our tools should make that task easier and more accessible to more people.
I feel you. I was recently hired to help with svn to git migration and Java upgrades from 5-7 to 8 (due to my previous experience with such migrations). When I joined they already had a plan. They told me no one will be using command line. They are currently discussing which GUI to use and everyone will have this GUI installed by default, git command will be discouraged as non-standard approach, windows users will not have git-bash installed. I was asked for recommendation of GUI tooling for git and I had absolutely nothing to say, the only I ever used was Kraken and that was in 2014?. When I offered to train and assist everyone with git command training to make everyone more efficient in industry standardised tooling, they told me that's not in the plan. My job was done there without me having to do doing anything, I was free to leave that job!
Sublime merge would have been a good suggestion in this scenario. It's UI uses standard git terminology and concepts, so you'd have been sneakily trainig them in the command line whilst they used the UI!
It was in a very old fashion and regulated working environment where developers and testers aren't allowed to install whatever they want. Software installers can be whitelisted after a review is done. It included things like: licence OSS vs enterprise, support, community, or even more banal things like stars on github. Adding new software to a list could take literally months - like in case of git GUI client. Sublime was frequently requested but managers were responding "you already can install Eclipse and Intellij, you also have Notepad++, you don't need more editors. More editors installed is a security risk to this company!" (some hackers found a way to run VSCode portable edition which didn't offer updates ;)) This was end of discussion.
This is also why there was so so much fuss about git GUI client, there were looking for a golden hammer, a GUI that would do everything and anything.
The git GUI in Intellij and related products is really quite good. The diff view that shows three adjacent panes for conflict resolution (|theirs ->|merge|<-yours|) is so much better than the normal conflict resolution flow (not least because you still get the normal code highlighting in it), and separate checkboxes for each changed section of the diff makes it so easy to chunk large changes into logical commits. I wish they offered it as a standalone product.
>What was their justification for being like that?
The more tools people are allowed to install and use, the less standardised software development. Meanwhile we didn't even have common source code formatting pattern and single Java class could be formatted with tabs, 2 spaces and 4 spaces.
Not necessarily. On my team at work we have people using Sublime Text, VS Code and vim, but all 3 (+ our CI) plug into ESLint and TypeScript for ensuring style coherence.
I have 10 years of git cli and I use GitHub desktop or Sourcetree most of the time. I started using using a git IDE to help support the team members that weren’t experienced in git that chose to use one. I work in games and a lot of game developers mostly know Perforce.
I would never brush off a team member with “cannot help you”. I’m a git expert and I will figure out what’s wrong and fix it.
Every IDE I know shows you a log of the raw commands its running. I use the IDE first, then if something goes wrong (which very very rarely happens, git isn't exactly complicated) I check the log and see what it's trying to do.
On top of that, the IDE will let you run git directly in an authenticated session if you really desire. If a simple/dumb GUI wrapper around git is enough to scare off an experienced developer, then I have my doubts about their competence.
It’s usually a mix of both ide and git issues. And yes I’ve become an expert in using Sourcetree and GitHub desktop. I actually like GitHub Desktop a lot and use it for most dev now.
- Want a diff between two commits from two different branches? Click one commit and Ctrl+click the other. All the diffs show up immediately.
- Messed something up badly and you need to see the reflog? Click the Recyclable Commits checkbox, and everything in the reflog shows up just like any normal commit. And you can use the diff trick above on them.
- Wonder what's in your stashes that you forgot about? Click the Stashes checkbox and they all show up as normal commits. Because that's what a stash really is.
- Committed something to the wrong branch? Drag the branch markers to where you want them.
This is my main gripe about git, it’s literally a tool created to suit the guy managing the linux kernel development via mailing lists… What proportion of junior developers are even tangentially working on anything resembling that?
Even if it’s exceptionally wonky, I have absolutely no problem introducing git to new devs, as long as it’s alongside a graphical representation (sourcetree or some ide-extension), and as long as I am able to enforce limitations on what commands can be run on the git CLI (or more realistically, disallow push to master, and force every merge/rebase through a review)
I’ve personally found that it’s trivial to understand how IDEs integrate git and then adapt the workflow around that, but it’s a complete clusterfuck to let self-proclaimed git wizards loose on a repo without any structure..
> This is my main gripe about git, it’s literally a tool created to suit the guy managing the linux kernel development via mailing lists… What proportion of junior developers are even tangentially working on anything resembling that?
always did give me a chuckle how it took off the way it did for projects that don't come even remotely close to the scalability (like tree sizes) it provides.
the facts that it's free, fast, reliable, good for offline operation and can be used for huge and tiny projects alike are nice though. just never expected to see the day when web designers would become religious about using it.
On a more serious note, I wonder if GP ever worked on projects outside of large enterprises and is just gatekeeping it. Git is useful on solo projects, for God's sake.
HG is simpler to understand, has a more consistent CLI, and way better error messaging. Just a pity that it's been so sorely overshadowed by the Swiss Army Chainsaw of VCS.
Git can certainly do almost anything/everything anybody might want from a VCS, but, just like a chainsaw, it'll cut your leg off just as soon as it'll cut off the branch you're pruning if you're not fully expert in using it.
I understand that some GUIs sort of become "black boxes" while trying to abstract away the complexity, but I know at least one (Sublime Merge) that always shows you the low-level commands it's trying to run.
Same for me. I switched from SVN to git professionally in 2013 and used git via Sourcetree on personal smaller projects. I had to switch to the CLI git because so used SVN also on CLI only and could not transfer the documentation to the buttons of Sourcetree. Whenever I help out other coworkers with git do it via commandline. Doesn‘t matter if windows or Unix. What drives me nuts with programs like Sourcetree is the fact that they apply their own default behaviors to make it „easier“ to use git. Like initializing submodules by default. I had a project with a sparse checkout scheme that could not be cloned via Sourcetree because of this. Our submodules where an optional compiler for a 3rd party platform.
I completely agree. At work we still use SVN, so I'm used to TortoiseSVN which is OK imo. Now for GIT there's TortoiseGIT, but it was such a bad experience. The TortoiseSVN background made it even worse, because things seemed similar, but did totally different things.
So weirdly, for SVN I still use Tortoise, but for GIT, I prefer the CLI client.
Specially when the ide doesn't use standard names and/or introduces new terms.
Visual/ide tools to use git are welcome and I use them occasionally. But the cli should be the common denominator.
Isn't that just being incredibly lazy. Surely a reasonably experience person like yourself should be able to read the error message and at least get a rough idea about what the problem is. Then from there explain how you would fix it on the CLI and try to map that onto the GUI. Most Git GUIs map fairly closely to the underlying git model.
Why not just say the truth "I could help you, but it's not my job, so I'm not going to"
> Most Git GUIs map fairly closely to the underlying git model.
Maybe, but most Git GUIs don't provide clear error messages. This is the case of VSCode, which my teamates keep using. When you use Git CLI you can just have the original error message and know what's wrong.
I was also burned by sourcetree some years ago where it lost part of my code while doing a merge I didn't even understand.
I am not a Git expert. But I can remember the 5 commands needed to do my job every day: `commit`, `push`, `pull`, `rebase`, `checkout`. (you can also add `add` and `status` to the list if you want)
They're straighforward, except for `checkout` which is adressed by `switch` for the main usage.
If you use it wrong, Git CLI will tell you in most of the cases, and even tell you how to do what you intented to do. Git GUIs will probably tell you something wrong happened and left you at that or try to be more intelligent than you are and do something wrong.
> Isn't that just being incredibly lazy.
-> this is what I'd answer to do those Git GUIs.
> Isn't that just being incredibly lazy.
-> this is what I'd say to people who won't write these 5 commands on a sticky note or something and keep it for a month before realizing it wasn't hard to remember once you _commit_ to it and that Git is not hard, minus exceptional problems but Git GUIs absolutely won't help you with these exceptional problems.
If you are using a command line tool for 10 years and don't consider yourself an expert then either you are not using the tool very often or the tool is not well designed.
In case of git I would say it is the latter.
I mostly use git via tortoise interface and that works well 95% of the time.
Other 5% is split between git mv, git branch -D, and trying various commands in order to make git do something simple that can't be done and then giving up.
At this stage I see git as necessary evil rather than something that helps me with source version control.
First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help.
And second, what exactly mystifies you about what e.g. SourceTree menu commands do? They map clearly and intuitively to CLI commands.
If you have "no idea" what it's trying to do then you're not even trying to be helpful. You're just being condescending.
I get you disagree with the GPs post but “noob” isn’t offensive. What’s offensive is their lack of support for colleagues (which reads like a potential issue with their own ego: where they didnt want to be shown up in an unfamiliar UI). But their post reads exactly the same if you substituted “noob” for “newbie”, “junior”, “inexperience” etc.
What we need to do is get passed this ridiculous mindset some have that not knowing something is a bad thing. We all have to start off somewhere and “noob” is just a common term for describing that. Case in point: I’ll readily post “noob question guys, how do I…?” on Slack to give context that I’m asking a potentially basic question and basically don’t really know what I’m doing. For reference, I am the most senior on my team and yet I have zero issue highlighting stuff I don’t know when asking for help. And that’s exactly the way it should be.
There’s no shame in being new at something. What there should be is shame in wanting to mock newbies and shaming and those who don’t offer up their help to others. Being a noob should be celebrated as someone new joining the team rather than added to our dictionary of inappropriate terms.
Anyway, I’ve been the “resident git expert” before, and even just supporting competent CLI users is miserable once the team grows beyond 30 or so people. I can’t imagine trying to then reverse engineer and debug a half dozen crappy GUIs.
Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos (both by admitting bozos and by chasing non-bozos out).
> which reads like a potential issue with their own ego: where they didn't want to be shown up in an unfamiliar UI
> What there should be is shame ... those who don’t offer up their help to others
I read it more as, I don't want to be become L1 Tech Support for something I don't know either.
What happens when the GP runs into an issue themselves. Do their colleagues help him or return the same cold shoulder?
Computers are sufficiently advanced that there will always be blind spots in your team. Sometimes that means working together as a team to figure them out. Which is the kind of behaviour a good manager should encourage and the sort of attitude a good senior engineer should have already learned.
The issue isn't the technical complexity, it's the office politics.
If they fix it, do they then become responsible for fixing it in future? Is this now a "responsibility" the "company" (coworkers) expects of them, with no compensation? In addition to their existing responsibilities?
I introduced git to the company I'm at (previously on SVN running on an old beige box in the corner).
It made collaboration easier. I accepted the fact I'll get pinged whenever someone makes git do a weird thing, but I'm lucky that for the most part coworkers learn from these incidents rather than coming back each time with the same issues.
Again, it shouldn’t be a matter of office politics. If you have a healthy team then everyone will chip in their individual strengths. Yours might be git but someone else might be stronger with Bash, package management, or whatever. Eventually you end up with everyone helping each other. So while you might get interrupted occasionally for git queries, you’d save hours on another issue that someone else helped you with.
There should also be schemes in place to help people level up their own skills. Whether it’s organised training days or an acknowledgment that x number of hours a sprint is spent on personal development (A Cloud Guru or whatever).
If a company doesn’t set up those two pillars then they risk creating toxic teams and that’s ultimately more harmful for productivity than any lost time in a given day helping a peer with version control.
Source: been a hiring manager at several companies. Seen what works and what doesn’t. Ultimately a closer team almost always out performs one where individuals are only looking out for themselves.
> First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help.
Unfortunately, a word needs to exist that stands in for this:
"Person, who isn't so different than myself when I started, with little experience who is mistake prone due to the lack of experience, who's mistakes creates disruption and often great expense at the most inconvenient times."
Being offended by noob just makes communication more difficult, and does not really change anything. We've had all kinds of much more offensive names for the same thing (many other names imply race, social status and so on). noob seems to be about as offensive as rookie, but one syllable less.
> Contrary to the belief of many, a noob/n00b and a newbie/newb are not the same thing. Newbs are those who are new to some task* and are very beginner at it, possibly a little overconfident about it, but they are willing to learn and fix their errors to move out of that stage. n00bs, on the other hand, know little and have no will to learn any more. They expect people to do the work for them and then expect to get praised about it
The specifics of the definition probably vary depending on who you ask but that's roughly it.
Indeed, and it should be clear that "noob" is intentionally/cleverly spelled like "boob" in the sense of "idiot". That's the whole point of the word -- that's the joke.
Now it's fine to joke around and call yourself a noob, that's just self-deprecating.
But if you're talking about other people and don't want to inadvertently offend, stick to "newbie" in speech or "newbie/newb" in writing, which have a connotation entirely of "beginner" as opposed to "idiot".
(Of course, if you're among friends where you enjoy making fun of each other, say whatever you want!)
I've been using the term noob for decades. Reading your comment is the first time I've ever seen anyone compare it with boob. There is a big world out there, with lots of different people using words to mean things.
I agree with your last paragraph but "noob" is offensive? That's just silly... it's like you said, we've all been there once and it's a useful term for quickly describing where one's at. There's no inherent malice unless intentionally added by the speaker/poster.
Just as a data point, I unselfconsciously describe myself as a noob (or more likely n00b) when I'm inexperienced with something, and still prone to making embarrassing mistakes because I don't know what I'm doing.
