É possível que um bom programador nunca tenha usado o controle de versão? [fechadas]

Estou procurando um programador especialista para ajudar a resolver uma situação difícil.

As entrevistas até agora foram surpreendentemente decepcionantes. O melhor candidato até agora é um programador muito experiente que nunca usou software de controle de versão.

O problema em si pode não ser muito sério, porque é algo que pode ser aprendido em pouco tempo.

Mas há um aspecto mais profundo, que me preocupa:

Como é possível desenvolver ativamente o software por 10 a 15 anos sem precisar de controle de versão?

O fato de não procurar uma solução para o problema de rastreamento muda um sinal de uma atitude errada em relação à programação?

Trabalhei por cerca de 11 anos em empresas que não usavam o controle de origem. Conseguimos (principalmente comentando alterações e mantendo o código em um servidor central que poderia ser recuperado para qualquer data). Nós nunca realmente perguntamos se havia uma maneira melhor. Dito isto, também foi nos dias em que eu tinha toda a biblioteca do MSDN em forma de livro na minha mesa.

Sim, havia programação antes da internet.

Eu luto para ver como você pode passar mais de 10 anos no setor agora sem ter passado pelo controle de origem. Mas, eu teria alguma simpatia, acreditaria que era possível e não rejeitaria o candidato apenas por esse detalhe. Gostaria de investigar e descobrir como o candidato conseguiu isso.

Como alternativa, eu poderia questionar se meu processo de entrevista foi o problema. De que maneira ele era o melhor candidato? Existem outras técnicas modernas de programação para as quais ele não tem e que não estou fazendo as perguntas certas? Se eu estivesse fazendo as perguntas certas, outro candidato brilharia?

Como nota final, porém, não tenha medo de rejeitar todos os candidatos, se você tiver preocupações. É demorado começar de novo, mas é mais demorado contratar a pessoa errada.

Eu acho que depende da atitude dele. Se ele é um programador muito experiente e um bom programador, acho que ele seria capaz de escolher um sistema de controle de versão rapidamente. Ele pode falar sobre isso de duas maneiras:

• Boa

  Eu nunca usei o controle de versão, mas estou muito animado para aprender e parece que isso realmente ajudaria a tornar o desenvolvimento mais eficiente. Não precisei tanto disso porque trabalhei em projetos sozinhos.

• Ruim

  O controle de versão é apenas uma palavra da moda que está morrendo lentamente na indústria. Estou acima do controle de versão.

Deixe-me dar uma perspectiva do desenvolvimento de software no DOS e Windows há mais de 20 anos.

O software de controle de versão no mundo Windows / PC geralmente não era confiável no início dos anos 90. O Visual Sourcesafe (VSS) era o melhor baseado no Windows, mas poderia ser peculiar e muitos programadores odiavam. Algumas equipes simplesmente não aceitariam seu uso depois de lidar com essa situação.

A maioria das outras opções de VCS da época não eram baseadas no Windows e, portanto, raramente eram usadas nas equipes de desenvolvimento do Windows. Algumas dessas eram soluções caras e as soluções de código aberto não eram tão aceitas tão prontamente quanto são hoje.

Em muitos casos, no final dos anos 90, início dos anos 00, se uma equipe do Windows não usava o VSS, não usava nada para controle de origem, além das convenções internas. Alguns deles ainda não usam um VCS, apesar da sofisticação do Team Foundation Server (TFS) e de ótimas opções gratuitas, como git e SVN.

É possível que alguém que trabalhou por anos em uma pequena equipe de desenvolvimento do Windows por anos não tenha usado um VCS. Eu entrevistei e até fiz contrato de trabalho em alguns lugares que não os usavam ou que eram muito aleatórios sobre o uso deles.

Portanto, não acho que a falta de experiência de seu candidato nessa área seja um "não" definitivo, mas você provavelmente deseja se aprofundar na situação de trabalho anterior para descobrir por que isso está faltando na experiência deles. Você também desejará explorar a atitude deles em relação ao controle de versão. Eles acham que é uma boa ideia, mas não foram autorizados a segui-la na posição anterior ou acham que é uma perda de tempo?

Você não pode ter controle de versão sem o software de controle de versão? Pergunte como eles gerenciaram seu código. Talvez já existisse um sistema caseiro.

