¿Cuándo alguien sería considerado un mal programador? [cerrado]

¿Cómo consideraría que un programador es malo en lo que está haciendo?

Si es posible ... ¿Cómo debería mejorar?

Cuando no aprenden de sus errores y de las revisiones por pares.

Todos somos verdes en algún momento; sin embargo, si no mejora o intenta mejorar, entonces es un mal programador.

Un programador que no sabe lo que no sabe y no está interesado en averiguarlo.

Una gran señal de advertencia es si son programadores de "culto a la carga", lo que significa que hacen cosas pero no saben por qué hacen esas cosas (es solo "magia"). Gran publicación de Eric Lippert aquí .

Del artículo:

programadores que entienden lo que hace el código, pero no cómo lo hace.

Un gran consejo para mí es cuando te hacen preguntas a ti o a los demás programadores que muestran claramente que han hecho un esfuerzo absolutamente cero para resolverlo por su cuenta.

Un corolario es cuando hacen la misma pregunta de programación varias veces indicando que no están internalizando la información.

Cuando les lleva mucho tiempo resolver el problema de FizzBuzz.

Programadores que se niegan a aprender nuevas tecnologías / idiomas e insisten en atenerse a lo que ya saben.

Anexo: (agregando lo que el guión dijo a continuación en los comentarios)

Una extensión de esto son las personas que conocen un subconjunto de la funcionalidad de alguna tecnología pero no muestran deseos de aprender nada más al respecto. Lenguaje de programación, editor, otras herramientas ...

Cuando un miembro del equipo es el desarrollador productor negativo .

|# Lines Written| - |# Lines of bugs introduced| - |# Lines of rework required| < 0

Lo que significa que el resto de su equipo tiene que hacer más trabajo debido al mal desarrollador. NNPP

Cuando producen cosas que pertenecen a The Daily WTF de forma regular.

Cuando saben que hay mejores formas de hacer las cosas, pero aún así se niegan a hacerlo, incluso cuando el tiempo lo permite.

Personalmente, creo que cualquier programador que pueda mirar su propio código que escribieron hace un tiempo y no encontrar algo malo no es bueno. "Un tiempo" puede escalar con la experiencia ... Yo diría entre unas pocas semanas hasta un año más o menos.

Aquellos que ignoran las advertencias en sus códigos y solo se preocupan por los errores.

Cuando era líder de equipo en una tienda pequeña, había varias personas a las que tuve que reasignar (ni yo ni mi supervisor directo teníamos la capacidad de rescindir el contrato sin una tonelada de burocracia y un montón de documentación) o no tener renovación de contrato. al final del compromiso actual. Algunos de los tipos enumerados también funcionaron para otros líderes de equipo, y prácticamente adoptaron la misma opinión. Cosas que llevaron a la gente a la categoría "Programador malo" en mi libro:

1. Imposible u Ossified en el pasado
   Cuando el 'programador' no parece ser capaz de absorber el nuevo sistema, la nueva herramienta o lo que sea que se esté implementando, sin importar cómo se realice la capacitación / educación. Tiene que repetir dicho entrenamiento con frecuencia.
   Cuando el 'programador' solo conoce la tecnología o el paradigma de codificación que usaban hace 10 o 15 años. Era lo suficientemente bueno entonces, entonces, ¿por qué deberían cambiar?
2. 
   Codificador de vaquero La persona que codifica primero, sin un plan. El 'programador' que realiza cambios no probados en el código de producción y / o datos "porque tenemos que arreglarlo ahora" y luego se sorprende cuando falla el "arreglo".
   El Cowboy tampoco es definitivamente un jugador de equipo. No necesita un equipo apestoso.
3. La veleta
   Este 'programador' está enamorado de la "tecnología del día " y ve cada nuevo marco, lenguaje, metodología o lo que sea nuevo y caliente como el
