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

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

Sim, houve programação antes da internet.

Eu luto para ver como você pode passar mais de 10 anos na indústria agora sem ter passado para o controle de código-fonte. Mas, eu teria alguma simpatia, eu acreditaria que era possível e eu não rejeitaria o candidato só naquele detalhe. Eu investigaria e descobriria como o candidato conseguiu isso.

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

Como nota final, não tenha medo de rejeitar todos os candidatos se tiver alguma dúvida. É 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 pegar um sistema de controle de versão rapidamente. Ele pode falar sobre isso de duas maneiras:

• Bom

  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.

  

• Ruim

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

Deixe-me dar a você algumas perspectivas sobre o desenvolvimento de software no DOS e no Windows por mais de 20 anos.

O software de controle de versão no mundo Windows / PC muitas vezes 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 o odiavam. Algumas equipes simplesmente não se divertem depois de lidar com essa situação.

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

Em muitos casos, durante o final dos anos 90, início dos 00, se uma equipe do Windows não usasse o VSS, eles não usavam nada para controle de origem, além das convenções internas. Vários 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 tenha trabalhado por anos em uma pequena equipe de desenvolvimento do Windows por anos não tenha usado um VCS. Eu entrevistei e até mesmo fiz contratos de trabalho em alguns lugares que não os usavam ou que eram muito aleatórios sobre o uso deles.

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

Querer fazer as coisas manualmente, reinventar a roda e ser resistente a mudanças não é novidade em programação. Você vai babar sobre um candidato que usa Visual Source Safe e "apenas" VSS?

Ao tentar encontrar talentos, você precisa ser capaz de dizer a diferença entre: não pode, não tem e não vai.

Não há desculpa para não usar o controle de versão, mesmo para um pequeno projeto desenvolvido por um único desenvolvedor. Configurando o controle de versão local é além de trivial, beneficia enorme. 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", que não estão dispostas a apresentar:

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

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

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

Eu não seria religioso por falta de experiência com controle de versão. É apenas uma ferramenta. No final, você pode pegar o básico de svn ou git em um dia ou dois. O resto você vai pegar com o tempo. E eu não posso acreditar que qualquer candidato meio decente não seria capaz de se encaixar se ele fosse trabalhar em um ambiente que usa controle de origem.

O uso do controle de origem é mais um hábito do que uma habilidade. Alguém que nunca usou isso pode exagerar o esforço necessário e subestimar os benefícios obtidos. Afinal, ele foi 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 do controle de origem? Isso pode lhe dizer algo sobre ele e como ele gerencia seu trabalho.

Você deixa muitas informações sobre sua experiência.

Basicamente, eu diria que é muito possível que um programador tenha 10-15 anos de experiência sem precisar saber sobre o controle de versão. Codificar por 10 anos não é o mesmo que 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 iria querer tocar. Dito isto, ele pode ser muito talentoso, mas eu acho que a partir da pequena informação, dado que ele não é.

Boa sorte.

Se é o segundo caso, onde eles decidiram ativamente contra o controle de versões, então me faz supor 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 aqui algumas respostas bastante críticas que não levam em conta a pessoa que está sendo julgada.

Pessoalmente, acho que o software de controle de versão é uma ferramenta inestimável. Mas nem todos temos escolha e controle sobre as ferramentas e processos que são usados em nossos ambientes de trabalho. Eu tenho trabalhado no desenvolvimento do Windows desde 1990. Como postado por outros, naquela época não havia muito disponível para o VCS no Windows. Nós não iríamos trazer servidores UNIX apenas para obter um VCS. Isso me fez um mau programador? Mais tarde, em minha carreira, trabalhei para uma empresa com um produto comercial de mercado vertical, no qual o controle de versão era um processo e não uma ferramenta. Isso me fez um mau programador? Todos os meus últimos três trabalhos confiaram muito nas ferramentas VCS. Isso faz de mim um bom programador?

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

Eu nunca me considerei um "programador" até que comecei a ganhar dinheiro fazendo isso profissionalmente.

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

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

Eu não usei o Git e não tinha um perfil do 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. Eu já consegui contratos de desenvolvimento de sites tanto para clientes quanto para mim, não foi muito doloroso aprender algo novo aos 30 anos de idade e a alguns anos de programação.