Desejar fazer as coisas manualmente, reinventar a roda e resistir à mudança não são novidade na programação. Você vai babar sobre um candidato que usa o Visual Source Safe e o "apenas" VSS?

Ao tentar encontrar talentos, você deve saber a diferença entre: não pode, não tem e não quer.

Não há desculpa para não usar o controle de versão, mesmo para um projeto pequeno desenvolvido por um único desenvolvedor. A configuração do controle de versão local está além do trivial, beneficia imensamente. Qualquer desenvolvedor que não saiba que não pode ser considerado bom nem experiente.

Quanto às empresas que percebem o controle de versão como "novidade", as quais não desejam introduzir:

• O SCCS foi lançado em 1972 ( 40 anos atrás )
• O RCS foi lançado em 1982 ( há 30 anos ), e é totalmente de código aberto e gratuito
• O CVS foi lançado em 1990 ( 21 anos atrás ), também completamente de código aberto e gratuito

Um programador que nunca usou o controle de versão provavelmente nunca colaborou com outros programadores. Eu provavelmente nunca consideraria contratar um programador, independentemente de outras credenciais.

Parece uma bandeira vermelha, mas aprofunde-se mais no porque ele não a usou. Eu ainda esperaria que um desenvolvedor solo usasse o controle de versão, especialmente em dez anos, mas eu perdoaria mais do que se ele estivesse trabalhando em equipe e nunca tentasse trazer o controle de versão.

Eu não seria religioso sobre a falta de experiência em controle de versão. É apenas uma ferramenta. No final, você pode aprender o básico do svn ou git em um dia ou dois. O resto você vai pegar com o tempo. E não acredito que qualquer candidato meio decente não seria capaz de se encaixar se trabalhasse em um ambiente que usa controle de origem.

Usar o controle de origem é mais um hábito do que uma habilidade. Alguém que nunca o usou pode exagerar o esforço necessário e subestimar os benefícios obtidos. Afinal, ele se saiu bem até agora. Somente depois que ele realmente usar o controle de origem, ele crescerá para apreciá-lo.

A pergunta que você deve fazer é: como ele conseguiu na ausência de controle de origem? Isso pode lhe dizer algo sobre ele e como ele gerencia seu trabalho.

Você deixa muita informação de fora sobre a experiência dele.

Basicamente, eu diria que é muito possível que um programador tenha 10 a 15 anos de experiência sem ter que saber sobre o controle de versão. Codificar por 10 anos não é igual a aprender constantemente novas técnicas de programação por 10 anos.

Sou muito jovem e já vi engenheiros de software antigos e "experientes", cujo código eu nunca gostaria de tocar. Dito isto, ele pode ser muito talentoso, mas eu acho que pelas poucas informações, uma vez que ele não é.

Boa sorte.

Pessoalmente, a coisa mais alarmante para mim é que o candidato nunca encontrou sistemas de controle de versão como um conceito ou decidiu que não vale a pena usá-lo. Acho o primeiro cenário altamente improvável, mas, se for esse o caso, leva-me a supor que o candidato tenha sido significativamente isolado durante a carreira, o que levantaria sérias dúvidas sobre seu valor como parte de uma equipe. Especificamente, eles podem ter conceitos muito bizarros sobre como fazer certas coisas e não conhecer a maneira "certa" de fazer as coisas.

Se for o segundo caso, onde eles decidiram ativamente contra o controle de versão, então eu me assumo que eles nunca trabalharam em algo significativo ou são extremamente arrogantes. Ou, na melhor das hipóteses, eles têm maneiras realmente terríveis de manter código como comentar blocos e atribuir cada linha de código a um autor, data e número de bug.

Estou vendo algumas respostas bastante julgadoras aqui que não levam em consideração a pessoa que está sendo julgada.

Pessoalmente, acho que o software de controle de versão é uma ferramenta inestimável. Porém, nem todos temos escolha e controle sobre as ferramentas e processos usados ​​em nossos ambientes de trabalho. Trabalho no desenvolvimento do Windows desde 1990. Conforme publicado por outros, naquele momento não havia muito disponível para o VCS no Windows. Não íamos trazer servidores UNIX apenas para obter um VCS. Isso me fez um programador ruim? Mais tarde na minha carreira, trabalhei para uma empresa com um produto comercial no mercado vertical, onde o controle de versão era um processo, não uma ferramenta. Isso me fez um programador ruim? Meus últimos três trabalhos se apoiaram fortemente nas ferramentas VCS. Isso me torna um bom programador?

