¿Cuáles son los signos reveladores de una persona que no ha aprendido a programar correctamente a pesar de que lo ha estado haciendo durante años?

Estoy tratando de resistirme a decir “tienen un trabajo como programador”.

Quiero decir, el campo tiene solo unos setenta años. En comparación con cualquier ingeniería o arte, todavía estamos en nuestra infancia y aprendiendo cosas a medida que avanzamos. No es como la ingeniería civil, donde podemos observar diez mil años de construcción de casas y decir que estas cosas funcionan absolutamente y estas no .

Pero estoy mayormente de acuerdo con Joe en que los principales programadores a tener en cuenta son las personas dogmáticas. Si hay un lenguaje verdadero, generalmente significa que no están dispuestos a aprender nada nuevo, incluidos los conceptos específicos del dominio, lo que los hace completamente inútiles en un proyecto real. También son peligrosos, porque las personas no técnicas lo escuchan y piensan: “tiene un título y es obstinado, debe ser un buen consejo”, si no tiene cuidado.

(Editar: una subclase de dogma que no he oído mencionar también debe destacarse, porque creo que varias personas lo han implicado, los tipos de Cult de Cargo. Encontrarás personas que realizarán ciertas tareas con una reverencia casi religiosa, incluso cuando no tienen ningún significado. Incluirán referencias a bibliotecas que no importan, eliminarán objetos manualmente cuando haya un recolector de basura perfectamente bueno, declararán muchas variables “por si acaso” o agregarán patrones de diseño con una fanfarria sorprendente. una vez y funcionó, así que presumiblemente eso es lo que necesitas para que las cosas funcionen).

Además, cualquiera que diga: “Necesito reescribir esto”. Si bien hay algunos casos extremos donde una reescritura completa podría estar en orden, y un millón de casos donde la refactorización es útil, querer reescribir el código dice muy claramente:

• No entiendo el código que estoy viendo.
• Si toco el código que estoy viendo, lo voy a romper.
• No me importa cuántos errores antiguos se hayan corregido que voy a reintroducir cuando simplifique este código.
• No me importa perder el dinero y el tiempo de mi empleador en el cronograma en lo que equivale a un juicio estético.

Vea cosas que nunca debe hacer, Parte I, gracias a Henré Botha por rastrearlo.

(Editar: un número sorprendente de personas en los comentarios aparentemente no puede distinguir entre “reescribir toda la base de código desde cero” y “corregir algunos errores”, o incluso “refactorizar”, a pesar de que lo excluyo específicamente. Eso me parece profundamente preocupante por varias razones …)

Los primos cercanos son los programadores que cuestionan el compilador o la biblioteca cuando su código no se compila. No, usted (ejemplo real de un ex colega) no encontró un error nuevo en printf() que nadie más haya notado antes. ¿Cuántas horas lo probaron y cuántas horas, perdón, segundos, pasaste probando tu código?

Y el último grupo que me preocupa, aunque no tanto, ya que hay tantos, son personas que no pueden estimar cuánto tiempo tomará algo o si sus estimaciones suponen que nada va a salir mal. Demuestra que realmente no estás pensando hacia dónde vas, y si no estás presupuestando para que todo salga mal, claramente nunca has trabajado con una computadora antes …

Tienden a preocuparse mucho por la mierda que no importa

Son religiosos sobre idiomas particulares; religiosos sobre sistemas operativos, religiosos sobre estilos de arriostramiento; religioso sobre estúpido dogma de programación (No use otra cosa; No regrese en el medio de una función. Condicione el valor de las expresiones primero, etc.); etc.

Les gusta hablar sobre programación más que hacerlo. Hablan mucho sobre patrones de diseño y otros temas de mierda.

Recientemente tuve que explicar por qué pensaba que un cuerpo de código en particular era malo, sin que pareciera solo una diferencia de estilo u opinión. Estas son algunas de las cosas que se me ocurrieron.

• No verifica los errores.
• No libera recursos.
• Números literales en lugar de constantes con nombre.
• Constantes “con nombre”, que son solo números traducidos en forma de texto.
• El mismo código se repite muchas veces en lugar de estar aislado en funciones / macros.
• Reinventa las funciones estándar de la biblioteca.

Muchos de estos se reducen al mismo problema básico: el código escrito incorrectamente es frágil. Puede funcionar ahora , pero se romperá de inmediato si necesita actualizarse o si hay algo a su alrededor. A menudo, el hecho de que funcione ahora parece ser el resultado de una persistencia obstinada, intentando cosas diferentes sin una comprensión real. Por el contrario, el código escrito correctamente se adapta fácilmente a los nuevos requisitos y circunstancias. El código que nadie se atreve a tocar es el código que más necesita reemplazar o refactorizar de su sistema.