Eu prefiro perguntar aos candidatos a desenvolvedor sobre o que eles são apaixonados, qual é o sistema mais legal que eles já fizeram em sua própria opinião e em que eles gastam seu tempo livre desenvolvendo suas habilidades. próprio tempo, que me assusta mais do que outras coisas, mas não significa que tem que assustar você.

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 com base em suas necessidades.

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

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

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

Se ele fosse strong nesse tipo de coisa, então talvez eu poderia ignorar a falta de conhecimento do controle de origem.

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

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

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

Eu pessoalmente introduzi controle de versão para 2 pequenas empresas, atualizei uma empresa média de algo horrível para SVN (a melhor opção na época) e trabalhei em outra pequena empresa que tinha apenas alguns VC, escrevi sua própria solução de VC para algum código e tinha muito código, mas não em qualquer 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?

Bem, não é uma falha instantânea, mas eu certamente estaria fazendo 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 antes no mesmo código? base, e quais métodos você usou para evitar confrontos?

Eu gostaria de concordar com as Pílulas de Explosão (mas meu representante é muito baixo, atm ...) ... a atitude é muito mais importante.

Há algumas coisas para procurar, que eu acredito que façam pela excelência de programação:

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

E, muitas vezes, mais do que um pequeno TOC.

Você conhece o tipo ... os que estão sentados martelando um problema, perdendo-se completamente no código enquanto exploram as opções. Estes são os que tomam notas à medida que avançam, deixam comentários em seus códigos para se certificar de que eles entendem seus próprios caminhos lógicos (e para iluminar o caminho para si mesmos ou para outros programadores que possam ter que lidar com o código no futuro. .. assim, "compaixão" na minha lista acima!), e rapidamente e claramente transmitir idéias complexas para os tomadores de decisão da cadeia para que os problemas possam ser resolvidos com eficiência.

Um excelente programador pode ter ficado preso por anos em um ambiente que não acreditou na idéia de VCS, teve experiências ruins com VCS (a la VSS), o que os deixou tímidos para experimentar novos sistemas, mas eu Isso garantiria que um excelente programador nessa situação ainda teria criado algum tipo de rotina para se proteger de perder todo o seu trabalho para algumas iterações de design ruins.

O tipo de programador a tomar cuidado, portanto, é aquele que afirma nunca ter necessidade de VCS, nem qualquer medida de proteção contra falhas inevitáveis. A atitude deles é de "bem, eu construí, portanto não pode estar errado". Esses são os que eu mais temo do que qualquer novato direto da faculdade, porque um novato pode aprender a apreciar os pontos strongs do VCS porque eles percebem o pouco que realmente sabem.

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

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 na mesma tecnologia sem aprender e se aperfeiçoar.

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

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

No entanto, não ser ouvido sobre o controle de origem na era da internet é uma situação realmente surpreendente. Assim, eu olharia para a sua vontade de aprender coisas novas (sobre o seu ambiente de desenvolvimento) e como ele é aberto a um ambiente de trabalho dinâmico.

A experiência é importante e você está certo de que a mecânica de usar as ferramentas de controle de código-fonte pode ser aprendida rapidamente. Mas você está certo em ver uma bandeira vermelha.

• 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 bem benigna. Muitos programadores ad-hoc começaram a fazer o que achavam que faziam sentido, começando com alguns livros sobre programação e não faziam um estudo sistemático do desenvolvimento de software. Às vezes, mais ainda nos velhos tempos, os cursos de ciência da computação se formariam sem nunca ter usado um sistema de controle de origem, porque todos os seus projetos eram projetos individuais e eles iam para empresas com processos de software altamente imaturos.

Pode valer a pena perguntar ao seu candidato mais algumas perguntas.

• Fale sobre uma vez em que você trabalhou como parte de uma equipe?
• Fale sobre uma ocasião em que uma equipe em que você trabalhou teve um conflito entre os membros da equipe?
• Fale sobre uma ocasião em que você recebeu código de outro desenvolvedor e realizou o projeto dele em andamento?
• Diga-me como você e outros membros de sua equipe se mantiveram afastados uns dos outros ao criar o código juntos?
• Fale sobre um problema relatado pelo 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 estar em um papel onde ele é o único especialista em software. Você vai querer alguém que esteja aberto a uma nova maneira de fazer as coisas. Mais perguntas:

• Fale sobre uma vez que você usou ou ajudou a criar um padrão de codificação?
• Que tipo 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 revisões por pares de software ou documentação?
• Você pode me falar sobre uma proposta ou contrato de desenvolvimento de software em que esteve envolvido na redação?
• Fale-me sobre seu gerente de software ou supervisor favorito?
• Fale-me sobre o seu colega de trabalho ou subordinado favorito?

No ano de 2012, para alguém com 15 anos de experiência na indústria, nunca ter usado controle de versão é uma bandeira vermelha. Pode não ser uma bandeira vermelha se o ano fosse 1982, ou mesmo 1992. Mas hoje, é melhor que haja uma excelente explicação para essa lacuna intrigante no histórico desses desenvolvedores.

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

Este é um pouco como um mecânico de automóveis que alega que está consertando carros há 15 anos, mas nunca teve uma mancha de gordura em si mesmo.

É claro, borrar-se com graxa não consertará a transmissão, e nenhuma das etapas do manual de reparo exige tal coisa, mas esse não é o ponto. O ponto é que estar completamente limpo é inconsistente com o que a mecânica do carro realmente parece quando está trabalhando. Nesse trabalho, você fica obcecado com você mesmo.

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

É possível ver todos os tipos de palhaços em entrevistas. Eu vi pessoas que não podem desenhar um diagrama de uma lista vinculada ou escrever uma função que insere um nó na cabeça de uma lista vinculada. No entanto, eles alegaram 20 anos de experiência de trabalho.

Até mesmo os recém-formados em ciências da computação podem ter uma familiaridade passiva com o controle de versões, mesmo que ainda não tenham feito amplo uso dele.

Eu acharia estranho, mas não impossível, para um programa experiente nunca ter usado o controle de fonte dedicado. Em uma empresa com a qual trabalhei, eles usaram o controle de fonte extensivamente para seus códigos tradicionais C # e VB. Mas o código de banco de dados puro (procedimentos armazenados e scripts, bem como definições de tabela) não estavam no controle de origem, apesar de ter dois desenvolvedores SQL profissionais cujo trabalho principal era escrever, manter e executar o código de banco de dados puro. Defendi o controle de origem para as entidades de banco de dados e obtive apenas parcialmente sucesso.

Em outra empresa, a equipe de desenvolvimento era pequena (uma loja de homem por muito tempo, depois duas). O controle de origem do desenvolvedor anterior tinha 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 fontes melhor, meu predecessor era definitivamente competente e inteligente.

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

Meu próprio 2c é que isso depende de como ele reagiu ao ser questionado sobre o VC. As possíveis reações podem ser:

1. Huh? O que é isso
2. Não, em vez disso, fizemos
3. Não shuffle envergonhado , a gerência não nos permitiria
4. Não shuffle envergonhado , mas eu mesmo investiguei um pouco e achei 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 irá pegá-lo bem. No caso de 3, ele recebe crédito por entender que é algo que deve ser feito, mas não tanto crédito quanto 4. Se ele foi capaz de nomear alguns factos sobre VC (listar alguns dos pacotes VC por aí) Tome isso como evidência de alguma curiosidade e poderia passar por ele.

Se ele respondesse 1 ou 2, isto é, se ele soubesse e não se importasse em saber sobre VC, questionaria seriamente o julgamento do candidato. Haverá outras ferramentas (acompanhamento de bugs, métricas de qualidade, automação de builds etc. etc.) com as quais ele precisará trabalhar e você provavelmente descobrirá que tem uma batalha difícil em todos esses problemas se ele não estiver aberto para tentar novas abordagens.

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

Escrever o que mudou é bom quando se olha para trás. Isso me salvou muitas vezes quando percebi o que estava errado e muitos problemas foram corrigidos rapidamente porque eu tinha escrito. Na minha opinião, é bom manter um registro. Especialmente se você estiver programando com mais pessoas do que você mesmo.

Se você estiver escrevendo um aplicativo da web, poderá continuar adicionando feautures sem controle de versão, pois está constantemente adicionando 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 de software foi de 12 a 18 meses. Se ainda não estava na lista de softwares aprovados, não havia como obtê-los nas máquinas. Unidades de CD / DVD foram bloqueadas e as máquinas não estavam conectadas à Internet.

O primeiro lugar em que corri para o controle de origem da solução foi ter um desenvolvedor escrevendo o seu próprio, no momento em que estava pronto para testar o projeto de vários anos estava terminando. Eles apostaram que escrever do zero foi mais rápido que o processo de aprovação.

