¿Debería escribir una buena documentación y un código limpio para aumentar el "Factor de bus"?

48

Uno de los objetivos principales de las empresas de desarrollo de software es aumentar su factor Bus. Esto también es defendido en una charla organizada por Google .

Eso significa que debe codificar y documentar todo de una manera que si mañana lo atropella en autobús, el proyecto aún puede continuar. En otras palabras, deberías hacerte fácilmente reemplazable por otro programador con un conjunto de habilidades similar al tuyo.

Al ser reemplazable, ¿no va eso en contra del interés de un desarrollador? En el libro, 48 leyes de poder, la Regla 11 establece que debes tratar de mantener a las personas dependientes de ti, para ganar poder, lo que luego se traduce en recompensas monetarias.

Además del escenario, donde necesita documentación para usted mismo para continuar un proyecto después de 6 meses de pausa, parece haber un claro conflicto de intereses aquí entre el desarrollador y la compañía de software.

Entonces, como programador, ¿debería realmente escribir una excelente documentación y un código fácil de leer para todos? ¿O debería escribir el código y la documentación de manera que haga el trabajo y usted mismo pueda entenderlo, pero otra persona puede tener problemas para entenderlo?

siamii
fuente
41
El libro de Greene es adecuado para déspotas y lacayos que se ganan el favor en feudos. No es una buena filosofía moral para el trabajo en equipo. Por decir lo menos! [Tenga en cuenta que wikipedia clasifica este libro bajo "sociopatía"]
Steven A. Lowe
27
Nunca te contrataría: D
deadalnix
37
Los cementerios están llenos de gente insustituible.
Trabajo
20
Nunca quieres ser insustituible: ¿cómo obtienes un ascenso si no puedes ser reemplazado? A menos que estés feliz exactamente donde estás, para siempre, el 'Factor de Bus' siempre es importante.
Dave
11
"El libro comparte elementos temáticos con El Príncipe de Niccolò Machiavelli y ha sido comparado con el tratado clásico de Sun-Tzu, El arte de la guerra". No creo que quiera trabajar con nadie que vea su lugar de trabajo como la política italiana del siglo XVI o ... la antigua guerra china.
Cascabel

Respuestas:

110

Debes esforzarte por ser irremplazable no escribiendo un código que nadie más entienda, sino reuniendo más experiencia y conocimiento que otros. La primera forma lo convierte en un desarrollador con el que todos intentan evitar trabajar, ya que temerán y detestarán mantener el código que escribió. De esta manera, te conviertes en un miembro del equipo buscado, a quien los gerentes quieren tener en su equipo.

En mi experiencia, escribir código limpio y bien documentado (y preferiblemente autodocumentado) siempre ha valido la pena. De hecho, aproveché casi todas las oportunidades para ayudar y enseñar a otros (además de aprender de ellos cuando sabían algo mejor), y casi nunca me sentí en peligro de ser reemplazado por alguien menos capaz que yo. De hecho, esto usualmente ayudó a todo el equipo a trabajar mejor y resolver problemas más rápido, lo cual es el sueño de todo gerente, y un gerente sensato no quiere reemplazar a los miembros de un buen equipo.

Péter Török
fuente
1
Es interesante que esto se mencione ahora, porque hace unos días me dijeron lo valiosos que fueron algunos diagramas que hice de uno de los proyectos en los que estoy trabajando actualmente, para las personas que probablemente nunca lo harán. Toca el código. Eso y, por supuesto, proporcionarme una vista de alto nivel de los diferentes módulos y cómo interactúan. Es posible que esa descripción general no sea particularmente necesaria en este momento cuando lo tengo todo en la memoria nueva, pero casi seguramente ayudará cuando vuelva a visitar el código dentro de un año ...
un CVn el
2
Algunas personas que escribieron código (malo, ofuscado) que los hizo "irremplazables" en mi trabajo ya no trabajan aquí. Los mejores programadores vieron su trabajo durante las revisiones de código o arreglando cosas mientras estaban de vacaciones. Vieron la "calidad" de su trabajo, y fueron enlatados.
CaffGeek
44