Usan lo que parece hacer el trabajo como la “solución” al “problema”, sin una comprensión más profunda de cuál es el problema y cuál es, a nivel semántico, la respuesta a ese problema, independientemente de cómo sucedan las cosas técnicamente .
Habrá algo de lógica faltante y conexiones faltantes en su argumentación de por qué eligieron una determinada solución. La argumentación se basará principalmente en “funciona”. Declarar que “funciona” se basará principalmente en la observación a simple vista, más o menos exhaustiva (no soy un nazi de pruebas, es suficiente que uno logre explicar lógicamente por qué la solución que aplicaron es la respuesta al problema que identificaron) .

Dicho de otro modo, les resulta difícil distinguir entre un truco, un truco necesario y una solución limpia adecuada.

Si bien estoy de acuerdo con la respuesta del usuario de Quora de que el dogma “estúpido” es un signo de inexperiencia o poca habilidad, al mismo tiempo código mal escrito, como algoritmos de escritura con un rendimiento terrible, desconocimiento de mejores construcciones de lenguaje o formatos y formatos inconsistentes estilo de codificación, a menudo es una señal de alguien que solo está haciendo los movimientos y realmente no le importa la calidad de su trabajo.

* Una vez tuve un VP, Operaciones que insistió en que todos los ingenieros de software usaran TextPad, exclusivamente. Amenazó con despedirnos si alguna vez utilizáramos otro editor de texto o IDE, alegando que haría su trabajo más difícil admitir otras aplicaciones. ¿Alguien tiene una estúpida historia de dogmas que eso?

La habilidad de programación y el dominio del lenguaje son dos cosas separadas. En mi opinión, alguien que escribe un código deficiente que funciona correctamente, siempre que no haya demasiadas redundancias evidentes en el código, está programando correctamente, porque puede dividir adecuadamente el problema en una jerarquía de procedimientos y formular el proceso en un lenguaje manera agnóstica Alguien que usa todas las construcciones de un lenguaje de programación correctamente, usa todas las convenciones de nomenclatura apropiadas de manera consistente y escribe código conciso, tiene un alto dominio del lenguaje. Se requiere cierto nivel de dominio del idioma para escribir un programa que funcione. Debes apuntar a ambos, y creo que debes apuntar a ellos en paralelo.

En general, los signos son los de las personas malas.

Son cobardes: aunque hay una mejor solución para un problema, se adhieren a la tecnología antigua / inapropiada solo porque no están familiarizados con ella. Tienen miedo de probar cosas nuevas.

Carecen de mentalidad de crecimiento: hacen lo mismo una y otra vez. Son complacientes con eso. No se preguntan: “¿Qué he aprendido esta semana?” Después de todo, 1 año = 52 semanas.

Son arrogantes: “Sé mejor que otros”. Debido a esta actitud, pierden la oportunidad de aprender mucho de los demás. Las grandes personas son humildes y aprendieron mucho de la experiencia de los demás. A la gente no le gusta hablar con personas arrogantes. Entonces las personas arrogantes extrañan mucho.

Son dogmáticos: algunos de los signos obvios de los programadores dogmáticos:
“¡Esto tiene que hacerse solo de esta manera!”,
“X es el dios de todos los idiomas”,
“Quiero ser experto en lenguaje X y no necesito aprender ningún otro idioma”,
“Los patrones de diseño son la panacea para nuestros problemas de diseño. ¡Aplíquelos!”

No les importa : no les importa la calidad. Ellos “simplemente hacen las cosas” y están contentos con eso, olvidando que “un gran producto es la consecuencia de un gran trabajo” y que “la artesanía proviene de preocuparse por su propio trabajo”

No son jugadores de equipo: su actitud es como “lo haré a mi manera. No necesito discutir / compartir mi solución con otros”,
“Seguiré mi propio estilo. No me importa el estándar / guía de codificación del proyecto”,
“No me importa si alguien más no entiende mi código. ¡Ese es su problema!”

La respuesta graciosa sería que se han convertido en un administrador de TI y pueden reclamar crédito por el código de otras personas.
Sin embargo, en serio, la mayoría de los desarrolladores tendrán áreas que conocen ‘un poco’, y pueden lograr obtener un código de trabajo, pero es posible que no estén utilizando las bibliotecas ideales. Sin embargo, un desarrollador experimentado debe tener una o más áreas que afirman que es su área principal de experiencia, y después de un tiempo suficiente en el campo, definitivamente debe ser capaz de responder preguntas razonablemente complejas sobre esto.
Por ejemplo, cualquiera que haya estado trabajando con bases de datos relacionales durante un tiempo debería saber cómo representar un árbol de nodos de profundidad variable en una tabla. Un desarrollador web (ni siquiera un diseñador) debe saber cómo hacer algunas devoluciones de llamada, manipular la página, procesar datos en Javascript, hacer CSS estándar, etc.