4. El "gran cerebro"
   Este 'programador' está tan seguro de su talento y capacidades que se hacen cosas que no tienen mucho sentido para el proyecto. por ejemplo, reescribir una biblioteca estándar "porque es ineficiente para nuestro sistema" o introducir herramientas y técnicas que no son adecuadas para el problema en cuestión. Por ejemplo, presentar Lisp o Forth en un entorno mainframe.
5. LOC ^a. Sandbagger
   Este 'programador' utiliza ofuscación y dirección errónea para aumentar el ^a. LOC: Líneas de código que se pagan. He visto código en esta situación que era página tras página, pantalla tras pantalla de estructura y lógica duplicadas, con solo los nombres de párrafo o variables de control cambiados para aumentar el recuento de líneas.
6. Experto indispensable
   El 'programador' que tiene el conocimiento del dominio para resolver los problemas en cuestión, pero ya que ellos "saben" todo al respecto. De hecho, si fueran atropellados por un autobús, toda la organización se vendría abajo. { Observación: Los que piensan que son indispensables generalmente lo son. (¿Alguien tiene la fuente de este aforismo?)}
7. The Pasta Chef
   Este 'programador' se especializa en código de espagueti, aderezado con identificadores que son demasiado difíciles de seguir sin un IDE implementado sintácticamente. por ejemplo , Index1O0, Index1I0O, etc.
8. Pasante de verano: específicamente un subtipo Caminata Desastre
   Mi antigua tienda solía contratar a una serie de pasantes en edad de secundaria o universidad. Una vez, un departamento necesitó una pequeña base de datos para rastrear el uso de algunos equipos (ahora esto era un regreso, y estaba usando dBase III). El tipo codificó durante todo el verano, pero no terminó cuando comenzó la universidad en el otoño. Obtuvo una extensión de una semana y luego una segunda semana. Al final de la segunda semana, me enviaron para tomar su proyecto y llevarlo nuevamente al Desarrollo de Sistemas para que estuviera terminado. Me mostró las cosas que había hecho, y luego la parte inacabada. Lo que funcionó fue agradable, pero la aplicación fueincompleto. Cuando abrí la nueva caja de disquetes formateados para obtener copias, dijo: "solo un segundo, déjenme eliminar mis archivos de prueba ..." y antes de que pudiera decir algo, había eliminado un montón de archivos.
   Siendo del tipo sospechoso, y descubriendo que su aplicación no era casi nada más que dulce para los ojos cuando regresé a mi tienda, volví al departamento, saqué a Norton y recuperé los archivos que había eliminado, tratando de encontrar alguna lógica adicional, incluso si está incompleto
   Encontré, no mala lógica, pero mal comportamiento. La impresora conectada a la PC que estaba usando era una impresora tipo margarita. El conjunto de caracteres normalmente montado era una variante suiza. La salida de los programas eliminados pone un nombre, dirección, fecha de nacimiento, algunos códigos de letras y algún tipo de número de identificación. El formato y el diseño me molestaron. Todas las fechas de nacimiento de varias personas eran apenas legales para beber. La mayoría de las direcciones no estaban allí, cuando las busqué en nuestro directorio entrecruzado. Cuando le mostré las impresiones a su supervisor, él me miró y dijo "Licencias de conducir, ¿no le parece?" Dije que lo hice. Dijo que por eso había encontrado el stock de transparencias cortado en la basura al lado del Xerox. Nuestro chico malo había hecho superposiciones para ajustar sus edades y las de sus amigos en sus licencias de conducir. Lo informamos a las autoridades.No ha pagado por sus últimas dos semanas.

Estos son solo algunos de los malos personajes con los que he tenido que trabajar ...

/ s / BezantSoft

Incapaz de adaptarse a las nuevas tecnologías

Además de la evidente falta de conocimiento / habilidad, un programador es malo, si su código es más difícil de leer y / o mantener de lo que debería ser.

