74

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?

lortabac
  • 1,442
  • 13
  • 21
  • 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 Oct 02 '12 at 11:18
  • 1
    I wrote in Delphi for many years (still do occasionally) only the enterprise version came with source control and (I was told) it was problematic to use with certain source control systems due to some of the binary files. So I put off using source control until I swapped to Java. But then I'm a one man band so the problem isn't so great. – Jaydee Oct 02 '12 at 12:42
  • it's possible, but a good programmer can learn it in 30-60 minutes. – e-MEE Oct 02 '12 at 13:23
  • 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. – atamanroman Oct 02 '12 at 13:45
  • Is version control something learned in college? – Chad Harrison Oct 02 '12 at 13:55
  • I've once worked on a mainframe COBOL team that did not use version control. They used [Endevor](http://en.wikipedia.org/wiki/Endevor), which isn't quite the same thing. – user16764 Oct 02 '12 at 14:20
  • @Jaydee it's possible to shove Delphi in SVN, but it's a huge pain and sucks in every way imaginable.. but even then, I'd rather have that than no source control – Earlz Oct 02 '12 at 15:34
  • 1
    You might have well have asked if can you make a *good* cake without using chocolate. – Conrad Frix Oct 02 '12 at 15:38
  • 3
    @ConradFrix Carrot Cake :) – Chad Harrison Oct 02 '12 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 Oct 02 '12 at 18:03
  • 1
    @lortabac - You have a fallacy in your logic here... "...not looking for a solution to the problem of tracking changes a sign...?"... According to you, the candidate said they didnt use source control tools. Having *source control*, and using dedicated source control tools to implement it, are not the same thing. As others have pointed out, dropbox could be used for 'source control'. Or simply being dedicated to backups is 'source control'. You also assume the candidate has *problems* managing his code, which may not be the case - so why would he look for a solution to a non-problem? – GrandmasterB Oct 02 '12 at 21:15
  • @hydroparadise Depends on your professors. One of mine introduced us to subversion, but I never used it for anything the entire four years I was there, because it wasn't necessary. – Izkata Oct 02 '12 at 22:46
  • @Jaydee: The only binary files I can think of (other than output files) are .dfm files, and Delphi supports saving those as text instead; it's a setting somewhere. (last time I used it was back with Delphi 5 though, which is over a decade old, so this is probably out of date :P) – John Bartholomew Oct 02 '12 at 23:03
  • 1
    There are some operating systems where version control is transparent and it's quite common to find programmers not using explicit full-featured version control systems (or realising it). E.g. Files-11 on VMS or journaling with OS/400. Some systems you don't 'check-out' you just branch by copying the file(s) to your personal profile where they take precedence over the branch/integration/staging/production/live version. These systems are typically mainframe/multi-user systems where you program through a terminal session over the network anyway, so perhaps that's why version control is baked-in. – Lee Kowalkowski Oct 02 '12 at 23:34
  • 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. – Jeanne Pindar Oct 03 '12 at 00:20
  • Software development involves a number of different skills - e.g. code writing, code reading, architecture, VCS usage, etc. It's desirable to be good at as many of these skills as possible, and VCS usage is clearly an important one to be good at. Nevertheless, it is theoretically possible to be good at code writing, code reading and architecture without using version control. Not having ever used version control does suggest a degree of eremitism, and likely a lack of experience, but it doesn't tell you that someone can't write good code. The two skills are distinct. – Stuart Golodetz Jan 10 '13 at 02:00
  • (To illustrate the point, it's not unheard of for hobby programmers who work alone on solo projects without team experience to be relatively better at code writing and architecture than at reading other people's code - they're doing the former a lot more than the latter. Conversely, a developer who maintains large codebases for a living but never designs a full system may sometimes be a lot better at reading foreign code than at architecture - same principle. Both can be considered "good programmers", they just focus on different skills.) – Stuart Golodetz Jan 10 '13 at 02:07

28 Answers28

90

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.

pdr
  • 53,387
  • 14
  • 137
  • 224
  • 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 Oct 02 '12 at 10:35
  • @vartec: Fair point. I'll remove that. My perspective was different because I spent a lot of that time on VAX/VMS. – pdr Oct 02 '12 at 10:41
  • oh.. well, then you might be right. I've never used VAX beyond starting a telnet to a UNIX server ;-) – vartec Oct 02 '12 at 10:44
  • 8
    +1: I still work [here](http://programmers.stackexchange.com/questions/112270/is-it-unusual-for-a-small-company-15-developers-not-to-use-managed-source-vers). 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 Oct 02 '12 at 11:45
  • 1
    @Vartec - The software might be free but the hardware to run it on isn't. The cost to backup the data isn't free also. There might also be other reasons CVS might not be a situation that can be used, and thus, only paid software can be used. – Ramhound Oct 02 '12 at 13:49
  • if anything, you have to be better at your job without the safety net of a version control system of some sort (including manual backups of the source trees, which is rudimentary version control), as there's no way back to a prior state if things do get messed up. – jwenting Oct 02 '12 at 13:49
  • 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. – BIDeveloper Oct 02 '12 at 13:51
  • 1
    "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)." So in a sense you did have source control... or part of it anyway. – LarsH Oct 02 '12 at 14:50
  • 4
    +1 for the point about asking the right questions. I wondered what made him the best candidate too. – shambulator Oct 02 '12 at 15:05
  • @shambulator I agree that my interview process might be wrong. I had never interviewed anyone before, let alone someone who has been working in the IT industry for much longer than me. What made him the best candidate (so far) is a good portfolio, meeting all the project requirements (except VCS) and the fact that the other candidates lacked even the basics. It's hard to believe, but there are "senior" developers who have no idea what a design pattern is. Maybe my ad is in the wrong place, but the programming language used in this project (PHP) also helps attracting the wrong people. – lortabac Oct 02 '12 at 15:56
  • 2
    @lortabac, I can buy PHP developers not knowing about design patterns, but a PHP developer not using VCS is a huge red flag, especially considering how many PHP libraries are distributed via SVN on code.google.com and via git on GitHub. – mpdonadio Oct 02 '12 at 18:22
  • 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 Oct 02 '12 at 18:56
  • Manual backups gone wrong: ages ago, self study project in highschool, computer without a hard drive. My backup procedure consisted of copying all files from my 'working' diskette to my 'backup' diskette... Lost 20 hours of work the night before a presentation because I stuck the discs in in the wrong order. I'd never go without version control now. – Mr.Mindor Oct 02 '12 at 21:16
  • +1 for several points. Not using source control would be a big red flag for me, but not quite Game Over. but I want to echo that it's better to hire no-one, than to make a bad hire, because you spend the time training them, they mess things up, and then you have to fire them. Each of which is expensive and no fun for anyone. – GlenPeterson Oct 02 '12 at 22:59
  • 1
    I would bold the part about questioning your interview process, and since you're going to get the accept, add some links to good bloggers posts on good interview questions I know Jeff Atwood and Steve Yegge both have articles on this as well as Spolsky I believe. Good for future readers of this if you add those resources. – Jimmy Hoffa Oct 03 '12 at 01:37
49

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.

Explosion Pills
  • 1,929
  • 16
  • 22
  • 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 Oct 02 '12 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 Oct 02 '12 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 Oct 02 '12 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 Oct 02 '12 at 13:40
  • @andyboot I meant that he would be excited to learn the details; I know maybe 10% of what there is to know about `git`, and I use it every day. – Explosion Pills Oct 02 '12 at 14:26
  • @alroc I agree with you, and I use it for projects I work on alone .. That just seems to be one plausible reason for why one might not have run into version control. – Explosion Pills Oct 02 '12 at 14:27
  • 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. – Steven Evers Oct 02 '12 at 21:44
  • 1
    @SnOrfus I agree there are base skills programmers "should" have. But I feel the ability (and desire) to quickly pick up new skills can trump already knowing some skills. – Steven Oct 02 '12 at 22:46
  • @SnOrfus Steven just said this was the mark of a good programmer, not that it meant instant hire. You can't hire an 8 year old for a slew of reasons. I would argue that most 8 year olds could not pick up programming skills as quickly as an educated adult either. I agree with Steven that the ability to pick up skills (and adapt) is more important than skills alone in some situations. Of course it depends. If you need something done quickly and there is a tremendous disparity in skill, go with the skilled person. – Explosion Pills Oct 02 '12 at 23:01
  • Also bad: "I'm so crazy for version control that if you go on github, you can see every tweak I've made to my `.bashrc` file since 1992, which I first started tracking in RCS, then CVS, then Subversion ..." :) :) – Kaz Oct 04 '12 at 01:54
  • @Kaz Why is that bad? (I like versioned dotfiles myself, especially when they start getting complex.) – Marnen Laibow-Koser May 15 '18 at 16:11
