Cuando se publicó la primera edición rusa del conocido libro "Cómo pastar gatos", dedicado al tema difícil de manejar de manera desordenada por los desarrolladores de software profesionales y no muy expertos, mi colega más experimentado, el gerente del proyecto, señaló: "Sería más correcto llamarlo" Cómo pastar ganado "" . La frase fue recordada y, como lo demuestra la experiencia acumulada desde entonces al interactuar con los programadores, un colega tenía razón.
Cómo los programadores de Nena ven a sus colegas
En Habré hay una buena cantidad de artículos dedicados a metodologías de desarrollo de software, comunicación e interacción en el equipo del proyecto, selección y contratación de programadores. Sin exagerar, cada artículo recoge muchos comentarios enojados de los programadores, en los que culpan a los "piemas", evaluadores, personal del departamento de personal, analistas, clientes, por cualquiera que no se ama a sí mismo por las deficiencias en una metodología particular o por fallas en los proyectos. En los artículos y en los comentarios a ellos, la opinión predominante es que el desarrollador siempre tiene la razón. La prevalencia de esta opinión se debe, entre otras cosas, al hecho de que los programadores constituyen la mayor parte de la audiencia en Habr. Al mismo tiempo, especialistas que no son programadores están trabajando en organizaciones y equipos de proyectos. Este artículo expresa en privado, precisamente, el punto de vista de un lado u otro formado en el otro lado de las "barricadas".
Hoy, Mi Joven Amigo, te describiré el mundo a través de los ojos de tus colegas y te contaré cómo tú, el Desarrollador de Software, el Gran y Siempre Correcto Programador, les pareces en este mundo. ¿Estás seguro de que eres el Centro del Universo, como tu gato, y de que todos te deben un
ataúd antes del final del proyecto? Esta es su opinión respaldada, entre otras cosas, por la superioridad cuantitativa de su cohorte en el equipo del proyecto, pero en realidad en una buena mitad de los proyectos en los que usted, un joven o que ya está envejeciendo, pero que todavía no tiene suficiente amigo mente-mente, el resto del equipo está tranquilo. Odia tu omnisciencia y tu excesiva presunción. Su esnobismo está bloqueado solo por el esnobismo exorbitante y excesivamente inflado del arquitecto, pero hablar sobre esa
casta se irá en otro momento.
Un analista de negocios lo odia por las partes de especificaciones que llevan más tiempo y que supuestamente no se realizaron debido a la supervisión.
Los evaluadores lo odian por implementar la versión final con correcciones 5 minutos antes del final de la jornada laboral y regresar tranquilamente a casa, y todavía tienen que pasar varias horas extras en la noche revisando cincuenta correcciones y pruebas de regresión antes del lanzamiento de mañana.
El gerente del proyecto lo odia por escupirlo desde el campanario más alto, porque su futuro, así como el salario en la empresa, no depende de su opinión y comentarios, sino solo de su jefe inmediato, que casi siempre encontrará una manera para protegerte de cualquier falla tuya. Bueno, por supuesto, te odia incluso más que a los evaluadores, porque después de que terminen sus pruebas y den el visto bueno para el lanzamiento de la compilación final, él, a las 11 en punto de la noche, todavía tendrá que completar la creación de informes de lanzamiento finales para equipos de implementación y mantenimiento para el cliente.
El servicio de soporte lo odia por el código "auto documentado" y por la evasión constante de las respuestas a sus preguntas, incluso si las horas para respaldar el código enajenado se asignan especialmente en su horario en el nuevo proyecto al que está asignado.
Sin embargo, lo primero es lo primero.
Camino de la vida de un programador ordinario
De alguna manera, después de un proyecto
exitoso , yo, con el consentimiento del jefe del departamento de desarrollo, preparé una presentación para el grupo de programación, que, entre otras cosas, incluía un "gráfico" que representaba el camino de la vida del programador, desde el principio, codificando en un bloc de notas a la edad escolar. a través del desarrollo de entornos de desarrollo integrados (20 años), gestión de defectos (25 años) e interacción con otros grupos de especialistas y contratistas externos (30 años), antes de aplicar la práctica de integración continua y desarrollo automático comunicados yvaniya alcanzaron la
aparición de las canas 35 años (edad hitos, por supuesto, condicional, y sólo sirven para ilustrar la forma de vida promedio). Un programador, como nadie más en el mundo moderno, se ve obligado a aprender y mejorar constantemente técnica y profesionalmente, y muchos tienen mucho éxito en esto. Al mismo tiempo, la mayoría de los que escriben su primer programa de
fraude de silbatos "Hello, World" y publican un currículum en hh.ru / monster.com inmediatamente comienzan a extender sus dedos en las entrevistas y orgullosamente se llaman a sí mismos "un verdadero profesional". - Estos no son de hecho.
En ese proyecto, un desarrollador logró olvidar poner el código actualizado en un repositorio común y dos de sus colegas medio día en modo extremo intentaron determinar por qué la función no funciona como se indica. Otro desarrollador cometió un error en el script de implementación, y si el gerente del proyecto no lo hubiera notado (!), La implementación de los resultados de la colaboración del equipo para toda la iteración se retrasaría hasta el próximo ciclo de lanzamiento del código en el entorno del producto, es decir. por 2 semanas
Ambos especialistas tenían más de un año de trabajo detrás de ellos, eran profesionales en desarrollo de software, es decir. Recibió una compensación monetaria por su trabajo, pero no codificó "por sí mismos" o en un proyecto de código abierto gratuito. Sin embargo, cometieron errores que son "infantiles" sin importar lo que vean. Es algo bien conocido, todos experimentamos fallas; solo el que no hace nada no corta. Pero es por eso que quería hacer esa presentación para que los desarrolladores la muestren, sobre la base de mi experiencia de asesorar a varios equipos de proyecto, qué áreas problemáticas tiene casi cualquier programador y en qué consisten no en el campo del conocimiento de una tecnología de programación en particular, sino en áreas relacionadas, donde tan querido por usted, MUD, diseñadores y destructores terminan, y las habilidades comienzan a trabajar con requisitos, herramientas, defectos, planificación, etc. Por lo tanto, si en algún lugar, mientras lee un artículo en cualquiera de los ejemplos anteriores, se reconoce accidentalmente a sí mismo y, después de leerlo, saca conclusiones apropiadas y logra "crecer por encima de usted mismo", otros lo verán legítimamente como un profesional en su campo y se alegrarán por eso que trabajan contigo en el mismo proyecto y equipo.
Interacción con no programadores.
Hágale saber, mi amigo hábil, que otros especialistas con los que trabaja codo a codo en el equipo del proyecto, como probadores, analistas, escritores técnicos, diseñadores y otros, no son menos responsables del éxito del proyecto que usted
, oh milagro del universo . Y todos estos no humanos desempeñan un papel no menos importante, y en algunos proyectos incluso más importante que su rol como codificador, y por lo tanto, la interacción competente y benevolente con ellos es una parte integral y clave de su trabajo, por lo que recibe mucho dinero de un cajero automático dos veces al mes (para en una palabra: el dinero es
mucho más grande de lo que todas estas personas sacan del mismo cajero automático). A menudo los mira y sus necesidades de diseño desde arriba o con los dedos, sin la atención que exigen. Y tienen necesidades y expectativas profesionales, y diversas, dependiendo de sus roles.
El analista, por ejemplo, espera que no solo se queje de y sin cada letra en las especificaciones, sino que también las traduzca concienzudamente en el código del programa. Y que no hará gafas cuando, durante las pruebas, le pregunten por qué no implementó la función clave que se incluyó en el lanzamiento de mañana y se estableció en los requisitos antes de ser nombrado miembro del equipo del proyecto hace un año, siempre allí y desde entonces nunca ha cambiado una sola letra.
El probador tiene derecho a esperar de usted un resultado de calidad sin errores de su trabajo. Cuando fue contratada, se le prometió y, por lo tanto, espera que no forme parte de la metodología de desarrollo de TDD, según la cual usted, MUD, "desecha" el producto inacabado para las pruebas y, en función de sus resultados, completa las funciones faltantes y corrige los defectos obvios. Y el evaluador ciertamente espera que no propague la podredumbre por el hecho de que no sabe cómo probar el producto de otra manera que no sea manualmente, o que sus habilidades para trabajar con el lenguaje de consulta de la base de datos son mucho menores que las suyas. Al final, no olvide que le pagan por las pruebas manuales varias veces menos que usted por la programación, y que si ella conociera SQL tan bien como usted, entonces se sentaría en su silla frente a su monitor, y no usted, porque con las mismas calificaciones entre usted, sería ella quien preferiría dejarla en el equipo y la organización, porque, a diferencia de usted, al haber superado el difícil camino de un probador, ella nunca se contagiará a sus colegas como usted.
Conocimiento de ingeniería de tecnología.
¿Ya has terminado el instituto de
jardín de infantes y en las entrevistas explicas con éxito cómo el diseñador difiere del destructor? Le diré un secreto que el mundo profesional de la creación de software no se limita a este conocimiento, y si continúa pensando que el código escrito y de alguna manera ejecutable es resultado suficiente de su trabajo para
no obtener Lyuley
del gerente / cliente del proyecto para recibir sn dos veces al mes, está en En su futura carrera, tendrá muchos más problemas sobre su propia cabeza, y lo más importante, será una fuente de dolor de cabeza persistente para todos los que no tienen la suerte de trabajar a su lado.
"Versiones? Comentando el código? ¿Cumpliendo con los estándares de codificación y nomenclatura? ¡No, no lo he escuchado! " Así que diga a sus colegas aquí y aquí en una variedad de equipos y organizaciones de proyectos. Joven amigo, te estás quejando de todo lo que no está directamente relacionado con el "jabbing de código": sobre la necesidad de agregar comentarios, cubrir el código con pruebas de bloque de acuerdo con los estándares establecidos en la empresa o departamento, fusionar sucursales de repositorio ... ¿Qué podemos decir sobre cosas más complejas que requieren un nivel avanzado o realmente altamente calificado: automatización de pruebas, implementación y soporte para integración continua, configuración de paquetes Bamboo-Cucumber-Maven-Puppet, muchas horas de búsqueda en registros del sistema en búsqueda x evidencia de errores de software: todo esto es para usted aburrimiento y excrementos que no le permiten mejorar sus habilidades de codificación directamente y que encuentra menospreciando sus preguntas frecuentes. Además, al negarse a usar cierto hardware, usted, un desarrollador de software profesional, a menudo simplemente oculta su incapacidad para usarlos. Recuerdo la reacción y la cara de un programador que, como un intento de detectar un defecto "flotante" difícil de encontrar, sugirió usar un perfilador integrado en el IDE: me dijeron que no era el trabajo del perro del gerente del proyecto aconsejar qué herramientas debería usar el programador en su trabajo.
Habilidades de herramientas
¿Cuán automatizado es su trabajo dentro de su estación de trabajo? ¿Has mejorado tus habilidades para trabajar con expresiones regulares, crear y ejecutar archivos por lotes? A solicitud de un colega, probador, analista o cliente, ¿puede analizar un par de cientos de miles de líneas de registros en un servidor remoto en 3 minutos, encontrar la entrada necesaria del parámetro clave, empaquetar la salida, reenviarla a la dirección especificada y volver a la tarea interrumpida? ¿Qué tan rápido, MUD, sabe cómo realizar operaciones de rutina que requieren repetición repetida durante la jornada laboral?
Como saben, es posible comenzar la compilación en entornos de desarrollo modernos presionando F5 (o F6? O F13? .. Al final, ¿por qué yo, el gerente del proyecto, necesito saber esas cosas? No sabes, MUD, qué tan rápido, en un par de minutos descargue de Jira, formatee correctamente en Excel y envíe un correo electrónico al cliente sobre el informe de defectos con gráficos y tendencias de
blackjet y prostitutas , pero nunca dejará de fijar su "piem" en la sala de fumadores entre sus colegas que no es estúpido sabe cómo el destructor difiere del constructor). Pero durante una carrera bastante larga, no he conocido a tantos programadores que usan métodos abreviados de teclado en el teclado para invocar ciertas acciones estándar; la mayoría usa el manipulador de mouse más lento para esto. Condicional "Tab - 1000 - Tab - 1 - Tab - 0 - Tab - Retroceso - 2 - Ctrl + S - Ctrl-F6 - Enter, Alt-Tab, F5" en 6 segundos le permite a un verdadero profesional hacer lo que hace con el mouse moviendo y tocando Con los dedos índices en el teclado, uno lento dura cinco largos minutos. Y cuando tales operaciones se realizan cientos de veces al día, en el contexto de una fecha límite próxima, otro gerente de proyecto a veces quiere
tomar y ... alejar a un "profesional" del teclado y hacer cambios / compilar / diseñar el código ejecutable y dar el visto bueno al grupo de prueba La nueva construcción finalmente está lista.
Por lo tanto, MUD, no seas perezoso y pasa tiempo dominando la impresión ciega de diez dedos y los métodos de trabajo efectivo con herramientas y cree en personas más experimentadas, incluso si algunos de ellos no son tan amados por tus gerentes de proyecto, esta vez valdrá la pena. Mientras tanto, usted, joven torpe, no ha alcanzado la perfección en esto: ¡vaya, entiérrese en el monitor y escriba el código, Bl ..!
Evaluación laboral
No puede soportarlo cuando el gerente del proyecto interviene en el sagrado proceso de "escribir código". Pero al mismo tiempo, nunca se negará el placer de dejar un comentario cáustico sobre plazos "poco realistas", requisitos "con fugas", solicitudes inoportunas de cambios, gerentes de proyectos incompetentes. Cuando, dentro del marco de una metodología particular, recurren a usted para obtener una opinión experta sobre la evaluación de los costos de mano de obra para la próxima iteración o para todo el proyecto, pone cara de sorpresa y comienza a "poner excusas" sobre especificaciones incomprensibles o incompletas, tecnologías desconocidas, y que no es su negocio en absoluto para planificar, no tienes tiempo para "tonterías" y es mejor que vayas y hagas lo real: escribir código. “Estimación de costos laborales por el método de puntos funcionales? ¿Por analogía basada en resultados anteriores? ¿Según el número de formularios de pantalla y las solicitudes de E / S de la base de datos? ¡No, no lo he escuchado! "
Por lo tanto, un joven amigo, manténgase callado en un trapo cuando no es asunto suyo planificar el trabajo en el proyecto, o mejore sus propias habilidades para emitir evaluaciones verdaderamente expertas, y no con el dedo en el cielo. Y hasta que
domines el último - ¡
IPKB !
Código hindú
Uno de sus pasatiempos favoritos es criticar el código de software creado por desarrolladores indios. No le des pan, solo déjanos burlarnos del estilo de programación de "pasta". Más que hablar sobre el código "hindú", te encanta conversar sobre tecnología (ver más abajo). Y todo esto a pesar del hecho de que usted mismo llama a los métodos el orgulloso nombre kolbasa (), copia inolvidablemente fragmentos de código en diferentes lugares del programa y crea clases del tamaño de una docena o dos pantallas.
Por la insignificancia de su propia experiencia profesional, , no le resulta familiar que la
mierda del código que usted escribe a menudo no sea mejor y, a veces, peor que el código que crean sus colegas del sur. Los programadores lamentables están presentes en cualquier país, "no juzguen, no seamos juzgados", y los verdaderos profesionales, les diré un secreto, MJD, no bajen a reprochar a sus colegas a nivel nacional y mejoren lentamente sus propias calificaciones y tiempo, asignados para la creación de un producto de software, gastan directamente en la programación y no en la búsqueda de
popotes a los ojos de los demás en una falla en el código de otro.
Discusión interminable de tecnología
Usted discute interminablemente con otros programadores qué Java ++ es superior a C ## o qué versión número ciento veintinueve fracción quince de cualquier biblioteca Javascript es mejor que la versión ciento veintinueve fracción trece. Nunca siente pena por tales discusiones, incluso en aquellos días en que quedan 2-3 días o semanas antes del final de una iteración o un proyecto de varios meses y el número de defectos graves no corregidos que se le asignan supera los cincuenta.
Lo hace sin una punzada de conciencia durante las horas de trabajo, y no los viernes por la noche o los fines de semana por un vaso de cerveza. Está involucrado en tal charla a pesar del hecho de que la cuestión de elegir y usar una u otra tecnología en un producto se encuentra fuera del alcance de su competencia (porque el tamaño de su competencia, MJD, simplemente no ha crecido todavía), pero aún así pasa tiempo con su empleador y proyecto en trepot improductivo.
Quejándose de manifestaciones "innecesarias"
Por lo tanto, cuando después de haber
pasado el tiempo hablando, hablé durante 2 horas en la cocina / sala de fumadores con media docena de los mismos codificadores de
mierda sobre la última conferencia de prensa / marco de Google-Microsoft-Apple-Linus Torvalds ayer, que robó un par de personas. días de desarrollo, de repente, al analizar la iteración completada, declara que se llevan a cabo demasiadas reuniones innecesarias en el proyecto y necesita acortarlas; en respuesta a esto, solo desea gritar una cosa: ¡cállate e
IPKB !
Ruso alfabetizado
Bueno, al final, como dicen, el último, pero lejos de ser el menos importante.
Incluso si usted, MUD, habla con fluidez idiomas como C ## o Brainwave, esto no lo salva por completo de la necesidad de escribir y hablar correctamente ruso (y también en inglés, siglo XXI en el patio). Por lo tanto, antes de la próxima vez, podrá escribir especificaciones, comentarios sobre el código, cartas al cliente o sus artículos inteligentes y comentarios aquí o sobre algún otro recurso para codificadores rápidos : ¡vaya y aprenda el idioma ruso correctamente, bl ..! Hágalo para que, sea lo que sea que escriba, cualquier persona competente lo lea con facilidad y alegría, y no tropezará con cada una de sus letras. Visite y memorice los contenidos del sitio tsya.ru , «» — , "
" «» — , «
», ..!!111
Epílogo
Espero que los consejos anteriores le convengan para su uso futuro, y con el tiempo se convertirá en un verdadero ingeniero para el desarrollo de software, un profesional en su campo que interactúa de manera competente y cortés con sus colegas en la tienda, realiza su trabajo de manera eficiente y a tiempo. ¡Te deseo éxito en tu arduo trabajo! Y, por favor, recuerde siempre que sus compañeros no programadores no merecen menos amor y respeto con su trabajo que el suyo y un gato.
Además
En los comentarios a la primera edición del artículo, se hizo la pregunta: ¿dónde se obtienen estos desarrolladores? Especialmente, por supuesto, el autor del artículo no seleccionó a esas personas en sus equipos de proyecto, pero hay tomas similares en casi cualquier organización.Por supuesto, no todos los desarrolladores que trabajan profesionalmente en el campo de TI son similares a los descritos en el artículo. El autor está de acuerdo con la opinión generalizada de que un programador experto es 10 veces más productivo que su colega novato. La productividad de un desarrollador de mano promedio es aproximadamente 3 veces mayor que la de un principiante, caminante de basura o ineptitud y productividad, el escape final de un experto, gurú, "bisonte" también es aproximadamente 3 veces mayor que el de un profesional ordinario.En mi experiencia, las proporciones cuantitativas del número de desarrolladores poco calificados a ordinarios y ordinarios a expertos son casi iguales: 1 a 3 y 3 a 1. Estas proporciones pueden variar mucho de una organización a otra, pero en promedio son bastante ciertas. A lo largo de mi carrera, he trabajado con cuatro personas, a las que clasifico por completo en la categoría de " estrellas " (la parte extrema del "espectro"). Sabían todo lo necesario para la implementación de sus tareas, además de mucho más que eso, evaluaron expertamente los costos laborales, realizaron el trabajo dentro del tiempo asignado, después de su trabajo en el proyecto, en el producto o en la empresa, dejaron artefactos claramente documentados." Ordinario"Programadores, aquellos que sabían hacer mucho de lo que podían hacer las" estrellas ", pero no todos juntos, había una mayoría absoluta. Su artículo, obviamente, no se refiere, o solo se refiere al hecho de que algunos de los bocetos dados pueden hacerlos sonreír como "pero, sí, lo recuerdo, recuerdo que la compañía hizo lo mismo en XYZ, Dios mío, qué tonto fui entonces". fue (hace dos / cinco / veinte años)! ".Aproximadamente el mismo número que las "estrellas", me encontré con verdaderos " gubios ", solo aquellos que se describen desagradablemente en el artículo: astutos, apresurados, tontos, despreciando a todos sus colegas que no son programadores en el cargo (excepto por su directo jefe), poco dispuestos a aprender, o "expertos" que no ven la necesidad de ello.Este artículo está dedicado a la última categoría.