¿Es posible que un buen programador nunca haya usado el control de versiones? [cerrado]

Estoy buscando un programador experto para ayudar a resolver una situación difícil.

Las entrevistas hasta ahora han sido sorprendentemente decepcionantes. El mejor candidato hasta ahora es un programador con mucha experiencia que nunca ha utilizado un software de control de versiones.

El problema en sí mismo podría no ser demasiado grave porque es algo que se puede aprender en poco tiempo.

Pero hay un aspecto más profundo, que me preocupa:

¿Cómo es posible desarrollar software activamente durante 10-15 años sin necesidad de control de versiones?

¿El hecho en sí mismo de no buscar una solución al problema del seguimiento cambia un signo de una actitud incorrecta hacia la programación?

Trabajé durante aproximadamente 11 años en empresas que no usaban el control de fuente. Lo gestionamos (principalmente comentando los cambios y manteniendo el código en un servidor central que podría recuperarse en cualquier fecha). Realmente nunca preguntamos si había una mejor manera. Dicho esto, esto también fue en los días en que tenía toda la biblioteca de MSDN en forma de libro en mi escritorio.

Sí, había programación antes de internet.

Me cuesta ver cómo puede pasar más de 10 años en la industria ahora sin haberse topado con el control de código fuente. Pero, tendría algo de simpatía, creo que era posible y no rechazaría al candidato solo con ese detalle. Investigaría y descubriría cómo el candidato ha logrado esto.

Alternativamente, podría cuestionar si mi proceso de entrevista fue el problema. ¿De qué manera era el mejor candidato? ¿Hay otras técnicas modernas de programación que él no tiene y que simplemente no estoy haciendo las preguntas correctas? Si estuviera haciendo las preguntas correctas, ¿brillaría otro candidato?

Sin embargo, como nota final, no tenga miedo de rechazar a todos los candidatos si tiene dudas. Comenzar de nuevo lleva mucho tiempo, pero es más lento contratar a la persona equivocada.

Creo que depende de su actitud. Si es un programador muy experimentado y un buen programador, creo que podría elegir un sistema de control de versiones rápidamente. Puede hablar sobre esto de dos maneras:

• Bueno

  Nunca he usado el control de versiones, pero estoy muy emocionado de aprender, y parece que realmente ayudaría a hacer que el desarrollo sea más eficiente. No lo he necesitado tanto porque he trabajado solo en proyectos.

• Malo

  El control de versiones es solo una palabra de moda que está muriendo lentamente en la industria. Estoy por encima del control de versiones.

Permítame darle una perspectiva desde el desarrollo de software en DOS y Windows durante más de 20 años.

El software de control de versiones en el mundo de Windows / PC a menudo no era confiable a principios de mediados de los 90. Visual Sourcesafe (VSS) era el mejor basado en Windows, pero podría ser peculiar y muchos programadores lo odiaban. Algunos equipos simplemente no considerarían su uso después de lidiar con esta situación.

La mayoría de las otras opciones de VCS en ese momento no estaban basadas en Windows y, por lo tanto, rara vez se usaban en los equipos de desarrollo de Windows. Algunas de estas eran soluciones costosas y las soluciones de código abierto no eran tan aceptadas tan fácilmente como lo son hoy.

En muchos casos, a fines de los años 90, principios de los años 00, si un equipo de Windows no usaba VSS, no usaban nada para el control de la fuente aparte de las convenciones internas. Algunos de ellos todavía no usan un VCS a pesar de la sofisticación de Team Foundation Server (TFS) y excelentes opciones gratuitas como git y SVN.

Es posible que alguien que trabajó durante años en un pequeño equipo de desarrollo de Windows durante años no haya utilizado un VCS. Me entrevisté e incluso trabajé por contrato en algunos lugares que no los usaban o que estaban muy al azar sobre su uso.

Por lo tanto, no creo que la falta de experiencia de su candidato en esta área sea un "no" definitivo, pero es probable que desee profundizar en su situación laboral anterior para descubrir por qué esto no se encuentra en su experiencia. También querrás explorar su actitud hacia el control de versiones. ¿Piensan que es una buena idea pero no se les permitió seguirla en su posición anterior o creen que es una pérdida de tiempo?

