¿Deberías guardar una copia de todo el código que escribes? [cerrado]

Sé que la compañía para la que trabaja posee el código y obviamente será arrestado si intenta venderlo. ¿Pero es poco común que los desarrolladores conserven una copia personal del código que escribieron (para referencia futura)?

Aparentemente, este tipo fue enviado a prisión por copiar el código fuente.

¿Pero es poco común que los desarrolladores conserven una copia personal del código que escribieron (para referencia futura)?

No sé qué tan común es, pero común o no, sigue siendo una mala idea.

Los programadores a menudo operan con la mentalidad de que resolver el mismo problema dos veces es una pérdida de tiempo. Intentamos diseñar nuestro código para que sea reutilizable (a veces). Construimos bibliotecas de clases y funciones para reutilizar en algún momento en el futuro. A veces incluso regalamos nuestro código para que nadie más tenga que escribir código para resolver el mismo problema que acabamos de hacer. Por lo tanto, puede ser comprensible querer llevar "su" código cuando se mude de un trabajo a otro. Pero aún no debe hacerlo, por las siguientes razones:

1. No es su código tomar.

2. El código que escribió para su antiguo empleador es parte del negocio que construyeron. Su código es parte de su ventaja competitiva. Claro, los competidores podrían escribir su propio código para resolver el mismo problema, pero no deberían tener la ventaja de aprovechar el trabajo que su empleador pagó, posee y no le autorizó a tomar.

3. Si tienen algún sentido, su nuevo empleador no quiere ninguna parte del código que le quitó a su antiguo empleador. Cuanto más se "refiera" al trabajo que hizo para algún empleador anterior, más pondrá a su nuevo empleador en peligro legal.

4. Si alguna vez accidentalmente deja que se le escape a New Employer que todavía tiene una copia de las cosas que hizo para Old Employer, su jefe en New probablemente se dará cuenta de que tomará una copia de su código cuando se vaya para otro trabajo. Eso podría no estar bien con él o ella.

5. Incluso si no está cruzando líneas reales o solo ideas vagas de sus cosas viejas, solo tener sus cosas viejas en su posesión podría levantar sospechas de que podría estar usándolas para algo. Imagínese que Old Employer demanda a New Employer, y como uno de los pocos empleados que se mudaron de Old a New, de repente se encuentra dando una declaración. Ninguno de ustedes copió el código de Old en el producto de New, pero el abogado que está frente a usted pregunta: "Sr. SuperFoo, ¿lo tiene o lo tiene en algún momento desde que dejó Old Employer tenía en su poder una copia de cualquier código que usted o alguien más escribió mientras trabajaba en Old Employer? "

6. No necesita el código que escribió el mes pasado, el año pasado o hace más tiempo. Usted resolvió el problema una vez y ahora sabe cómo resolverlo nuevamente. O bien, puede saber cómo no resolver el problema: su nueva implementación será mejor porque tiene experiencia.

7. Hay mejores formas Es difícil regresar y aprender algo útil al leer el código antiguo fuera de contexto. Un diario o diario que describe lo que aprende, las ideas que tiene, etc., es mucho más útil más adelante.

8. Incluso si Old Employer sabe que tienes su código y está de acuerdo con eso, ¡ todavía no lo quieres! Lo único que puede surgir de tenerlo es una llamada telefónica a las 3 am: "¿Hola, SuperFoo? ¿Cómo estás? Escucha, tienes una copia de nuestras cosas, ¿verdad? Mira, tenemos un problema con el sistema, y ​​lo hemos reducido a un par de archivos que usted escribió que nuestro nuevo tipo simplemente no entiende. Sé que es tarde, pero ¿podría guiarlo a través de SuperDuper.pl? "

Déjalo ir. No lo necesitas

Siempre guardo una copia del código que escribo y la llevo entre trabajos. Los empleadores posteriores nunca llegan a ver / ejecutar el código, pero lo uso como referencia en casa: "Ah sí, ¿no hice algo similar a eso en el Proyecto X?".

¿Es esto legal? Depende de la jurisdicción y las circunstancias, pero es bastante común. Moralmente, no tengo ningún problema con eso, siempre que no solo le des código a nuevos empleadores ... Es un recordatorio y una demostración de lo que has hecho, en lugar de un recurso gratuito para tu empleador.

[La otra cara de esto es la vergüenza inevitable que aparece cuando miras el código anterior: '¿Qué estaba pensando? ¿Por qué demonios lo hice que forma ?? ']