Cuando nadie más puede leer su código. No importa lo brillante que seas; Ningún programador es una isla.

Alguien que no presta atención a los detalles y siempre está en "funciona, así que lo dejo solo. Todas esas excepciones en los registros no importan".

Para mí hay dos categorías para programadores: solo y en equipo.

Los malos programadores solos son

• Aquellos que tardaron demasiado en hacer la tarea simple.
• Aquellos que no pueden investigar por sí mismos para lo que están haciendo.
• Aquellos que olvidarán lo que se ha codificado hoy dentro de unos días y no pueden mantener su propia base de código muy bien.
• Los que no pueden adaptarse a los requisitos cambian.

Los programadores de equipos malos son aquellos que entran en la categoría de programadores solos malos, incluidos

• Aquellos que no pueden coordinarse con otros miembros del equipo.
• Los que no aceptan las críticas.
• Aquellos que no saben cómo ser útiles para los demás y cómo beneficiarse de otros miembros del equipo.
• Aquellos que no pueden escribir código legible.
• Aquellos que no comentan en aras de la legibilidad para los demás.

No están dispuestos a admitir que no saben la respuesta y / o no están dispuestos a buscar cosas.

Si no lo sabes, no te des por vencido, descúbrelo y hazlo.

Una gran señal de advertencia en mi experiencia es cuando no comentan sus hacks ...

Sabes a lo que me refiero: cuando te obligan a hacer algo muy hacky porque simplemente no hay mejor manera de hacerlo.

Los buenos programadores odiarán tener que hacerlo y escribir comentarios en línea que digan cuánto odian poner en ese tipo de pirateo, pero no hay otra opción. Los malos programadores simplemente lo introducirán y no lo comentarán.

Silencio obviamente cuando un programador escribe MUCHO código. Funciones muy grandes, tal vez copiar / pegar líneas o bloques de código, usando mucho más si es necesario, etc. Esto podría deberse a que el programador no conoce una función estándar para hacer lo que quiere, pero la mayor parte del tiempo no lo es.

Que se le muestre repetidamente la forma correcta de hacerlo, y repetidamente solo hacerlo de la manera fácil.

Estoy moviendo mi respuesta aquí desde un tema duplicado cerrado que preguntó ¿Puedes reconocer si eres un mal programador? El otro tema se estaba cerrando mientras redactaba mi respuesta. Mi respuesta aborda más directamente la pregunta, ya que fue formulada por el otro autor de la pregunta y se leerá mejor si entiendes eso.

¡Suspiro! ¡Una parte de mí no quería agregar a este tema ya ocupado, pero la otra parte ganó! ¿Por qué ganó? ¿Por qué me molesto en agregar aún más palabras a este multílogo particular? Bueno, porque, hasta cierto punto, puedo tener una opinión ligeramente diferente sobre esto que los muchos comentaristas anteriores.

El binario funciona muy bien en las computadoras: es '1' o '0', "encendido" o "apagado". Podemos abstraer y codificar mucha información usando esos dos famosos estados. Pero, no tiende a funcionar tan bien para asuntos humanos: "bueno" o "malo", "sano" o "loco", "bueno" o "malo", "inteligente" o "estúpido", "gordo" o "delgado", "vivo" o "muerto"? Este tipo de evaluaciones polarizadas siempre han dejado al ser humano afectuoso parte de mí terriblemente insatisfecho. Por los esquemas de medición que elijo aplicar, generalmente encuentro que las respuestas a tales contrastes en realidad se encuentran en algún lugar a lo largo de un continuo entre uno de esos polos y el otro, no en ninguno de los extremos.

He luchado con esta tendencia hacia la polarización durante bastante tiempo, ahora, y mi solución personal es que encuentro mucho más útil aplicar tres palabras a cualquier evaluación: "¡ hasta qué punto!"

