The number of CS grads who don't even know basic Git commands is astounding
twitter.com
twitter.com
None of the specific languages or software I learned during my degree do I even use now in my current role.
That a CS grad doesn't even know basic Git is telling not of their degree, but of the individual themselves - that they have no desire to learn beyond what's taught, and couldn't even be bothered to look into the requirements of the industry that they want to work in.
I argue that it should be a barrier to hiring, on that ground.
Or maybe all that doesn't exist when you attend Canadian Chromebook degree mills?
If we had git back then.. I remember one bug that took 6 hours to find, finally found it at 8am before the 10am class. Was typing as fast as I could for the next two hours... If there any kind of basic VCS back then that would have been as easy to use - it would have been many fewer all nighters.
Which is to say, a data structures class should have students coding. There are a number of skills you want when coding, basic and common skills that just make it a ton easier. Namely, confidence and iteration speed go up a ton when you can rollback. A modern IDE can do a lot of that too..
I guess I'm becoming an old fart, I've no idea why basic and helpful tools would not be emphasized early. Debugging with those tools is one of those things you want to learn. It helps build a data/fact based approach to coding.
So even students who failed the programming part and passed by acing the exam and the theoretic part knew what a shell was, what a compiler and linker did, how to find documentation and how to actually do all that on either their laptop or a provided thin client.
And most classes were set up like this. As a first semster student you'd be submitting your MIPS assembler homework using a VCS etc.
It's wankery, no matter what the student's future path is intended to be. You can't work in CS research either if you don't know how to use a computer.
yeah, but all of the VCSs before git could've claimed the same thing.
if that's not a fad, what is?
i'm glad git is the soup du jourre today , it's a lot nicer to use than it's ancestors -- but it's not like there isn't room for improvement, either.
that's how git came about, I don't feel like we're at the end-all-be-all VCS yet, especially when there is money to be made by doing things better.
Git deserves credit for popularizing distributed VCS - which is HUGE - but it was not the first or the best DVCS. Its CLI is full of footguns and it's too eager to irreparably erase history.
Is there though? Why would I pay for a VCS when there already is Git, Mercurial and other free and open source solutions?
Git may not be the most intuitive but it's a solid product and most people work well with it, even those who every now and then delete and re-clone a repo because they don't know another way to get out of a pickle.
Git being the de facto standard in the space is coming up on twenty years. That's about as far from a "fad" as you can get.
> i'm glad git is the soup du jourre today
The problem isn't so much with the "soup du jour", but that the whole concept of "soup" seems foreign to the people the tweet is talking about.
(But yes, given the twenty years mentioned above, "the concept of soup" in practice is pretty much equal to "the soup of the last few decades". Claiming to be a software developer nowadays while being unfamiliar with git is like claiming you were "computer literate" in the nineties but not being able to use Windows.)
First, git doesn't especially solve problems that CS majors have until they are near the end of their courses. The need to manage collaboration, organization, and change in a code base is trivial until pretty late in a CS program, and typically never gets past basic.
Second, the context here is the git command-line interface. People can and do use git extensively without it.
Third, git's not exactly perfect. Personally, I'll be a little sad if git remains the de facto standard source control in the long term... it's not bad, but we can do better.
I think lack of knowledge of git commands in a CS grad would be essentially uncorrelated with future professional success.
Second, a successful CS grad has hopefully written at least something that is at least 2000 lines long. Doing that without VCS of any kind is not impressive, it is obtuse. That is a strong no hire signal imo.
Somewhere in an alternative universe, we're building all of our version control tooling on top of Pijul... Maybe even with AST-aware diffing.
You know, sometimes 100% is enough. Have a beer and relax.
I know times have changed, but I don't think git should be taught in a university-level computer science course. You teach graph theory and then many operations in git should become clear after reading the documentation. I don't think any implementation-specific skills should be taught, unless you use it as an example, like Java or C++ to teach OOP. Instead, you teach broad concepts that underpin all of modern computing.
Isn't there a saying along the lines of "computer science is as much about computers as astronomy is about telescopes"? When I was at university twenty years ago people were still claiming you could easily pass a computer science program without ever touching a computer.
Here's a serious research venue asking for technical artifacts for reproducability: shell scripts, VMs, Docker containers, configs, READMEs, etc. https://petsymposium.org/artifacts.php
Other calls for artifacts if you're curious:
- https://www.usenix.org/conference/usenixsecurity24/call-for-...
- https://www.ndss-symposium.org/ndss2025/submisions/call-for-...
- https://www.sigsac.org/ccs/CCS2024/call-for/call-for-artifac...
Never have I needed to understand the underlying Merkle tree implementation of git to use it. Instead, I need to know when to branch, how to reset, and what makes up a good commit working set and message.
All of this would be the same if I was sullying myself by learning vocational skills or just being able to effectively and efficiently work by myself on a research project.
And source control is an extremely important general concept in the space.
The idea of "programming with other people, on the same codebase" is not some industry specific skill set.
It is important and useful for a thing that involves programming and working with other people.
You could substitute git with WhatsApp, Google Drive, or e-mail for small projects, and get by just fine, but, why not spend 15 minutes learning the basics of git?
As far as I know, the use of git and other distributed version control software is very popular, and we don't see the same hesitation when adopting technologies like Google Docs and its collaborative editing features in college or university.
Is distributed version control software truly a controversial technology?
If distributed version control software is not suitable for use in college and university, what would be a more appropriate technology?
10 years ago, my no-name college had a CS degree that required us all to take a "Software Engineering" course that covered the fundamentals needed once you graduated, including Git. We did group-style large coding projects where teams had to submit their GitHub repo at the end.
The prof was able to review who committed what and then hammered us on good commit messages, clean coding style, testing, etc.. I feel that a large part of my career success was due to the early start I had from that course.
I lone wolfed most of my group projects in college, and don't have any regrets, but, of the projects that I didn't loan wolf, most people didn't write a single line of code, or only contributed in relatively inconsequential ways.
I think that adopting distributed version control systems in higher education would be mostly good.
Which is to say, the idea CS do not need to ever code is a stretch. How does a person work on cutting edge graphics algorithms without building something with it? Without coding in a pretty serious way?
One example, at the end of my intro to programming, the final assignment was to build something, I wrote a chess program (with a GUI). While some classes are quite theoretical, I strongly disagree that a person can get through all of a CS program without their coding skills being challenged.
git is a tool, not a discipline. It's made to facilitate work, not to create a whole knowledge domain unto itself.
I wouldn't fault a seasoned and well trained mechanic for not knowing the specifics of a specialty tool necessitating the need to find the manual; similarly although git is the current VCS-ish thing of choice right now, it doesn't represent all of computer science.
> the current VCS-ish thing of choice
It's not like they're using mercurial instead. There's a lot of concepts here they should be familiar with.
> the specifics of a specialty tool
Are you calling VCS specialty in the context of a CS degree? I wouldn't.
I feel like there's a line where we expect some on the job ramp up. Version control was not ubiquitous 20 years ago even if it technically existed in some early form. We honestly weren't really using SVN/CVS much back then and git wasn't invented 20 years ago. Containerization is another example where it was not ubiquitous even 10 years ago.
What if some new technology becomes fairly ubiquitous across the industry? There's some line where you need to accept people won't be taught this in a CS degree. There's a reasonable assumption that you'll learn on the job and also continuously throughout your career.
>Should they also be taught containers? Yes, because that's how things are done today while 20 years ago they might have all ssh'd into the same server running the development environment and 30 years ago they would have all sat in the same computer lab. And 'taught' in a sense that lists them a few good documentation resources to get them up to speed while using a provided image.
And if they end up with an actual degree they should have covered both hypervisors and containers in an operating systems course.
I dont know if that answers "who cares", but a mechanic that does not know how to do something they need to do multiple times every day - there is a skill gap. While CS is about theory, I would expect a CS grad to have used all of the basic programming tools and more.
If a codebase has no VCS.. that seems almost ideological. I've done a git init on a linux file system to understand patch changes.
With that aside, what does disaster recovery look like without VCS? Remote backups ate an obtuse form of VCS.
If your laptop explodes, are you losing months of work? I mentor junior devs to push daily, if their laptop blows up I want them set up again in 30 minutes with at most one days worth of work lost (because they push their branches remotely, if only for the redundancy. Doing so daily makes it easy to recreate what was lost, compared to a week or two of effort).
Without VCS, integration is s larger challenge. It can be done, but continuously and also efficiently?
Seemingly we are talking about non collaborative code bases, a vanishingly small subset of projects. Most software is developed by teams.
Last, it is so damn easy to run 'git init'. My last job - the team used git locally and then did the stuff in TFS when they finally had to. The point is how easy and useful it was. The other guy that did his own thing, did not use VCS, his stuff was scary. His code was disaster if it stopped building, of if we lost his laptop.
Which is to say, VCS is an underpinning for CI & CD, DR, and is stupid easy to get the init setup done. Just about any codebase - yeah. Even if that means doing git locally and then throwing it away.
It is different to choose to not use all the tools compared to not being able to use them, and yet another to be unwilling to learn them either due to prejudice.
First, VCS is a generic term. Saving files to a backup is a VCS, zipping and sending files via email is a VCS.
What kinds of system use VCS as their underpinnings? Build systems, disaster recovery systems, deployment systems, more... Without VCS, you can't have those systems, and which code bases require none of those systems?
Perhaps we are talking mostly demo projects, small ad-hoc scripts. Would you posit other examples perhaps? My perspective is that it is so trivially damn easy to get a VCS set up locally, even a distributed one, that while - yes - you can live without it - in what cases should you really be living without it? Particularly in light of all the downstream dependencies of a VCS.
Maybe we disagree on the ROI of VCS? I can understand someone not building a CI/CD pipeline because it is kinda costly and maybe won't be used enough to justify it. With Git (VCS), there was a time period where I was new to it and was corrupting files left and right. Getting past that, the cost to set up & use is absurdly tiny, my daily workflow has had no issues for years now. Perhaps there is a difference in perspective there? That you view the ongoing cost to be really large? So much so, that a cat walking across your keyboard is so rare and the daily pain so large, that you have a different perspective on the ROI?
CS grads don't need to know VCS, but software engineers do.
On the other hand, we had classes like Operating Systems, Computer Networks and more where we had to write things in C and assembly.
They're not necessarily wrong but the issue I have is that, in science what should be taught is to question everything and see if it's actually correct and verifiably so. With a lot of these concepts this is seemingly never done. It also comes from a specific period where everything happens to be quite tightly bound to Java (UML, Clean Code etc. especially). That doesn't mean that I can't learn something from it. But it is almost a little hypocritical when you are taught the importance of abstracting and generalizing but then the tools given themselves are not even general enough to apply to anything besides enterprise Java.
CS is an infant of a field. Not too surprising perhaps the degrees would specialize.
> Computer Engineering or any of the other legitimately useful CS degree paths instead of CS itself.
> At least at the school I went to, CS was kind of a joke for undergrad.
> The students that cared about CPU design, low level software (firmware, drivers, kernel, embedded), or robotics (including computer vision, etc) all went computer engineering.
> The students that cared about cryptography or the formal maths side of computing all went to the mathematics dept in their applied discrete maths or applied computational mathematics degree paths.
> The students that cared primarily about high performance computing or applied computing in general (but didn't go one of the aforementioned routes) went through the computational modelling and data analytics program.
> And the students that wanted to learn CS for the purpose of game design or creative arts had their own program within the school of arts (can't remember the name).
> So out of the students who were interested in computing that went to my uni for undergrad, the ones that were left in the CS department were those who were told "get a CS degree for lots of money", those that didn't bother researching any other programs, and those who wanted to be web devs or enterprise java/c# devs.
Graduates of a computer science program don't know specific commands around versioning software that they can learn in 10 minutes on the job. Gasp.
Algorithms, mathematics and logic are timeless, tooling is not, and it baffles me that people can't distinguish between the two.
EDIT: Furthermore, where did they pull this statistic from? I didn't realize that the census also included questions around git knowledge.
It's very painful though.
Though.. in software engineering, being able to write well is perhaps the single most important skill. Communication, documentation, very important.
Are we going to then say English majors are the best programmers? If they later become dev managers or director - then perhaps. Does a person learn English really well by also learning Latin and the origins of english and it's great works? I believe yes, and that is why I think knowing the theory and underpinnings of CS are very useful foundational knowledge. Required? No, but nor is touch typing or anything else that makes a person extremely competent.
Git isn't even 20 years old. I graduated before that. I learnt the basics of version control in a day and searched to unblock myself when needed without fuss. It's not a particularly big deal.
When i read things like this I'm extremely concerned and embarrassed for the people demanding new graduates be rote taught specific tech stacks. That's the real concern here. The projection from having so little faith in their own ability to learn they can't even see that something like git is going to be one of the many things needing to be learnt on a new job.
I think that's too narrow of a reading. There are some foundational practical tools and concepts that are broadly applicable to all computing tasks: version control, command line file-and-folder navigation, quick-and-dirty sripting. These don't (and shouldn't) need to be "rote-taught." But they can absolutely be integrated into existing coursework so students learn how to use them in context. In a data structures class? Run the lab work in Linux and C++ with basic makefiles. Have a compilers course? Offer the skeleton code for the parser as a git repository and submit via merge request.
If people were graduating from college with a CS degree, and didn't know how to use a keyboard and mouse, then yes Id advocate for them to be "rote taught" basic keyboard and mouse skills that they should have learned in elementary school.
It would show that something is extremely wrong going on if the most basic of skill set isn't know by people who's entire field of study involves computers, and didn't know how basic interactions with a computer work.
The labs all had Solaris machines. Most students had never seen Unix or a terminal before in their lives. The instruction on how to use it was extremely minimal.
There was a very wide gap between the students who were huge nerds who already knew, or learned in their own, and those who didn’t. There wasn’t even YouTube, or Stack Overflow, or anything much to help in those days.
The biggest difference was between the students who had to physically go to the lab to do their projects, and the others like me who knew SSH existed, and how to use it, doing our projects from the comfort of the dorms.
That was a bit before my time so they would have had to cope with actual UNIX-like CDE on Solaris until they figured out how to access the nicer Linux servers that had KDE. But in these days thin clients with 24" screens were actually pretty nice compared to what students actually owned. Even on Solaris with Mozilla and CDE.
The actual teaching material didn't change that much though because the university essentially taught the same sh course with here's latex, here's man, here's how you install whatever you need to ~/bin since the late 1980ies. It didn't matter if a professer wanted to use C++ or Modula2 or Pascal or Java because every student got that crash course in how to actually use the faculty provided computung pools.
First semester homework and midterm tests ensured that they were able to start their IDE or interpreter and knew how to compile their homework on the right architecture, how to search for documentation and how to actually use a keyboard to submit their math homework. The beauty of that approach was that it allowed the 10% or so who were really interested in learning more access to university resources while also ensuring that no math-cs double major graduates without at least a modest grasp of tools that were state of the art in Knuth's days.
That's right. We would have been completely lost were it not for... books.
CS degrees does not teach software engineering. They teach computer science. But also, do I think they should probably teach source control basics if the degree involves a significant amount of programming? Yes.
https://gist.github.com/amontalenti/dabeba392b8ac144c6f68bdd...
The guide stemmed out of the fact that I saw questions related to all this from beginner programmers, even those with CS degrees. I think one of the issues is that CS departments (including the one I went through at NYU years ago) think some of these things are sort of like "implementation details" of computing/programming, so no one course ever focuses on the topics in a cohesive way. They just sort of expect you to pick it up by osmosis. When I was an undergrad I supplemented by working on GNOME/GTK open source projects, which gave me nice exposure to UNIX tooling, version control, issue trackers, as well as compilers, C, and Python.
(Funny enough, we did have a course on shell programming at NYU way back when, but it was only because the author of ksh, David Korn, was a professor!)
(My university had exactly this issue.)
It's whether they worked on CS sufficiently complex to need code versioning while acquiring their degree.
mechanical engineers have a fighting chance at knowing, and tradie apprentices assuredly do.
This is less surprising simply because those disciplines and their relative abstraction hierarchies are older, more well understood, and more clearly delineated. CS is less than a century old.
Git is like Autoconf for a lot of problems: utterly unnecessary but often included by default because people have been told "best practice" and never thought to ask themselves if that was true in their case.
Who are you paraphrasing there?
Git is the program where I see the most alternate interfaces trying to make it easier to use.
"basic git commands" are more or less easy but git overall is a mess.
Next, a person learns why something is actually a best practice. Which, eventually is a way to also learn whdn something is no longer the best practice. They learn when to break the best practice, specifically which situations it is not best.
Not being able to rollback or view file history are major handicaps. It is like not being able to dribble a basketball with your left hand. It is a best practice to be an ambidextrous dribbler. CS is young, some best practices are opinion, others are tools that you should know about in order to achieve basic competency.
Is your alternative another versioning software or just a massive pile of folders?
i dont really ever have a need to go back over the previous versions tho. don't revisit old mistakes, make fresh new ones!
I love it here.
I read something a while back that did color my understanding of folks somewhat, and that was that there are a lot of people who come into the technology field for the money, not necessarily because of their lifelong interest in tinkering with computers. That to me is nuts, but I guess it’s to be expected. Maybe the sample size of my experience with these folks is overrepresented with people who are in it for the money and not curiosity and creativity. I don’t know.
(Full disclosure: I have a masters)
Not being snarky, but the elite schools are significantly advanced.
Imagine learning algorithms from Knuth (yes, I know he hasn't taught undergraduates in 50 years). Looking at the results after being taught by Dr. Smith at Generic State University, you might be unable to recognize the genius.
Are you trying to defend a software engineer who is bad at writing readable code by... bringing Knuth to the table?
The same Knuth who published "Literate Programming"? "Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do"?
The readability problems may be the reader.
Once, one of my teammates committed an extremely complex piece of code that I wasn't able to understand. As I expected, we soon started to start bug reports. Finally, the original author couldn't fix it properly, so I threw away the code and rewrote it from scratch. I made it simple, readable, and, what's more important - debuggable. And it was correct.
So what? Your personal experience says that you are not the smartest person in the world, and my personal experience says that magic is magic — it doesn't work properly in the real world.
It's easy to build "magic" code that's hard to understand. You can just run any readable piece of code through an obfuscator. Still, no one believes that an obfuscator is genius. If you see "magic" code that, for some reason, truly works, it means that the author did a ton of research and forgot to put that into comments — i.e., obfuscated a code. If, even with comments, it still looks like magic, then the author avoided doing a self-review & simplification of the code. And well, sometimes, even after that, code can still be magic... if we have chosen the wrong tool for doing the job (does it sound like a depiction of genius?).
IMO, it should. An education without any relation to practical skills just makes it that much harder to leverage what you learn.
Such hubris in that original statement! As if Git is the be-all and end-all of all computer programs. Yes, Git is important. No, it's not the only version-control program in the Universe.
CS majors should learn it just by messing around with projects, but I don't see why an otherwise great candidate couldn't learn it very quickly
The OP was just surprised that people don't know git, and indicated that he wouldn't hire a junior engineer who didn't know git, but, there's very likely nuance to this, and I don't think that one person's personal preference necessarily needs to be discussed and debated extensively on Twitter, HackerNews, etc.
In my opinion, git is a very popular tool, and lots, and lots of people use it - and it only takes 15-30 minutes to learn the basics - for this reason, I think that it is fair to be surprised that someone doesn't know it.
It's worth noting that the person who said that they'd only hire junior developers who know git isn't the President of the United States or anything, and can absolutely make their own hiring decisions.
It's perfectly reasonable to make your own hiring decisions, IMO, and asking people to know git, or the fundamentals of version control seems totally fair, IMO.
If people are willing to spend a few weeks solving leetcode problems, or answering mock interview questions, I feel like they could absolutely spend 15-30 minutes learning how to use git.
What matters is are they curious and how quickly they can self teach this or that tech.
And besides, learning the basics of git should be an afterthought for someone being hired for a programming job!! Come on.*
* Not gatekeeping here, I'm just trying to say that in the spectrum of tasks an entry-level programmer will need to get good at, git is a minor footnote. You can generally learn 99% of what you'll need to do in a short period of time, unless your team is doing exotic stuff, in which case they should stop doing that.