Los programadores básicamente se subespecializan, por lo que es difícil señalar un área única y decir que todos los desarrolladores experimentados serán buenos en esto. Cosas como estimar cuánto tiempo tomará algo generalmente debería mejorar con el tiempo (dentro de su especialidad), y la cantidad de errores en el código resultante debería reducirse, pero es difícil probarlos.

Sin embargo, si observa su código y ve aproximaciones aproximadas de funciones de biblioteca muy estándar, entonces esto es bastante sugerente de alguien que no pasa suficiente tiempo aprendiendo cómo usar sus herramientas correctamente.

Se ponen demasiado a la defensiva cuando pides una explicación de algo que han escrito, en lugar de dar una razón; cualquier razón.

No saben cómo usar el control de versiones correctamente.

Copie el código de pegado de sus proyectos anteriores sin comprender el contexto.

Repasar la documentación es algo que nunca han hecho; por cualquier motivo.

No se mantienen al día con los cambios. No solo se resisten a aprender nuevos idiomas, sino que ni siquiera se mantienen al día con los cambios en su propio idioma. Por ej. Conozco a muchos programadores Java experimentados que no saben nada sobre enumeraciones, bibliotecas de concurrencia y ni siquiera pueden usar genéricos de manera efectiva; incluso a veces falta una comprensión adecuada de las Colecciones; olvídate de lambda.

Si alguien a quien admiran, o alguien en una posición autorizada les dice que esta es la forma en que debe hacerse, no lo cuestionan.

Para mí, hay varios tipos diferentes de programadores, algunos son “técnicamente” mejores que otros, algunos tal vez lo sepan mejor, pero han tenido razones para tomar decisiones que no fueron óptimas.

Para mí, si alguien ha estado en el negocio por un período de tiempo, digamos 3-4 años o más, y no ha tenido su código puesto en producción y luego lo apoyó después del lanzamiento, tendría preguntas. Puede ser un gran codificador, un código y una sintaxis magníficos, pero al final del día el código debe usarse o no es más que líneas bonitas en un IDE. He visto un código atroz que funciona y hace el trabajo, y ha producido beneficios para el negocio durante años y años, y también proyectos excelentes y bien codificados a medio terminar que simplemente no fueron a ninguna parte. Si puedes mezclar los dos juntos, maravilloso, pero si no puedes, cruzaré la línea de meta cualquier día.

Los no aprendidos …

• Constantemente tienen que “parchear” el mismo código de producción una y otra vez, a pesar de que no hay nuevas características o cambios en las interfaces.
• Cree varios errores nuevos “arreglando” errores existentes.
• Tenga seguridad laboral porque * nadie * se atreve a tocar su código, y el sistema no sobrevivirá una semana sin ellos.

Mientras tanto, los sabios …

• Detecte los errores más importantes antes de implementar en producción.
• Elimine errores sin romper otras partes del sistema.
• Rara vez tiene que volver para mantener un proyecto anterior una vez que ha estado en producción durante un tiempo.
• Son los primeros en ser despedidos porque se puede confiar en que sus cosas continuarán trabajando mucho después de que se hayan ido. 🙂

Llámame cliché, pero me gusta ver la codificación como un arte. En este sentido, encontrará que ningún programador necesariamente lo hace mal, pero algunos pueden hacerlo de manera más eficiente. Esto se adapta bien a los aficionados a la programación, pero en la industria este estándar no se mantendrá bien.

Cuando veo la codificación como una profesión, creo que cualquiera que tenga una verdadera pasión por ella hará el corte. Fui a la escuela para programar y terminé mi clase de C # en la primera semana de tomar el curso. Todos con los que había ido a la escuela simplemente estaban interesados ​​en el dinero y tenían poca idea de cómo funcionaba una computadora, y aquellos que sí tenían no tenían idea de cómo programar. Principalmente, si el dinero y el éxito en la vida son sus únicos motivos como programador, nunca se verá impulsado por sus propios intereses a aprender más y mejorar usted mismo. Si no eres un buen programador, si lo tienes, eventualmente encontrarás el camino. Desafortunadamente, esta industria está llena de figuras muy rígidas y de personas que lo examinarán constantemente, pero esta es nuestra forma de forzarnos unos a otros para que eventualmente podamos llevarnos bien.

Básicamente, usted es o tiene una buena oportunidad de ser un buen programador si lo encuentra realmente interesante y tiene la ambición y la dedicación de aprenderlo POR SU PROPIO TIEMPO. Nadie aprende a programar de la noche a la mañana y nadie nace mágicamente con este talento. Es trabajo duro y dedicación. Si desea innovar la tecnología, primero tendrá que innovar usted mismo.