Seria ótimo se todos pudéssemos usar apenas as melhores e mais recentes ferramentas, linguagens e tecnologias. Mas a profissão de desenvolvimento de software nem sempre funciona dessa maneira. É um pouco idealista dizer "eu deixaria o emprego imediatamente, se não o fizessem ..." ou "eu nunca aceitaria um emprego que não usasse ..." ou "eu os forçaria a usar. .. " Não estamos todos cercados por uma oferta infinita de oportunidades de emprego, onde tudo funciona exatamente como queremos. Como temos contas a pagar e precisamos de um emprego, lidamos com o que está ao nosso redor.

No final, a resposta para sua pergunta é a seguinte: julgue esse programador por suas habilidades, suas filosofias e suas decisões, não as decisões (possivelmente equivocadas) tomadas pelas pessoas encarregadas de seus empregos anteriores.

Eu nunca me considerei um "programador" até começar a ganhar dinheiro fazendo isso profissionalmente.

Ganhei bastante dinheiro criando sistemas que tornaram os clientes ainda mais lucrativos. Se eu sou ou não um desenvolvedor "bom", é subjetivo.

Posso fazer o GSD (Get Something Done) rapidamente, o que para o desenvolvimento da web geralmente agrada meus clientes. Eles podem não ver algum código feio nos bastidores, falta de comentários etc.

Eu não tinha usado o Git e não tinha um perfil no Github até este ano, o que eu acho que está muito atrasado em termos de padrões modernos de programadores. Eu também comecei a fazer projetos Rails e Django depois de ter feito PHP, Flash e iOS no passado. Desde então, consegui contratos para desenvolver sites, tanto para clientes quanto para mim, não tem sido muito doloroso aprender algo novo aos 30 anos de idade e alguns anos fora da programação.

Muito na sociedade moderna se concentra em acompanhar os Jones e em se preocupar com o que as outras pessoas pensam. Se você pode romper esses grilhões e considerar o que precisa para o desenvolvimento de seu software (velocidade / tempo de colocação no mercado, gerenciamento otimizado de recursos, código bem documentado, escalabilidade etc.), isso pode ser muito mais do que saber se alguém conhece Mercurial, SVN , Git ou qualquer outro sistema de controle de versão.

Prefiro perguntar aos candidatos a desenvolvedor pelo que eles são apaixonados, qual é o sistema mais legal que eles já criaram em sua própria opinião e em que gastam seu tempo livre desenvolvendo suas habilidades. Se as pessoas não desenvolvem suas habilidades em seu próprio tempo, isso me assusta mais do que outras coisas, mas não significa que tem que te assustar.

Eu acho que você já tem ótimas respostas para essa pergunta das pessoas aqui e isso deve ajudá-lo a tomar sua própria decisão informada com base em seus requisitos.

Acho incrível que um profissional de software nunca tenha usado o controle de fonte e eu ficaria muito nervoso em contratá-lo.

Que experiência ele tem. Gostaria de saber o que mais ele não sabe que você ainda não descobriu.

Qual é a sua experiência em desenvolvimento de software? Você está em condições de perguntar a ele sobre arquitetura, padrões de design, problemas comuns de desenvolvimento de software, questões de desempenho do sistema, questões de segurança do sistema etc.?

Se ele se destacasse nesse tipo de coisa, talvez eu pudesse ignorar a falta de conhecimento sobre controle de origem.

É possível que um bom programador nunca tenha usado o controle de versão?

Sim. Muitas pequenas empresas com programadores autodidatas não o utilizam.

Como é possível desenvolver ativamente o software por 10 a 15 anos sem precisar de controle de versão?

Eu introduzi pessoalmente o controle de versão para duas pequenas empresas, atualizei uma empresa de médio porte de algo horrível para SVN (melhor opção na época) e trabalhei em outra empresa pequena que tinha apenas um VC, escreveu sua própria solução de VC para algum código e tinha muito código simplesmente não em nenhum VC.

