¿Ayudando a los programadores junior a superar sus defectos? [cerrado]

¿Cuáles son sus quejas comunes sobre los desarrolladores junior que se unen a su equipo o con quién tiene que trabajar? Obviamente, son inexpertos, por lo que no puede esperar que lo sepan todo, pero ¿qué habilidades a menudo faltan inexplicablemente y cómo, específicamente, podemos ayudarlos a desarrollar estas habilidades faltantes?

No me refiero a habilidades interpersonales como "escuchar consejos", me refiero a cuestiones técnicas como (si corresponde):

• 'nunca has hecho SQL?'

• '¿Nunca has escrito una prueba unitaria?'

• 'no sabes cómo usar una línea de comandos de Unix?'

Cosas que no esperas - Me gustaría escuchar sus observaciones y técnicas para la enseñanza de nuevos programadores para superar estos inconvenientes específicos.

Sin saber qué es el control de versión o cómo usarlo correctamente .

Uno de los desarrolladores junior que ha estado en mi empresa durante varios meses recientemente tuvo que aprender los conceptos básicos de Subversion. Realmente me hizo estremecer ... ¿ha estado revisando el código para vivir proyectos todo el tiempo ... y no tenía idea de lo que estaba haciendo ...?

No hacer suficientes preguntas

Sé que son juniors, espero que cometan errores y simplemente no sepan cosas. Se podrían haber evitado tantos jodidos reales simplemente haciendo una pregunta en lugar de asumir algo. Honestamente, no puedo ser molestado lo suficiente.

Tuve TONELADAS de preguntas cuando comencé: preguntarles me salvó el trasero en varias ocasiones. Demonios, todavía tengo muchas preguntas ... Me gusta pensar que son mejores preguntas ahora.

Copie pegar y prueba y error en lugar de tratar de comprender los fundamentos subyacentes

Muchos desarrolladores junior copiarán el código que parece cercano, luego probarán casi al azar diferentes permutaciones de modificaciones por fuerza bruta hasta que encuentren uno que funcione. Si no sabe por qué funciona, es probable que esté introduciendo errores en los casos límite que alguien que lo entienda tendrá que limpiar más tarde.

Manteniendo su "primer borrador" de código

Cuando un desarrollador experimentado escribe una nueva función de cierta complejidad, comienza con un trozo que no hace más que compilar, luego reescribe para agregar comentarios de pseudocódigo de alto nivel para el algoritmo general, luego reescribe esos comentarios uno por uno con código real, agregando y eliminando código ficticio según sea necesario para la prueba, luego reescriba para eliminar la redundancia que surgió durante la implementación, y así sucesivamente en una serie de mejoras sucesivas e incrementales.

Los desarrolladores junior tienen una tendencia a escribirlo en una gran parte, luego hacen una depuración masiva de fuerza bruta. No les gusta eliminar una línea de código una vez que está escrita en el editor, y están tan contentos de que finalmente lo hayan hecho funcionar que detestan reescribir las mejoras no funcionales, pero ellos son los que deben hacerlo. así que lo más.

Creer que eres el primero en encontrar una situación.

Cada problema de programación que enfrenta ha sido enfrentado por otros, de alguna forma general. Hay mucho que aprender de programadores experimentados. Soy lo suficientemente mayor como para recordar programar antes de Google, y fue una mierda . Era aún peor cuando teníamos motores de búsqueda, pero todavía no había tanta información buena en la web. La programación ahora es mucho más productiva porque tiene acceso al conocimiento global en segundos. Las personas que no lo usan lo ignoran a su propio riesgo.

Editar :

Para ser claro, estoy no abogando copiar / pegar programación. Sin embargo, estoy seguro de que debe revisar el conocimiento existente antes de poder tomar buenas decisiones usted mismo.

Pensando que lo saben todo.

Tuve un jr. pasante que intentó resolver todo con javascript. Intentó explicar varios conceptos, pero siempre pensó que podía hacerlo mejor. Ahora renunció y estoy reelaborando un importante programa que creó para imprimir utilizando HTML en lugar de una tecnología lista para imprimir como PDF. Sin mencionar un montón de otros problemas importantes.