34

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?

jfrankcarr
  • 5,082
  • 2
  • 19
  • 25
  • 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 Oct 02 '12 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 Oct 02 '12 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. – GrandmasterB Oct 02 '12 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. – GlenPeterson Oct 02 '12 at 22:55
  • We used tlib (http://www.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. Oct 03 '12 at 01:44
29

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • 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 Oct 02 '12 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 Oct 02 '12 at 22:06
19

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
vartec
  • 20,760
  • 1
  • 52
  • 98
  • 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 Oct 02 '12 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 Oct 02 '12 at 10:24
  • 2
    @pdr: I've used SVN as example, because a) it's been around for quite long time (so no excuse as "I've never heard of it"); b) it can be local (no "I don't trust no cloud"); c) that particular example is Tortoise, which is GUI and requires no editing nor anything like that – vartec Oct 02 '12 at 10:24
  • 2
    Also, I wouldn't say that `git` and `hg` aren't the easiest to understand by a VCS newbie. – vartec Oct 02 '12 at 10:29
  • 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 Oct 02 '12 at 10:33
  • 1
    @pdr: but that's **internal layout** of the repository. You don't really need to know that if you're not going to use that. Ok, in theory you could use `git` or `hg` only committing to locally, which would be very easy. However it's kind of like using a microscope to drive a nail. – vartec Oct 02 '12 at 10:40
  • 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 Oct 02 '12 at 10:45
  • 1
    I just thought I'd drop this one here: http://hginit.com/ – Xeo Oct 02 '12 at 11:24
  • 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 Oct 02 '12 at 11:36
  • 4
    I've never used version control either if you mean svn, git, etc. I'm a lone developer and what I make is internal. If I had to share with others I probably would learn and use one but I have my own methods. I have 15 years experience and more than one of my projects is in use by some very large companies. Just last week I installed git just to learn it. I find it convenient, period. It automates some of the things I alredy do so I'll probably start using it. But please don't say I'm not any good or experienced. – Rob Oct 02 '12 at 13:21
  • 3
    I don't want to be rude but imho a good dev is someone who want to/does automate things as much as possible, and as you say, "It automates some of the things I alredy do" – Guillaume86 Oct 02 '12 at 16:47