O fato de não procurar uma solução para o problema de rastreamento muda um sinal de uma atitude errada em relação à programação?

Bem, não é um fracasso instantâneo, mas eu certamente faria muitas perguntas de acompanhamento. Coisas como:

Você já experimentou algum software de VC? O que? O que você pensou disso? Existe algum motivo para você não usá-lo? O que você usou antes para gerenciar código? Você já trabalhou com alguém na mesma base de código e quais métodos você usou para evitar conflitos?

Eu gostaria de concordar com os comprimidos de explosão (mas meu representante é muito baixo, atm ...) ... a atitude é muito mais importante.

Há algumas coisas a serem procuradas, que acredito serem excelentes para a programação:

1. Comunicação
2. Criatividade
3. Compaixão (diga o que?)

E, muitas vezes, mais do que um pouco de TOC.

Você conhece o tipo ... aqueles que ficam sentados lá, martelando em um problema, perdendo-se completamente em seu código enquanto exploram opções. São eles que fazem anotações à medida que avançam, deixam comentários em seu código para garantir que eles entendam seus próprios caminhos lógicos (e para iluminar o caminho para eles ou outros programadores que possam ter que lidar com o código no futuro. .. assim, "compaixão" na minha lista acima!), e transmitir de forma rápida e clara idéias complexas aos tomadores de decisão da cadeia, para que os problemas possam ser tratados com eficiência.

Um excelente programador pode ter ficado parado por anos em um ambiente que não aceitou a idéia do VCS, teve más experiências com o VCS (à la VSS), o que os deixou com muita vergonha de experimentar novos sistemas, mas eu garantiria que um excelente programador nessa situação ainda teria configurado algum tipo de rotina para se proteger de perder todo o seu trabalho para algumas iterações ruins de design.

O tipo de programador com o qual se deve tomar cuidado, portanto, é aquele que afirma nunca ter precisado do VCS, nem qualquer medida de proteção contra inevitáveis ​​falhas. A atitude deles é de "bem, eu a construí, portanto não pode estar errado". Esses são os que eu mais temo do que qualquer noviciado logo depois da faculdade, porque um novato pode aprender a apreciar os pontos fortes do VCS porque percebe o quão pouco realmente sabe.

Como é possível desenvolver ativamente o software por 10 a 15 anos sem precisar de controle de versão?

Se ele vem de equipes da velha escola, onde pequenos projetos são gerenciados por uma única pessoa, é muito possível. Ele pode ter 10 anos de experiência no mesmo conjunto de tecnologias sem aprender e se aperfeiçoar.

O fato de não procurar uma solução para o problema de rastreamento muda um sinal de uma atitude errada em relação à programação?

Se o seu candidato estiver em um ambiente de desenvolvimento de equipe (pelo menos 4 ou mais programadores), é uma questão trivial. No entanto, pode haver uma divisão de trabalho entre programadores, trabalhada em módulos atribuídos exclusivamente a eles, o que pode reduzir a necessidade de controlar o código de origem.

No entanto, não ser ouvido sobre o controle de fontes na era da Internet é uma situação realmente surpreendente. Assim, eu examinaria sua disposição em aprender coisas novas (relativas ao seu ambiente de desenvolvimento) e como ele está aberto a um ambiente de trabalho dinâmico.

A experiência é importante e você está certo de que a mecânica do uso das ferramentas de controle de origem pode ser aprendida rapidamente. Mas você está certo ao ver uma bandeira vermelha.

• O seu candidato está isolado da profissão e de suas tendências?
• Os muitos outros aspectos do trabalho em equipe também precisam ser aprendidos?

Para mim, a questão sobre o controle de versão é mais um sintoma do que a doença. A causa pode variar e ser bastante benigna. Muitos programadores ad-hoc começaram a fazer o que achavam que fazia sentido, começando com alguns livros sobre programação e não fizeram um estudo sistemático do desenvolvimento de software. Às vezes, mais ainda nos velhos tempos, os graduados em ciência da computação se formavam sem nunca usar um sistema de controle de fonte, porque todos os seus projetos eram projetos individuais e eles foram para empresas com processos de software altamente imaturos.

No entanto, ele chegou lá, se ele é um lobo solitário há uma década ou mais, pode tornar difícil viver com pessoas.