¿No puede tener control de versiones sin software de control de versiones? Pregunte cómo gestionaron su código. Quizás ya existía un sistema de cosecha propia.

Querer hacer las cosas manualmente, reinventar la rueda y resistir los cambios no son nada nuevo en la programación. ¿Vas a babear sobre un candidato que usa Visual Source Safe y "solo" VSS?

Al tratar de encontrar talento, debe ser capaz de distinguir entre: no puede, no tiene y no quiere.

No hay excusa para no usar el control de versiones, incluso para un pequeño proyecto desarrollado por un solo desarrollador. Configurar el control de versiones local es más que trivial, los beneficios enormes Cualquier desarrollador que no sepa eso no puede considerarse bueno ni experimentado.

En cuanto a las empresas que perciben el control de versiones como "novedad", que no están dispuestas a introducir:

• SCCS fue lanzado en 1972 (hace 40 años )
• RCS fue lanzado en 1982 (hace 30 años ), y es completamente de código abierto y gratuito
• CVS fue lanzado en 1990 (hace 21 años ), también de código abierto y gratuito

Un programador que nunca ha usado el control de versiones probablemente nunca ha cooperado con otros programadores. Probablemente nunca consideraría contratar a tal programador, independientemente de cualquier otra credencial.

Parece una bandera roja bien, pero profundiza en por qué no la ha usado. Todavía esperaría que un desarrollador en solitario utilizara el control de versiones, especialmente en diez años, pero lo perdonaría más que si estuviera trabajando en un equipo y nunca hubiera intentado incorporar el control de versiones.

No sería religioso por la falta de experiencia en el control de versiones. Es solo una herramienta. Al final, puedes aprender los conceptos básicos de svn o git en un día o dos. El resto lo recogerás con el tiempo. Y no puedo creer que ningún candidato medio decente no podría encajar si trabajara en un entorno que utiliza el control de fuente.

Usar el control de fuente es más un hábito que una habilidad. Alguien que nunca lo haya usado puede exagerar el esfuerzo requerido y subestimar los beneficios obtenidos. Después de todo, lo hizo bien hasta ahora. Solo después de que realmente use el control de fuente, crecerá para apreciarlo.

La pregunta que debe hacer es, ¿cómo se las arregló en ausencia de control de fuente? Esto podría decirle algo sobre él y cómo maneja su trabajo.

Dejas mucha información sobre su experiencia.

Básicamente, diría que es muy posible que un programador pueda tener 10-15 años de experiencia sin tener que saber sobre el control de versiones. La codificación durante 10 años no equivale a aprender constantemente nuevas técnicas de programación durante 10 años.

Soy muy joven y he visto ingenieros de software viejos y "experimentados" cuyo código nunca quisiera tocar. Dicho esto, podría ser muy talentoso, pero supongo por la poca información dada que no lo es.

Buena suerte.

Personalmente, lo más alarmante para mí es que el candidato nunca ha encontrado un sistema de control de versiones como concepto, o ha decidido que no vale la pena usarlo. Creo que el primer escenario es altamente improbable, pero si ese es el caso, entonces me lleva a asumir que el candidato ha estado significativamente aislado durante la duración de su carrera, lo que arrojaría serias dudas sobre su valor como parte de un equipo. Específicamente, pueden ser conceptos muy extraños sobre cómo hacer ciertas cosas y no conocer ninguna de las formas "correctas" de hacer las cosas.

Si es el segundo caso, donde han decidido activamente en contra del control de versiones, entonces me hace suponer que nunca trabajaron en algo significativo o que son extremadamente arrogantes. O, en el mejor de los casos, tienen formas realmente terribles de mantener el código, como comentar bloques y atribuir cada línea de código a un autor, fecha y número de error.

Estoy viendo algunas respuestas bastante críticas aquí que en realidad no tienen en cuenta a la persona que se está juzgando.

Personalmente, considero que el software de control de versiones es una herramienta invaluable. Pero no todos tenemos opciones y control sobre las herramientas y procesos que se utilizan en nuestros entornos de trabajo. He trabajado en el desarrollo de Windows desde 1990. Según lo publicado por otros, en ese momento no había mucho disponible para VCS en Windows. No íbamos a traer servidores UNIX solo para obtener un VCS. ¿Eso me hizo un mal programador? Más adelante en mi carrera, trabajé para una empresa con un producto comercial de mercado vertical donde el control de versiones era un proceso, no una herramienta. ¿Eso me hizo un mal programador? Mis últimos tres trabajos se han basado en gran medida en las herramientas de VCS. ¿Eso me hace un buen programador?