Esta es una muy mala idea. Ese código no te pertenece (legalmente hablando) y tenerlo en posesión puede meterte en muchos problemas. Esto se vuelve aún más cierto cuando te mudas a un nuevo trabajo y aún mantienes ese código fuente. Peor aún si es un competidor. Su empresa no estaría contenta si tuviera acceso a su código fuente cuando ya no trabaje para ellos.

Se trata de gestionar su riesgo. Obviamente, se espera que conserve cosas de un empleador anterior que pueda usar en otro lugar. Es por eso que hacen que sus cláusulas de no competir firmen que duran X meses / años después de que las deja, sin embargo, tener posesión del código lo hace más vulnerable a alguien que lo acusa de copiar descaradamente el código de la compañía (incluso si no lo hizo, y solo usé las mismas ideas). ¿Vale la pena tener el código para gestionar este riesgo?

Seguramente lo útil que obtuviste al escribir el código no es la sintaxis exacta; es el conocimiento que obtuviste. Probablemente no valga la pena lidiar con todas estas cosas legales.

No es raro

Tengo una copia de casi ¹ cada código que escribí profesionalmente, y ciertamente todo el código de mis proyectos actuales, independientemente de quién lo escribió ² . Junto con el código , tengo una gran cantidad de documentos legales que definen claramente lo que puedo y no puedo hacer con él. Simplemente tener el código no es lo mismo que tratar de sacar provecho del código.

Dicho esto, es un problema legal, y los problemas legales tienden a ser extremadamente complicados y localizados. En caso de duda, realmente necesita hablar con un abogado. Puedo mantener mi código, pero estoy 99% seguro de que no me meteré en problemas por hacerlo.

_{¹ Lo que falta es principalmente lo que no me importó archivar. Solo falta un código de proyecto pequeño por razones legales.
² Naturaleza de los proyectos y mi papel en ellos, soy uno de los tipos que necesitan tener al menos una idea de lo que sucede, incluso si no estuve involucrado en la construcción de un módulo específico.}

Veo a su hombre chino arrestado y lo crío con un "código no es propiedad, por lo tanto no puede ser robado".

Ref .: Código 'no propiedad física', reglas de la corte en el caso de espionaje de Goldman Sachs

Con eso dicho.

• ¿Guardo el código que escribo? Absolutamente.
• ¿Mantengo proyectos completos? Absolutamente.
• ¿Me aseguro de pasar el código de mi PC desde el trabajo a una máquina doméstica? ¡Puedes apostar!
• ¿Alguna vez vuelvo a usar ese código en otra empresa o en un proyecto personal? No.
• ¿A menudo miro el código antiguo y me pongo WtF? Todo el tiempo.

Aquí hay una pregunta simple para ti. Diríjase a su jefe y dígales: "Tengo una copia de todo el código que escribí mientras trabajaba aquí. Solo el código que escribí, no otras personas. Esto es para mi propia educación, y nunca lo entregaré".

Sus próximas acciones dictarán (sí, esa palabra existe en América del Norte / Mundo) si usted está equivocado o correcto en sus ojos.

Independientemente de su propia "ética", usted trabaja para un empleador. Si ellos consideran que lo que estás haciendo está mal, entonces está mal basado en su ética. A medida que le pagan, y usted está empleado por ellos, entonces está en su tribunal acordar con ellos o estar en desacuerdo, lo que podría hacer que lo despidan.

Ahora es una cuestión de integridad. Dejé que un empleado anterior tomara parte de nuestro código, pero primero lo examiné todo.

El hecho de que creas que estás en lo correcto no te convierte en lo correcto. Por lo general, los desarrolladores de software firman contratos cuando están empleados. Si firmó uno, debe cumplir con su palabra.

¿Es raro que los desarrolladores conserven una copia personal del código que escribieron?

Respondiendo la pregunta directamente, diré en mis experiencias que esto es poco común. La excepción a esto que he visto son las personas que hacen mucho trabajo independiente y mantienen el código a mano para futuros proyectos de mantenimiento y mejora de sus clientes, y me imagino que esto está claramente establecido en el contrato (aunque no estoy en la costumbre de revisar los contratos independientes de mis amigos, así que quién sabe). Las personas que conozco que trabajan en empresas más grandes nunca han admitido guardar el código de los antiguos empleadores.

Sé que no lo haría porque no puedo pensar en una sola situación en la que sería útil (sin mencionar que estoy bastante seguro de que mi empleador actual prohíbe tales cosas; solo tendría que buscar los documentos para estar seguro ) El código que he escrito / arreglado suele ser tan específico para un requisito comercial particular que no puedo imaginar que vuelva a aparecer en el futuro de tal manera que sea más fácil reutilizar el código anterior que escribir nuevo código.

