Uno de los idiotas sobrecargados son los gerentes que manejan programadores. No todos, pero aquellos que no eran programadores. Aquellos que piensan que es posible "aumentar" la eficiencia (o aumentar la "eficiencia") por métodos de los libros. Sin siquiera molestarse en leer estos libros, Vidosik es, después de todo, un gitano.
Los que nunca escribieron código. Aquellos para quienes se hacen películas de Hollywood sobre programadores, bueno, aquellos donde miran correos electrónicos en la línea de comando. Aquellos que no están interesados en nada, excepto los indicadores, los términos y su propio salario.
Los que son más.
Pero son idiotas por otra razón. Quieren eficiencia, o al menos productividad (vamos, gerente, google, cuál es la diferencia), sin entender ni lo uno ni lo otro. Generalmente no comprende la esencia, el proceso de obtención del resultado, las pérdidas que ocurren en este proceso, los costos de desarrollo. En resumen, trabajar con un programador como con una caja negra.
Se encontraron con la administración de programadores por exactamente una razón: aquí hay exageración, dinero, el mercado y un montón de los mismos idiotas. Hay donde perderse.
Si hubiera una exageración en la industria del ensamblaje mecánico, correríamos allí. Las camionetas son malas. No me sorprenderá que el tipo que vende árboles de Navidad en nuestro trimestre en diciembre sea un gerente de TI de vacaciones.
En resumen, si es posible, persiga a estos tipos en el cuello. No te preocupes, encontrarán un trabajo. Ninguno de ellos hará nada decente hasta que se convierta en programador. Porque no comprende la esencia, el mecanismo, la lógica del proceso que controla.
Bueno, eso es suficiente sobre los gerentes. Ahora, para programadores. Cómo aumentar la eficiencia del desarrollo aprendiendo a escribir código de alta calidad.
Para aumentar la eficiencia, es necesario resolver rápidamente los problemas sin perder calidad. Para resolver problemas más rápido, debe poder escribir de inmediato código de alta calidad. Y "calidad", y "escribir", y "de inmediato". Lo explicaré con una metáfora.
Escribir un código de calidad es como hablar de manera competente en un idioma extranjero. Cuando no conoces el idioma, pasas mucho tiempo para formular tus pensamientos al respecto.
Si necesita decirlo con urgencia, solo debe pegar algunas palabras, a menudo no las que necesita, olvidarse de los artículos, el orden correcto de las palabras, sin mencionar los tiempos de los verbos y la mala pronunciación.
Si hay tiempo para la redacción de la respuesta, tendrá que abrir un diccionario o un traductor de Internet y dedicar mucho tiempo a la redacción de sus pensamientos. Sin embargo, el sentimiento seguirá siendo desagradable: dices la respuesta y no sabes si es correcta o no. De manera similar con el código, parece haber escrito, parece funcionar, pero es de calidad o no, HZ.
Resulta una doble pérdida de tiempo. Se necesita tiempo para encontrar una respuesta. También lleva tiempo formular esta respuesta; además, no es tan poco.
Si la habilidad de escribir código de alta calidad está presente, entonces la respuesta puede formularse inmediatamente, tan pronto como haya madurado en la cabeza, sin perder tiempo adicional en la traducción.
La habilidad de escribir código de calidad ayuda con el diseño arquitectónico. Simplemente no considerará las opciones incorrectas, irrealizables o mano a mano en su cabeza.
Resumiendo: la habilidad de escribir código de alta calidad acelera significativamente la solución de problemas.
Pero eso no es todo. Gracias a valenki-managers, hay un inconveniente, por lo que no tenemos ninguna razón para escribir código de alta calidad. El administrador de código no se ve, el código del cliente no se ve. Raramente nos mostramos código, solo ocasionalmente, en algunos proyectos donde hay un "inspector de código" designado o refactorización periódica.
Resulta que, en la mayoría de los casos, el govnokod va a la producción o al cliente. La persona que escribió el govnokod forma una conexión neural estable: el govnokod no solo es posible de escribir, sino que también es necesario: se acepta e incluso se paga por él.
Como resultado, la habilidad de escribir código de alta calidad no tiene ninguna posibilidad de desarrollarse. El código escrito por un empleado condicional nunca es verificado por nadie. La única razón por la que aprende a programar normalmente es por la motivación intrínseca.
Pero esta motivación intrínseca entra en conflicto con los planes y requisitos de eficiencia y productividad. Esta contradicción se resuelve claramente no a favor de un código de alta calidad, porque ni siquiera culpan al govnokod. Y por no cumplir el plan, ¿de qué otra manera?
Como ser Veo y ofrezco dos formas que se pueden combinar.
El primero es mostrar su código a alguien dentro de la empresa. No reactivamente (cuando se le pide / forzado), sino de manera proactiva (er, amigo, mira mi código, por favor). Lo principal aquí es no colgar mocos de azúcar, no intente poner un código cortés en las críticas al código. Si el código es una mierda, lo decimos: el código es una mierda. Con explicaciones, por supuesto, y recomendaciones sobre cómo mejorarlo.
Pero de esta manera también es regular. Su aplicabilidad depende del punto en el que ocurrió el contacto. Si el trabajo ya ha entrado en producción y resultó que el código es una mierda, no tiene sentido rehacerlo. Más precisamente, ocasiones: las métricas también se hundirán. Los gerentes atacarán y aplastarán los requisitos de eficiencia. Y ni siquiera trates de explicarles que el govnokod definitivamente regresará en forma de errores: te saldrá de lado. Uno solo puede comprometerse a no hacerlo más.
Si el trabajo aún no se ha entregado, o acaba de comenzar, verter mierda en el código (o su proyecto, idea) con mierda puede tener un significado bastante práctico: una persona lo hará normalmente.
La segunda forma, la más genial, es hacer un desarrollo de código abierto después de horas. Después de todo, cuál es el objetivo: que un grupo de programadores, es decir, programadores, vean su código y hablen sobre él. No hay tiempo para todos dentro de la empresa. Pero los programadores de todo el mundo todavía no tienen nada que hacer, y si escribes algo útil desde el punto de vista de la aplicación, definitivamente mirarán dentro.
La característica principal, en mi opinión, es escribir código después de horas, porque la contradicción entre la calidad del código y la velocidad del resultado no funcionará. Al menos un año escribe tu desarrollo. Ni los plazos, ni los conocimientos tradicionales, ni el dinero, ni el jefe te presionarán. Completa libertad y creatividad.
Solo en la creatividad libre entenderás y sentirás lo que es un código genial, verás la belleza de YaP y la tecnología, y sentirás el encanto de las tareas comerciales. Bueno, aprenderá a escribir código de alta calidad.
Es cierto que esto requerirá que pase tiempo personal. Como, de hecho, cualquier otro desarrollo. Considere esto no como un costo, sino como una inversión en usted mismo.