Sería genial si todos pudiéramos usar solo las últimas y mejores herramientas, idiomas y tecnologías. Pero la profesión del desarrollo de software no siempre funciona de esa manera. Es un poco idealista decir "Dejaría el trabajo inmediatamente, si no lo hicieran ..." o "Nunca tomaría un trabajo que no usara ..." o "Los obligaría a usar. .. ". No todos estamos rodeados de una oferta infinita de oportunidades de trabajo donde todo funciona exactamente como queremos. Tenemos facturas que pagar y necesitamos un trabajo, por lo que nos ocupamos de lo que nos rodea.

Al final, la respuesta a su pregunta es la siguiente: juzgue a este programador por sus habilidades, sus filosofías y sus decisiones, no por las decisiones (posiblemente equivocadas) tomadas por las personas a cargo de sus trabajos anteriores.

Nunca me consideré un "programador" hasta que comencé a ganar dinero haciéndolo profesionalmente.

He ganado bastante dinero creando sistemas que hicieron que los clientes ganaran aún más dinero. Si soy o no un "buen" desarrollador es subjetivo.

Puedo GSD (hacer algo) rápidamente, lo que para el desarrollo web generalmente ha complacido a mis clientes. Es posible que no vean algún código feo detrás de escena, falta de comentarios, etc.

No había usado Git y no tenía un perfil de Github hasta este año, lo que creo que está "atrasado" en términos de los estándares modernos de programación. También acabo de empezar a hacer proyectos Rails y Django después de haber hecho PHP, Flash e iOS en el pasado. Desde entonces obtuve contratos de desarrollo de sitios tanto para clientes como para mí, no ha sido demasiado doloroso aprender algo nuevo a los 30 años de edad y algunos años fuera de la programación.

Demasiado en la sociedad moderna se enfoca en mantenerse al día con los Jones y preocuparse por lo que otras personas piensan. Si puede romper esos grilletes y considerar lo que necesita para su desarrollo de software (velocidad / tiempo de comercialización, administración de recursos optimizada, código bien documentado, escalabilidad, etc.), entonces eso puede ser mucho más importante que si alguien conoce Mercurial, SVN , Git o cualquier otro sistema de control de versiones.

Prefiero preguntar a los candidatos a desarrolladores qué les apasiona, cuál es el sistema más genial que han hecho en su propia opinión y en qué dedican su tiempo libre a desarrollar sus habilidades. Si las personas no avanzan sus habilidades en su propio tiempo, eso me asusta más que otras cosas, pero no significa que tenga que asustarte.

Creo que ya tiene algunas excelentes respuestas a esta pregunta de parte de la gente de aquí y eso debería ayudarlo a tomar su propia decisión informada en función de sus requisitos.

Me parece increíble que un profesional de software nunca haya usado el control de fuente, y estaría muy nervioso por contratarlo.

Qué experiencia tiene él. Me pregunto qué más no sabe que hasta ahora no has descubierto.

¿Cuál es su experiencia de desarrollo de software usted mismo? ¿Está en condiciones de preguntarle sobre arquitectura, patrones de diseño, problemas comunes de desarrollo de software, preguntas de rendimiento del sistema, preguntas de seguridad del sistema, etc.?

Si salió fuerte en ese tipo de cosas, entonces tal vez podría pasar por alto la falta de conocimiento sobre el control de la fuente.

¿Es posible que un buen programador nunca haya usado el control de versiones?

Si. Muchas pequeñas empresas con programadores autodidactas no lo usan.

¿Cómo es posible desarrollar software activamente durante 10-15 años sin necesidad de control de versiones?

Personalmente, presenté el control de versiones a 2 pequeñas empresas, actualicé 1 compañía mediana de algo horrible a SVN (la mejor opción en ese momento) y trabajé en otra pequeña compañía que solo tenía algo de VC, escribí su propia solución de VC para algún código y tenía mucho código simplemente no en ningún VC.

¿El hecho en sí mismo de no buscar una solución al problema del seguimiento cambia un signo de una actitud incorrecta hacia la programación?