En el pasado, era común que los desarrolladores tuvieran su biblioteca personal de rutinas que usarían para resolver problemas en el trabajo actual. La fuente se quedaría atrás cuando el desarrollador se fuera, pero cualquier mejora también fue con él.

Esto resultó en una situación de ganar-ganar. También era solo un subconjunto de todo el código escrito.

Por supuesto, la mayoría de lo que había en las bibliotecas personales estaría en las bibliotecas estándar de hoy.

Bajo una relación de empleador a empleado en la mayor parte de América del Norte, es ilegal transferir o transmitir material digital (es decir, el código fuente) desde el equipo de su empleador sin la autorización legal previa del empleador.

Parte de las leyes legales relacionadas con la definición de un empleado en el lugar de trabajo, es la descripción de que el empleado no proporciona su propio equipo de trabajo a menos que se indique lo contrario en el contrato del empleado, con excepción de los oficios que requieren que el empleado compre su propio equipo (es decir, trabajador de la construcción).

La mayoría de las leyes laborales en América del Norte definen al empleador como el principal tomador de riesgos en una relación de empleado a empleador. Al empleado se le paga por su tiempo mientras el empleador proporciona materiales, equipos y controla las actividades laborales del empleado.

¿En qué momento durante esta relación está bien robar material valioso del empleador, que ha pagado y se ha arriesgado al crear dicho material?

El problema clave con esto fue la pregunta "¿código fuente que escribiste?". No señor, no fue usted quien lo escribió. Bajo la guía de su empleador, fueron ellos quienes lo escribieron. Usted es solo la mano contratada que lo escribió. No hay un tribunal en América del Norte que se ponga del lado de usted en caso de que su empleador tome medidas legales para asegurar su propiedad. Solo copiar el código fuente a una memoria USB puede llevarte al agua caliente.

Dicho esto, si un empleador le permitió usar su propio equipo (es decir, una computadora portátil) o transmitir el material, entonces es un asunto diferente. El empleador debe notificarle al finalizar que cualquier material debe ser devuelto / destruido.

Solo pensé en publicar esta respuesta, porque parece que algunas personas pensaron que era un área gris. Realmente no creo que si usted es un desarrollador, deba ir a Internet publicando copias de los materiales del empleador. Quiero decir, claramente ya sabías la respuesta a esta pregunta porque creaste una nueva cuenta de miembro solo para hacer esta pregunta. ;)

He hecho esto en el pasado hace unos pocos trabajos.

Sin embargo, nunca volví y lo miré. Ocasionalmente he reutilizado ideas y cosas que aprendí, pero no he encontrado una razón para volver y mirar el código.

Entonces no me molestaría más. Es legalmente dudoso, y nunca lo he encontrado útil en la práctica.

Seguro. Me gusta guardar una copia de todo el trabajo que hago, ya sea escribir código o no. Llámalo álbum de recortes, si quieres. ¿Rompiendo las reglas? Quizás.

Los comentarios sobre la ventaja competitiva son irrelevantes a menos que su próximo empleador sea un competidor directo. Si pasa de una compañía telefónica a una casa de software, o de un desarrollador de juegos a un desarrollador de bases de datos, no importa. Si realmente planea reutilizar el código, bueno, esa es una historia diferente.

Curiosamente, a menudo escuchas que los desarrolladores web traen una "caja de herramientas" con un conjunto estándar de bibliotecas JavaScript y hojas de estilo CSS . Pero no he visto eso mencionado aquí.

Recientemente he eliminado todo el código antiguo que mantenía de mi empleador anterior. Solo mantuve partes de código que pensé que eran buenas para futuras referencias. De hecho, he descubierto que me he movido considerablemente desde que me fui y nunca me he referido al código anterior. He encontrado / descubierto / aprendido formas mucho mejores de resolver los mismos problemas.

Sin embargo, fue un pequeño viaje agradable por el carril de la memoria :)

Creo que debe haber una distinción entre un patrón de diseño y un código real (copiar línea por línea)

Anotar algo de psuedocode es algo así: esta es una excelente manera de cargar de manera diferida X en Y es una cosa. Escribir todo el código es otra cosa.

Con el permiso de su empleador, publique el código ordenado y reutilizable como proyectos de código abierto para que otras personas lo usen. Entonces su empleador también puede beneficiarse de las contribuciones de otras personas a este código.

