Cómo identificar un buen programador

Estoy de acuerdo con Glyn Williams en que un buen programador se envía a una fecha límite en lugar de teorizar. Dicho esto, creo que una analogía más acertada sería la de un arquitecto en lugar de un artista. ¿Por qué?

Porque un buen programador también envía una solución elegante y eficiente. Creo que la mejor manera de identificar si un programador hace esto es con un primer día de prueba de trabajo con Devskiller.

Lo que pasa con el arte es que no siempre tiene que tener una función que no sea para comunicar una vista específica. El software, por otro lado, necesita realizar una función para ser de cualquier valor para cualquier persona. Después de todo, solo el uso más geek sería mirar una pieza de código únicamente por su belleza estética.

Claramente, los abogados de Oracle son las personas más geek alrededor

Pero puedes admirar una gran pieza arquitectónica por su belleza y eficiencia. Tome la gran terminal central de Nueva York y la forma en que recibe grandes volúmenes de personas rápidamente desde los trenes de nivel inferior hasta la calle. Los arquitectos evitaron las escaleras y en su lugar instalaron un sistema de rampas largas y anchas.

Fuente: Grand Central Terminal Ramp, Ciudad de Nueva York – Nueva Inglaterra perdida

En cuanto a las soluciones, es hermoso y eficiente, y se sigue usando más de 100 años después de su construcción, transportando a miles de personas todos los días sin necesidad de modificaciones de los planes originales.

Un buen programador debe producir un código como este, eficiente, funcional y hermoso. Entonces, ¿cómo se prueba para eso? Con un primer día de prueba de trabajo.

Vea, como señaló el ex vicepresidente senior de Operaciones de Personas de Google, Laszlo Bock, en Wired: “El mejor indicador de cómo se desempeñará alguien en un trabajo es una prueba de muestra de trabajo”. Y esto no es diferente para un programador de software . Piénsalo.

Para saber si una persona es un buen programador, debe saber cuán eficientes son en la creación de código elegante dentro de un plazo. No tendría sentido darles una pregunta abstracta como en una entrevista de pizarra, o simplemente concentrarse en producir una respuesta determinada como una prueba algorítmica.

En su lugar, coloque al programador en el mismo entorno que tendrán en el trabajo, incluido el acceso a todas las herramientas y recursos que normalmente utilizarían. Luego, hágales una tarea que tendrían que hacer en su primer día, establecer una fecha límite y ver qué ofrecen.

Por supuesto, la segunda parte es ver qué tan eficiente es su código. Después de todo, una solución realmente hinchada entregada a tiempo sigue siendo una solución hinchada. Para eso, necesitas un experto en el campo o un sistema como Devskiller.

La plataforma de Devskiller administra la prueba y luego evalúa el código automáticamente para no solo ver si funciona, sino también si lo hace de manera eficiente. La prueba se administra automáticamente, lo que ahorra el costoso tiempo de su equipo de desarrollo para realizar entrevistas técnicas. El resultado es que tiene la mejor indicación de si alguien es un buen programador.

Un buen programador es alguien que entiende el panorama más amplio de la programación. No solo desde una perspectiva técnica. Conocen múltiples métodos para resolver un problema y pueden elegir el mejor. Saben cuándo usar las bibliotecas / fuentes existentes y cuándo abordar un problema ellos mismos. Pueden equilibrar claridad y complejidad. Saben cuándo optimizar y cuándo no. Entienden que mantener el código desordenado es mucho más doloroso y lleva mucho más tiempo que escribirlo inicialmente. También entienden dónde esforzarse y cuándo renunciar a algo.

Una vez trabajé con un chico que se describió a sí mismo como un “hacker”. Conocía la programación y podía hacer las cosas, pero se negó a cambiar su actitud con respecto a los comentarios, el estilo y las convenciones de nombres. Básicamente, su código era un lío impenetrable, sin comentarios, de nombres de variables globales de una sola letra, nombres de funciones crípticas cortas y estilo no conformista incoherente. Eso es genial si trabajas solo y nadie tiene que ver lo que has escrito. Pero ese tipo de actitud no tiene lugar en MI equipo.

Llevaría a un amable programador que produce un código claro y lento a una estrella de rock egoísta que produce voces rápidas pero llenas de baches, cualquier día.

Las otras respuestas aquí son buenas.

Pero hay una serie de aspectos que me faltan para mencionar, y es bastante importante, y las consecuencias de la falta de este atributo tienen consecuencias negativas generalizadas más allá del mero código.

  • Ser abierto y aceptar la revisión de código.
  • Habilidad para soportar críticas negativas de trabajo.
  • Capacidad para escuchar los consejos de otros sobre un problema técnico o social y considerarlos seriamente.

No creo que nadie sea lo suficientemente inteligente o que tenga un conocimiento lo suficientemente profundo de cualquier tema para comprenderlo o anticipar todas las consecuencias de sus decisiones de diseño.

Incluso los proyectos muy pequeños necesitan supervisión y revisión por pares para asegurarse de que no cometas errores obvios, para asegurarte de que no solo estás escribiendo agujeros de seguridad al acecho, para asegurarte de que no solo estás escribiendo un código que nadie puede leer.