Pode valer a pena perguntar se o seu candidato tem mais algumas perguntas investigativas.

• Conte-me sobre uma vez que você trabalhou como parte de uma equipe?
• Conte-me sobre um momento em que uma equipe em que você trabalhou teve um conflito entre os membros da equipe?
• Conte-me sobre uma época em que você recebeu código de outro desenvolvedor e levou o projeto adiante?
• Diga-me como você e outros membros da sua equipe se mantiveram afastados quando criaram código juntos?
• Conte-me sobre um problema relatado por um cliente relacionado a um recurso que costumava funcionar, mas não funcionou em uma versão posterior? Como você resolveu isso?
• Do que você gosta em trabalhar em equipe?

Ele também pode estar acostumado a ter controle quase completo sobre seus métodos, processos e desempenhar um papel em que é o único especialista em software. Você vai querer alguém que esteja aberto a uma nova maneira de fazer as coisas. Mais perguntas:

• Conte-me sobre um período em que você usou ou ajudou a criar um padrão de codificação?
• Que tipos de coisas você deseja ver em um padrão de codificação?
• Como você se sente ao reescrever o código de outra pessoa?
• Conte-me sobre uma vez em que você esteve envolvido em análises por pares de software ou documentação?
• Você pode me falar sobre uma proposta ou contrato para o desenvolvimento de software que você estava envolvido por escrito?
• Conte-me sobre seu gerente ou supervisor favorito de software?
• Conte-me sobre seu colega de trabalho favorito ou subordinado?

No ano de 2012, para alguém com 15 anos de experiência no setor nunca ter usado o controle de versão é uma bandeira vermelha. Pode não ser uma bandeira vermelha se o ano foi de 1982 ou mesmo de 1992. Mas hoje, é melhor haver uma excelente explicação para essa lacuna intrigante no contexto desse desenvolvedor.

Situações extraordinárias exigem explicações extraordinárias.

É como um mecânico de automóveis que afirma que conserta carros há 15 anos, mas nunca conseguiu nem um pouco de graxa em si mesmo.

É claro que se sujar com graxa não conserta a transmissão e nenhuma das etapas do manual de reparo exige isso, mas esse não é o ponto. A questão é que estar completamente limpo é inconsistente com a aparência de mecânicos de automóveis quando eles estão trabalhando. Nesse trabalho, você engorda.

Se você está entrevistando alguém experiente que admite que não tem experiência com controle de versão, provavelmente está exagerando ou fabricando parte de sua experiência (e nem sabe que esse controle de versão é algo amplamente usado e importante, e algo sobre o qual ele também deveria mentir! )

É possível ver todos os tipos de piadistas nas entrevistas. Vi pessoas que não conseguem desenhar um diagrama de uma lista vinculada ou escrever uma função que insere um nó no início de uma lista vinculada. No entanto, eles reivindicaram 20 anos de experiência profissional.

Mesmo os recém-formados em ciência da computação podem ter uma familiaridade passiva com o controle de versão, mesmo que ainda não o tenham feito uso extensivo.

Eu acharia estranho, mas não impossível, para um programa experiente nunca ter usado controle de fonte dedicado. Em uma empresa com a qual trabalhei, eles usaram extensivamente o controle de origem para o código C # e VB tradicional. Mas o código puro do banco de dados (procedimentos e scripts armazenados, bem como as definições de tabela) não estavam no controle de origem, apesar de haver dois Desenvolvedores SQL profissionais cuja tarefa principal era escrever, manter e executar o código puro do banco de dados. Defendi o controle de origem para as entidades de banco de dados de lá e foi apenas parcialmente bem-sucedido.

Em outra empresa, a equipe de desenvolvimento era pequena (um homem comprava por muito tempo e depois dois). O controle de origem do desenvolvedor anterior era ter várias cópias dos arquivos de origem com uma data adicionada no final. Além de não ter um sistema de controle de fonte melhor, meu antecessor era definitivamente competente e um homem inteligente.

Antes de me tornar profissional, eu era um hobby e não usava nenhum controle de fonte, sabia vagamente o que era, mas não me incomodei.

Em resumo, acho estranho que um profissional não esteja familiarizado com isso, mas principalmente se ele estiver acostumado a equipes muito pequenas, certamente é possível ser competente sem ele. Na contratação, eu não seguraria isso contra ele. Eu absolutamente manteria uma relutância em aprender e começar a usá-lo no trabalho contra ele ...