De esta manera, puede mantener el código legalmente, crear una cartera pública de código que ha escrito y el código puede beneficiar a otras personas.

Por una cantidad diferente de razones, como trabajar desde casa, es posible que ya tenga una copia, y por mi parte no las eliminaría después de un trabajo, ¿por qué hacer eso? No va en contra de mis creencias o algo así.

Pero, con respecto a su uso, ¡no es tan útil como una publicación de blog!

En pocas palabras: escriba su código, escriba un blog sobre los problemas que ha enfrentado y cómo los resolvió (especialmente cuando se trata de cosas genéricas y amplias), y no le importe guardar un recuerdo (posiblemente encriptado) del último trabajo.

En finanzas, el CFA aborda este problema. No se le permite tomar información relacionada con los clientes o su trabajo para la empresa (en este caso, el código). Pero nada le impide memorizar lo que puede y luego escribirlo más tarde.

No estoy seguro de cuán legítimo es eso, pero creo que su mejor opción es dejar su código fuente, pero anote sus ideas y cómo lo hizo tan pronto como llegue a casa. Robar es robar y en la corte lo único que intentan averiguar para decidir es si copiaste el código o no.

Si está guardando su código con el objetivo de reutilizarlo más tarde, tengo dos problemas con eso:

• Si el código es específico del dominio, probablemente también sea propietario. De todos modos, no hay dos negocios o problemas exactamente iguales e intentar solucionar un problema con la solución para otro no es un buen patrón.

• Si el código que está guardando resuelve un problema común, debe cuestionar su enfoque. ¿Por qué gasta tanto esfuerzo para resolver un problema común cuando es probable que existan (y mejores) soluciones de código abierto?

  Si cree que tiene la mejor solución para un problema común, realmente debería intentar compartir su código públicamente en un repositorio público y / o blog de código cuando lo escriba, no guardarlo para usted. Su jefe no debe oponerse a compartir una biblioteca genérica ni forzarlo a reinventar la rueda (si lo hace, busque un nuevo trabajo).

Si está guardando su código porque desea mostrárselo a un posible empleador o para mejorar sus habilidades, le sugiero que contribuya a un proyecto de código abierto.

Todavía no he guardado ningún código que he hecho para los empleadores. Cosas independientes que he guardado (puede ser difícil soportar a un cliente si pierdo mi código).

Sin embargo, estoy considerando mantener el código que hice para este empleador. La razón es que soy desarrollador web y he desarrollado muchas cosas del lado del cliente que se ven bastante bonitas. No los diseñé, pero los implementé y a menudo se me ocurrió la idea. Me gustaría guardar una copia de estas cosas para crear una cartera en línea. Como todos sabemos, los sitios no duran para siempre, por lo que no puedo contar de manera realista con mi trabajo en línea. Tener una copia de seguridad me permitiría tener una cartera en línea.

Sé que los diseñadores a menudo guardan copias de su trabajo (incluso si se trata de trabajo por contrato) para fines de cartera.

No estoy seguro de cuál es la legalidad de esto (no se menciona explícitamente en mi contrato).

Bueno, para desarrollar la lógica comercial de mi empresa, no puedo guardar el código porque es propiedad ilegal y personal de la empresa. Como desarrollador, sé cómo desarrollar esa lógica, por lo que puedo tener esa lógica en mi mente. Básicamente, por defecto, está almacenado en su mente, y si lo necesita la próxima vez, automáticamente debe implementar la lógica / mejor lógica que la anterior. Es la naturaleza humana y la inteligencia. :)

Pero el problema se crea cuando desarrolla alguna lógica de utilidad, son reutilizables y siempre importantes, es posible que la necesite con frecuencia en diferentes proyectos. Por lo tanto, deberías tenerlo contigo.

Tengo una solución alternativa para eso. Simplemente cree un JAR sin fuente / documentación para esas utilidades y agréguelo como un JAR externo de terceros en su proyecto. Probablemente al hacer esto puede confirmar su responsabilidad, así como su auto satisfacción de que tiene el código ;)

No guardo el código por una simple razón: la compañía me pagó para escribir el código para ellos. Les doy mi código y ellos me dan mi cheque de pago. El tipo que hizo mi almuerzo no puede quedarse con parte de él, ¿por qué el código sería diferente?

Además, antes de dejar el trabajo, todos esos dolores de cabeza permanecen allí, nuevo trabajo, nuevo comienzo, pero con un poco más de experiencia y comprensión de los tipos de problemas en el dominio de ese antiguo trabajo.