4 ms·

I'm about to graduate with CS degree, and my first question to potential employers is going to be "Do you use source control, and is it Git?"

by _RPM 12y ago

burkaman 12y ago
I would try not to judge companies like that. I had an internship at a place that was consistently rated the best place to work in the area, interesting work, great development environment, etc., but they used this source control product called AccuRev. It was this slow GUI-based thing with it's own unique vocabulary, nobody really liked it, but it was still a great place to work. If they don't use source control at all, that's obviously a problem, but don't discount a company just because they don't use your favorite software.
- a_c_s 12y ago
  Excellent advice - the converse is true too: just because a company uses the right tools doesn't mean that the company doesn't have a toxic corporate culture that makes it a terrible place to work.
hueving 12y ago
And what is your follow-up when they say they don't because they need more centralized control/auditing due to the sensitivity of their work?
- _RPM 12y ago
  As long as I don't have to use a windows GUI, and can use the terminal to commit changes, then I could be in.
- ZeroGravitas 12y ago
  "Why do you need to control/audit all work done locally rather than what is pushed to your main git repository, and how can you realistically enforce that with any tool?"
  - mickeyp 12y ago
    In Subversion you can explicitly check out a file so others cannot. That's rather important if you are modifying binary blobs of data with no way of merging conflicting changes. Art assets like video and images are good examples. Subversion (and Perforce and other centralised tools) will let you restrict who can check out what from a repository. That's useful if you want someone to only work on a small part of the code but cannot risk giving them access to all of it, for security or secrecy reasons. And finally, as much as I love git and DVCS, for some teams Subversion works just fine. They may well have Continuous Deployment set up with strong CI tests on commit or they use Subversion's "reintegrate branch" functionality which is somewhat similar to rebase. Honestly, merging in Subversion isn't really that bad.
    - vidarh 12y ago
      If you can't risk giving someone access to all of it, giving them any kind of access to what in my experience is likely to be a poorly secured centralised repo is a recipe for disaster. E.g. I've worked on systems that were ostensibly locked down like this. Except that for any developer who cared, getting physical access to any number of machines where the "secret" code would be sitting checked out, with suitable credentials to do stuff to it, was trivial. I'm sure some people get it right. But I'd be very critical of that as a reason. Especially given that you could easily solve this in Git too, by putting the sensitive stuff in a separate repo. Your point regarding binary assets is better, and if someone had raised that as an objection to git, it'd be worth listening. But that's a very different argument than the hypothetical argument posed above. "SVN works for us" is also a very different argument. Had those arguments been given, I'd be sympathetic. But the hypothetical "we need control and auditability" given above would be a red flag to me.
      - hueving 12y ago
        The binary blob argument is a subset of the central control paradigm. Without the built in notion of having to perform actions against a central server, git makes it very difficult to perform those tasks. How about the removal of a sensitive file accidentally added to a git repo? It can't be done without rewriting the entire commit history after the file was committed and then forcing a push which will screw everyone up with an existing clone. You could argue that the file should never have been committed, but then I'd argue you have never worked with humans.
- vidarh 12y ago
  "Bye." Given that nothing stops you from running a centralized Git repo for things that are candidates for audits or release. If someone uses that as their reason for not switching to Git, it indicates to me that they don't understand their requirements and/or is using it as an excuse because they don't have any real reasons. I'd even argue that if you want more control and auditing, Git is an improvement over alternatives like Subversion, because it makes it more manageable (and so more likely to actually happen) to set up workflows with far more frequent commits and subsequent reviews by a gatekeeper. You don't need to let your lower level developers even have any kind of access to the main repository, yet you can retain full history of changes that happens before their code is approved and pushed to the main repo by a suitably anointed person.
  - hueving 12y ago
    If you're using a gate keeping process, it doesn't matter what the committers even use then. They can just push a patch to the gate keeper. You sound pretty close-minded and relatively inexperienced if you would turn down a great career because they used something other than git. It's borderline idiotic to make such a large decision based on something inconsequential. Maybe that's okay in the Web app industry where most of the jobs are just variants of the same thing so you have plenty to filter through, but the idea of turning down a job at somewhere you've been hoping to work like NASA or Google just because they don't use a tool you like is one of the dumbest things I've heard in a long time.
maaaats 12y ago
And during that degree, you learned the pro's and con's of every VCS and when to use which, I guess? I'm soon graduating myself, and I would never dream of believing that I know better than those with more experience than me.
- UK-AL 12y ago
  I've working for for quite a few years, I can tell you their are many clueless people who have racked up many years of experience. I really would not get your hopes up on how well things are run. In your career YOU WILL meet people who refuse to try new stuff because "this is the way we've always done it" and unreasonable reasons. I've met people who refuse to move on from visual source safe for example. The majority of your first years of your career will be learning how to navigate office politics, how to introduce change, how to get things done without getting fired, how to manipulate your boss to make the right decisions without imposing yourself on him. Those are more important than raw technical skill. Most of the value of 'experience' comes from those skills.
  - gutnor 12y ago
    The reverse is true too. If a fresh graduate is moaning about us not using GIT directly in the interview, I may wonder how that guy will turn out. Not even a single day of work under his belt and he already is either afraid to move out of his comfort zone, or has already made up his mind about what technologies must be used. Thankfully, being cocky is somewhat tolerated even expected from overeager graduates. However, that eagerness turn into zealotry and, later on, obsolescence/cluelessness for a significant part of them. You know those guys, since they cause you the most problems at work. They built their reputation by embracing new stuff and now prevent everybody to move on.
- _RPM 12y ago
  Don't take this the wrong way, but there are certain qualities that go together with a team that uses SVN vs Git. I can tell a lot about you just by watch VCS you use.

