Is it possible for a good programmer to have never used version control?

Question

I am looking for an expert programmer to help solve a difficult situation.

The interviews so far have been surprisingly disappointing. The best candidate so far is a very experienced programmer who has never used version control software.

The problem in itself might not be too serious because it is something which can be learned in a short time.

But there is a deeper aspect, which worries me:

How is it possible to actively develop software for 10-15 years without ever needing version control?

Is the fact itself of not looking for a solution to the problem of tracking changes a sign of a wrong attitude to programming?

Answer 1

I worked for about 11 years in companies that didn't use source control. We managed (mostly by commenting changes and keeping code on a central server that could be recovered to any date). We never really asked whether there was a better way. That said, this was also in the days when I had the entire MSDN library in book form on my desk.

Yes, there was programming before the internet.

I struggle to see how you can spend 10+ years in the industry now without having run into source control. But, I would have some sympathy, I would believe it was possible and I wouldn't reject the candidate on that one detail alone. I would probe and find out how the candidate has managed this.

Alternatively, I might question whether my interview process was the problem. In what way was he the best candidate? Are there other modern programming techniques that he doesn't have that I'm just not asking the right questions for? If I were asking the right questions, would another candidate shine?

As a final note though, don't be afraid to reject all candidates if you have concerns. It is time consuming to start over, but it's more time-consuming to hire the wrong person.

Answer 2

I think it depends on his attitude. If he is a very experienced programmer, and a good programmer, I think he would be able to pick up a version control system quickly. He may talk about it in two ways:

• Good

  I've never used version control, but I'm very excited to learn, and it seems like it would really help make development more efficient. I haven't needed it as much because I've worked on projects alone.

• Bad

  Version control is just a buzzword that's slowly dying in industry. I'm above version control.

Answer 3

Let me give you some perspective from doing software development in DOS and Windows for over 20 years.

Version control software in the Windows/PC world was often unreliable in the early-mid 90's. Visual Sourcesafe (VSS) was about the best Windows based one around but it could be quirky and many programmers hated it. Some teams simply wouldn't entertain their use after dealing with this situation.

Most other VCS options at the time weren't Windows based and, therefore, were rarely used in Windows development teams. Some of these were expensive solutions and open source solutions weren't as accepted as readily as they are today.

In many cases, during the late 90's, early 00's, if a Windows team didn't use VSS, they didn't use anything for source control aside from in-house conventions. A number of them still don't use a VCS in spite of the sophistication of Team Foundation Server (TFS) and great free options like git and SVN.

It's possible that someone who worked for years in a small Windows development team for years to have not used a VCS. I've interviewed at and even done contract work at some places that didn't use them or that were very haphazard about their use.

So, I don't think your candidate's lack of experience in this area is a definite 'no' but you probably want to delve more into their previous work situation to find out why this is missing from their experience. You'll also want to explore their attitude toward version control. Do they think it's a good idea but they weren't allowed to pursue it at their previous position or do they think it's a waste of time?

Answer 4

Can't you have version control without version control software? Ask how they managed their code. Maybe there was a home-grown system already in place.

Wanting to do things manually, reinventing the wheel and being resistent to change are nothing new to programming. Are you going to drool over a candidate that uses Visual Source Safe and "only" VSS?

When trying to find talent, you have to be able to tell the difference between: can't, haven't and won't.

Answer 5

There is no excuse for not using version control, even for a small project developed by single developer. Setting up local version control is beyond trivial, benefits huge. Any developer not knowing that cannot be considered good nor experienced.

As for companies perceiving version control as "novelty", which they are not willing to introduce:

• SCCS was released in 1972 (40 years ago)
• RCS was released in 1982 (30 years ago), and it's completely open source and free
• CVS was released in 1990 (21 years ago), also completely open source and free

Answer 6

A programmer who has never used version control has probably never cooperated with other programmers. I would probably never consider hiring such a programmer, regardless of any other credentials.

Answer 7

Seems like a red flag alright, but dig deeper into why he hasn't used it. I would still expect a solo developer to use version control especially in ten years but I'd be more forgiving of it than if he was working in a team and never even tried to bring in version control.

Answer 8