Bueno, no es un fracaso instantáneo, pero sin duda estaría haciendo muchas preguntas de seguimiento. Cosas como:

¿Alguna vez has probado algún software de VC? ¿Qué? ¿Que piensas de eso? ¿Hay alguna razón por la que no lo usarías? ¿Qué has usado antes para administrar el código? ¿Has trabajado antes con alguien en la misma base de código y qué métodos utilizaste para evitar enfrentamientos?

Me gustaría estar de acuerdo con las píldoras de explosión (pero mi representante es demasiado bajo, cajero automático ...) ... la actitud es mucho más importante.

Hay algunas cosas a tener en cuenta, que creo que contribuyen a la excelencia de la programación:

1. Comunicación
2. Creatividad
3. Compasión (¿decir qué?)

Y, a menudo, más que un poco de TOC.

Ya sabes el tipo ... los que se sientan allí martillando un problema, perdiéndose completamente en su código mientras exploran opciones. Estos son los que toman notas a medida que avanzan, dejan comentarios en su código para asegurarse de que entienden sus propios caminos lógicos (y para iluminar el camino para ellos mismos u otros programadores que puedan tener que lidiar con el código en el futuro. .. por lo tanto, "compasión" en mi lista de arriba!), y rápida y claramente transmitir ideas complejas a los tomadores de decisiones en la cadena para que los problemas puedan abordarse de manera eficiente.

Un programador excelente puede haber estado atrapado durante años en un entorno que no aceptaba la idea de VCS, tuvo malas experiencias con VCS (a la VSS), lo que los hizo tímidos para probar nuevos sistemas, pero le garantizo que un programador excelente en esa situación todavía habría establecido algún tipo de rutina para protegerse de perder todo su trabajo en un par de iteraciones de diseño erróneas.

Por lo tanto, el tipo de programador del que hay que tener cuidado es el que afirma que nunca ha necesitado VCS, ni ninguna medida de protección contra los inevitables errores. Su actitud es de "bueno, lo construí, por lo tanto, no puede estar equivocado". Esos son los que más temo que cualquier noviciado recién salido de la universidad, porque un novato puede aprender a apreciar las fortalezas de VCS porque se dan cuenta de lo poco que realmente saben.

¿Cómo es posible desarrollar software activamente durante 10-15 años sin necesidad de control de versiones?

Si viene de equipos de la vieja escuela donde los proyectos pequeños son administrados por una sola persona, es muy posible. Puede tener 10 años de experiencia en el mismo conjunto de tecnología sin aprender y mejorar.

¿El hecho en sí mismo de no buscar una solución al problema del seguimiento cambia un signo de una actitud incorrecta hacia la programación?

Si su candidato ha estado en un entorno de desarrollo de equipo (al menos 4 o más programadores), entonces es una pregunta trivial. Sin embargo, puede haber una división de trabajo entre programadores, trabajados en módulos asignados únicamente a ellos, lo que puede reducir la necesidad de controlar el código fuente.

Sin embargo, no ser escuchado sobre el control de fuentes en la era de Internet es una situación realmente sorprendente. Por lo tanto, vería su disposición a aprender cosas nuevas (en relación con su entorno de desarrollo) y qué tan abierto está a un entorno de trabajo dinámico.

La experiencia importa y tiene razón en que la mecánica del uso de herramientas de control de código fuente se puede aprender con bastante rapidez. Pero tienes razón al ver una bandera roja.

• ¿Está su candidato aislado de la profesión y sus tendencias?
• ¿También se deberán aprender los muchos otros aspectos del trabajo en equipo?

Para mí, el problema del control de versiones es más un síntoma que la enfermedad. La causa puede variar y ser bastante benigna. Muchos programadores ad-hoc comenzaron a hacer lo que pensaban que tenía sentido, comenzando con algunos libros sobre programación, y no hicieron un estudio sistemático del desarrollo de software. A veces, más aún en los viejos tiempos, los graduados en ciencias de la computación se graduarían sin haber usado un sistema de control de fuente porque todos sus proyectos eran proyectos individuales y se dirigían a empresas con procesos de software muy inmaduros.

Sin embargo, llegó allí, si ha sido un lobo solitario durante una década o más, puede ser difícil vivir con personas.

