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?
fuente
Respuestas:
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.
fuente
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.
fuente
Si eres insustituible, no puedes ser promovido.
fuente
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.
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.
fuente
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:
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.
fuente
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.fuente
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"?
fuente
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 .
fuente
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?
fuente
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:
fuente
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.
fuente
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
fuente
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.
fuente
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.
¿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.
fuente
(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.
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).
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.
fuente
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.
fuente
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.
fuente
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!
fuente
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.
fuente
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 ...)
fuente