Meu 2c é que depende de como ele reagiu ao ser perguntado sobre VC. As possíveis reações podem ser:

1. Hã? O que é isso
2. Não, nós fizemos
3. Sem embaralhamento embaraçado , a gerência não nos permitiria
4. Sem embaralhamento embaraçado , mas eu próprio investiguei um pouco e pensei que parecia algo que deveríamos estar fazendo.

No caso de 4, o cara receberia um passe de mim, ele tem a atitude certa e provavelmente vai se dar bem. No caso de 3, ele recebe crédito por entender que é algo que deve ser feito, mas não tanto quanto 4. Se ele conseguiu citar alguns factóides sobre VC (liste alguns dos pacotes de VC por aí) eu ' tomaria isso como evidência de alguma curiosidade e poderia passar por ele.

Se ele respondeu 1 ou 2, ou seja, se ele soubesse e não quisesse saber sobre VC, eu questionaria seriamente o julgamento do candidato. Haverá outras ferramentas (rastreamento de bugs, métricas de qualidade, automação de construção etc. etc.) com as quais ele precisará trabalhar e você provavelmente descobrirá que tem uma batalha árdua por todos esses problemas, se ele não estiver aberto a tentar novas abordagens.

Como a maioria das pessoas aqui, acho que seria injusto prejudicar o candidato apenas porque o empregador não estava em dia; para mim, tudo depende de como eles reagiram.

Escrever o que mudou é bom quando se olha para trás. Isso me salvou muitas vezes ao descobrir o que havia de errado e muitos problemas foram resolvidos rapidamente porque eu o escrevi. Na minha opinião, é bom manter um registro. Especialmente se você estiver programando com mais pessoas que você.

Se você estiver escrevendo um aplicativo da Web, poderá continuar adicionando belezas sem controle de versão, porque constantemente adiciona coisas novas a ele. Mas talvez você escreva um registro ou um post de notícias com as novidades.

É tudo sobre o que você está programando.

Trabalhei em locais onde o processo de aprovação do software era de 12 a 18 meses. Se ainda não estava na lista de softwares aprovados, não havia como obtê-lo nas máquinas. As unidades de CD / DVD estavam bloqueadas e as máquinas não estavam conectadas à Internet.

O primeiro lugar em que eu entrei no controle de origem da solução foi ter um desenvolvedor escrevendo por conta própria, quando estava pronto para testar o projeto de vários anos que estava acabando. Eles apostaram que escrever do zero era mais rápido que o processo de aprovação.

O segundo lugar em que encontrei esse problema usou o controle de origem nos primeiros meses, mas o cliente queria que todo o desenvolvimento fosse feito em sua rede interna. Eles novamente trancaram tudo, então voltamos a muitas pastas compactadas.

Conheço desenvolvedores que só trabalharam nessas condições. Eles querem usar essas ferramentas, gostariam de usá-las, mas não têm permissão para usá-las.

Investigue por que eles não os usaram. Não entender os procedimentos por causa de zero de experiência é muito diferente de rejeitar as ferramentas.

Estou desenvolvendo nos últimos 15 anos. Usou o controle de versão apenas algumas vezes. Ainda estou usando meus próprios scripts e programas agendados para fazer backup de todas as pastas de desenvolvimento incrementalmente. Não sei o que dizer Se alguém me perguntar se eu uso o Controle de versão. Eu nunca precisei do sistema de controle de versão, sempre trabalhei em pequenos projetos. Quero dizer, não sou o melhor programador por aí, mas tenho certeza de que não sou o pior. Na maioria das vezes, tenho vergonha de dizer às pessoas que não uso regularmente o sistema de controle de versão, mas é assim que é para mim.

Falando da minha experiência como programador em sistemas IBM MVS: nos primeiros dez anos de minha carreira profissional, o sistema operacional com o qual trabalhei tinha exatamente um tipo de arquivo com versão disponível para o programador: o conjunto de dados de geração. Este era essencialmente um arquivo com um número fixo de versões, e você tinha que lembrar qual versão era o que - praticamente inútil para o controle de versão moderno. Juntamente com um sistema de arquivos que não tinha diretórios reais, apenas mais ou menos qualificadores (8 caracteres), o conceito de sistema de gerenciamento de código-fonte era completamente estranho a qualquer pessoa que trabalhasse naquele ambiente.