Puede valer la pena preguntarle a su candidato algunas preguntas más de sondeo.

• ¿Cuéntame sobre alguna vez que trabajaste como parte de un equipo?
• ¿Cuéntame sobre un momento en que un equipo en el que trabajaste tuvo un conflicto entre los miembros del equipo?
• ¿Cuénteme sobre un momento en que recibió código de otro desarrollador y llevó adelante su proyecto?
• ¿Cuéntame cómo tú y otros miembros de tu equipo se mantuvieron al margen cuando crearon código juntos?
• ¿Cuénteme acerca de un problema informado por un cliente relacionado con una función que solía funcionar, pero que no funcionó en una versión posterior? ¿Cómo lo resolviste?
• ¿Qué te gusta de trabajar en equipo?

También puede estar acostumbrado a tener un control casi completo sobre sus métodos, procesos y desempeñar un papel en el que es el único experto en software. Querrás a alguien que esté abierto a una nueva forma de hacer las cosas. Más preguntas:

• ¿Cuéntame sobre una vez que usaste o ayudaste a crear un estándar de codificación?
• ¿Qué tipo de cosas quieres ver en un estándar de codificación?
• ¿Cómo te sientes al volver a escribir el código de otra persona?
• ¿Cuéntame sobre una vez que estuviste involucrado en revisiones por pares de software o documentación?
• ¿Me puede decir acerca de una propuesta o contrato para el desarrollo de software que estuvo involucrado por escrito?
• ¿Cuéntame sobre tu administrador o supervisor de software favorito?
• ¿Cuéntame sobre tu compañero de trabajo favorito o subordinado?

En el año 2012, para alguien con 15 años de experiencia en la industria que nunca haya usado el control de versiones es una señal de alerta. Podría no ser una señal de alerta si el año fuera 1982, o incluso 1992. Pero hoy, es mejor que haya una excelente explicación para esta brecha desconcertante en los antecedentes de ese desarrollador.

Las situaciones extraordinarias requieren explicaciones extraordinarias.

Esto es algo así como un mecánico de automóviles que afirma que ha estado reparando automóviles durante 15 años, pero que nunca se engrasó.

Por supuesto, untarlo con grasa no arreglará una transmisión, y ninguno de los pasos en el manual de reparación requiere tal cosa, pero ese no es el punto. El punto es que estar completamente limpio es enormemente inconsistente con la apariencia de la mecánica del automóvil cuando están trabajando. En ese trabajo, te engordas a ti mismo.

Si está entrevistando a alguien experimentado que admite que no tiene experiencia en el control de versiones, probablemente esté exagerando o fabricando parte de su experiencia (¡y ni siquiera sabe que el control de versiones es algo ampliamente utilizado e importante, y algo sobre lo que también debe mentir! )

Es posible ver todo tipo de bromistas en las entrevistas. He visto personas que no pueden dibujar un diagrama de una lista vinculada, o escribir una función que inserte un nodo al principio de una lista vinculada. Sin embargo, reclamaron 20 años de experiencia laboral.

Se puede esperar que incluso los nuevos graduados de la informática tengan una familiaridad pasiva con el control de versiones, incluso si aún no lo han utilizado ampliamente.

Me resultaría extraño, pero no imposible que un programa experimentado nunca haya utilizado un control de fuente dedicado. En una empresa con la que trabajé, utilizaron el control de origen ampliamente para su código tradicional C # y VB. Pero el código puro de la base de datos (procedimientos y scripts almacenados, así como las definiciones de tabla) no estaban bajo el control de la fuente a pesar de tener dos desarrolladores SQL profesionales cuyo trabajo principal era escribir, mantener y ejecutar código de base de datos puro. Defendí el control de origen para las entidades de la base de datos allí y solo tuve un éxito parcial.

En otra compañía, el equipo de desarrollo era pequeño (un hombre compró durante mucho tiempo, luego dos). El control de origen del desarrollador anterior era tener múltiples copias de los archivos de origen con una fecha agregada al final. Además de carecer de un mejor sistema de control de fuente, mi predecesor allí era definitivamente competente y un hombre inteligente.

Antes de convertirme en profesional, era aficionado y no utilizaba ningún control de fuente, sabía vagamente de qué se trataba pero no me molesté.

