¿Debe escribir buena documentación y código limpio para aumentar el "factor de bus"?

Debes esforzarte por volverte insustituible no escribiendo el código que nadie más entiende, sino acumulando más experiencia y conocimiento que otros. La forma anterior te convierte en un desarrollador con el que todos intentan evitar trabajar, ya que temen y detestan el mantenimiento del código que escribiste. De esta última manera, usted se convierte en un miembro del equipo buscado, que los gerentes quieren tener en su equipo.

En mi experiencia, escribir código limpio, bien documentado (y preferiblemente autodocumentado) siempre ha dado sus frutos. 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ía en peligro de ser reemplazado por alguien menos capaz que yo. De hecho, esto generalmente ayudó a que todo el equipo trabajara mejor y resolviera los problemas más rápidamente, lo que es el sueño de todos los gerentes, y un gerente sensato no quiere reemplazar a los miembros de un buen equipo.

Si va a manipular organizaciones o personas de forma tan transparente, es mejor que sean estúpidos o en un atasco que no les deje otra opción. Una tienda de desarrollo de software bien dirigida vería tu código oscuro y la documentación faltante y simplemente te despediría antes de que pudieras hacer mucho daño. Si están mal administrados o no pueden hacer que otros desarrolladores trabajen para ellos, ¿por qué querrías tener una sinecura con ellos?

PS Ni el Sr. Greene ni Maquiavelo lograron mucho, aparte de escribir libros que intentaron adular a los "hombres duros" de la época. Sigue sus consejos con un grano de sal.

Si eres insustituible, no puedes ser promovido.

No quieres ser insustituible. No quieres que las personas se sientan dependientes 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 win-win .
Tan pronto como la gente comience a sentir, tratará de presionarlos para que salgan perdiendo de una situación de ganar-perder, y se recuperarán. Los intentos de establecer situaciones de ganar-perder a menudo terminan en un resultado de pérdida-pérdida, ya que en realidad está desperdiciando recursos para que su socio se ponga en una posición perdedora, en lugar de invertirlo en el éxito general de su asociación.

Si haces esto con tus empleadores, intentarán imponerte medidas para reducir tu monopolio de conocimiento. En su mayoría, estas serán pautas ridículas sobre cómo debe hacer su trabajo y, de ese modo, convertirán su vida laboral en un infierno. Además, te llamarán a las 3 en punto de la noche cuando algo se rompa, porque eres la única persona que puede arreglarlo. Tratar de explotar situaciones como el apalancamiento es probable que sea contraproducente y le cause 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 usted, porque es probable que sea el alma pobre, que debe hacer algunos cambios en el código dentro de dos años.

  

Ser reemplazable, ¿eso no va 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 reemplazarte (si tienes experiencia y eres lo suficientemente inteligente), pero es imposible en años luz.

La forma de ser verdaderamente un producto valioso para su empleador (no solo el empleador actual, sino cualquier empleador) es demostrar la capacidad de escribir un código tan fácil de asimilar por cualquiera que lea el código (poco aumentar el tiempo para trabajar con él) y documentar el código (cualquier persona puede obtener una descripción general de alto nivel de sus sistemas sin tener que codificar el código).

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