I wouldn't be religious about lack of version control experience. It's only a tool. In the end, you can pick up the basics of svn or git in a day or two. The rest you'll pick up with time. And I can't believe that any half-decent candidate wouldn't be able to fit in if he was to work in an environment that uses source control.

Using source control is more of a habit than a skill. Someone who has never used it may exaggerate the effort required and underestimate the benefits gained. After all, he did fine until now. Only after he actually uses source control, he'll grow to appreciate it.

The question you should ask is, how did he manage in the absence of source control? This could tell you something about him and how he manages his work.

Answer 9

You leave a lot of information out about his experience.

Basically, I would say that it's very possible that an programmer can have 10-15 years of experience without having to know about version control. Coding for 10 years is not equal to constantly learning new programming techniques for 10 years.

I'm very young and I have seen old and "experienced" software engineers whose code I would never want to touch. That said, he might be very talented, but I would guess from the little information given that he is not.

Good luck.

Answer 10

Personally, the most alarming thing to me is that the candidate has either never encountered version control systems as a concept, or has decided that it is not worth using. I find the first scenario highly unlikely, but if that is the case, then it leads me to assume the candidate has been significantly isolated for the duration of their career, which would cast serious doubt on their value as a part of a team. Specifically, they may very bizarre concepts about how to do certain things and not know any of the "right" way to do things.

If it's the second case, where they have actively decided against version control, then it makes me assume that they either never worked on anything of significance, or are extremely arrogant. Or, at best, they have really terrible ways of maintaining code like commenting out blocks, and attributing every line of code to an author, date, and bug number.

Answer 11

I am seeing some rather judgmental answers here that don't actually take into account the person being judged.

I personally find version control software to be an invaluable tool. But, we don't all have choice and control about the tools and processes that are used in our work environments. I have worked in Windows development since 1990. As posted by others, at that time there wasn't much available for VCS in Windows. We were not going to bring in UNIX servers just to get a VCS. Did that make me a bad programmer? Later in my career, I worked for a company with a vertical market commercial product where version control was a process not a tool. Did that make me a bad programmer? My last three jobs have all relied heavily on VCS tools. Does that make me a good programmer?

It would be great if we all got to use only the latest and greatest tools, languages and technologies. But the profession of software development doesn't always work that way. It is a little idealistic to say "I would leave the job immediately, if they didn't..." or "I would never take a job that didn't use..." or "I would force them to use...". We aren't all surrounded by an infinite supply of job opportunities where everything works exactly as we want. We have bills to pay and need a job, so we deal with what is around us.

In the end, the answer to your question is this: Judge this programmer by his skills, his philosophies and his decisions, not the (possibly misguided) decisions made by the people in charge at his prior jobs.

Answer 12

I never considered myself a "programmer" until I started making money doing it professionally.

I've made quite a bit of money creating systems which made clients even more money. Whether or not I am a "good" developer is subjective.

I can GSD (Get Something Done) rapidly, which for web development has usually pleased my clients. They may not see some ugly code behind the scenes, lack of comments, etc.

I hadn't used Git and didn't have a Github profile until this year, which I feel is way "behind the times" in terms of modern programmer standards. I've also just started doing Rails and Django projects after only having done PHP, Flash and iOS in the past. I've since landed contracts developing sites in both for clients and for me, it's not been too painful to learn something new at all at 30 years of age and a few years out of programming.

Too much in modern day society focuses on keeping up with the Jones' and caring what other people think. If you can break off those shackles and consider what you need for your software development (speed/time to market, optimized resource management, well documented code, scalability, etc), then that may matter a lot more than whether someone knows Mercurial, SVN, Git or any other version control systems.

I prefer to ask developer candidates what they are passionate about, what is the coolest system they have ever made in their own opinion and what they spend their free time developing their skills in. If people don't advance their skills in their own time, that scares me more than other things, but doesn't mean it has to scare you.

I think you have some great answers to this question already from the people here and that should help you make your own informed decision based on your requirements.

Answer 13

I find it incredible that a software professional has never used source control, and I'd be very nervous about hiring him.

What experience DOES he have. I would wonder what else he does not know that you have so far not found out.