En resumen, creo que es extraño que un profesional no esté muy familiarizado con él, pero especialmente si está acostumbrado a equipos muy pequeños, sin duda es posible ser competente sin él. Al contratar, no sostendría eso contra él. Sin embargo, me resistiría absolutamente a aprender y comenzar a usarlo en el trabajo contra él ...

Mi propio 2c es que depende de cómo reaccionó cuando le preguntaron sobre VC. Las posibles reacciones pueden ser:

1. ¿Eh? Que es eso
2. No lo hicimos en su lugar
3. Sin barajar avergonzado , la administración no nos permitiría
4. Sin barajar avergonzado , pero yo mismo investigué un poco y pensé que parecía algo que deberíamos estar haciendo.

En el caso de 4, el tipo recibiría un pase de mí, tiene la actitud correcta y probablemente lo tomará bien. En el caso de 3, obtiene crédito por entender que es algo que se debe hacer, pero no tanto como 4. Si pudo nombrar un par de factoids sobre VC (enumere algunos de los paquetes de VC que existen) I ' tomaría eso como evidencia de cierta curiosidad y podría pasarlo por alto.

Si él respondió 1 o 2, es decir, si él supiera y no quisiera saber sobre VC, cuestionaría seriamente el juicio del candidato. Habrá otras herramientas (seguimiento de errores, métricas de calidad, automatización de compilación, etc.) con las que tendrá que trabajar y probablemente encontrará que tiene una batalla cuesta arriba en todos estos problemas si no está abierto a probar nuevos enfoques.

Como la mayoría de las personas aquí, creo que sería injusto perjudicar al candidato solo porque su empleador no estaba al día; Para mí, todo depende de cómo reaccionaron.

Escribir lo que ha cambiado es bueno cuando se mira hacia atrás. Me ha salvado muchas veces al calcular lo que está mal y muchos problemas se solucionaron rápidamente porque lo tenía escrito. En mi opinión, es bueno mantener un registro. Especialmente si está programando con más personas que usted.

Si está escribiendo una aplicación web, puede seguir agregando funciones sin control de versiones porque constantemente está agregando cosas nuevas. Pero tal vez escriba un registro o una publicación de noticias con las cosas nuevas.

Se trata de lo que estás programando.

He trabajado en lugares donde el proceso de aprobación del software fue de 12 a 18 meses. Si aún no estaba en la lista de software aprobado, no había forma de ponerlo en las máquinas. Las unidades de CD / DVD estaban bloqueadas y las máquinas no estaban conectadas a Internet.

El primer lugar en el que encontré el control de código fuente fue que un desarrollador escribiera el suyo, para cuando estuviera listo para probar el proyecto de varios años se estaba terminando. Apostaron a que escribirlo desde cero era más rápido que el proceso de aprobación.

El segundo lugar en el que me encontré con este problema sí utilizó el control de fuente durante los primeros meses, pero luego el cliente quería que todo el desarrollo se realizara en su red interna. Nuevamente bloquearon todo, por lo que volvieron a muchas carpetas comprimidas.

Conozco desarrolladores que solo han trabajado en estas condiciones. Quieren usar estas herramientas, les encantaría usar estas herramientas, pero no se les permite usar estas herramientas.

Investigue por qué no los han usado. No entender los procedimientos debido a la experiencia cero, es muy diferente a rechazar las herramientas.

Estoy desarrollando durante los últimos 15 años. Usé el control de versiones solo unas pocas veces. Todavía estoy usando mis propios scripts y programas programados para hacer una copia de seguridad de todas las carpetas de desarrollo de forma incremental. No sé qué decir si alguien me pregunta si uso el Control de versiones. Nunca he necesitado un sistema de control de versiones, siempre trabajé en pequeños proyectos. Quiero decir que no soy el mejor programador, pero estoy seguro de que no soy el peor. La mayoría de las veces me da vergüenza decirle a la gente que no uso regularmente el sistema de control de versiones, pero así es para mí.

Hablando desde mi experiencia como programador en sistemas IBM MVS: durante los primeros diez años de mi carrera laboral, el sistema operativo con el que trabajé tenía exactamente un tipo de archivo versionable disponible para el programador: el conjunto de datos de generación. Esto era esencialmente un archivo con un número fijo de versiones, y tenía que recordar qué versión era qué, prácticamente inútil para el control de versiones moderno. Junto con un sistema de archivos que no tenía directorios reales, solo más o menos calificadores (de 8 caracteres), el concepto de un sistema de administración de código fuente era completamente extraño para cualquiera que trabajara en ese entorno.