14

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
JesperE
  • 1,664
  • 13
  • 15
  • 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 Oct 02 '12 at 11:38
  • 12
    That's a gloriously sweeping statement and patently untrue. – Murph Oct 02 '12 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 Oct 02 '12 at 12:12
  • This is just another version of vartec's answer. – JeffO Oct 02 '12 at 12:15
  • Or you could call his answer another version of mine. I think I wrote my answer first. :) – JesperE Oct 02 '12 at 12:18
  • 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. – György Andrasek Oct 02 '12 at 12:24
  • 1
    I guess I fail to see how it is possible to efficiently cooperate with other programmers without using version control. I simply cannot wrap my head around that concept. If I applied to a job and found out that they didn't use source control, I would walk out the door immediately. – JesperE Oct 02 '12 at 13:08
  • 1
    @JesperE - I do it daily. We don't use source control outside of having a hard copy of what we released in the past. We use that as a baseline for future changes. Having used source control it was tough to adapt to not using "actual" source control software but it can be done. – Ramhound Oct 02 '12 at 13:52
  • @LordScree I am unable to upvote your comment more than once, so I'm adding this comment in support. I 100% agree with you. – Erick Robertson Oct 02 '12 at 16:00
  • 5
    Scary to see so many people here actually find the lack of source control as something normal or acceptable. – JesperE Oct 02 '12 at 18:07
  • 1
    It scares me to think of a programmer who doesn't do hobby projects that would benefit from source control. It seems a bit un progressive... – rogerdpack Oct 02 '12 at 20:30
  • @rogerdpack I honestly cannot figure out the meaning of that sentence. – JesperE Oct 03 '12 at 06:11