What is your software development experience yourself? Are you in a position to ask him about architecture, design patterns, common software development problems, system performance questions, system security questions etc?

If he came out strong on that type of stuff, then maybe I could overlook the lack of source control knowledge.

Answer 14

How is it possible to actively develop software for 10-15 years without ever needing version control?

If he is coming from old school teams where small projects are managed by a single person, it is very possible. He may have 10 years of experience in the same technology set without learning and improving himself.

Is the fact itself of not looking for a solution to the problem of tracking changes a sign of a wrong attitude to programming?

If your candidate has been in a team development (at least 4 or more programmers) environment then it is a trivial question. However, there might be a work division between programmers, worked on modules solely assigned to them, which may reduce the need to source control the code.

However, not being heard about source control in internet era is really surprising situation. Thus, i would look at his willingness to learn new things (concerning your development environment) and how open is he to a dynamic work environment.

Answer 15

Is it possible for a good programmer to have never used version control?

Yes. Many small companies with self taught programmers don't use it.

How is it possible to actively develop software for 10-15 years without ever needing version control?

I have personally introduced version control to 2 small companies, have upgraded 1 medium company from something god awful to SVN (best option at the time) and worked in another small company that had only some VC, wrote their own VC solution for some code and had lots of code just not in any VC.

Is the fact itself of not looking for a solution to the problem of tracking changes a sign of a wrong attitude to programming?

Well it's not an instant fail, but I would certainly be asking lot's of follow-up questions. Things like:

Have you ever tried any VC software? What? What did you think of it? Is there any reason you wouldn't use it? What have you used before to manage code? Have you worked with anyone before on the same code base, and what methods did you use to avoid clashes?

Answer 16

I'd like to agree with Explosion Pills (but my rep's too low, atm...)... attitude is far more important.

There are a few things to look for, that I believe make for programming excellence:

1. Communication
2. Creativity
3. Compassion (say what?)

And, often times, more than a little OCD.

You know the type... the ones who sit there hammering on a problem, completely losing themselves in their code as they explore options. These are the ones who take notes as they go along, leave comments in their code to make sure that they understand their own logical paths (and to light the way for themselves or other programmers who might have to deal with the code in the future ... thus, "compassion" in my list above!), and quickly and clearly convey complex ideas to decision makers up the chain so that problems can be addressed efficiently.

An excellent programmer may have been stuck for years in an environment that either didn't buy into the idea of VCS, had bad experiences with VCS (a la VSS) which made them gun-shy to try new systems, but I would guarantee that an excellent programmer in that situation would still have set up some sort of routine to protect themselves from losing all their work to a couple bad design iterations.

The kind of programmer to beware of, therefore, is the one who claims to have never needed VCS, nor any measure of protection from inevitable screw-ups. Their attitude is one of "well, I built it, therefore it can't be wrong." Those are the ones I fear more than any novitiate straight out of college, because a novice can learn to appreciate the strengths of VCS because they realize how little they actually know.

Answer 17

Experience matters and you are correct that the mechanics of using source control tools can be learned pretty quickly. But you are right to see a red flag.

• Is your candidate isolated from the profession and its trends?
• Will the many other aspects of working in a team also need to be learned?

For me, the issue about version control is more of a symptom than the disease. The cause may vary, and be pretty benign. A lot of ad-hoc programmers just started doing what they thought made sense, starting with a few books about programming, and did not make a systematic study of software development. Sometimes, more so in the old days, computer science majors would graduate without ever having used a source control system because all their projects were individual projects and they went to companies with highly immature software process.

However he got there, if he has been a lone wolf for a decade or more, it may make living with people hard to do.

It might be worth asking if your candidate a few more probing questions.

• Tell me about a time you worked as part of a team?
• Tell me about a time when a team you worked on had a conflict between team members?
• Tell me about a time when you received code from another developer and carried his project forward?
• Tell me how you and other members of your team kept out of each others way when creating code together?
• Tell me about a customer reported problem related to a feature that used to work, but didn't work in a later version? How did you solve it?
• What do you like about working in a team?

He may also be accustomed to having nearly complete control over his methods, processes, and being in a role where he is the sole software expert. You will want someone who will be open to a new way of doing things. More questions:

• Tell me about a time you used or helped create a coding standard?
• What kinds of things do you want to see in a coding standard?
• How do you feel about rewriting someone else's code?
• Tell me about a time you were involved in peer reviews of software or documentation?
• Can you tell me about a proposal or contract for software development that you were involved in writing?
• Tell me about your favorite software manager or supervisor?
• Tell me about your favorite coworker or subordinate?

Answer 18

In the year 2012, for someone with 15 years of industry experience never to have used version control is a red flag. It might not be such a red flag if the year was 1982, or even 1992. But today, there had better be an excellent explanation for this puzzling gap in that developer's background.

Extraordinary situations require extraordinary explanations.

This is somewhat like a car mechanic who claims he's been fixing cars for 15 years, but never got so much as a spot of grease on himself.

Of course, smearing yourself with grease will not fix a transmission, and none of the steps in the repair manual call for such a thing, but that is not the point. The point is that being squeaky clean is gapingly inconsistent with what car mechanics actually look like when they are working. In that work, you get grease on yourself.

If you're interviewing someone experienced who admits he has no version control experience, he's probably exaggerating or fabricating some of his experience (and doesn't even know that version control is something widely used and important, and something he should also lie about!)

It's possible to see all kinds of jokers in interviews. I've seen people who cannot draw a diagram of a linked list, or write a function which inserts a node at the head of a linked list. Yet they claimed 20 years of work experience.

Even new grads from computer science can be expectd to have passive familiarity with version control, even if they haven't yet made extensive use of it.

Answer 19

I would find it strange, but not impossible for an experienced program to have never used dedicated source control. At one company I worked with, they used source control extensively for their traditional C# and VB code. But the pure database code (stored procedures and scripts as well as table definitions) were not in source control despite having two professional SQL Developers whose main job was to write, maintain, and execute pure database code. I championed source control for the database entities there and was only partially successful.

At another company, the development team was small (one man shop for a long time, then two). The previous developer's source control was have multiple copies of the source files with a date added at the end. Aside from lacking a better source control system, my predecessor there was definitely competent and a smart man.

Before I became I professional, I was a hobbyist and didn't use any source control at all, I vaguely knew what it was but didn't bother.

In short, I think it odd that a professional wouldn't be very familiar with it, but especially if he is used to very-small teams it is certainly possible to be competent without it. In hiring, I would not hold that against him. I would absolutely hold a reluctance to learn and begin using it on the job against him though...

Answer 20

My own 2c is that it depends on how he reacted to being asked about VC. The possible reactions might be:

1. Huh? What's that
2. No we did instead
3. No embarrassed shuffle, management wouldn't allow us
4. No embarrassed shuffle, but I investigated a little myself and thought it looked like something we should be doing.

In the case of 4, the guy would get a pass from me, he has the right attitude and will probably pick it up fine. In the case of 3, he gets credit for understanding that it's something that should be done but not as much credit as 4. If he was able to name a couple of factoids about VC (list some of the VC packages out there) I'd take that as evidence of some curiosity and might pass him.

If he answered 1 or 2, that is, if he did know and didn't care to know about VC, I would seriously question the judgement of the candidate. There will be other tools (bug tracking, quality metrics, build automation etc. etc.) that he'll need to work with and you'll probably find you have an uphill battle on all of these issues if he's not open to trying new approaches.

Like most people here, I think it would be unfair to disadvantage the candidate just because their employer wasn't up to speed; for me, it all depends on how they reacted to it.

Answer 21

Writing what's changed is good when looking back. It has saved me a lot of times when figuring what's wrong and loads of problems were fixed quickly because I had it written down. In my opinion, it's good to keep an log. Especially if you are programming with more people than yourself.

If you are writing a web app, you can keep adding feautures with no version control because you are constantly just adding new things to it. But maybe you will write a log or a news post with the things that's new.

It's all about what you are programming on.

Answer 22

I have worked at locations where the process of getting software approved was 12 to 18 months. If it wasn't already on the list of approved software there was no way to get it on the machines. CD/DVD drives were locked down, and the machines were not connected to the internet.

The first place I ran into source control the solution was to have a developer write their own, by the time it was ready for testing the multi-year project was winding down. They gambled that writing it from scratch was faster than the approval process.

The 2nd place that I ran into this problem did use source control for the first few months, but then the customer wanted all development done on their internal network. They again locked down everything, so it was back to lots of zipped folders.

I know developers that have only worked in these conditions. They want to use these tools, they would love to use these tools, but they are not allowed to use these tools.

Investigate why they have not used them. Not understanding the procedures because of zero experience, is far different than rejecting the tools.

Answer 23

I am developing for last 15 years. Used the version control only few times. I am still using my own scheduled scripts and programs to backup all development folders incrementally. I don't know what to say If somebody asks me If I use Version Control. I have never been in need of version control system, I always worked on tiny projects. I mean I am not the best programmer out there but I am sure I am not the worst. Most of the time I am embarrassed to tell people that I don't regularly use version control system, but that is how it is for me.

Answer 24

Speaking from my experience as a programmer on IBM MVS systems: for the first ten years of my working career, the operating system I worked with had exactly one versionable filetype available to the programmer: the generation data set. This was essentially a file with a fixed number of versions, and you had to remember what version was what - pretty much useless for modern version control. Coupled with a filesystem that had no real directories, just more or fewer (8-character) qualifiers, the concept of a source-code management system was completely foreign to anyone working in that environment.

I didn't actually see a source-code control system until I moved to SunOS 3 and got to use RCS. At that point I was an extremely facile IBM systems programmer, highly productive, and very good at my job. All versioning was handled by copying backups to tape, and recording what was where.

If I were still working on mainframes at this point, it's entirely possible that I might still have never have been exposed to a formal version control system; the alternatives that are specifically supported are ClearCase and Rational, neither of which is free (and in point of fact are both quite expensive).

So saying that someone is by definition incompetent because he or she has never used version control is a specious argument. It is necessary to dig in and look at the details. If they claim to be a Linux/Unix/Mac OS developer but have never ever used version control, it speaks less well for them, and you may have to weigh whether their overall experience is such a good fit that you'd be willing to train them in modern software engineering. If they're and old-school mainframe programmer - and that's what you need - then concentrate on whether they have precisely the needed programming skills you want, and resign yourself to the fact that you'll need to teach this to them. As others have said, their response to the concept will be the deciding factor in that case.

Answer 25

Pretty please! The entirety of our community doesn't live in highly-developed social communities where geeky hangouts and hacky events are overly abundant, neither do we all work in software development companies and some of us cannot even find relevant or up-to-date published resources in our native languages, printed or online, let ever encounter a fellow programmer in the flesh.

For all I can understand, if he's an experienced software developer as you say, then he's likely been a lone wolf working as a freelancer for small businesses.

Answer 26

There are few possible reasons to not use version control:

1. Working in companies which are not doing software development as their main line of business.
2. Or if the developer has decided to use some other system - only valid for experienced ones.
3. Or if the developer has not yet learned how each system works
4. Or it's attitude problem against the tools which they're unfamiliar

But you should be careful when you meet people who assume:

1. That there is only one way to do something
2. Or that every programmer must do it the same way they're doing
3. Or that the practices people are using are easy to change

Answer 27

Just as possible as it is for a poor programmer to be an expert on version control. My point is, I don't know what version control does for your programming skills or problem solving abilities. It is a question of experience. Many smaller shops either don't use it or leave it to the indaviduals (who are often working solo) to figure it out for themselves.

Answer 28

I think it's not so much a question of "How is it possible to actively develop software for 10-15 years without ever needing version control?", but "How is it possible to actively develop software for the last 10-15 years without ever needing version control?".

Sure programming is possible without version control, but a professional ought to be familiar with the current state of the art, and be able to select the right tools to do the job. Failing to use the appropriate version management software makes your work risky and unreliable, and one of the reasons you want to hire a professional developer is that they ought to be able to manage risk.

A code-base that is properly annotated in a VCS is worth far more than one which is not. The reason for every change can be tracked and understood, making it possible for maintainers to get a deeper grasp of what they need to know. Failing to do this is unprofessional, and the only excuse for it would be if he/she had been constrained by poor managers at his/her previous job. Even then, shouldn't they have used versioning for their private projects?