La lección es pedirles a las personas mayores una orientación general importante al principio de un proyecto, no se salgan de la arquitectura sin ayuda. Puede escribir el código y los detalles solo, pero asegúrese de utilizar al menos la tecnología adecuada.

Raramente me molesto cuando los jóvenes no saben lo básico, no se les enseñan habilidades de la industria como SCC en la Universidad. Es el trabajo de los desarrolladores senior enseñarles. Solo me molestan los enfrentamientos de personalidad. Pero me molestan más los desarrolladores senior que no conocen los conceptos básicos.

No queriendo avanzar en su conocimiento, en su lugar, tomar el camino de menor resistencia.

El otro día, un pasante junto con el diseñador gráfico (que es sorprendentemente experto en programación) solicitó ayuda porque tuvieron problemas para implementar algo en jQuery; el cierre puede ser doloroso si no puede verlo venir.

Me senté con el interno y le expliqué exactamente qué estaba mal y por qué. Arreglamos el error, luego señalé varias mejoras adicionales que podrían hacerse ("ya que estoy aquí") y terminamos reescribiendo la función culpable en 10 líneas en lugar de 20 y sin errores. Después de responder cualquier pregunta, satisfecho de que todo estaba bien en el mundo una vez más, me fui.

Al día siguiente, el interno llegó con una pregunta que reveló que "um, quería hacer algunos cambios y reescribió la función a mi manera porque me resultaba difícil de entender" (en su mayor parte deshaciendo mis mejoras).

Podría haber intentado más en su lugar (hacer preguntas adicionales, leer sobre los conceptos que mencioné), el código tan corto nunca puede ser tan difícil de entender, o tomar la salida fácil. Me entristece cada vez que veo a alguien hacer lo último.

No entiendo POO. Lamentablemente, esto es mucho más común de lo que la mayoría de nosotros probablemente nos damos cuenta.

Saber cómo crear una clase, una clase abstracta, una interfaz o incluso conocer el polimorfismo es una cosa; comprender cómo usarlos adecuadamente en beneficio de su programa es otro .

Si desea evitar esta, encontré estas preguntas y sus respuestas esclarecedoras:

• Olor de código: Abuso de herencia - Los peligros de la herencia
• ¿De dónde viene este concepto de "composición del favor sobre la herencia"? - Los peligros de los mantras sobre evitar la herencia

Sin saber lo que no sabes, y en la ignorancia pensando que lo sabes todo.

(Y su primo cercano, no queriendo preguntar).

En parte, esto es una cuestión de organización: una inducción entrante adecuada contribuiría en gran medida a evitar que algunas de estas cosas se conviertan en problemas. Pero muy pocas empresas tienen tiempo o personas disponibles para una inducción entrante, algo que debería llevar desde unos pocos días hasta unas pocas semanas y saca a los desarrolladores de su trabajo. Entonces tenemos que apagar los fuegos en su lugar.

Estoy sorprendido de cuántos programadores junior relativamente nuevos de un programa CS son débiles con los algoritmos. La mala elección del algoritmo puede no destacarse realmente en la línea de aplicaciones comerciales, pero cuando se procesan miles de millones de solicitudes de servicio web por día, realmente importa.

Aquí hay una pregunta de entrevista que uso que casi todos los programadores Junior pierden y que resalta el problema:

Escribe un código que calcule el enésimo número de Fibonacci .

Casi siempre van por lo más alto, escriben lo obvio pero ineficiente

int Fib(int n)
{
    if (n == 0) return 0;
    if (n == 1) return 1;
    return Fib(n-2) + Fib(n-1);
}

Cuando se me pide que comente sobre la complejidad algorítmica, generalmente obtengo "es peor que O (N) ... uhm ... O (N logN)". En realidad es (mucho) peor que eso ...

¡Hacer sangría de código hacia atrás!

Por supuesto que no es muy "típico". Nunca podría creer que fuera posible, pero como escribiría un desarrollador normal

try {
    switch(action){
        case case1:
            ...
            break;
        case case2:
            ...
            break;
        default:
            break;
    }
}
catch(Exception e) {
    e.printStackTrace();
}

ella escribiría como (¡Dios, todavía me parece imposible!)

            try {
        switch(action){
    case case1:
...
break;
    case case2:
...
break;
    default:
break;
        }
            }

¿No es frustrante?