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?

  • 26
    Who says he did not need version control? He needed it, and I guess he did it manually. Said that, a programmer who does this seems to be very resistant against learning something new - be prepared for that.
    – Doc Brown
    Commented Oct 2, 2012 at 11:18
  • 6
    @e-MEE depends, you may learn update/resolve/commit in 30-60 minutes but no one learns how a (d)vcs works in an hour. Most ppl who use it for years still don't really get it. Commented Oct 2, 2012 at 13:45
  • 3
    @ConradFrix Carrot Cake :) Commented Oct 2, 2012 at 16:01
  • 8
    It is possible for a good programmer to have never used version control, if the calendar says that today is 1981.
    – Kaz
    Commented Oct 2, 2012 at 18:03
  • 7
    This sounds like a classic case of someone who does not have 10 years of experience, but rather 1 year of experience repeated 10 times. Commented Oct 3, 2012 at 0:20

28 Answers 28


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.

  • 17
    +1, it's an interesting answer. However, I don't quite agree with "in those days, source control cost good money". RCS has been around for 30 years, CVS - 21 years; Both are open source.
    – vartec
    Commented Oct 2, 2012 at 10:35
  • 8
    +1: I still work here. We're finally getting managed source control this year (largely due to me). I don't think we're all terrible developers as a result of not having it until now, but I'm sooooo damn glad it's coming in
    – m-smith
    Commented Oct 2, 2012 at 11:45
  • 3
    If the candidate understands the principles of Source Control then I see no problem. An experienced developer should be able to pick up the "syntax" of whichever system you use pretty quick. One question I would ask - is all this experience at one site? If so then maybe he didn't have the authority to be able to introduce a system. If his experience has been with different companies then I'd dig around a bit further. The number of companies, with development teams, which do not use source control must be minimal nowadays. Commented Oct 2, 2012 at 13:51
  • 4
    +1 for the point about asking the right questions. I wondered what made him the best candidate too. Commented Oct 2, 2012 at 15:05
  • 3
    @Ramhound: and you believe when doing source control manually you need less hardware and less time for backups? To my experience, the opposite is quite true.
    – Doc Brown
    Commented Oct 2, 2012 at 18:56

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.

  • 17
    I would agree that it could have been a valid 10 years ago, but nowadays? I'd say it not "Good/Bad" but "Bad/Horrible"
    – vartec
    Commented Oct 2, 2012 at 11:19
  • 24
    Even if you're working alone, using a VCS is extremely valuable. After having a project go from "it's almost working" to never getting it to work right again, and not having any way to revert back to the "almost working" version, I vowed to put everything into a VCS no matter how small the project.
    – alroc
    Commented Oct 2, 2012 at 12:36
  • 11
    " I'm very excited to learn," - This isn't some expensive commercial product like Coherence. Source control is something anyone can become acquainted with. If you read any blogs on software development you should be aware of it.
    – andy boot
    Commented Oct 2, 2012 at 13:08
  • 8
    +1 for this answer. It's not the mark of a good programmer that he/she has every skill. It's that he/she can pick up any skill required.
    – Steven
    Commented Oct 2, 2012 at 13:40
  • 2
    @Steven: No. Not at all. By that logic, an 8 year old could be hired because they could pick up programming. IMO there are, or should be, base skills required to be considered a programmer. Proficiency in a programming language is one, knowledge and use of any VCS is another. There are more. Commented Oct 2, 2012 at 21:44

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?

  • 18
    VSS wasn't "quirky" - it was just plain bad. Corrupted repositories & data loss were common, but you might not discover it for weeks or months after the problem happened, unless you ran a daily integrity check (and good luck recovering from it even then). File locking & sharing were atrocious. Programmers hated it because it made their lives hell - the exact opposite of what a VCS should do.
    – alroc
    Commented Oct 2, 2012 at 12:34
  • @alroc - Believe it or not, there were some less reliable and more quirky ones out there. I had the misfortune of using one circa 1995. I never had a serious problem with VSS reliability but I did hear tales of woe from others. I know some organizations who stopped using any VCS after bad experiences with VSS.
    – jfrankcarr
    Commented Oct 2, 2012 at 14:37
  • UGGH, we tried Powerbuilder's source control back in the day. It actively caused us to lose source code. PB would crash, and any checked out pbl became inaccessable to everyone else. What a joke that was. Commented Oct 2, 2012 at 21:00
  • I worked for 1.5 years at a shop that used used Visual Source Safe. One of the best programmers would ruin the repository about every other time he tried to check in his code over the phone (yes, this was a while ago). One of my least favorite VCS systems. Commented Oct 2, 2012 at 22:55
  • We used tlib (burtonsys.com/index.html) at one job in a DOS environment. Granted this was in 2005, but it seemed like they had been using it for a while.
    – Doug T.
    Commented Oct 3, 2012 at 1:44

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.

  • Before I found about version control and it's usefulness (I discovered it about after 2 years of non-professional, hobbyist programming) it was not uncommon for me to have five folders with "backups" of project milestones - a primitive VCS.
    – orlp
    Commented Oct 2, 2012 at 16:35
  • "Can't, haven't, won't, and wasn't allowed to"? I've heard of places that wouldn't agree to run source control because they liked the jungle that was their network drives.
    – Philip
    Commented Oct 2, 2012 at 22:06

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
  • 21
    Not sure SVN is the best example for "beyond trivial" setup. Some of those files you have to edit, direct in the repo, can be fiddly. Setting up a local DVCS is beyond trivial. And setting up a BitBucket/GitHub account and cloning repos from it isn't much more complicated
    – pdr
    Commented Oct 2, 2012 at 10:21
  • 9
    @vartec: What's beyond trivial is git init. The page linked could make me run away as it feels quite complicated.
    – maaartinus
    Commented Oct 2, 2012 at 10:24
  • 7
    @vartec: I would argue that git and hg are easier to understand by a VCS newbie than someone who has been using centralised VCS for years, and easier than CVCS for the newbie. Just look at the Repository Layout section on that page as if you didn't understand it already. Then think "I have a repository here, I want to clone it here."
    – pdr
    Commented Oct 2, 2012 at 10:33
  • 8
    @vartec: Hmm. Can't agree. I like to be able to branch and clone even when I'm working alone. Sometimes I have ideas. And sometimes they're bad ones :).
    – pdr
    Commented Oct 2, 2012 at 10:45
  • 4
    I have worked in companies where management rejected versión control. It was not an option. And we did interesting and complex projects. I don't think I am a worst developer because of that. At home I don't use it neither, so far although I admit I have considered it.
    – Picarus
    Commented Oct 2, 2012 at 11:36

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.

  • 34
    I disagree. Not using source control would require a much higher level of co-operation with other programmers than normal. I might even go as far as to say that if you've come from an environment where there is no source control, then you truly know the importance of co-operation
    – m-smith
    Commented Oct 2, 2012 at 11:38
  • 12
    That's a gloriously sweeping statement and patently untrue.
    – Murph
    Commented Oct 2, 2012 at 11:42
  • 3
    I simply would not want to hire a programmer who doesn't know how to use modern tools. He/she may know how to write incredibly nice code, but I would consider at least basic knowledge of version control an absolute requirement.
    – JesperE
    Commented Oct 2, 2012 at 12:12
  • 6
    A lot of people around here seem to be confusing not having been exposed to VCS and actively refusing to use it at their new job. What if it simply never occurred to him/them at their previous workplace or was verboten by management? That said, this would be a critical issue if I was doing the hiring, and their willing to learn would be a hard requirement for me. Commented Oct 2, 2012 at 12:24
  • 5
    Scary to see so many people here actually find the lack of source control as something normal or acceptable.
    – JesperE
    Commented Oct 2, 2012 at 18:07

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.

  • 6
    +1: I'd be horrified if I was unemployable simply because my current manager didn't see the importance of source control. At least I do use source control for all my personal projects, so I wouldn't be totally screwed by this situation...
    – m-smith
    Commented Oct 2, 2012 at 11:50
  • 2
    @LordScree - Working on a high-volume website may be difficult to do on your own, but you can still learn to use source control outside of your job.
    – JeffO
    Commented Oct 2, 2012 at 12:18

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.

  • 4
    Definitely need to find out how he managed updates, releases etc without version control
    – ChrisF
    Commented Oct 2, 2012 at 11:43

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.


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.


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.

  • 4
    If you have only worked with idiots for 15 years, and not done any intelligent open source on the side, that will probably reflect on your skill set and attitude. People are shaped by their environments. If that wasn't the case, why would we even look at someone's employment history.
    – Kaz
    Commented Oct 2, 2012 at 23:18
  • @Kaz We look at their employment history not for their co-workers input but their own. Can't judge someone on the area they grew up in otherwise we might start interviewing neighbours too. Commented Oct 3, 2012 at 0:32
  • Shaped by our environments, yes, but we are not defined by our environments. I am just suggesting that OP take a full view of the programmer and not make a harsh judgment based on one criteria.
    – cdkMoose
    Commented Oct 3, 2012 at 15:08

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.


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.


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?

  • 1
    Nothing new in this answer.
    – pdr
    Commented Oct 2, 2012 at 12:52
  • 1
    Smart self-taught programmers today all know about version control and use it. The rest have their heads stuck somewhere.
    – Kaz
    Commented Oct 3, 2012 at 1:26
  • @Kaz Disagree. I think that's what we like to think, but I've meet programmers I'd consider smart who didn't, as my personal experience says. Not using version control is a big warning sign that they might have their head stuck somewhere [charming phrase :-) ] but it's not always the case.
    – James
    Commented Oct 3, 2012 at 14:06

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.


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.

  • Not everyone reads programming blogs/etc. In particular, someone who's career has been entirely with a single legacy platform isn't going to find much of immediate value from them. How many Mainframe/COBOL/RPG (not gaming) software blogs are you aware of? Programming those platforms hasn't really changed much in the last 30 years, and many of the best sources of information for them are almost certainly still in dead tree format. If programming is your job, vs what your life revolves around, when working in those areas reading tech blogs/etc isn't going to have much short term ROI. Commented Oct 2, 2012 at 14:27
  • 1
    Even on a one-person project, you benefit from version control. If a bug is found, you are able to state "that was introduced in version 3.13", and so users of 3.13 and onward are affected. You can also easily make a patch for various versions, for people who don't want to migrate to the latest. If you can do these things without version control, then you are doing de facto, ad hoc version control. You expect your users to use your software to eliminate laborious and error-prone manual work, but you, the programmer, do not do that yourself! LOL.
    – Kaz
    Commented Oct 2, 2012 at 23:14

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?

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.

  • The best you can consistently hope for from new graduates is, "Oh, I've heard of that". We had a one week introduction to what it was, based around Subversion, but never used version control for anything.
    – Izkata
    Commented Oct 2, 2012 at 22:48
  • Yes, and because they are new graduates, we "buy" that and move on.
    – Kaz
    Commented Oct 2, 2012 at 22:51
  • "passing familiarity" (what I think you meant in the answer) implies they've used it at some point; I'm pointing out you can't even expect that.
    – Izkata
    Commented Oct 2, 2012 at 22:52
  • I would say that if CS graduates have not used version control, then their alma mater's department has failed to implement an adequate, mandatory software engineering course in which undergrads not only learn about software engineering concepts, but also work on a team project (with version control and all). I would like to have a word or two with the head of that department.
    – Kaz
    Commented Oct 2, 2012 at 23:31
  • I've been professionally programming for almost 20 years. I know what a linked list is, and why they would be used. I have never used one, and would probably struggle with the finer points of writing your function. I think just because you use 30 year-old techniques, to say that everyone else should is a little unfair. Commented Oct 3, 2012 at 0:44

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...

  • ask the DBA to generate SQL scripts from the database and then he can put the scripts in source control.
    – linquize
    Commented Feb 23, 2013 at 10:16
  • @linquize Oh agreed. That is one of the better ways to do it (though not quite the only one). I simply mention that I have met many competent professionals and a skilled amateur that did not have experience with source control, especially on the DBA side. In hiring, I would hold a reluctance to learn source control against a potential new hire, but I would not be overly surprised at not having used it before, especially if they were used to a small team and were mostly on the database side. Commented Feb 24, 2013 at 1: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.


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.


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.

  • Nothing new in this answer.
    – pdr
    Commented Oct 2, 2012 at 12:54

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.

  • I've had an opposite experience: some people give me a funny look when I say that I use version control on small projects where I'm the only developer. Maybe less so nowadays, because version control is used for hosting open source projects and so it is understood as a deployment method.
    – Kaz
    Commented Oct 2, 2012 at 22:55
  • 2
    You should change your attitude and look into version control because it lets you do many things easily. For instance the git version control system has an automated workflow (git bisect) for finding a regression bug. This performs the binary searching through the version history of a project to try find the changeset which introduced the bug. All you do is rebuild, run your test, and inform git whether it was good or bad; it then selects and retrieves the baseline to be tested next.
    – Kaz
    Commented Oct 2, 2012 at 22:58
  • In git you can make some experimental changes and then put them into a stash. Your work is reverted to the original and the changes are saved. Later you can explore your stash and re-apply those changes to keep experimenting with them, or throw them away. And of course any decent version control system has branching, with which you can do things like develop a feature, in isolation, of a stable version. Or go back and fix a bug in a release (to give a patch to customers) and easily merge that change to the current development version also.
    – Kaz
    Commented Oct 2, 2012 at 23:01

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.


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.


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

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.


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?

Not the answer you're looking for? Browse other questions tagged or ask your own question.