I'm about to graduate with CS degree, and my first question to potential employers is going to be "Do you use source control, and is it Git?"

by _RPM 12y ago

I'm about to graduate with CS degree, and my first question to potential employers is going to be "Do you use source control, and is it Git?"

burkaman 12y ago

I would try not to judge companies like that. I had an internship at a place that was consistently rated the best place to work in the area, interesting work, great development environment, etc., but they used this source control product called AccuRev. It was this slow GUI-based thing with it's own unique vocabulary, nobody really liked it, but it was still a great place to work. If they don't use source control at all, that's obviously a problem, but don't discount a company just because they don't use your favorite software.

a_c_s 12y ago
Excellent advice - the converse is true too: just because a company uses the right tools doesn't mean that the company doesn't have a toxic corporate culture that makes it a terrible place to work.

hueving 12y ago

And what is your follow-up when they say they don't because they need more centralized control/auditing due to the sensitivity of their work?

_RPM 12y ago
As long as I don't have to use a windows GUI, and can use the terminal to commit changes, then I could be in.
ZeroGravitas 12y ago
"Why do you need to control/audit all work done locally rather than what is pushed to your main git repository, and how can you realistically enforce that with any tool?"
- mickeyp 12y ago
  In Subversion you can explicitly check out a file so others cannot. That's rather important if you are modifying binary blobs of data with no way of merging conflicting changes. Art assets like video and images are good examples. Subversion (and Perforce and other centralised tools) will let you restrict who can check out what from a repository. That's useful if you want someone to only work on a small part of the code but cannot risk giving them access to all of it, for security or secrecy reasons. And finally, as much as I love git and DVCS, for some teams Subversion works just fine. They may well have Continuous Deployment set up with strong CI tests on commit or they use Subversion's "reintegrate branch" functionality which is somewhat similar to rebase. Honestly, merging in Subversion isn't really that bad.
  - vidarh 12y ago
    If you can't risk giving someone access to all of it, giving them any kind of access to what in my experience is likely to be a poorly secured centralised repo is a recipe for disaster. E.g. I've worked on systems that were ostensibly locked down like this. Except that for any developer who cared, getting physical access to any number of machines where the "secret" code would be sitting checked out, with suitable credentials to do stuff to it, was trivial. I'm sure some people get it right. But I'd be very critical of that as a reason. Especially given that you could easily solve this in Git too, by putting the sensitive stuff in a separate repo. Your point regarding binary assets is better, and if someone had raised that as an objection to git, it'd be worth listening. But that's a very different argument than the hypothetical argument posed above. "SVN works for us" is also a very different argument. Had those arguments been given, I'd be sympathetic. But the hypothetical "we need control and auditability" given above would be a red flag to me.
    - hueving 12y ago
      The binary blob argument is a subset of the central control paradigm. Without the built in notion of having to perform actions against a central server, git makes it very difficult to perform those tasks. How about the removal of a sensitive file accidentally added to a git repo? It can't be done without rewriting the entire commit history after the file was committed and then forcing a push which will screw everyone up with an existing clone. You could argue that the file should never have been committed, but then I'd argue you have never worked with humans.
vidarh 12y ago
"Bye." Given that nothing stops you from running a centralized Git repo for things that are candidates for audits or release. If someone uses that as their reason for not switching to Git, it indicates to me that they don't understand their requirements and/or is using it as an excuse because they don't have any real reasons. I'd even argue that if you want more control and auditing, Git is an improvement over alternatives like Subversion, because it makes it more manageable (and so more likely to actually happen) to set up workflows with far more frequent commits and subsequent reviews by a gatekeeper. You don't need to let your lower level developers even have any kind of access to the main repository, yet you can retain full history of changes that happens before their code is approved and pushed to the main repo by a suitably anointed person.
- hueving 12y ago
  If you're using a gate keeping process, it doesn't matter what the committers even use then. They can just push a patch to the gate keeper. You sound pretty close-minded and relatively inexperienced if you would turn down a great career because they used something other than git. It's borderline idiotic to make such a large decision based on something inconsequential. Maybe that's okay in the Web app industry where most of the jobs are just variants of the same thing so you have plenty to filter through, but the idea of turning down a job at somewhere you've been hoping to work like NASA or Google just because they don't use a tool you like is one of the dumbest things I've heard in a long time.

maaaats 12y ago

And during that degree, you learned the pro's and con's of every VCS and when to use which, I guess? I'm soon graduating myself, and I would never dream of believing that I know better than those with more experience than me.

UK-AL 12y ago
I've working for for quite a few years, I can tell you their are many clueless people who have racked up many years of experience. I really would not get your hopes up on how well things are run. In your career YOU WILL meet people who refuse to try new stuff because "this is the way we've always done it" and unreasonable reasons. I've met people who refuse to move on from visual source safe for example. The majority of your first years of your career will be learning how to navigate office politics, how to introduce change, how to get things done without getting fired, how to manipulate your boss to make the right decisions without imposing yourself on him. Those are more important than raw technical skill. Most of the value of 'experience' comes from those skills.
- gutnor 12y ago
  The reverse is true too. If a fresh graduate is moaning about us not using GIT directly in the interview, I may wonder how that guy will turn out. Not even a single day of work under his belt and he already is either afraid to move out of his comfort zone, or has already made up his mind about what technologies must be used. Thankfully, being cocky is somewhat tolerated even expected from overeager graduates. However, that eagerness turn into zealotry and, later on, obsolescence/cluelessness for a significant part of them. You know those guys, since they cause you the most problems at work. They built their reputation by embracing new stuff and now prevent everybody to move on.
_RPM 12y ago
Don't take this the wrong way, but there are certain qualities that go together with a team that uses SVN vs Git. I can tell a lot about you just by watch VCS you use.