He estado en la industria del software program durante más de 15 años y, a medida que pasa el tiempo, siento que me estoy volviendo cada vez más delirante. Como compañero desarrollador, la retórica de nuestra industria me ha lavado el cerebro para creer que todo se trata de escribir “código limpio”. Sabes de lo que estoy hablando: hablar es barato; muéstrame el código!
No somos conscientes, pero el problema empieza cuando somos desarrolladores junior. Estamos ansiosos por aprender y, a menudo, pedimos consejo a nuestros compañeros senior. Preguntamos cosas como: ¿Qué libros recomiendas? Dos de los libros más recomendados son código limpio y el pragmático Programador. Ambos son libros excelentes, y creo que todo el mundo debería leerlos. Ambos libros comparten algunos de los mismos consejos y tratan de enseñarnos cómo escribir mejor código y convertirnos en mejores profesionales. Sin embargo, tienen áreas de enfoque muy diferentes.
Entre muchos otros consejos, código limpio se enfoca en evitar la duplicación, nombrando descriptivamente las variables, manteniendo el formato del código consistente, manteniendo las funciones pequeñas y asegurando que solo hagan una cosa.
Por otro lado, El programador pragmático se enfoca en cosas como construir equipos pragmáticos, enseñándonos que nuestro objetivo como desarrolladores debe ser deleitar a los usuarios y que no es posible escribir un software program perfecto.
Después de leer ambos libros, volvemos al trabajo con muchas ganas de aplicar nuestros nuevos conocimientos. El problema es que el consejo compartido por código limpio es mucho menos abierto al debate y más accesible para poner en práctica que el compartido por El programador pragmático. En mi humilde opinión, el consejo compartido por El programador pragmático es mucho más profundo y significativo.
Todos nosotros (desarrolladores Junior o Senior) podemos identificar y señalar cuando uno de los miembros de nuestro equipo intenta fusionar una “Clase de Dios” (una clase que es demasiado grande y hace demasiadas cosas). Sin embargo, tratar de decidir si una pieza de software program es lo suficientemente buena o no puede convertirse en el debate del siglo.
He estado tratando de averiguar si soy el único que se siente así leyendo recomendaciones en línea sobre ambos libros. he encontrado un Publicación de reddit en el que alguien pregunta qué libro es mejor. Aquí hay dos de los comentarios que me gustaría desglosar:
Recomiendo el programador pragmático (primero). Es una lectura más fácil y contiene más sobre una carrera de desarrollo de software program en normal en lugar de solo sobre código.
La primera recomendación parece reforzar la thought de El programador pragmáticoEl contenido de es mucho más profundo (“carrera de desarrollo de software program en normal”) que código limpio (“solo se trata de código”).
Preferí el código limpio ya que se trata más de los principios de lo que hace a un buen ingeniero. He leído el programador pragmático pero no sentí que realmente agregara nada a mis habilidades.
Creo que el programador pragmático le mostrará patrones para usar y varias soluciones, mientras que el código limpio se tratará de profesionalismo.
Entonces, si desea mejorar y ejercitarse a sí mismo, obtenga un código limpio. Si necesita ayuda con patrones y soluciones, entonces pragmático.
La segunda recomendación resuena con mi sentimiento de que la El programador pragmático es menos accionable. El lector destaca cómo “los principios de lo que hace a un buen ingeniero” se sintieron inútiles (“realmente agregó algo a mis habilidades”). Por otro lado, el lector podría “superarse” y “ejercitarse” utilizando los consejos de “profesionalidad” contenidos en código limpio.
No nos damos cuenta, pero tenemos un sesgo inconsciente hacia la priorización de consejos que se sienten más prácticos y fáciles de aplicar. El problema de este sesgo es que a medida que pasa el tiempo, nos enfocamos cada vez más en los consejos brindados por código limpio y cada vez menos en los consejos proporcionados por El programador pragmático. Con el tiempo, los desarrolladores se centran más en cuestiones relacionadas con el código y menos en otros tipos de problemas. Cuando las cosas no van bien, tendemos a buscar las causas en el código y no en otro lugar.
Nota: Dentro del propio código, es más possible que identifiquemos y señalemos problemas que son más obvios y prácticos, como problemas de formato, en lugar de problemas semánticos de la API. Nuestro cerebro está predispuesto a invertir el Pirámide de revisión de código. Por ejemplo, es muy possible que notemos que el código se repite e intentemos hacer cumplir la No te repitas (SECO) principio, mientras que es mucho más unbelievable que notemos una abstracción incorrecta. Este hecho nos hace propensos a introducir la introducción y la abstracción incorrecta como solución a un problema DRY sin ser conscientes de nuestras acciones. El problema es que la abstracción incorrecta es mucho más costosa que “la duplicación es más barata que la abstracción equivocada”.
Durante el resto de esta publicación, me referiré a este tipo de sesgo (en el contexto de nuestra industria) como “el delirio del código”.
Nota: Este sesgo hacia el asesoramiento procesable se nota más allá de nuestro código e influye en nuestros procesos y herramientas. Por ejemplo, muchas organizaciones intentan volverse más ágiles y adoptar prácticas ágiles como Scrum. Pronto se obsesionan con los rituales Scrum (Standup, Dash planning…). Esta obsesión es comprensible porque los rituales son muy procesables. El problema es que realizar rituales no es lo que hace que una organización sea ágil. El manifiesto ágil no menciona casi nada acerca de los rituales.
Puede pensar que este no es su problema porque tal vez no haya leído esos libros, pero le garantizo que este sesgo lo impacta a diario. No importa porque este sesgo es common. Solo estoy usando los libros como ejemplo; tal vez obtuviste tu conocimiento de un colega más senior o de un curso en línea. El engaño del código todavía se aplica a ti.
¿Cuál es el daño causado por el engaño del código? #
Al desarrollar un producto de software program, muchos factores influyen en si nuestro producto (y, en última instancia, nuestra organización) fallará o tendrá éxito. La manera en que lo veo; estos factores se pueden agrupar de la siguiente manera:
- Producto = UX + Conjunto de características + Preposición de valor + Código
- Mercado = Necesidades inmerecidas + Cliente objetivo
- Cultura = Misión + Visión + Procesos + Herramientas
Desde el primer día, mi industria me ha lavado el cerebro para creer que la calidad del código distingue a los grandes desarrolladores, pero a medida que adquirí experiencia, me di cuenta cada vez más de lo delirante que es esta thought. Con el tiempo, me he vuelto más consciente de que los problemas relacionados con el código deberían ser la menor de mis preocupaciones. Tal como lo veo hoy, casi todo en la lista anterior triunfa sobre el código. Por ejemplo, creo que UX es más importante que el código o que los Procesos y Herramientas son más críticos que el código.
La palabra “ilusión” tiene el siguiente significado:
engaño
/dɪˈluːʒ(ə)n/
sustantivo
una creencia o impresión idiosincrásica mantenida a pesar de ser contradicha por la realidad o el argumento racional
Entonces, ¿cuál es el significado del engaño del código? Analicemos esta definición. Un “engaño” es un modo de comportamiento o forma de pensar. En el contexto de la ilusión del código, esta forma de comportamiento es el sesgo del desarrollador hacia el “código limpio”. Creemos que cuando las cosas van bien o mal, la causa debe estar relacionada con el código. En mi opinión, esta creencia se contradice con la realidad. La calidad del código es solo un issue muy pequeño en el destino de una organización.
Hace unos años, Google publicó un estudio titulado Las cinco claves para un equipo de Google exitoso. El estudio destacó lo siguiente:
Hay cinco dinámicas clave que distinguen a los equipos exitosos de otros equipos en Google:
- Seguridad psicológica: ¿Podemos arriesgarnos en este equipo sin sentirnos inseguros o avergonzados?
- Confianza: ¿Podemos contar unos con otros para hacer un trabajo de alta calidad a tiempo?
- Estructura y claridad: ¿Están claros los objetivos, roles y planes de ejecución en nuestro equipo?
- significado de trabajo: ¿Estamos trabajando en algo que es personalmente importante para cada uno de nosotros?
- Impacto del trabajo: ¿Creemos fundamentalmente que el trabajo que estamos haciendo es importante?
La seguridad psicológica fue, de lejos, la más importante de las cinco dinámicas que encontramos: es la base de las otras cuatro.
Mi experiencia private es que la seguridad psicológica se ve más comprometida en equipos con una cultura donde la calidad del código se valora más que todo lo demás. Por ejemplo, organizaciones que toleran los “imbéciles brillantes”. Los idiotas brillantes son individuos de alto rendimiento capaces de producir código de alta calidad en muy poco tiempo. Sin embargo, estos individuos tienen habilidades de inteligencia emocional muy débiles. Los idiotas brillantes hacen que otros miembros del equipo se sientan como una mierda cada vez que cometen un error de codificación. Incluso cuando la realidad es que el error podría tener un impacto nulo en el desempeño normal de la empresa.
¿Es hora de reevaluarnos a nosotros mismos? #
Nuestra industria cree que el código triunfa sobre todo lo demás “a pesar de ser contradicho por la realidad o el argumento racional”. Esta forma de pensar es tan poderosa que va más allá del equipo de desarrollo. Por ejemplo, una organización puede decidir que invertir en el equipo de desarrollo es una prioridad más alta que invertir en el equipo de UX o que debe diseñar entrevistas para centrarse en evaluar las habilidades técnicas sobre la inteligencia emocional.
Estoy cansado de encontrarme siendo parte de equipos profundamente frustrados por razones como:
- Nuestra pila tecnológica es demasiado antigua.
- Nuestras reuniones de pie están tardando demasiado.
- Nuestra cobertura de prueba es demasiado baja.
- Alguien está tratando de usar espacios en lugar de tabulaciones.
En lugar de razones como:
- No invertimos lo suficiente en el equipo de UX.
- Hay demasiados boletos WIP.
- No hacemos pruebas A/B.
- No hablamos lo suficiente con nuestros usuarios.
He sido testigo de la falla de muchos equipos de desarrolladores experimentados con un presupuesto virtualmente infinito. Por otro lado, algunos de los casos de éxito más destacados que he presenciado son el resultado del trabajo de un grupo de licenciados sin casi ninguna experiencia previa en una startup sin prácticamente recursos. Las causas de este fenómeno son evidentes en mi mente. En las grandes corporaciones, los desarrolladores no tienen que preocuparse por el próximo cheque de pago, por lo que pasan mucho tiempo discutiendo problemas de código (por ejemplo, una refactorización de 6 meses). Mientras que en las startups, la mentalidad es “envíalo o muere”.
Soy desarrollador y produzco código todos los días; aceptar que escribir bien el código no es tan esencial como me lavaron el cerebro para creerlo es una píldora difícil de tragar, pero debo aceptar la realidad. Apuntar a la perfección del código en el software program no solo es poco realista sino contraproducente. Conduce a todo tipo de problemas: optimizaciones prematuras, sobrecarga de funciones y exceso de ingeniería..
Escribir código limpio no es lo que hace que un desarrollador sea un gran desarrollador. Un gran desarrollador debería:
- Estar obsesionado con entregar valor al cliente.
- Tenga buen criterio para llegar a compromisos entre la calidad del código y el valor para el cliente.
- Intenta escribir código limpio, pero sabe cuándo dejar de perseguirlo.
- Sabe que no todas las partes de una solución son igualmente críticas y solo buscará un código limpio cuando valga la pena. Por ejemplo, las interfaces son mucho más importantes que las implementaciones. Si obtiene las interfaces correctas, reemplazar las implementaciones con el tiempo no debería ser un problema.
El engaño del código a menudo nos hace centrarnos en cosas que a menudo no tienen sentido y son una pérdida whole de tiempo. No estoy abogando por escribir código espagueti, pero tengo la sensación de que usar nuestra energía para centrarnos en la excelencia de la ingeniería por encima de la satisfacción del usuario está contribuyendo a que una gran parte de nuestra industria se sienta depressing. Deberíamos apuntar a escribir software program lo suficientemente bueno recordando que los desarrolladores no pueden decidir cuándo el software program es lo suficientemente bueno: los usuarios lo hacen..
Nota: El título de esta publicación es una carta de referencia de 1968 de Edsger Dijkstra publicada como “Ir a declaración considerada dañina”.
3
Prestigio
3
Prestigio