Entonces, mi respuesta a su pregunta es sugerirle que lo reformule y preguntarse esto: "¿Hasta qué punto soy un mal programador?" O, mejor aún, preguntar en la otra dirección: "¿Hasta qué punto soy un buen programador?" Si persigue la verdad, probablemente se ubicará en algún lugar a lo largo de un continuo entre ser un programador "malo" y uno "bueno". Luego, una vez que logre ubicar aproximadamente dónde se encuentra a lo largo de este camino, probablemente pueda identificar un punto algo más cercano al "buen" final, un punto en el que le gustaría encontrarse en el futuro cercano.

Si no establece ese punto demasiado lejos, probablemente pueda poner su extremo trasero en marcha y comenzar a moverlo en esa dirección. Si logra iterar este algoritmo heurístico bastante simple varias veces, ¡pronto puede encontrarse con una programación demasiado ocupada para tener que hacer esta pregunta nuevamente! Ah, y probablemente progresará más rápido si comienza a golpear el código en un teclado tan rápido y con la mayor frecuencia posible; y, si te tomas un pequeño descanso de vez en cuando, ¡lee un código de alta calidad escrito por tus compañeros! En estos días de desarrollo dinámico de código abierto, no tiene escasez de código libre y exquisito para aprender.

Por lo tanto, te recomiendo encarecidamente que pruebes mis tres pequeñas palabras, "en qué medida", ¡y veas cuán lejos en una buena dirección pueden llevarte!

Alguien que dice "No se puede hacer".

En mi opinión, se trata de resolver problemas, la herramienta debería ser mucho menos relevante que realmente hacer el trabajo. Si tengo que resolverlo usando MS-Access o lenguaje ensamblador, es cuestión de tiempo y dinero, no de "No se puede hacer"

Una señal de advertencia se centra demasiado en la forma académica y "adecuada" de hacer las cosas, y no se enfoca lo suficiente en hacer el trabajo.

Si solo conoce la sintaxis de un lenguaje pero no conoce los conceptos básicos de los algoritmos.

Cuando hacen mucho pontificado pero producen muy poco.

! (inteligente y hace las cosas)

Aquellos que no conocen principios como SOLID, DRY, OOP, etc. Es importante tener una buena comprensión de los principios y fundamentos de programación en lugar de conocer tecnologías específicas. Aquellos con una base sólida podrán aprender nuevos temas fácilmente y producirán un mejor código.

Un programador incorporado que no entiende las interrupciones muy bien o la multitarea. También programadores que necesitan trabajar con campos de bits pero que no comprenden las operaciones lógicas y los cambios.

Una señal de reconocimiento inmediato es alguien que dice: "No entiendo por qué no funciona. Hice todo bien".

Una cosa que distingue a un mal programador de un programador novato es la obstinada insistencia en implementar su sistema favorito en cualquier idioma y API en el que estén trabajando.

Una vez heredé un sistema donde el desarrollador anterior volvió a implementar (en Java) un gran conjunto de la API Ashton Tate DBase III + en capas sobre la biblioteca de acceso dbf personalizada. No se utilizó ninguno del marco de colecciones de Java.

Esto fue para que pudiera escribir una aplicación Java / swing que se viera y actuara como una aplicación DBase III + (o posiblemente clipper).

Las aplicaciones que escribió en este sistema tenían menús de barra lite y abrirían un formulario de ventana completa con una fila de botones en la parte inferior cuando navegaste por la barra lite a la opción. Era como una pequeña máquina del tiempo desde la década de 1980.

El hombre era claramente un desarrollador experto. Sabía lo suficiente como para poder escribir todo el sistema él mismo en el plazo de ese proyecto. También pudo reutilizarlo en algunos otros sistemas internos.

Pero fue un programador horrible porque su código hizo un mal uso de las características de los sistemas en los que trabajó. Estaba más dispuesto a pasar 3 meses en una biblioteca personalizada de dudoso beneficio que aprender Java / Swing / SQL.