Na verdade, não vi um sistema de controle de código-fonte até me mudar para o SunOS 3 e usar o RCS. Naquele momento, eu era um programador de sistemas IBM extremamente fácil, altamente produtivo e muito bom no meu trabalho. Todas as versões eram tratadas copiando backups para fita e gravando o que estava onde.

Se eu ainda estivesse trabalhando em mainframes nesse momento, é perfeitamente possível que eu ainda não tenha sido exposto a um sistema formal de controle de versão; as alternativas especificamente suportadas são o ClearCase e o Rational, nenhuma das quais é gratuita (e na verdade são ambas muito caras).

Dizer que alguém é por definição incompetente porque nunca usou controle de versão é um argumento ilusório. É necessário cavar e olhar para os detalhes. Se eles afirmam ser um desenvolvedor de Linux / Unix / Mac OS, mas nunca usaram o controle de versão, ele fala menos bem para eles, e talvez você precise avaliar se a experiência geral deles é tão boa que você gostaria de treiná-los em engenharia de software moderna. Se eles são um programador de mainframe da velha escola - e é isso que você precisa -, concentre-se em saber se eles têm exatamente as habilidades de programação necessárias que você deseja e resigne-se ao fato de que você precisará ensinar isso a eles. Como outros já disseram, sua resposta ao conceito será o fator decisivo nesse caso.

Muito por favor! Toda a nossa comunidade não vive em comunidades sociais altamente desenvolvidas, onde os hangouts e eventos hacky são excessivamente abundantes, nem todos trabalhamos em empresas de desenvolvimento de software e alguns de nós nem conseguem encontrar recursos publicados relevantes ou atualizados em nossas línguas nativas, impressas ou on-line, vamos encontrar um programador de verdade.

Pelo que entendi, se ele é um desenvolvedor de software experiente, como você diz, provavelmente é um lobo solitário trabalhando como freelancer para pequenas empresas.

Existem alguns motivos possíveis para não usar o controle de versão:

1. Trabalhando em empresas que não desenvolvem software como sua principal linha de negócios.
2. Ou se o desenvolvedor decidiu usar outro sistema - válido apenas para os experientes.
3. Ou se o desenvolvedor ainda não aprendeu como cada sistema funciona
4. Ou é um problema de atitude contra as ferramentas que eles não conhecem

Mas você deve ter cuidado ao encontrar pessoas que assumem:

1. Que existe apenas uma maneira de fazer algo
2. Ou que todo programador deve fazer da mesma maneira que está fazendo
3. Ou que as práticas que as pessoas estão usando são fáceis de mudar

Tão possível quanto um programador ruim seja especialista em controle de versão. O que quero dizer é que não sei o que o controle de versão faz por suas habilidades de programação ou de resolução de problemas. É uma questão de experiência. Muitas lojas menores não a usam ou a deixam para os indivíduos (que frequentemente trabalham sozinhos) para descobrir por si mesmas.

Eu acho que não se trata tanto de "Como é possível desenvolver ativamente software por 10 a 15 anos sem precisar de controle de versão?", Mas "Como é possível desenvolver ativamente software por 10 a 15 anos sem nunca precisando de controle de versão? "

Certamente é possível programar sem controle de versão, mas um profissional deve estar familiarizado com o estado da arte atual e ser capaz de selecionar as ferramentas certas para realizar o trabalho. Deixar de usar o software de gerenciamento de versão apropriado torna seu trabalho arriscado e não confiável, e um dos motivos pelos quais você deseja contratar um desenvolvedor profissional é que ele deve gerenciar riscos.

Uma base de código que é anotada corretamente em um VCS vale muito mais do que uma que não é. O motivo de cada mudança pode ser rastreado e compreendido, possibilitando aos mantenedores uma compreensão mais profunda do que eles precisam saber. Deixar de fazer isso não é profissional, e a única desculpa seria se ele / ela tivesse sido restringido por gerentes ruins em seu trabalho anterior. Mesmo assim, eles não deveriam ter usado versões para seus projetos particulares?