Una de las profesiones más saturadas por idiotas es la de gerentes que manejan programadores. No todos, solo aquellos que nunca han sido programadores. Aquellos que piensan que se puede "aumentar" la eficiencia (o "mejorar la eficacia"?) con métodos de libros. Ni siquiera tomándose la molestia de leer esos mismos libros, porque hay un video de moda.
Aquellos que nunca han escrito código. Aquellos para quienes hacen películas de Hollywood sobre programadores, como las que muestran cómo se revisa el correo electrónico desde la línea de comandos. Aquellos a quienes no les interesa nada aparte de indicadores, plazos y su propio salario.
Aquellos que son la mayoría.
Pero son idiotas por otra razón. Quieren eficacia, o al menos efectividad (vamos, gerente, googlea cuál es la diferencia), sin entender ni lo uno ni lo otro. No comprenden la esencia, el proceso de obtener resultados, las pérdidas que ocurren en este proceso, los costos de desarrollo. En resumen, trabajan con el programador como si fuera una caja negra.
Han llegado a gestionar programadores exactamente por una razón: aquí hay un boom, dinero, mercado y un montón de idiotas como ellos. Hay lugares donde pueden ocultarse.
Si hubiera un boom en la producción de ensamblaje mecánico, correrían hacia allá. Universales de poca monta. No me sorprendería que el tipo que vende árboles de Navidad en nuestro barrio en diciembre fuera un gerente de TI de vacaciones.
En resumen, si tienen la oportunidad, deshágase de esos chicos. No se preocupen, encontrarán trabajo. Ninguno de ellos, nunca hará nada decente, hasta que se convierta en programador. Porque no entiende la esencia, el mecanismo, la lógica del proceso que gestiona.
Bien, suficiente sobre los gerentes. Ahora hablemos de lo que realmente importa, para los programadores. Cómo aumentar la eficacia del desarrollo aprendiendo a escribir código de calidad.
Para aumentar la eficacia, hay que resolver tareas más rápido, sin perder calidad. Para resolver tareas más rápido, hay que saber escribir código de calidad de inmediato. Tanto "calidad", como "escribir", y "de inmediato". Lo explicaré con una metáfora.
Escribir código de calidad es como hablar correctamente un idioma extranjero. Cuando no conoces el idioma, pierdes mucho tiempo tratando de formular tus pensamientos en él.
Si es necesario decir algo de forma urgente, simplemente juntarás algunas palabras, muchas veces no las adecuadas, olvidarás los artículos, el orden correcto de las palabras, sin mencionar los tiempos verbales y una pronunciación deficiente.
Si hay tiempo para formular una respuesta, tendré que abrir un diccionario o un traductor en línea y gastar mucho tiempo articulando mis pensamientos. La sensación, sin embargo, seguirá siendo incómoda: respondes y no sabes si es correcto o no. Lo mismo ocurre con el código: parece que lo escribiste, parece que funciona, pero no sabes si es de calidad o no, la verdad.
Así, se produce una doble pérdida de tiempo. Se necesita tiempo para pensar en la respuesta. También se necesita tiempo para formular esa respuesta, y no es tan poco.
Si, por el contrario, se tiene la habilidad de escribir código de calidad, se puede formular la respuesta de inmediato, tan pronto como se forma en la mente, sin perder tiempo adicional en la traducción.
La habilidad de escribir código de calidad ayuda en el diseño de arquitectura. Simplemente no considerarás en tu cabeza opciones incorrectas, irrealizables o torpes.
En resumen: la habilidad de escribir código de calidad acelera significativamente la solución de problemas.
Pero eso no es todo. Gracias a los gerentes que no saben, hay un inconveniente: no tenemos motivo para escribir código de calidad. El gerente no revisa el código, el cliente no revisa el código. Nos mostramos el código raramente, solo a veces, en algunos proyectos donde hay un 'verificador' de código asignado o una refactorización periódica.
De este modo, en la mayoría de los casos, el mal código llega a producción o al cliente. La persona que escribió el mal código formará una conexión neuronal persistente: no solo se puede escribir mal código, sino que también se debe hacer, ya que lo aceptan y además lo pagan.
Al final, la habilidad de escribir código de calidad no tiene ninguna posibilidad de desarrollarse. El código escrito por un empleado convencional nunca es revisado por nadie. La única razón por la que aprenderá a programar adecuadamente es la motivación interna.
Pero esta motivación interna entra en conflicto con los planes y requisitos de eficiencia y productividad. Esta contradicción evidentemente no se resuelve a favor del código de calidad, ya que no se critica el mal código. Y por no cumplir con el plan, se recibe reproches todo el tiempo.
¿Qué hacer? Veo y propongo dos caminos que se pueden combinar.
El primero es mostrar tu código a alguien dentro de la empresa. No de forma reactiva (cuando te lo piden / obligan), sino proactivamente (eh, amigo, echa un vistazo a mi código, por favor). Lo importante aquí es no endulzar los comentarios, no tratar de suavizar la crítica al código. Si el código es malo, lo decimos así: el código es malo. Con explicaciones, por supuesto, y recomendaciones sobre cómo mejorarlo.
Pero este camino tampoco es ideal. Su aplicabilidad depende del momento en que se realizó el contacto. Si el trabajo ya ha sido lanzado a producción y resulta que el código es malo, no tiene sentido volver a hacerlo. Más bien, el problema es que las métricas también se verán afectadas. Los gerentes llegarán y aplastarán con requisitos de eficiencia. Y ni lo intentes explicarles que el código deficiente inevitablemente regresará en forma de errores: eso te saldrá caro. Solo puedes comprometerte a no hacerlo de nuevo.
Sin embargo, si el trabajo aún no se ha entregado, o recién comienza, criticar el código (o su proyecto, idea) puede tener un sentido práctico bastante válido: la persona lo hará bien.
El segundo camino, el más genial, es dedicarse al desarrollo de código abierto en el tiempo libre. La meta es que un montón de programadores, exactamente programadores, vean tu código y den su opinión al respecto. Dentro de la empresa, todos están demasiado ocupados. Pero a programadores de todo el mundo no les falta nada que hacer, y si escribes algo útil desde un punto de vista práctico, ellos lo revisarán.
Lo más importante, en mi opinión, es escribir código en tu tiempo libre, porque no habrá un conflicto entre la calidad del código y la velocidad de entrega del resultado. Puedes dedicar un año a tu desarrollo. No habrá presión de plazos, requisitos, dinero o jefes. Total libertad y creatividad.
Solo en la libre creatividad entenderás y sentirás lo que es un buen código, verás la belleza de los lenguajes de programación y tecnologías, apreciarás las tareas empresariales. Y aprenderás a escribir código de calidad.
Sin embargo, esto requerirá que inviertas tu tiempo personal. Al igual que cualquier otro tipo de desarrollo. Míralo no como un gasto, sino como una inversión: en ti mismo.
Fuente: habr.com