O segundo lugar em que me deparei com 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 voltaram para muitas pastas compactadas.

Eu conheço desenvolvedores que só trabalharam nessas condições. Eles querem usar essas ferramentas, adorariam usar essas ferramentas, mas não podem usar essas ferramentas.

Investigue porque eles não os usaram. Não entender os procedimentos por causa da experiência zero é muito diferente do que 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 de forma incremental. Eu não sei o que dizer Se alguém me perguntar se eu uso o controle de versão. Eu nunca precisei de um sistema de controle de versão, sempre trabalhei em pequenos projetos. Quer dizer, eu não sou o melhor programador lá fora, mas tenho certeza de que não sou o pior. Na maior parte do tempo, tenho vergonha de dizer às pessoas que não uso regularmente o sistema de controle de versões, mas é assim que é para mim.

Falando da minha experiência como programador em sistemas IBM MVS: nos primeiros dez anos da 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 moderna. Juntamente com um sistema de arquivos que não tinha diretórios reais, apenas mais ou menos (8 caracteres) qualificadores, o conceito de um sistema de gerenciamento de código-fonte era completamente estranho para qualquer pessoa que trabalhasse nesse 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 em meu trabalho. Todas as versões foram tratadas copiando os backups para a fita e registrando o que estava onde.

Se eu ainda estivesse trabalhando em mainframes neste momento, é bem possível que eu nunca tenha sido exposto a um sistema formal de controle de versão; as alternativas que são especificamente suportadas são o ClearCase e o Rational, nenhum dos quais é livre (e, na verdade, ambos são muito caros).

Assim, dizer que alguém é, por definição, incompetente porque nunca usou o controle de versão é um argumento especioso. É necessário cavar e olhar os detalhes. Se eles afirmam ser um desenvolvedor Linux / Unix / Mac OS, mas nunca usaram o controle de versão, ele não fala muito bem para eles, e você pode ter que pesar se sua experiência geral é tão boa que você estaria disposto a treiná-los em engenharia de software moderna. Se eles são um programador de mainframe da velha escola - e é isso que você precisa - então concentre-se em saber se eles têm exatamente as habilidades de programação necessárias que você quer, e se resigne ao fato de que você precisará ensinar isso a eles. Como outros disseram, sua resposta ao conceito será o fator decisivo nesse caso.

Pretty please! A totalidade da nossa comunidade não vive em comunidades sociais altamente desenvolvidas, onde hangouts nerds e eventos hacky são excessivamente abundantes, nem todos nós trabalhamos em empresas de desenvolvimento de software e alguns de nós não conseguem encontrar recursos publicados relevantes ou atualizados. em nossas línguas nativas, impressas ou on-line, jamais encontremos um colega programador em carne e osso.

Para tudo que eu posso entender, se ele é um desenvolvedor de software experiente, como você diz, então ele provavelmente tem sido um lobo solitário trabalhando como freelancer para pequenas empresas.

Existem algumas razões possíveis para não usar o controle de versão:

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

Mas você deve ter cuidado ao conhecer pessoas que presumem:

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 alterar

Assim como é possível para um programador fraco ser especialista em controle de versão. Meu ponto é, eu não sei o que o controle de versão faz para suas habilidades de programação ou habilidades para resolver problemas. É uma questão de experiência. Muitas pequenas lojas não as usam ou deixam para os induviduais (que geralmente trabalham sozinhas) para descobrir por si mesmas.

Eu acho que não é tanto uma questão de "Como é que é possível desenvolver activamente software de 10-15 anos sem nunca precisar de controle de versão?", Mas "Como é que é possível desenvolver ativamente software para o último 10-15 anos sem precisar de controle de versão? "

programação Claro é possível sem controle de versão, mas um profissional deve estar familiarizado com o estado atual da arte, e ser capaz de selecionar as ferramentas certas para fazer o trabalho. Deixar de usar o software de gerenciamento de versão apropriada torna o seu trabalho arriscado e pouco confiável, e uma das razões que você quer contratar um desenvolvedor profissional é que eles devem ser capazes de gerir o risco.

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 que os mantenedores tenham uma compreensão mais profunda do que precisam saber. Não fazer isso é pouco profissional, e a única desculpa para isso seria se ele / ela tivesse sido constrangido por gerentes pobres em seu trabalho anterior. Mesmo assim, eles não deveriam ter usado versionamento para seus projetos privados?