El código limpio y bien documentado también es digno de incluirlo en un currículum (al menos, resultados tangibles de él, es decir, "pudimos atraer a n de nuevos desarrolladores con un incremento y asistencia mínimos debido a mi documentación) , donde ser astuto acerca de hacerse "insustituible" no lo es.

Las respuestas negativas no son demasiado sorprendentes, dada la cantidad de programadores mejores que el promedio que este sitio atrae. 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 sí mismos, a los que cuidaron celosamente al crear grandes cantidades de documentación para las horrendas interfaces que tenían diseñado.

Todo el trabajo de un individuo era mantener el código de un módulo que unía dos subsistemas completamente separados, lo que permitía que los módulos de cada sistema se comunicaran a través de un UART. Básicamente, era 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 individual que cualquiera de los dos módulos de comunicación querría enviar entre sí. Lo que significaba que su módulo necesitaba conocer todos los mensajes y que debía actualizarse cada vez que se añadía o cambiaba un mensaje. ¡Habla de intimidad inapropiada!

El problema es que este tipo mantuvo un documento de Word con una lista ordenada de todos los códigos / mensajes, y lo actualizó con diligencia según fuera necesario. Se convirtió en su trabajo completo . Unas 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 encantó ver la documentación. Un poco me hace llorar por la industria automotriz.

Supongo que mi punto es: a veces escribir documentación puede, de hecho, proteger programadores mediocres. Los gerentes a menudo no pueden distinguir entre un diseño bueno 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 bien formateadas puede ser muy reconfortante, incluso si lo que describe es una idea fundamental.

  

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

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

¿Pero qué sucede cuando la compañía se estrella, probablemente porque contrataron a muchas 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í sucesivamente.

Ahora véalo de otra forma: ¿cuántos desarrolladores han perdido su trabajo por ser alguien que escribe código que cualquiera puede leer?

La única posibilidad de que eso ocurra es si la empresa está en problemas y hace que la gente sea redundante. Si eso sucede, es mejor que salgas y estarás muy bien preparado para las próximas entrevistas. Además, su conciencia será completamente gratuita, no dejará atrás el código inexplicable que escribió para su propio beneficio personal.

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é crees que una empresa tiende a pensar cuando me he excedido con mis propios requisitos? ¿Piensan "bien, nos desharemos de él ahora" o piensan "por qué no lo movemos a otro rol y lo dejamos hacerlo de nuevo"?

  

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

Tienes razón, pero creo que entendiste mal el significado de reemplazable. Podía encontrar a 1000 desarrolladores que escriben código agitado, sin documentar que puede convertirse rápidamente en un lío que no se puede mantener.

Un desarrollador que produce no solo programas constantes, sino también código limpio, documentación informativa y garantiza la continuidad del proyecto, que no solo es insustituible, sino que también es inestimable .

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

Considera lo que sucede cuando juegas juegos pequeños intentando hacerte "insustituible" a la vez que evitas que otras personas aprendan cómo funciona tu código. Usted permanece en el mismo trabajo manteniendo sus propios líos mientras la compañía lo tolera. Y ese es el mejor de los casos, el peor de los casos es que otros ingenieros y gerentes más talentosos y éticos de su compañía ven el obstáculo que sus malas prácticas imponen a la compañía 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 considera lo que sucede cuando escribes un buen código y una buena documentación. Usted crea un componente o un sistema que funciona bien, que luego de un tiempo en funcionamiento, el funcionamiento de los errores funciona sin problemas y casi no necesita ser revisado. 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 te reconocerá por haber hecho un buen trabajo y comenzará a respetar tu opinión. Tendrá la capacidad de ascender en la cadena de alimentos y tomar decisiones más significativas, o hacer un trabajo más importante e impactante, o administrar proyectos a un nivel superior. Su carrera mejorará, obtendrá un ascenso, ganará más dinero, obtendrá reconocimiento y aprobación por parte de sus compañeros, agregará más y más éxitos de proyectos cada vez más importantes a su historial.

¿Qué ruta preferirías?

Si eres el único punto de falla, tu cliente (o empleador) probablemente intentará reemplazarte; Siempre hay un punto en el que es menos costoso reemplazar el software que mantenerlo, sin importar lo esencial que parezca. Hay una razón por la que IT es una de las profesiones más externalizables.

Por otra parte, 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

La excelente documentación eventualmente se volverá obsoleta con refactorización / evolución, y mantenerla actualizada requiere mucho tiempo.

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

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

Lo que es peor, podría ser pasar días buscando un nuevo trabajo porque su jefe descubrió que no estaba escribiendo el código de mantenimiento.

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

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

  

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

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

  

Ley 11 Aprende a mantener a las personas dependientes de ti.

¿Qué significa eso para ti?

¿Quiere que la gente dependa de usted porque los 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? ¿Quieres que tus colegas se vean mal sin tu ayuda o quieres que te aprecien por hacer que se vean bien?

Es tu llamada.

(asumiendo código de producción)

Tiendo a ir un poco más lejos. He escrito sobre cómo hacer que los programas sean "a prueba de idiotas", pero no siempre lo califico: escribo muchos códigos que otras personas no verán ni trabajarán (al menos, esa es la expectativa cuando se escribe). Yo soy el idiota del que estoy tratando de defenderme en ese caso. Es bueno que su programa detecte 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 la implementación son obvios cuando escribes un programa (a menos que lo estés implementando prematuramente), pero deben ser abstractos y resistentes a los 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 escalarse 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 un tiempo más fácil para reutilizar los programas. Además, esos programas complejos que 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 llevarte una cantidad absurda de tiempo entenderlo y depurarlo en comparación con la versión de prueba de idiotas. Si un componente introduce un cambio de ruptura, puede pasar desapercibido durante mucho tiempo de lo contrario. Los programas son complejos; no puedes escapar de esa realidad, pero puedes hacerla a prueba de idiotas, lo que hará tu vida mucho más fácil cuando algo salga mal o cuando deba reutilizarse o modificarse. Por lo tanto, el enfoque a prueba de idiotas significa que su software puede ser comprendido, 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 aparte: si a la gente le encanta trabajar con sus programas, está haciendo un buen trabajo, no se preocupe por el reemplazo. Claro, podría llegar a escenarios en los que los programas ininteligibles puedan salvar su trabajo, pero escribir un buen programa que otros puedan usar y mantener es claramente el mal menor (vea las respuestas de los demás). Si me sorprendo escribiendo algo que no es una prueba de idiotas, trato de arreglarlo.

  

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

Realmente no tienes idea de lo que pensabas en algunas ocasiones cuando revisabas las implementaciones inactivas. Cuando tiene experiencia con realmente , entonces el problema es más sencillo porque puede confiar más en las metodologías o enfoques establecidos que utiliza. Eso, sin embargo, también asume que estas metodologías son invariantes. A pesar de que la documentación puede ser laxa, aún tiene que estar a la defensiva en sus implementaciones (por ejemplo, sabe que es mejor pasar NULL en este escenario: pruebe esa condición).

  

Entonces, como programador, si realmente escribe una excelente documentación y un código fácil de leer para todos; o ¿debería escribir código y 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 más resistente a los errores que el enfoque de factor de bus. Escriba sus programas y documentación de manera que sea fácil de entender para alguien externo al proyecto, también es bueno para usted. Si lo hace, aumentará su valor para su empresa y su equipo, no querrán reemplazarlo.

Has malinterpretado fundamentalmente el juego. El juego no es seguir haciendo las mismas cosas que has hecho antes, ser 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 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. Tu premisa solo funciona si estás contento de quedarte estancado haciendo lo mismo una y otra vez sin posibilidad de aprender o mejorar.

También voy a señalar que si no tienes la oportunidad de mirar ese código muy a menudo, también tendrás problemas para resolverlo en seis meses si lo ofuscas deliberadamente.

Documenté el pequeño código que escribo, no para que otros puedan leerlo, ¡sino para que I pueda leerlo dentro de 3 meses! Se trata de facilitar el mantenimiento. Si eres responsable del código que escribiste y no puedes corregir los errores que aparecen más adelante, entonces querrás que esté bien documentado ... Es irrelevante cuán reemplazable eres si no eres capaz para hacer tu trabajo!

Todos los profesionales de la computación "irremplazables" con los que he tenido la desgracia de interactuar fueron reemplazados, en gran parte porque estaban tratando de mantener como rehenes los recursos de sus empleadores. Cuando personas que me informan me dicen que su tiempo es tan valioso como para "desperdiciar" la documentación, los reemplazo lo antes posible.

Parecería que si un empleado potencial considera que las 48 leyes de poder sean ética o moralmente aceptables, entonces estaría mejor sin ellos.

Si REALMENTE desea ser insustituible (lo que quizás desee reconsiderar después de leer todas las respuestas ...): ¿por qué dejar de no documentar el código?

Hay una guía verdaderamente brillante sobre cómo escribir código que no se puede mantener y que definitivamente debes leer: enlace

¡Disfruta! (Ciertamente lo hice ...)