Si va a manipular organizaciones o personas de manera tan transparente, será mejor que sean estúpidos o estén en un aprieto que no les deja otra opción. Una tienda de desarrollo de software bien administrada vería su código oscuro y la documentación que faltaba y simplemente lo despediría antes de que pudiera causar mucho daño. Si están mal administrados o no pueden lograr que otros desarrolladores trabajen para ellos, ¿por qué querrías tener una actitud segura con ellos?

PD Ni el Sr. Greene ni Maquiavelo lograron mucho aparte de escribir libros que intentaron halagar a los posibles "hombres duros" de la época. Siga sus consejos con un grano de sal.

Charles E. Grant
fuente
42

Si eres insustituible, no puedes ser promovido.

James McLeod
fuente
14
Peor aún, en algunos lugares, si alguna vez demuestras que puedes tomar el código que no funciona de otras personas y hacerlo funcionar, nunca más se te permitirá trabajar en tu propio código, porque será percibido como más barato dejar que los otros chicos desbaste una gran pila de vapor, y luego haga que limpie y pula dicha enorme pila de vapor.
John R. Strohm
mejor argumentación sobre el tema
ZJR
2
Respuesta clásica de hecho.
Sarawut Positwinyu
@ JohnR.Strohm Amigo !!!! He estado allí y eso se siente muy mal. Al ser un ingeniero más cuidadoso, tomaría un poco más de tiempo en una tarea. Entonces, el gerente comenzó a permitir que otras personas escribieran código en mal estado rápidamente y luego me pidieron que lo limpiara en una revisión de código. Me sentí absolutamente mal utilizado porque ese papel se convirtió en mi relevancia para el equipo a pesar de que no era lo que quería. No hace falta decir que abandoné el equipo poco después de darme cuenta de esto.
davidXYZ
17

No quieres ser insustituible. No quieres que la gente se sienta dependiente de ti, quieres que te aprecien. En general, desea mantenerse alejado de las personas, que creen que incluso la mitad de las leyes del poder deben aplicarse a las relaciones (profesionales o personales).
Estas reglas son un conjunto de instrucciones sobre cómo establecer con éxito una situación de ganar-perder. Lo que quieres es una situación de ganar-ganar .
Tan pronto como las personas comiencen a sentir, estás tratando de empujarlos al lado perdedor de una situación de ganar-perder, lucharán. Los intentos de establecer situaciones de ganar-perder a menudo terminan en un resultado de perder-perder, porque efectivamente está desperdiciando recursos para llevar a su pareja a una posición perdedora, en lugar de invertirlos en el éxito general de su asociación.

Si hace esto con sus empleadores, intentarán imponerle medidas para reducir su monopolio de conocimiento. En su mayoría, estas serán pautas ridículas sobre cómo debe hacer su trabajo y, por lo tanto, convertirán su vida laboral en un infierno. Además, lo llamarán a las 3 en punto de la noche cuando algo se rompe, porque usted es la única persona que puede solucionarlo. Tratar de explotar situaciones como el apalancamiento puede ser contraproducente y causarle más problemas.

Los cementerios están llenos de hombres indispensables.
- Gaulle, Charles De

Así que corta la basura y haz tu trabajo correctamente. Si no es por otra cosa, entonces para ti, porque es probable que seas la pobre alma, que tiene que hacer algunos cambios en el código dentro de 2 años.

