Como empleado de una empresa, cuando escribe código, ¿siente que tiene un archivo adjunto? ¿Sientes que tienes algo de propiedad del código? ¿O lo escribes completamente separado de él sin preocuparte por lo que le sucede después de que te has mudado a otra cosa?
EDITAR: No estoy hablando de escribir código incorrecto y luego ejecutar ...
Respuestas:
Después de 30 años como contratista, es mixto.
Todo es desechable. He trabajado con cientos de clientes. Nunca volveré a ver el código. ¿Por qué apegarse? No hay sentido de propiedad.
Es muy visible Es más costoso que el código interno, por lo que recibe mucho escrutinio. Dado que no estaré cerca para mantenerlo, se somete a un gran escrutinio. Los tutoriales y las entregas de código son muy importantes. Hay algo de orgullo en la artesanía. Pero no hay sentido de propiedad.
Mi récord es de 17 años de producción. 12 de esos años con cero mantenimiento de ningún tipo.
Lo sé porque recibí una llamada. Estaban revisando sus sistemas de contabilidad y querían saber cómo reemplazar el inteligente algoritmo de asignación de costos que había creado hace muchos años. Miré el código y los archivos no cambiaron desde la última mejora hace 12 años. (No es una corrección de errores, AFAIK.)
La siguiente carrera más larga, que yo sepa, fue de 7 años de operación impecable. Eso, sin embargo, tenía un problema serio de Y2K y requería un poco de revisión para usar nombres de archivo que tenían años de 4 dígitos. Todos los algoritmos internos eran correctos, pero los archivos de registro habrían aparecido en el orden incorrecto.
Una vez más, sé que fue perfecto porque los archivos no habían sido tocados desde la última versión que hice.
Entonces, sí, hay mucho orgullo en la artesanía.
Pero no "propiedad". Es su código, no el mío. Solo lo construyo.
Como desarrollador más o menos en solitario, el miedo a tener que mantener lo que escribo es el principal impulsor detrás de mí tratando de no escribir código horrible.
En el trabajo, parte del código es mío, en un sentido similar al de la silla en la que estoy sentado. Lo escribí, lo hice lo mejor que pude, me siento posesivo, la gente me preguntará acerca de los cambios y se referirá a él como mío. Y, como mi silla, una vez que deje la empresa, nunca más la volveré a ver, y ya no tendré ningún apego emocional.
La palabra "mío" tiene muchas variaciones en su significado. "Mi esposa" y "mi cepillo de dientes" no son estrictamente paralelos.
Si escribe código para usted, puede permitirse tener sentimientos hacia él. Si escribe código para un negocio, debe purgar brutalmente esos sentimientos siempre que sea posible. No puedo contar la cantidad de veces que he visto a buenos programadores causar dolor al emocionarse por el código.
Dígase a sí mismo: "Lo logré, es bueno, pero no es mío y puedo hacer más". Si lo cree , cuando 6 meses de su vida se vuelvan obsoletos porque un representante de ventas de un producto inferior le dio a su jefe un BJ durante el almuerzo, no perderá su trabajo por volverse loco con él.
Recuerda que te están pagando. A todos nos gustaría estar haciendo cosas geniales, pero si nos están pagando para cavar hoyos, luego llenarlos nuevamente, ese es su privilegio. Acabo de tener una situación en la que escribí una aplicación web, luego pasé meses incorporando características terribles, luego meses más codificándola de nuevo al estado original. Las últimas dos semanas de "trabajo" obtuve de mi repositorio SVN, luego lo volví a comprometer con los nuevos números de versión. Y estoy de acuerdo con eso.
No, pero realmente odio tener que corregir errores introducidos por otros en el código que escribí originalmente. Sería más feliz si me hubieran asignado el cambio en primer lugar. Lo odio aún más cuando la solución está completamente fuera del diseño original, por ejemplo, creando una dependencia circular con un módulo de nivel superior.
Si y no.
Sí, es algo que creó y, por lo tanto, tiene un archivo adjunto, al igual que un diseñador de automóviles se siente orgulloso o avergonzado cuando ve autos que diseñaron en la carretera.
No: en lo que respecta a la propiedad, generalmente renuncias a cambio de que te paguen por trabajar en una empresa. Los empleados de la línea de fábrica que fabrican automóviles no son propietarios de cada uno que sale de la línea porque se les paga por su tiempo.
Me siento muy propietario sobre el código que escribo; representa las decisiones que tomé sobre cómo resolver un problema determinado y, por lo tanto, es un reflejo de mi capacidad para pensar un problema de manera racional e idear una solución lógica y con suerte elegante. Dicho esto, todo lo que escribo en horario de empresa pertenece a la empresa. Espero que nada de eso vuelva a morderme, y prefiero que me pidan que arregle mi propio código, pero si no, entonces no. (Y podría agregar que el tipo que escribió el código hace tres meses y que puso mi nombre en el control de fuente es un idiota).
De ningún modo. Una vez que lo verifico, ya no es "mío". Seré el tipo de ayuda para el mantenimiento y la resolución de problemas, naturalmente, pero no siento ningún sentido de pertenencia al respecto.
He conocido a algunas personas que se sentían muy propietarias de su código, hasta el punto de que se irritarían si alguien más corrigiera un error o lo modificara de alguna manera sin ejecutarlo primero. Nunca me he sentido así. Todo lo que pido es que si encuentra un problema en mi código y lo soluciona, dígame cuál fue el problema y cómo se solucionó para que no cometa el mismo error en el futuro.
Me encantan los códigos que escribo. Los entiendo y los adapto para que otros también lo hagan. Cuando las personas se acercan a mí y me dicen "Amigo, todavía estamos usando ese guión que escribiste para nosotros. Es tan estable y portátil", me encanta ese sentimiento de orgullo y propiedad.
No hay nada malo en adjuntarse a su código si puede ver dónde va a terminar, es decir, si todo es interno y sabe para quién o para qué está programando, entonces diría que es algo bueno obtener adjunto Porque solo te encantará crear más piezas de brillo, mucho más.
Por otro lado (totalmente consciente de que podría estar reiterando lo que dijo @ S.Lott) si el código va a terminar como propiedad de un cliente, entonces no tiene sentido volverse sentimental al respecto. Es como ... cuidar al cachorro de tu amigo cuando se va de vacaciones. : - /
Los contratistas y consultores que tal vez nunca vuelvan a ver su código probablemente no sean el candidato ideal para apegarse emocionalmente a su código. Tener que "abandonarlo" una y otra vez probablemente paralizaría el impulso creativo de los consultores pobres después de un tiempo.
Si lo miramos desde la perspectiva de un empleado y no de un contratista, diría que me gustaría que todos los miembros de mi equipo se sintieran dueños del código que escriben y de todo lo que crean. Esta propiedad y orgullo deberían extenderse a todo el equipo. Sentir orgullo y propiedad crea un apego al producto en las preguntas y agrega significado y sentido al trabajo de un miembro del equipo. He visto que esto aumenta enormemente el rendimiento en equipos pequeños y grandes.
Lo que debería evitarse y lo que no me gusta son las personas que parecen emocionalmente apegadas a las líneas específicas de código que han escrito y lo defiende hasta la tumba. No quieren que se realicen cambios, miran hacia abajo y rechazan cualquier idea de cambio o mejora e intentan justificarlo con algo que suene creíble. Lo que a menudo se reduce, según mi propia experiencia, es el miedo al cambio y el miedo a lo desconocido. En realidad, no es renunciar a sus viejas líneas de código ese es el problema. En cambio, es tener que asumir algo nuevo, a veces no escrito por ti mismo, y el miedo a fallar.
Este tipo de apego "enfermo" al código es algo en lo que trabajo duro para tratar de evitarlo. Pero las conexiones emocionales "saludables" con el producto, y por extensión el código escrito, es algo que animo.
Esta es una pregunta interesante y estoy de acuerdo con una de las publicaciones anteriores: Sí y No, pero por diferentes razones.
¿Me apego al código? Definitivamente si. Pero no creo que sea el código en sí, sino la arquitectura y la aplicación en general. Por lo general, debe hacer una gran cantidad de investigación específica de dominio antes de poder realmente poner en código lo que la gente de negocios quiere (a menos que esté escribiendo un IDE, entonces definitivamente está atrapado en la recursión).
Por otro lado: no hay muchas cosas que me gusten más que tirar partes obsoletas de la base de código. No importa cuán difícil haya sido la escritura. El viaje es mucho más importante que el producto (al menos para el ego, por supuesto, el producto en sí también tiene que funcionar).
¿Hay un sentido de propiedad? Bueno, depende de la situación del proyecto. Cuando nunca volverás a ver el código (porque tu parte en el proyecto ha terminado y sigues adelante), ¿por qué te enamoras de las cosas? Sin embargo, si sigues apoyándolo (de cualquier manera), ¡una sensación de apego es algo bueno! Cuando te preocupas por el producto que estás construyendo, es muy probable que intentes entregar artefactos de alta calidad.
Así que, en general, trato de adoptar una "relación" pragmática con el código que escribo.
Demonios, sí, una vez golpeé a un compañero de trabajo porque era lo suficientemente arrogante como para renombrar un par de variables.
No en realidad no. Me pagan por el desarrollo de software. Aunque lo admito, ver correcciones de errores hechas a mi código por otros desarrolladores tiene un impacto en el ego.