También estoy en desacuerdo con toda esta situación de “dogma”. He trabajado en un par de equipos y he visto un código muy pobre. Una mala convención puede provocar inestabilidad y un desarrollo más lento. Además, como seres humanos, lo que se entiende más fácilmente es, por lo tanto, más productivo. En mi trabajo actual, programo en JS usando Node.js / Express. Podría desarrollar esto en C y hacer que sea mucho más difícil y largo de desarrollar, pero eso no sería a favor mío o de la empresa para la que trabajo. La productividad es muy importante. Estoy de acuerdo en que reescribir el código para que sea más estético no es apropiado, pero en algún momento ayudaría a limpiar el código. Si tiene un desorden de código sin comentarios, será difícil de leer, y especialmente desalentador para los programadores más nuevos que aún están desarrollando sus habilidades.

Al final de la historia, eres un buen programador si estás interesado en la programación y dedicas tu propio tiempo a aprender más constantemente .

Cuando un desarrollador escribe código como si nunca tuviera que ser mantenido por nadie, nunca. El código debe escribirse con el pensamiento en mente de que alguna pobre alma tendrá que leer esto y comprender lo que está haciendo algún día.

Su código funciona.

Es decir, funciona dentro de un ámbito estrechamente definido, ignora todos los casos extremos y no está escrito de manera defensiva y resistente. Además, incluye muchos supuestos incorporados y contratos de código implícito, y no resiste bien la refactorización o los cambios de requisitos futuros.

Señales de advertencia: Métodos largos con múltiples ramas, demasiados parámetros para los métodos, dependencias concretas, dependencia excesiva en la tipificación débil y, como se mencionó anteriormente, contratos de código implícito e indocumentado.

Editado para agregar:

Por dependencias concretas, me refiero a no usar la Inversión de dependencia, o no codificar a las interfaces. En otras palabras, un método tendría una dependencia externa (a una base de datos, sistema de archivos o una conexión de red a otra computadora), lo que hace que el método no sea elegible para pruebas unitarias.

En cuanto a la dependencia excesiva en la conversión de texto débil, el ejemplo particular en el que estoy pensando es un método que toma un objeto para su parámetro, y luego internamente tiene una instrucción Select Case para bifurcar el código dependiendo del tipo de objeto

La programación ES un arte: crea una reacción en un sistema informático de la nada y la imaginación. Aprender a programar es como aprender a hablar. No puedes aprender a hablar un idioma específico si no sabes cómo hablar realmente. Pero saber hablar te permite aprender cualquier idioma. Desafortunadamente, hay demasiadas personas que simplemente repiten los ruidos que escuchan a otros sin saber lo que realmente están diciendo.

Los indicadores de no ser realmente un buen programador son innumerables e incluyen todos y cada uno de los que se enumeran aquí. Mi motivo favorito son aquellos que no se detienen a considerar y planificar las formas en que las cosas pueden salir mal y simplemente codifican un requisito singular sin pensar en posibles condiciones de error.

La persona no puede resolver ni siquiera problemas algorítmicos simples. Esto es una indicación de que el programador ha pasado la mayor parte de su carrera pegando llamadas API en lugar de resolver problemas computacionales.

1. Los programadores que no obtienen una comprensión profunda sobre la arquitectura de una aplicación antes de comenzar a codificar es un regalo muerto.

2. Programadores que diseñan y crean una aplicación con una arquitectura interna que es eficiente, segura, robusta, escalable pero imposible de mantener para el desarrollador promedio. (regla: debe suponer que todos los futuros mantenedores son de habilidad promedio solamente)

Creo que 2 también podría resumirse en algunas circunstancias como “uso excesivo de patrones de diseño”.

No he visto uno de los más infravalorados enumerados aquí … Comentarios!

Es muy fácil para (incluso algunos codificadores experimentados) descuidar completamente comentar su código. Los comentarios son importantes y aseguran que su código sea comprensible para otros que tengan que admitir su código. (futuro incluido).

Los minutos adicionales que acumulas mientras escribes tu código la primera vez pueden ahorrarte muchas horas tratando de descubrir qué fragmento hace qué. Y si un codificador no piensa que está muy adelantado en un proyecto, generalmente es una señal de que no ha pasado por el proceso suficientes veces o que no tiene la estandarización requerida para que el código supere cierto nivel.

Entonces, en conclusión …
Comentarios! Comentarios! Comentarios!

Las personas que no reconocen que la respuesta a su problema puede ser algo que no han encontrado antes.
Intentan hacer su propia solución “creativa y genial” con las herramientas que tienen, cuando un google rápido muestra que otras personas han pasado exactamente por lo mismo y han encontrado una solución mucho mejor .