Muy a menudo veo personas que acuden a un espacio problemático, y creen que ya tienen la idea correcta, y es increíblemente difícil explicarles cómo su idea inicial es defectuosa en muchos escenarios, y es probable que desacrediten a los demás. Escenarios como ilegítimos sin seria consideración.

Estas personas simplemente repasan el código, dejando un rastro de destrucción a su paso por todas las cosas que rompieron, sin detenerse a considerar lo que podrían estar rompiendo.

Aprende a equivocarte, y abrázalo como tu amigo. Porque estar equivocado te enseñará cómo escribir mejor código. Estar equivocado y saber que estás equivocado te hará tener mejor software.

Hay muchos aspectos que definen buenos programadores vs malos. Estoy totalmente de acuerdo con la respuesta de Glyn. Además a continuación están las cualidades que creo que son ideales.

  • Código limpio que incluye sangría adecuada, funciones limpias.
  • Comentarios cuando y donde sea necesario.
  • Código de legibilidad . Viene con comentarios y también siguiendo la convención de nomenclatura relevante.
  • Pruebas unitarias . No me tomó mucho tiempo entender por qué la prueba de unidad es importante.
  • Manejo de excepciones .
  • Mecanismo de registro .
  • Escribir un archivo de configuración para permitir que todo tipo de ingenieros utilicen su código fácilmente.
  • Velocidad: aunque no es importante en todo momento, el envío de códigos a tiempo es un factor importante en los modelos ágiles. Por lo tanto, cumplir con los plazos es tan importante como escribir un buen código y seguir todos los pasos anteriores.

Muchos ingenieros piensan que la calidad de un programador, es su comprensión de algo complejo. Su dominio de las mejores prácticas. Su dominio de las metodologías asesinas…. Estos son lo que yo llamo “entradas”. Estas son cosas que los programadores ponen en un proyecto.

Los artistas no ven el mundo así. Los artistas tienden a juzgar a otros artistas por su obra. Hacen un juicio, no sobre la metodología sino sobre la salida solo. Ellos miran los resultados.

En mi opinión, los artistas tienen este derecho.

Debemos juzgar a los buenos programadores por los resultados:

¿Se envió el proyecto?
¿Se envió a tiempo?
¿Fue estable el programa? – y así. Porque esto es lo que importa más que las otras cosas.

Puedo escuchar a los ingenieros aullando en protesta. ¿Qué pasa con la calidad del código? ¿Qué pasa con la metodología de ? Reutilización, pruebas unitarias etc.

La cosa es que los buenos programadores usarán esas metodologías. Así como los buenos artistas emplearán el tipo correcto de técnica de pincel.
Pero la verdad es que también lo hacen los malos programadores y los malos artistas.

Buenas programadoras de barco. Los malos programadores se felicitan por las metodologías inteligentes, mientras que faltan fechas límite.

#polémico

Aquí hay algunas otras grandes respuestas sobre el trabajo en equipo, el proceso, las pruebas, el código claro, etc.

Quiero mencionar a un tipo llamado Art que tuve el privilegio de tener en mi equipo por un tiempo.

He encontrado que el código de las personas tiende a leer como piensan sus mentes. Las personas que piensan de manera organizada y expresan sus pensamientos claramente tienden a codificar todo lo que es bastante fácil de leer, entender y mantener. Las personas que rebotan en una conversación tienden a ser un código bastante caótico, que no se puede mantener, de hecho, que nadie más puede leer. Con suerte, se pone a prueba lo suficiente como para que funcione bien.

Tuvimos un problema espinoso de diseño, como surge un momento, y tuvimos una reunión de equipo para hablar sobre los problemas y cómo diseñarlos.

El arte no dijo nada, pero escuchó durante media hora. Salió y se dirigió a su cubo, y regresó en unos 20 minutos.

Dibujó una estructura en el tablero blanco, y toda conversación se detuvo. Lo que dibujó fue alrededor de 1/3 de lo complejo de lo que habíamos estado hablando, y fue inmediatamente evidente que había captado la verdadera esencia del problema y había diseñado el mejor enfoque posible. No había nada más que decir.

Su código también era estupendo. Funcionó, y usted podría leerlo y ver que funcionaría.

Era dulce, sencillo y brillante. (Y el único programador al que entro fue el que salió de CalTech).

Él es mi estándar de un gran programador.

En realidad, eso no es tan fácil. Es un poco como identificar a un buen artista o arquitecto de edificios. Puede intentar definir algunas métricas (uso de materiales, productividad, ingresos monetarios, reputación), pero eso no lo comprenderá completamente.

Mira su trabajo pasado. ¿Completaron esos proyectos a tiempo? ¿Los proyectos resolvieron los problemas para los que fueron construidos? ¿A otras personas les gusta trabajar con el programador? ¿Pueden otras personas entender fácilmente su código?

Si es así a todos estos, tienes un gran programador.

Esto no dice nada específicamente acerca de los programadores. Podría reemplazar “programador” con cualquier rol que tenga un resultado y no cambiaría el significado.

Sus criterios básicamente dicen “Un buen programador piensa como un gerente de proyectos”. Tengo mis dudas sobre su validez.

Los artistas casi hacen lo que en el mundo tecnológico conocemos como “únicos”. Eso no suele ser lo que hacen los “buenos programadores”.