12

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.

Eoin Carroll
  • 652
  • 5
  • 12
  • 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 Oct 02 '12 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 Oct 02 '12 at 12:18
9

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.

scrwtp
  • 4,532
  • 1
  • 24
  • 29
4

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.

hippietrail
  • 263
  • 3
  • 10
Ms01
  • 117
  • 7
4

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.

brianmearns
  • 101
  • 3
4

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.

cdkMoose
  • 1,775
  • 9
  • 12
  • 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 Oct 02 '12 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. – James Khoury Oct 03 '12 at 00: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 Oct 03 '12 at 15:08
4

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.

ljs.dev
  • 157
  • 7
2

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.

ozz
  • 8,322
  • 2
  • 29
  • 62
2

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.

Yusubov
  • 21,328
  • 6
  • 45
  • 71
  • 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. – Dan Is Fiddling By Firelight Oct 02 '12 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 Oct 02 '12 at 23:14
2

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?

James
  • 1,825
  • 14
  • 15
  • 1
    Nothing new in this answer. – pdr Oct 02 '12 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 Oct 03 '12 at 01: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 Oct 03 '12 at 14:06
2

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.

Jason M. Batchelor
  • 151
  • 4
2

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?
DeveloperDon
  • 4,958
  • 1
  • 26
  • 53
2

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.

Kaz
  • 3,572
  • 1
  • 19
  • 30
  • 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 Oct 02 '12 at 22:48
  • Yes, and because they are new graduates, we "buy" that and move on. – Kaz Oct 02 '12 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 Oct 02 '12 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 Oct 02 '12 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. – DefenestrationDay Oct 03 '12 at 00:44
  • The job I was interviewing people for required the kind of programming in which linked lists may appear. (More importantly, there was complicated use of pointers.) The layers of software you're relying on to post your comment depend on implementations of linked lists: in the operating systems and middleware of your PC, the server, and all the network elements in between, and in the web browser and server. The people who don't use linked lists couldn't be bothered to make all that tech, so it had to be produced by the buffoons who use such 30-year-old (actually 60-year-old) techniques. – Kaz Oct 03 '12 at 01:15
1

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

TimothyAWiseman
  • 131
  • 3
  • ask the DBA to generate SQL scripts from the database and then he can put the scripts in source control. – linquize Feb 23 '13 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. – TimothyAWiseman Feb 24 '13 at 01:20
1

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.

PhilDin
  • 171
  • 3
1

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.

Jason Stackhouse
  • 101
  • 1
0

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.

mhoran_psprep
  • 2,328
  • 2
  • 16
  • 14
0

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.

THEn
  • 101
  • 3
  • 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 Oct 02 '12 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 Oct 02 '12 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 Oct 02 '12 at 23:01
0

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.

Joe McMahon
  • 239
  • 1
  • 5
0

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.

Filip Dupanović
  • 1,215
  • 8
  • 13
-1

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
tp1
  • 1,902
  • 11
  • 10
-2

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.

aserwin
  • 161
  • 6
-2

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?

Dominic Cronin
  • 397
  • 1
  • 9