En realidad, no vi un sistema de control de código fuente hasta que me mudé a SunOS 3 y pude usar RCS. En ese momento era un programador de sistemas de IBM extremadamente fácil, altamente productivo y muy bueno en mi trabajo. Todas las versiones se manejaron copiando copias de seguridad en cinta y registrando dónde estaba.

Si todavía estuviera trabajando en mainframes en este momento, es muy posible que aún no haya estado expuesto a un sistema formal de control de versiones; Las alternativas que se admiten específicamente son ClearCase y Rational, ninguna de las cuales es gratuita (y de hecho ambas son bastante caras).

Entonces decir que alguien es incompetente por definición porque nunca ha usado el control de versiones es un argumento engañoso. Es necesario profundizar y mirar los detalles. Si afirman ser un desarrollador de Linux / Unix / Mac OS pero nunca han utilizado el control de versiones, eso les habla mal, y es posible que tenga que sopesar si su experiencia general es tan buena que estaría dispuesto a hacerlo. capacitarlos en ingeniería de software moderna. Si son un programador de mainframe de la vieja escuela, y eso es lo que necesita, entonces concéntrese en si tienen exactamente las habilidades de programación necesarias que desea, y resignarse al hecho de que tendrá que enseñarles esto. Como otros han dicho, su respuesta al concepto será el factor decisivo en ese caso.

¡Bastante por favor! La totalidad de nuestra comunidad no vive en comunidades sociales altamente desarrolladas donde los lugares de reunión geek y los eventos hacky son demasiado abundantes, tampoco trabajamos en compañías de desarrollo de software y algunos de nosotros ni siquiera podemos encontrar recursos publicados relevantes o actualizados. en nuestros idiomas nativos, impresos o en línea, siempre encontremos un compañero programador en la carne.

Por lo que puedo entender, si él es un desarrollador de software experimentado como usted dice, entonces probablemente haya sido un lobo solitario trabajando como freelance para pequeñas empresas.

Hay algunas razones posibles para no usar el control de versiones:

1. Trabajando en compañías que no están desarrollando software como su principal línea de negocios.
2. O si el desarrollador ha decidido utilizar algún otro sistema, solo válido para los experimentados.
3. O si el desarrollador aún no ha aprendido cómo funciona cada sistema
4. O es un problema de actitud contra las herramientas que no conocen

Pero debe tener cuidado cuando conozca a personas que asumen:

1. Que solo hay una manera de hacer algo
2. O que cada programador debe hacerlo de la misma manera que lo hace
3. O que las prácticas que utilizan las personas son fáciles de cambiar

De la misma manera que es posible que un programador pobre sea un experto en control de versiones. Mi punto es que no sé qué hace el control de versiones para tus habilidades de programación o para resolver problemas. Es una cuestión de experiencia. Muchas tiendas más pequeñas no lo usan o lo dejan en manos de los indaviduals (que a menudo trabajan solos) para que lo descubran por sí mismos.

Creo que no se trata tanto de "¿Cómo es posible desarrollar software activamente durante 10-15 años sin necesidad de control de versiones?", Sino de "¿Cómo es posible desarrollar software activamente durante los últimos 10-15 años sin tener que hacerlo? necesita control de versiones?

La programación segura es posible sin control de versiones, pero un profesional debe estar familiarizado con el estado actual de la técnica y poder seleccionar las herramientas adecuadas para hacer el trabajo. Si no utiliza el software de administración de versiones apropiado, su trabajo es arriesgado y poco confiable, y una de las razones por las que desea contratar a un desarrollador profesional es que deberían poder administrar el riesgo.

Un código base que está anotado correctamente en un VCS vale mucho más que uno que no lo es. El motivo de cada cambio puede rastrearse y entenderse, lo que hace posible que los encargados del mantenimiento tengan una comprensión más profunda de lo que necesitan saber. No hacerlo no es profesional, y la única excusa para ello sería si él / ella hubiera sido limitado por gerentes pobres en su trabajo anterior. Incluso entonces, ¿no deberían haber usado versiones para sus proyectos privados?