back2dos
fuente
Descubrí que cada vez que trato de establecer una situación de "ganar-ganar", la gente querrá ganar y parecer superior. Es casi como ese libro sobre cómo funciona la mafia: si tratas a un compañero como igual, muy pronto asumirá que es superior a ti. Funciona en el diseñador gráfico que acaba de salir de la universidad durante 3 años: cuanto más lo respetaba, más me trataba como a basura. Y ahora parezco superior al principio, y más personas me respetan. Eso raro. Pero el lugar de diferencia debería tener una cultura diferente. Trabajo en las nuevas empresas de Silicon Valley.
nopole
1
@ 動靜 能量: Esto suena más como perder-ganar. El objetivo de ganar-ganar no es ser amable con todos incondicionalmente. Si tiene la sensación de que alguien lo trata como basura, debe abordarlo de manera abierta, clara y razonable. Se puede demostrar fácilmente que si alguien en su equipo se comporta como un imbécil, no es beneficioso para el rendimiento general del equipo.
back2dos
¿Es "perder-ganar" una situación especial en el sistema "ganar-ganar" o "ganar-perder"? No puedo encontrar mucha información ... pero tenga en cuenta que no todo en el mundo puede ser ganar-ganar. El compañero de trabajo que quiere ser el director o el líder del equipo definitivamente no lo hará ganar-ganar. O los compañeros de trabajo que quieren aparecer como la súper estrella u obtener un ascenso, un aumento de sueldo, proteger su título de "arquitecto" o no ser despedidos antes de la fecha de un año de la opción de compra de acciones, definitivamente no lo verán como "ganar-ganar" cuando necesita desanimarte. Ahora ni siquiera quiero entrar en una situación de "perder-ganar" para empezar ...
nopole
la razón es que si él me trata como a una basura primero, probablemente lo odiaré un poco, y luego no será una buena relación. Si parezco superior y que él me respeta un poco, entonces la relación puede continuar mejor sin los altibajos. Pero cierto, descubrí que en el valle de silicio de garganta cortada, si estás "aceptando" y "tolerando", te conviertes en un felpudo que a la gente le gusta pisar. Así que definitivamente tome represalias apropiadamente o hágale saber que hay una consecuencia.
nopole
@ 動靜 能量: Sigue el enlace en mi publicación. En su caso, debe abogar abiertamente por ganar-ganar o no llegar a un acuerdo. A menudo, todo tipo de interacción se convierte en peleas, cuando pasar tiempo discutiendo la forma en que se aborda la interacción resolvería las cosas. Es tan simple como: "Preferiría que nuestra relación fuera una colaboración, en lugar de una competencia, y estoy dispuesto a hacer compromisos en consecuencia. Si no lo ve como una opción, sea lo suficientemente honesto como para decirme ahora. Si lo intenta para usar esto para burlarme, te arrancaré las bolas ". Aunque es posible que desee reformular el último bit;)
back2dos
15

Las respuestas negativas no son demasiado sorprendentes, dada la cantidad de programadores mejores que el promedio que atrae este sitio. Las personas con talento generalmente no necesitan recurrir a este tipo de tácticas de seguridad a través de la ofuscación. Pero trabajé en un proveedor automotriz de Fortune 500 con unos pocos desarrolladores no tan talentosos que se habían forjado pequeños feudos para ellos, que guardaban celosamente al crear grandes cantidades de documentación para las horrendas interfaces que habían diseñado.

El trabajo completo de un tipo era mantener el código para un módulo que unía dos subsistemas completamente separados, permitiendo que los módulos en cada sistema se comuniquen a través de un UART. Básicamente, fue la programación en serie 101. En lugar de simplemente crear una interfaz general que se parecía a esto:

  int sendData (int targetModule, void * data, size_t byteCount);
  int recvData (int sourceModule, void * data, size_t maxBytes);

creó códigos de operación separados para cada mensaje que cualquiera de los dos módulos de comunicación podría querer enviarse entre sí. Lo que significaba que su módulo necesitaba saber acerca de cada mensaje, y necesitaba actualizarse cada vez que se agregaba o cambiaba un mensaje. ¡Habla sobre intimidad inapropiada!

La cosa es que este tipo mantuvo un documento de Word que enumeraba todos los códigos de operación / mensajes, y lo actualizó diligentemente según fuera necesario. Se convirtió en todo su trabajo . Algunas veces a la semana, enviaba una nueva revisión a todas las personas lo suficientemente desafortunadas como para tenerlo en su camino crítico. Y esto fue visto como 'profesional', ya que a la gerencia le encantaba ver la documentación. Un poco me hace llorar por la industria automotriz.

Creo que mi punto es: a veces escribir documentación puede, de hecho, proteger a los programadores mediocres. Los gerentes a menudo no pueden distinguir entre un buen diseño y uno malo, y muchos se ven obligados a tomar decisiones técnicas con información limitada. Es increíblemente estresante para ellos. Ver un documento de Word con docenas de tablas cuidadosamente formateadas puede ser muy reconfortante, incluso si lo que describe es una idea fundamentalmente mala.

