If-else y más maneras de molestar a un desarrollador
Hablar de If-else versus polimorfismo es una forma.
Sinceramente, es bastante fácil. Básicamente, cualquier cosa puede molestar a un desarrollador. Cuantas más opiniones “religiosas” tenga el desarrollador, más fácil será. Mucha gente opina que no hay cultura más tóxica que la de los desarrolladores, programadores e ingenieros…
Sí, incluso se discute mucho sobre cuándo es un desarrollador miserable, también conocido como mono de código, un programador estimado o un ingeniero santurrón. Algunos ingenieros se agitan furiosamente cuando se les llama “desarrolladores”.
Solo voy a enumerar un montón de cosas que realmente afectan a los desarrolladores, sin ningún orden en particular. Supongo que todos enfurecen a los programadores en diversos grados según sus experiencias, habilidades y creencias.
If-else vs. polimorfismo.
Vaya, no se sabe en qué nido de avispas se encuentra hasta que va a uno de artículos sobre Deja de usar If-Else, por ejemplo. Existen artículo que reciben más de 100.000 visitas en menos de unos pocos días (algo viral en los estándares medios). Incluso generan su propio hilo de odio en Reddit. Aparentemente, hay toda una religión centrada en escribir código incorrecto con ramificaciones tradicionales, como usar if-else.
El simple hecho de usar POO es agravante para algunos, y también lo es decirles a los principiantes que el pensamiento orientado a objetos es demasiado complejo para ellos.
Personas no tecnológicas que estiman tareas de programación.
Por ejemplo, supongamos que uno de sus primeros proyectos fue estimado por un colega con una maestría en ciencias políticas. Tuvo que entregar una solución desarrollada desde cero durante el proyecto, que incluía configurar tres entornos en la nube, crear el modelo de base de datos, escribir la lógica empresarial, back-end y front-end.
Tiempo y recursos estimados: 34 a 36 horas, desarrollador único. El plazo se presentó al cliente sin consultarle sobre lo que es realista.
Tonterías como esta molesta a los desarrolladores.
Artículos de tecnología y código.
Los artículos a menudo desafían la forma de hacer las cosas de los demás. Es común que reciba comentarios como “tengo 20 años de experiencia y siempre he hecho X de la misma manera, y funciona”.
La persona realmente está diciendo que su estilo de código no ha cambiado durante los últimos 20 años y solo estaba leyendo el artículo para verificar que su conocimiento antiguo aún se mantiene, para su decepción, no es así.
Código de otros.
Bueno, a veces odiamos el código de otros desarrolladores. Especialmente si no estamos seguros de lo que se supone que debe hacer, es entonces cuando realmente nos gusta despotricar sobre lo ineficiente que es el código (para encubrir el hecho de que no entendemos las intenciones). Además de tratar de comprender el propósito, literalmente, todo es un agravante potencial. Cada cosa menor, como llaves colocadas en la misma línea, línea separada o K & R, debate en Google sobre llaves, y se volverá más tonto a cada minuto.
Tabs vs. Spaces también es un clásico.
Festivales de novatadas (revisiones de código y solicitudes de extracción)
Hablando de cultura tóxica, CR / PR es realmente uno de esos eventos que pueden sacar lo peor.
Las revisiones de código son como invitaciones abiertas para avergonzar públicamente a otros por lo deficientes que son sus habilidades de programación. O, al menos, algunos tratan a las relaciones públicas de esa manera. No hay nada más molesto que dedicar tiempo a preparar una función para pasar a la maestra (no a la principal, sino a la maestra…), solo para que otros que ni siquiera participaron en la implementación de la función destruyeran su código.
Es esencialmente una temporada abierta para expresar sus puntos de vista personales sobre cómo otros deberían escribir código.
Comentarios de código. ¿Huele a código o es útil?
Una vez más, los desarrolladores son religiosos sobre esto. Puede encontrar fácilmente a alguien con quien tener largas discusiones. Los comentarios de código también son conocidos por atraer mucha atención durante las revisiones de código, “si necesita un comentario, su código no es lo suficientemente claro”.
Obviamente, comentar atentamente su código es de gran ayuda para cualquiera que venga después de usted. Incluso su yo futuro estará agradecido.