evadeflow
fuente
Una perspectiva interesante
scribu
Esto no se limita solo a la industria automotriz. Creo que cualquier organización grande, que no esté en el campo del software / tecnología en sí, sino que emplee desarrolladores de software (entre otros miembros del personal de TI), sufrirá este tipo de cosas en mayor o menor medida.
CraigTP
Creo en el valor de la documentación, pero la documentación no es lo que protege el trabajo de este tipo. Él solo está allí debido a la gestión incompetente y la complacencia. Es sorprendente que nadie se haya tomado 90 minutos de su día para escribir una nota titulada: Cómo ahorrar millones de dólares Y construir un mejor producto. Quizás esto sea parte de la razón por la cual compañías como GM y Chrysler se encontraron en agujeros muy profundos y muy caros.
Caleb
1
@Caleb: En cualquier organización grande, ninguna buena acción queda impune. Es mucho más fácil permitir a otros su feudo y crear un feudo para ti, si puedes.
Gilbert Le Blanc
3
@Caleb: Nos estamos saliendo del tema, pero yo y otros como yo hemos decidido no luchar contra la naturaleza humana. Puede lograr una meritocracia en un pequeño (<20) grupo de tecnología de la información, pero una vez que pase aproximadamente 100 desarrolladores de software, su organización será un feudo, le guste o no.
Gilbert Le Blanc
14

Al ser reemplazable, ¿no va eso en contra del interés de un desarrollador?

Odio decírtelo, pero todos son reemplazables. Claro, a veces puede ser un pequeño desafío reemplazarlo (si tiene experiencia y es lo suficientemente brillante), pero son años luz de imposible.

La manera de ser realmente un producto valioso para su empleador (no solo el empleador actual, sino cualquier empleador) es demostrar la capacidad de escribir código que sea fácil de entender para cualquiera que lea el código (poco tiempo de aceleración para trabajar con él) y documentar el código (cualquiera puede obtener una visión general de alto nivel de sus sistemas sin profundizar en el código).

En realidad, ser bueno en la documentación del código es una cualidad difícil de encontrar en estos días, por lo que eso solo lo ayudará a diferenciarse de los demás.

El código limpio y bien documentado también es digno de ser incluido en un currículum (al menos, resultados tangibles del mismo, es decir, "pudimos atraer a nnuevos desarrolladores con un aumento y asistencia mínimos debido a mi documentación), donde ser astuto acerca de cómo hacer usted mismo "insustituible" no lo es.

Demian Brecht
fuente
-1: Odio decírtelo, pero todos son reemplazables. - Sí, pero algunas personas son más difíciles de reemplazar que otras.
Jim G.
10

Al ser reemplazable, ¿no va eso en contra del interés de un desarrollador?

Depende de cuáles sean los intereses de ese desarrollador. Si usted es alguien que quiere mantenerlo en un solo trabajo durante toda su carrera, sea completamente indispensable para una empresa que recompense la incompetencia y gane un buen dinero, entonces sí, absolutamente.

Pero, ¿qué sucede cuando la empresa falla, probablemente porque contrataron a demasiadas personas así? ¿A dónde vas a ir después? ¿Qué pasa cuando te preguntan por qué te quedaste en el mismo trabajo durante 15 años? Y así.

Ahora mírelo de una manera diferente: ¿Cuántos desarrolladores han perdido sus trabajos al ser alguien que escribe código que cualquiera puede leer?

La única probabilidad de que eso suceda es si la empresa tiene problemas y hace que las personas sean redundantes. Si eso sucede, es mejor que salgas y estarás muy bien preparado para las próximas entrevistas. Además, su conciencia será completamente libre: no dejará código inexplicable que escribió para su propio beneficio.

No sé qué tipo de persona eres, pero eso sirve mejor a mis intereses.

Personalmente, creo que una de mis mayores fortalezas es la automatización de mi propio trabajo. ¿Qué cree que tiende a pensar una empresa cuando me he convertido en un excedente para mis propios requisitos? ¿Piensan "está bien, nos libraremos de él ahora" o piensan "por qué no lo movemos a otro papel y lo dejamos volver a hacerlo"?

pdr
fuente
9

Al ser reemplazable, ¿no va eso en contra del interés de un desarrollador?

Tienes razón, pero creo que entendiste mal el significado de reemplazable. Pude encontrar 1000 desarrolladores que escriben código agitado, indocumentado que puede convertirse rápidamente en un desastre imposible de mantener.

A los desarrolladores que producen no solo programas estables, sino también código limpio, documentación informativa y aseguran la continuidad del proyecto, eso no solo es insustituible, no tiene precio .

rahmu
fuente
7

Abordaré esta pregunta desde una perspectiva diferente, ya que hay varias respuestas excelentes.

Considera lo que sucede cuando juegas juegos mezquinos tratando de hacerte "irremplazable" pero evitando que otras personas aprendan cómo funciona tu código. Permaneces en el mismo trabajo manteniendo tus propios problemas mientras la empresa te tolere. Y ese es el mejor de los casos, el peor de los casos es que otros ingenieros y gerentes más talentosos y más éticos en su empresa vean el obstáculo que sus malas prácticas imponen a la empresa y deciden hacer algo al respecto: despedirlo y reescribirlo Todo desde cero. Se ha hecho. De hecho, es algo bastante común que suceda.

Ahora considere lo que sucede cuando escribe un buen código y una buena documentación. Usted crea un componente o un sistema que funciona bien, que después de un tiempo en funcionamiento, la resolución de los errores funciona sin problemas y apenas necesita ser examinado. Se necesita poco esfuerzo para mantenerlo. Luego puede pasar a proyectos más grandes y mejores, con una sólida victoria en su haber. La gente lo reconocerá por haber hecho un buen trabajo y comenzará a respetar su opinión. Tendrá la capacidad de ascender en la cadena alimentaria y tomar decisiones más significativas, o hacer un trabajo más importante e impactante, o gestionar proyectos a un nivel superior. Su carrera mejorará, será promovido, ganará más dinero, obtendrá el reconocimiento y la aprobación de sus pares, agregará más y más éxitos de proyectos cada vez más importantes a su historial.

¿Qué ruta preferirías?

Cuña
fuente
4

Si usted es el único punto de falla, su cliente (o empleador) probablemente tratará de reemplazarlo; siempre hay un punto en el que es menos costoso reemplazar el software que mantenerlo, sin importar cuán esencial parezca. Hay una razón por la cual TI es una de las profesiones más subcontratables.

Por otro lado, ser reemplazable le brinda varios beneficios invaluables:

  • poder tomar vacaciones
  • no estar de guardia
  • libertad para salir y trabajar en un proyecto nuevo y emocionante
Domchi
fuente
-1: Si usted es el único punto de falla, su cliente (o empleador) probablemente tratará de reemplazarlo; - No en mi experiencia. Por favor, vea la respuesta @evadeflow.
Jim G.
3

Si no pasa 5 minutos escribiendo una documentación rápida, entonces pasará una hora releyendo y explicándola a las personas cuando necesiten usar su código.

Peor aún podría pasar días buscando un nuevo trabajo porque su jefe descubrió que no estaba escribiendo código que se pudiera mantener.

Pubby
fuente
3

Con el tiempo, la excelente documentación quedará obsoleta con la refactorización / evolución, y mantenerla actualizada lleva mucho tiempo.

Código limpio + prueba de unidad> excelente documentación

xsace
fuente
1
Convenido. No puedo decir cuántos proyectos he trabajado en los que todos en el equipo (incluyéndome a mí) decidieron que íbamos a "hacerlo bien esta vez" y usar doxygen o CppDoc para documentar todo y mantenerlo actualizado. fecha. No ha sucedido todavía. Como los cronogramas del proyecto son lo que son, las cadenas de documentos inevitablemente se desincronizarían con respecto al código, y nuestra cobertura de prueba sería mínima o inexistente. Ahora tiendo a mirar a los dardos a cualquiera que sugiera usar doxygen, y les pido que me muestren sus pruebas primero. La documentación para el código sin ninguna prueba es solo un paquete de mentiras.
evadeflow
Esto no viene al caso: las buenas pruebas unitarias son documentación. Solo está abogando por una variedad particular de código limpio y documentado, sin decir que no debe hacerse.
Cascabel
2

La respuesta a tu pregunta es sí". Sí, debe escribir buena documentación y código limpio. Hacer lo contrario deliberadamente muestra una falta de integridad, que, si bien cada vez es más frecuente en el mundo de los negocios, no es de repente algo "bueno".

Nadie es insustituible. Las personas que fabrican una situación en la que piensan que son tienden a descubrir de la manera difícil que no lo son. Fabricar una codependencia para usted es contraproducente, ya que también lo limita a usted, no solo a su empleador.

temptar
fuente
2

Uno de los principales objetivos de las empresas de desarrollo de software es aumentar su factor Bus

Falsa premisa. Los objetivos principales de una empresa de desarrollo de software (en todos los que he trabajado) son producir el mejor software posible y ganar dinero, no necesariamente en ese orden. Reducir el "factor del autobús" es solo una forma de evitar perder dinero.

Ley 11 Aprenda a mantener a las personas dependientes de usted.

¿Qué significa eso para usted?

¿Desea que las personas dependan de usted porque las ha socavado de tal manera que solo pueden avanzar con su ayuda? ¿O quieres que la gente dependa de ti porque eres inteligente y perspicaz, confiable, confiable y capaz de ayudar a otros a hacer mejor su trabajo también? ¿Quieres hacer que tus colegas se vean mal sin tu ayuda, o quieres que te aprecien por hacer que se vean bien?

Es tu llamada.

Caleb
fuente
1

(asumiendo el código de producción)

Tiendo a ir un poco más lejos. He escrito sobre hacer que los programas sean "a prueba de idiotas", pero no siempre califico eso: escribo mucho código que otras personas no verán ni trabajarán (al menos, eso es lo que se espera cuando se escribe). yoSoy el idiota del que estoy tratando de defenderme en ese caso. Es bueno cuando su programa detecta problemas para usted, y el problema se ha simplificado tanto que es bastante obvio que hay un error y su origen. La verdad es que los detalles de implementación son obvios cuando escribe un programa (a menos que lo esté implementando prematuramente), pero deben ser abstraídos y resistentes a errores para los clientes (incluso cuando existe la localidad del módulo). La razón es que los programas se vuelven muy complejos. A veces puedes separar los problemas, pero no todo el tiempo. Si mantiene sus componentes muy estrictos, simples, bien encapsulados y a prueba de idiotas, tienden a escalar bien y la mayoría de los defectos se detectan antes de ser enviados. Es más fácil de reutilizar, y tiene más confianza y es más fácil reutilizar los programas. Además, esos programas complejos que usted escribe solo se vuelven más complejos (incluso para usted) después de un tiempo alejado del programa. Cuando lo lees en 6 meses, puede llevar una cantidad absurda de tiempo entenderlo y depurarlo en comparación con la versión a prueba de idiotas. Si un componente introduce un cambio importante, de lo contrario puede pasar desapercibido durante mucho tiempo. Los programas son complejos; no puedes escapar de esa realidad, pero puedes hacerlo a prueba de idiotas, lo que hará tu vida mucho más fácil cuando algo salga mal o cuando deba ser reutilizado o alterado. Por lo tanto, el enfoque de prueba idiota significa que su software puede ser entendido, reutilizado o mantenido por sus juniors o personas más nuevas en el equipo también (no solo alguien tan bueno / experimentado como usted). El reemplazo es una preocupación separada: si a la gente le encanta trabajar con sus programas, está haciendo un buen trabajo, no lo haga. No te preocupes por el reemplazo. Claro, podría idear escenarios en los que los programas ininteligibles podrían salvar su trabajo, pero escribir un buen programa que otros puedan usar y mantener es claramente el mal menor (mire las respuestas de los demás). Si me encuentro escribiendo algo que no es una prueba idiota, trato de arreglarlo.

Además del escenario, donde necesita documentación para usted mismo para continuar un proyecto después de 6 meses de pausa, parece haber un claro conflicto de intereses aquí entre el desarrollador y la compañía de software.

Realmente no tienes idea de lo que estabas pensando algunas veces cuando vuelves a visitar implementaciones inactivas. Cuando tienes mucha experiencia, entonces el problema es más simple porque puedes confiar más en las metodologías o enfoques establecidos que utilizas. Eso, sin embargo, también supone que estas metodologías son invariables. Aunque la documentación puede ser laxa, aún tiene que estar a la defensiva en sus implementaciones (por ejemplo, sabe que no debe pasar NULL en este escenario: pruebe esa condición).

Entonces, como programador, ¿debería realmente escribir una excelente documentación y un código fácil de leer para todos? ¿O debería escribir el código y la documentación de manera que haga el trabajo y usted mismo pueda entenderlo, pero otra persona puede tener problemas para entenderlo?

Recomiendo el enfoque a prueba de idiotas, que es aún más claro y resistente a los errores que el enfoque de factor de bus. Escriba sus programas y documentación de manera que alguien externo al proyecto pueda entenderlo fácilmente; también es bueno para usted. Si lo hace, aumentará su valor para su empresa y equipo, no querrán reemplazarlo.

justin
fuente
1

Has entendido mal el juego fundamentalmente. El juego no es seguir haciendo las mismas cosas que antes, siendo responsable de todo el código que has escrito porque nadie más lo entiende. El juego consiste en completar un proyecto y pasar al siguiente, dejando atrás un código que otra persona puede entender y trabajar fácilmente en su ausencia para que pueda hacer cosas nuevas y asumir más y diferentes responsabilidades. Su premisa solo funciona si está contento de estar atrapado haciendo lo mismo una y otra vez sin posibilidad de aprender o mejorar.

tvanfosson
fuente
1

También voy a señalar que si no tiene la oportunidad de mirar ese código con mucha frecuencia, también tendrá problemas para resolverlo en seis meses si lo ofusca deliberadamente.

HLGEM
fuente
0

Yo documento lo poco código que escribo, no para que otros puedan leerlo, pero por lo que me puede leerlo en 3 meses el tiempo! Se trata de facilitar el mantenimiento. Si usted es responsable del código que escribió, y no puede corregir los errores que aparecen más adelante en la línea, entonces querrá que esté bien documentado ... Es bastante irrelevante lo reemplazable que es si no puede para hacer tu trabajo!

Seamus
fuente
-1: ¿Por qué no te esfuerzas por el código de autodocumentación? A diferencia de, en el mejor de los casos, documentación redundante y, en el peor, ¿documentación que quedará obsoleta muy rápidamente? Por favor, vea la respuesta @xsAce.
Jim G.
0

Todos los profesionales informáticos "insustituibles" con los que tuve la desgracia de interactuar fueron reemplazados, en gran parte porque intentaban retener los recursos de sus empleadores como rehenes. Cuando las personas que me informan me dicen que su tiempo es valioso para "desperdiciar" la documentación, las reemplazo lo antes posible.

Parece que si un posible empleado considera que las 48 leyes del poder son éticamente o moralmente aceptables, entonces estaría mejor sin ellas.

John Percival Hackworth
fuente
-1: Cuando las personas que me informan me dicen que su tiempo es demasiado valioso para "desperdiciar" la documentación, las reemplazo lo antes posible.
Jim G.
@ Jim G: Bien. Voy a suponer que tu tiempo es valioso para desperdiciar documentando ...
John Percival Hackworth
0

Si REALMENTE desea ser irremplazable (lo que tal vez desee reconsiderar después de leer todas las respuestas ...), ¿por qué dejar de no documentar el código?

Hay una guía realmente brillante sobre cómo escribir código inmanejable que definitivamente deberías leer: http://thc.org/root/phun/unmaintain.html

¡Disfrutar! (Ciertamente lo hice ...)

yonix
fuente
También hay "Refuctoring" :)
CraigTP