¿Qué hace a un buen ingeniero de software?

He entrevistado literalmente a cientos de ingenieros de software en las últimas dos décadas para mis equipos en Microsoft, Adobe, Spotify y otros lugares.

Con los años, me he centrado en algunas cosas que considero vitales para cualquiera que se una a mi organización. Este es el tipo de cosas que valoro como gerente de contratación, por supuesto. Otros tendrán sus propios criterios críticos.

Hay en un orden de prioridad aproximado.

1) pragmatismo
No me molesto con preguntas de programación difíciles o difíciles diseñadas para evaluar un rincón de tu conocimiento o algunas curiosidades. En cambio, hago una pregunta muy simple. Algo que cualquiera podría hacer. Entonces lo complico. Y complicarlo de nuevo. Y otra vez. Busco el punto donde ya no puedes adaptar tu primera respuesta. Lo que quiero saber es que estás dispuesto a tirar tu primera respuesta cuando ya no tenga sentido. Te sorprendería saber cuántos ingenieros piratearán algo que nunca funcionará cuando podrían tirarlo a la basura y hacer algo mucho más simple en una cuarta parte del tiempo.

2) interés
¿Realmente te gusta escribir código todos los días? ¿Lees blogs de programación por diversión? ¿Trabaja en sus propios proyectos de codificación fuera del trabajo? Si este va a ser su trabajo, quiero a alguien que esté encantado de que les paguen por escribir software. No alguien que prefiera estar haciendo otra cosa.

3) Actitud / humildad
He trabajado con personas brillantes que son idiotas. Por cada pulgada que hicieron avanzar el producto con su innovación o genio, hicieron que el proyecto retrocediera dos pulgadas al ser imposible trabajar con ellos. Quiero a alguien que esté allí para mejorar el equipo, no a alguien que sienta que todos solo necesitan hacer lo que se les dice.

4) inteligencia
Sí, necesitas ser inteligente. Escribir software es parte del arte y requiere creatividad, pero también tiene que ver con la resolución de problemas y la capacidad intelectual para descubrir por qué esta cosa falla, pero solo el martes cuando la luna está llena.

5) Lenguajes de programación / experiencia de dominio
He trabajado profesionalmente con una docena o más de lenguajes de programación. Algunas ya ni las recuerdo. Si bien tengo mucha profundidad en algunos de ellos a través de años de experiencia, he podido aprender a otros según sea necesario para adaptarme al proyecto. Preferiría ver a alguien con alguna habilidad en más de un idioma porque eso muestra algo de amplitud y disposición para aprender, pero mientras puedas codificar y ser inteligente (ver # 4) probablemente puedas aprender cualquier idioma que estemos trabajando. en razonablemente rápido. Contrato a largo plazo, podemos tomar un poco más de tiempo para ponerlo al día si le queda bien. Del mismo modo con la experiencia de dominio. Si tienes una aptitud, podemos enseñarte.

Sin embargo, tengo algunas advertencias para el n. ° 5:
Si estoy contratando para un puesto de alto nivel que requiere conocimiento de dominio, sí, eso está en los requisitos de trabajo, por lo que debe traer eso. Sin embargo, aún necesitaría manejar 1-4.

En idiomas, hay una advertencia importante. Si estamos haciendo C ++ o C, necesitarás tener algo de experiencia allí. Si alguna vez ha trabajado con lenguajes de alto nivel recolectados de basura, simplemente tomará demasiado tiempo realmente ponerlo al día. Lo he intentado muchas veces en el pasado y me he dado cuenta de que generalmente no vale la pena el esfuerzo.

La mejor manera de juzgar la habilidad de un desarrollador es hacer que escriba un código.

Pero hay un problema..
El código enviado a un desafío de codificación NO es el mejor código del desarrollador. Es su código que se realizó bajo la presión de un proceso de contratación.

Podríamos simplemente revisar el código, ver si funciona, ver si el diseño coincide con nuestra propia idea del diseño y luego decidir en base a eso si son buenos.

¿Pero es un buen enfoque?

Le sugeriré que no hay una solución correcta o incorrecta. El código no es realmente código, es mucho mejor que eso. Es una colección de pistas.

Estas pistas pueden pasarse por alto fácilmente. Quiero mostrarte cómo aprovecharlos al máximo. Incluso:

• Cómo detectar rasgos de un buen desarrollador en cualquier código (bueno o malo)
• Cómo detectar los olores del código vinculados con malas prácticas de desarrollo y desarrolladores potencialmente malos
• Qué hacer ante un código muy promedio (Sugerencia: este es el 90% de todas las presentaciones)
• La mejor manera de superar nuestros prejuicios personales al revisar (incluso si nuestro camino es mejor)

Pero primero, déjame contarte una pequeña historia de hace unos años:

(Esto fue publicado en nuestro blog y escrito por uno de nuestro equipo de revisión de élite: Andy Davis)

Una vez trabajé con un ‘Desarrollador de software en prueba’ que me dijo que hace algo llamado MDD. Estaba intrigado, ¿qué es MDD? Estoy en TDD, BDD e incluso ATDD, pero ¿qué es MDD?

“El desarrollo derivado del trabajo”, dijo, “escribo el código de una manera que solo yo puedo entender. De esa manera mantendré mi trabajo todo el tiempo que quiera y continuaré pagando mi hipoteca ”.

Él rió. Todos nos reímos.

El comentario fue hecho en broma. Lo desafortunado es que resultó ser cierto.

No pasó mucho tiempo antes de que buscara una nueva compañía para pagar su hipoteca.

Si solo hubiera hecho un desafío de codificación, ¿tal vez podríamos haber detectado MDD antes?

Como desarrolladores, somos las mejores personas para revisar los envíos de desafíos de codificación. Entonces que podemos esperar?

Consideremos algunos de los tipos de presentaciones que recibiremos como revisores:

1. Buen código limpio por un buen desarrollador
2. Código malo
3. Código promedio

Buen código

¿Qué hacemos cuando recibimos un código realmente bueno? Pan comido. Elogie todos los aspectos positivos, déle una excelente revisión.

Por otro lado. Es completamente plausible que un mal desarrollador del ‘mundo real’ se haya vuelto bueno para codificar desafíos, pero es bastante raro.

Código malo

Código completo de espagueti, que no funciona y no tiene sentido. Pan comido. Elija algunos de los principales aspectos negativos, brinde comentarios constructivos y siga adelante.

Esto me recuerda a dos de mis experiencias de revisión Geektastic. Una presentación dejó 3 de los 4 métodos completamente sin implementar (luego descubrí por qué, no se almacenaron datos en el primer método, por lo que sería imposible recuperarlos con los otros 3). La otra presentación extraña fue una aplicación de Windows completa cuando el desafío solo pidió implementar 4 métodos pequeños.

Ninguna de esas soluciones tenía pruebas y ninguna de ellas funcionó. Así que ambos eran obvios, puntos nulos.

Código promedio

Esto nos deja con un código promedio. Estos son los más difíciles de marcar y desafortunadamente los más comunes.

Es fácil descartar este código como código incorrecto, porque no es tan fácil de leer y seguir como el “código bueno”. Y no es una zona de desastre como el “código incorrecto”.

Entonces lleva un poco más de tiempo. Pero es por eso que estamos aquí, es por eso que necesita nuestro cerebro de desarrollador. Podemos desbloquear el código y generar positivos y negativos.

Para hacerle justicia, debemos pasar por alto la comparación con una solución perfecta. Lo que nos interesa es detectar pequeñas gemas de las cosas buenas y algunos olores de las cosas malas (vea el libro de Martin Fowler para una introducción a Code Smells).

Estas pequeñas gemas y olores son los factores que nos darán una idea más amplia.

Para el código promedio, DEBEMOS interesarnos en la imagen más grande.

La contratación cuesta dinero, por lo que debemos mirar más allá de las declaraciones como “es un código basura”.

Si podemos encontrar un diamante en bruto, un desarrollador productivo, esto tendrá un gran ahorro para la contratación de la empresa y este valor se reembolsará una y otra vez.

Los desarrolladores productivos están al acecho dentro de los envíos de código promedio, así como en los envíos de código buenos, solo tenemos que encontrarlos.

Todos sabemos que contratar a un mal desarrollador puede ser destructivo para el equipo, el código y la compañía, por lo que es bueno ser cauteloso. Sin embargo, perder un gran desarrollador es potencialmente un riesgo aún mayor, especialmente en la “etapa de pantalla”. Detectar accidentalmente a alguien podría significar decenas o cientos de personas más que necesitan presentar una solicitud y pasar por el proceso antes de encontrar a alguien tan bueno nuevamente.
Steve Jobs dijo una vez:

“La diferencia entre el mejor trabajador en hardware de computadora y el promedio puede ser de 2 a 1, si tienes suerte. Con automóviles, tal vez 2 a 1. Pero en software, es al menos 25 a 1. La diferencia entre el programador promedio y uno excelente es al menos que ”

Esto nos dice que debemos buscar más señales de un buen desarrollador. Esto mitigará el riesgo de detectar accidentalmente ese desarrollador 25x. Le debemos al arrendatario buscar pistas de que podrían tener un potencial 25x (o incluso 5x). Afortunadamente somos humanos, por lo que podemos hacer esto.

¿Cuáles son algunas pistas que apuntan a un buen desarrollador?

Para encontrar buenos desarrolladores, primero debemos acordar las cosas que hacen que un buen desarrollador:

1. Un buen jugador de equipo
2. Eficiente para resolver problemas
3. Puede trabajar con código greenfield y brownfield
4. Utiliza las mejores prácticas.
5. Se preocupa por el valor del software para la empresa.
6. Entiende que el software es costoso, “sin código” es “buen código”
7. Puede emparejar el programa y arrancar algo solo
8. Siempre esta aprendiendo

Dado que nos estamos centrando únicamente en el código y los desafíos, podemos destilar esta lista para:

Escribe código que se puede mantener

El código que se puede mantener es: –

• Código que funciona *
• Código que comunica su intención
• Código que es fácil de cambiar

* La mantenibilidad del código es lo principal que busco al marcar un desafío de codificación. A veces ni siquiera ejecutaré el código porque el hecho de si funciona al 100% o no es tan importante como si pudiera recoger el código y hacer un cambio rápido para que funcione.

Código que funciona

Hay varias formas de saber si el código funciona.

• El desarrollador dice que sí
• Probarlo manualmente
• Tiene pruebas automatizadas de algún tipo que demuestran que funciona

La prueba más barata son las pruebas automatizadas que viven junto al código. Las pruebas escritas por el desarrollador en el momento en que se escribió el código y se pueden ejecutar en cualquier momento para comprobar si el sistema aún funciona. Se les conoce comúnmente como pruebas unitarias. Sin embargo, también hay pruebas de integración y pruebas de aceptación, pero no voy a entrar en eso aquí, llamémoslas Pruebas.
Las pruebas demuestran que el código funciona como se supone que debe hacerlo. Sin pruebas, podemos descifrar el código y no saber si lo hemos descifrado hasta que se descubra el error en producción o, si tenemos suerte, un probador manual.
Entonces, una solución de desafío de codificación que se envía sin ninguna prueba o con rutas de código escritas que no tienen pruebas, es una GRAN ALARMA. Como revisor, no puedo saber si el sistema funciona sin ejecutar manualmente varios escenarios, o si soy sensato, escribiendo pruebas que cubran todos los requisitos.

Aquí hay una guía simple

1. Buenas características, funciona y tiene pruebas que prueban que funciona
2. Malos rasgos, no funciona, funciona, PERO no tiene pruebas, no funciona, Y no tiene pruebas

El código que funciona pero no tiene pruebas es malo porque

1. Podríamos cambiar una línea de código (por accidente o intencionalmente) y romper el código. Nadie lo sabría (de todos modos, no de inmediato. Y cuanto más se acerca un error a la producción, más costoso es descubrirlo y solucionarlo)
2. No hay una manera fácil de entender lo que se supone que debe hacer el sistema actualmente (es decir, la documentación)

Código sin pruebas, oculta sus intenciones. La intención está bloqueada de forma segura en la cabeza del desarrollador original, que desafortunadamente no sirve de nada en un entorno de equipo.

¿Cómo sabemos si el código comunica su intención?

Hay una cita maravillosa que leí en el blog de Jeff Atwood, pero aparentemente se origina un poco antes.

Siempre codifique como si la persona que termina manteniendo su código es un psicópata violento que sabe dónde vive.

O poner menos dramáticamente. Escriba el código para el mantenedor, no para usted. Si recibimos algún código, esperamos que hayan hecho lo mismo por nosotros, ya que facilitará mucho nuestro trabajo.
La forma más sencilla de detectar el código que comunica la intención son:

• Bien probado
• Denominación expresiva (de todo, incluidas las pruebas)

Bien probado

En el contexto de un desafío de codificación, aquí es donde comenzamos a otorgar puntos por trabajos. Incluso si el código no funciona del todo, si la intención se expresa en las pruebas, significa que los requisitos están documentados con el código de forma activa y ejecutable.

La documentación ejecutable que cubre todo el sistema significa que cambiar el código es un simple caso de cambiar la documentación (la prueba) en el lugar correcto. Esto deja una prueba fallida y permite un cambio de código dirigido sin temor a que el resto del sistema se rompa.

Ese es un ejemplo de Test Driven Development (TDD): para obtener más información, lea Test Driven Developer by Example – Kent Beck

Los desafíos de codificación que se completaron con TDD son bastante fáciles de detectar. Tendrán un conjunto de pruebas de regresión que se pueden ejecutar (ya que este es un efecto secundario de conducir el código). Porque el código será y el código en sí será naturalmente más estilo API, con dependencias menos difíciles y con l

TDD no es la única forma de tener un código bien probado (y, por lo tanto, funcionando). Un candidato puede llegar a esto sin escribir primero las pruebas. Pero si no escriben las pruebas en absoluto, entonces esa es una historia diferente. Y NO estoy de acuerdo en que TDD esté muerto por cierto, incluso si DHH grita en voz alta al respecto.

Buen nombre

No hay mejor manera de expresar la intención que usar variables, objetos y funciones bien nombrados. Las variables nombradas con una sola letra como a, b, c, x o el molesto hábito geek de foo / bar son absolutamente inútiles para expresar la intención. Además, en estos días no es necesario acortar las palabras, no tenemos mucho límite de ancho de pantalla, no hay nada peor que ver variables como fname lname.

Un nombre muy pobre que vi recientemente fue

foreach (var itemExists in personList) {…}

Se podría pensar que itemExists era un booleano, pero no lo es, era una cadena del nombre de la persona. El código dentro del bucle for usó esa variable itemExists. Obviamente, la línea de código no se leía bien: una simple corrección de nombre para la persona ordena todo el asunto.

foreach (nombre de var en personList) {…}

Hablamos anteriormente sobre la importancia de escribir exámenes, y los exámenes son un excelente ejemplo de dónde es extremadamente importante nombrar bien. Considere los dos siguientes nombres de métodos de prueba: –

test_name_splitter () {…}

splitting_a_name_with_a_single_space_splits_it_into_first_and_last_name () {…}

Para alguien nuevo en este tipo de nombres, el segundo parece estúpidamente detallado. Si es usted, tómese el tiempo para pensarlo. El nombre del método es nuestro único intento de expresar la intención a la siguiente persona para mantener el código. Por lo tanto, es lógico que este nombre de método sea una oración y la oración exprese la intención lo mejor que pueda.

Como el código cambia, podemos pensar en un próximo requisito. Tal vez sea dividir nombres con dos espacios en primer nombre y apellido. ¿Cómo encajaríamos en el estilo de nombre test_name_splitter ()? test_name_splitter2 ()? una afirmación adicional dentro de la misma prueba? O tal vez una nueva prueba:
splitting_a_name_with_two_spaces_splits_it_into_first_middle_and_last_name () {…}

Aquí es donde las pruebas comienzan a ser poderosas. La documentación comienza a surgir. Además, esta documentación está en vivo con el código, si el código cambia, entonces la documentación cambia (siempre que el responsable del software sepa lo que está haciendo).

A algunas personas les gusta ejecutar generadores de documentos en la parte superior de los nombres de las pruebas, pero para ser honesto, eso es solo un escaparate, no se necesita un documento a nivel de código. Es mejor guardar estas cosas en el código únicamente para que los desarrolladores encuentren y cambien el código con confianza.

Comentarios

Los comentarios son algo de lo que deberíamos hablar.

Históricamente, se pensaba que los comentarios eran buenos. Frases como “Todo el código debe ser comentado” se usaban para anillarse y en algunas compañías incluso se podían obtener advertencias oficiales o ser despedido si no comentaba su código.

En la actualidad, es más probable que escuchemos lo contrario. Podría decirse que una regla general de “no se permiten comentarios” es una mejor regla, ya que nos obliga a nombrar bien las cosas y hacer que el código sea legible en lugar de simplemente lanzar un bloque de comentarios sobre código confuso.

La solución real es solo usar un comentario si realmente necesita un comentario y si ese comentario tiene un propósito real.

// esta no es la forma obvia de hacerlo, pero la forma obvia no funciona por la razón X
GetPerson ();

El ejemplo de comentario anterior tiene un propósito. Sin embargo, lo siguiente no sirve para nada.

// inicializa una nueva instancia de objeto Person
Persona persona = Persona nueva ()

Este comentario no está mal, es solo basura. No proporciona más información que la línea que decora.
Sin embargo, la principal desventaja de este tipo de comentarios es que pueden engañarnos, tome este ejemplo de uno de los desafíos de codificación que revisé recientemente

+ // si no se encuentra, devuelve nulo
+ if (encontrado) devuelve nulo;

El comentario me dice exactamente lo contrario de lo que hace: claramente el desarrollador lo volteó en algún momento, estoy seguro de que fue correcto cuando se escribió por primera vez. Pero antes de que se registrara (se enviara), no estaba sincronizado con el código. Afortunadamente, este fue fácil de detectar, pero imagina una gran base de código con cientos de ejemplos de esto, ¡qué campo de minas!

Consejo: si cree que necesita comentar el código para explicar lo que hace, considere cambiar el nombre de algunas de las variables o envolver la funcionalidad en una nueva función o clase bien nombrada; ahora vea si ese comentario aún es necesario. Continúa, borra ese comentario, te reto.
Debe haber más cosas a tener en cuenta?

¿Qué más?

Hemos hablado sobre Naming, Comentarios, Código que funciona.

¿Por qué no hemos tocado los patrones de diseño, la inmutabilidad, los tipos de valor, los modelos de objetos y la comprensión adecuada de los principios de SOLID?

Bueno, esos son geniales, pero esos envíos se encuentran dentro de la categoría de “Código de buena limpieza que funciona” y esos envíos serán fáciles de detectar antes de llegar a ese nivel de detalle.

¿Pero debe haber más cosas malas? Sí, claro que la hay. Pero nuevamente será bastante obvio antes de que necesites llegar a ese nivel.

Para el registro, aquí hay algunos otros olores a tener en cuenta:

1. Código de procedimiento largo, sin ningún modelo de objeto (OO)
2. Abuso primitivo (string e int para todo)
3. Código comentado (¿por qué comentado?)
4. El objeto de Dios (general_helper)
5. Las pruebas que no funcionan debido al entorno, por ejemplo, se han codificado contra un servidor y necesitan una configuración específica que la prueba en sí no hace
6. Cambie las declaraciones (lo que implica una posible violación de OCP)
7. La nueva palabra clave en el medio del código (lo que implica una infracción DIP)

¿Suficiente sobre el código?

Volvamos nuestra atención a nosotros mismos y pensemos en la mentalidad del revisor y cómo entrar en ella.

La mentalidad que deberíamos tener como revisores de código Algunos candidatos pensarán en cosas que otros no.

Incluso pensarán en cosas que no pensamos en absoluto. Cuanto más marcamos el mismo desafío, más comenzamos a aprender sobre él y más material tenemos en nuestros bolsillos para marcar a las personas. Esto es muy injusto y, lo que es más importante, es probable que haga exactamente lo que no queremos: descartar a los buenos desarrolladores.

Entonces, ¿cuál es la mentalidad más importante al revisar una presentación de desafío?

Respuesta: empatía.

El hecho de que nosotros, los seres humanos, hayamos sido elegidos para marcar la sumisión es porque podemos ver cosas que una máquina no puede. Podemos darle al candidato el beneficio de la duda y ponernos en su lugar. Podemos pasar por alto las cosas que necesitan pasar por alto y tenemos el potencial de ver lo que el desarrollador estaba tratando de hacer, en lugar de lo que realmente hicieron.

Un marcador de máquina necesitaría algo de inteligencia artificial seria para tratar de descubrir las cosas que podemos resolver en solo 1 minuto de revisar el código.

Por lo tanto, es importante que no comencemos a actuar como máquinas para decidir si es correcto o incorrecto. Va mucho más profundo que lo correcto o incorrecto.

La forma más sencilla de hacer esto es hacer el desafío nosotros mismos (en las mismas condiciones que los candidatos). Hacemos esto, no para encontrar la solución ideal, sino para hacernos darnos cuenta de que no encontraremos el código perfecto. Probablemente ni siquiera se nos ocurra un código con el que estamos contentos, y mucho menos un revisor. Nos comprometeremos, es posible que no lo terminemos, e incluso podríamos hacer un desastre completo, sucede. Días después nos daremos cuenta de algo que es mejor que la forma en que lo hicimos, tendremos la necesidad de cambiar nuestra solución. NO DEBEMOS CAMBIARLO.

Una vez más, esto lleva lentamente a tratar a un candidato de manera injusta y a descartar candidatos potencialmente decentes.

A nuestros cerebros les gusta cambiar nuestros recuerdos, con el tiempo comenzaremos a creer que hicimos una mejor solución de la que realmente hicimos y utilizaremos esto injustamente contra los candidatos que estamos marcando.
Afortunadamente, hay una manera fácil de salir de esta trampa.

Guarde una copia de nuestro primer intento de solución, incluidas todas sus deficiencias, y haga un acuerdo con nosotros mismos de que no cambiaremos ese código.

Cada vez que recibimos un desafío de revisión, deberíamos tomarnos 30 segundos para analizar nuestra propia solución.

Esto nos devolverá a la mentalidad abierta y justa y nos permitirá bajar de nuestras torres de marfil. Se lo debemos al candidato y al arrendatario.

Somos parciales: ¿qué debemos hacer?

Tenemos opiniones fuertes y creemos que nuestras opiniones son correctas. La verdad es que podríamos serlo, pero estos puntos de vista no siempre nos ayudarán cuando revisemos los desafíos del código.

Las opiniones sobre grandes temas como SOLID y patrones de diseño están bien. A menudo se nos paga por nuestras opiniones y experiencia sobre estas cosas, así que esto no es de lo que estoy hablando.

De lo que estoy hablando es de sugerir que las preferencias superficiales son mejores de una forma que de otra.

Ejemplos

• Llaves de apertura {en la misma línea o en una nueva línea
• Sangría 4 espacios en lugar de 2
• Espacios antes o después de varias construcciones de código
• Convenciones de nomenclatura (como under_scores o camelCase)
• Sentencias if / else de línea única
• Usando una línea de código alternativa que hace el mismo trabajo
• Usando un marco alternativo que hace el mismo trabajo
• No necesitamos comentar sobre preferencias personales (o incluso de equipo).

Podemos averiguar más adelante si un desarrollador está abierto a hacerlo de la manera en que lo hace el equipo.

Es difícil de hacer, pero tenemos que resistir el impulso de escribir el comentario de revisión sugiriendo que una forma es mejor que la otra cuando todo se reduce a una preferencia.

Recapitulemos y terminemos

Un buen código probablemente significa que son buenos: un código limpio, bien probado, similar a la producción que cubre muchos o todos los requisitos significa que son buenos. Sin plagio, es poco probable que sean un mal desarrollador que de alguna manera sea un especialista en desafíos de codificación súper tonto, e incluso si ese es el caso, se descubrirán en la siguiente etapa.

Un código terrible que no funciona y que no tiene ningún sentido probablemente significa que son malos. Sin embargo, sea constructivo, es muy posible que sean jóvenes y tengan pasión por aprender mejores formas, incluso si el código le dice que lo son. mal en este momento.

El código promedio (y a veces menos que el promedio) no significa necesariamente que sean un desarrollador terrible. Hay cosas que se pueden encontrar en un código incorrecto que significa que el código no es tan malo … por ejemplo, pruebas que expresan la intención incluso si el código no funciona del todo, buenas variables y nombres de funciones, la decisión de usar un modelo de objetos, pensamientos sobre DRY , KISS y la regla del boy scout, hay muchas cosas potenciales para elegir: no le dé un ‘no’ general solo porque el código no fue perfecto o fue un poco difícil de entender.

Haga nuestro mejor esfuerzo para buscar lo positivo: la contratación es costosa, encontrar un diamante en bruto es extremadamente valioso. Incluso los grandes desarrolladores no escribirán código sorprendente bajo la presión de un proceso de contratación. Date cuenta de eso y comienza a buscar cosas buenas. Cuando se critica el código, es demasiado fácil entrar en el modo negativo de solo encontrar fallas. No dejes que lo positivo pase desapercibido. Comenta los aspectos positivos. Haz una lista de los aspectos positivos. Cuando los aspectos positivos se colocan junto con los negativos, el envío del código puede no verse tan mal como pensamos al principio.

Empatía: no somos máquinas, podemos ponernos en el lugar del candidato. Deberíamos intentar el desafío nosotros mismos y conservar una copia de esa solución para siempre. Debemos referirnos a él para encajar nuestras mentes en la apertura y la justicia necesarias al marcar un desafío.

Pase por alto nuestros propios prejuicios: no le gustan los guiones bajos, está bien, no significa que el candidato esté equivocado, y no tiene que decirles que lo prefiere a su manera sin guiones bajos, a pesar de que los guiones bajos son malos :).

Finalmente…

Ser humano

Recordemos que somos humanos. Somos seres humanos revisando el código de otros seres humanos. Tener una experiencia de persona a persona. Esta es la oportunidad de aprovechar el beneficio de la duda, para encontrar esos diamantes en bruto, especialmente si el código es menos que ideal.

He realizado muchos envíos de código donde mi código era mucho menor que el mejor, pero aún así me contrataron y aún hice un gran trabajo para el cliente. También he sido excluido y, en algunos casos, ignorado por completo cuando quería comentarios, estoy seguro de que tú también.

Igualmente, he visto y revisado cientos de piezas de código. He visto algunas sorpresas absolutas y he visto algo de elegancia pura (y todo lo demás). He sido amable, he sido grosero, e incluso he recibido una crítica completamente errónea hasta el punto de avergonzarme, pero sucede que, después de todo, somos humanos.
Hagamos una parada. Repasemos los desafíos de codificación de la manera correcta, con una mente abierta.

Una licenciatura en Ciencias de la Computación es el grado que * esperaría * de alguien que trabaja como ingeniero de software (al menos aquí en los EE. UU.). Aquellos con graduados en Ingeniería Eléctrica e Ingeniería en Computación a menudo también se encuentran trabajando como Ingenieros de Software, sin embargo, esos títulos se centran más en hardware. También encontrará personas autodidactas sin título o no relacionadas, por supuesto.

No hay un examen que uno tome para llamarse ingeniero de software. También hay muchos títulos de trabajo en tecnología que se utilizan de manera diferente por diferentes personas. Entonces, la cuestión de cuándo se le permite llamarse ingeniero es tan abstracto como cuando se le permite llamarse artista.

En cuanto a qué estudian los estudiantes de CS, un programa universitario acreditado en realidad tiene pautas razonablemente estándar: Licenciatura en Ciencias de la Computación

Los grandes ingenieros han internalizado la idea de que el panorama tecnológico es enorme y vasto y tienen la sensación de que hay muchas cosas que no saben, pero también están entusiasmados con las posibilidades. Son apasionadamente curiosos y juguetones. Les gusta trabajar con personas y, por lo general, puede darse cuenta porque a las personas les gusta trabajar con ellos, dependerán de su red para recibir asesoramiento, y le pedirán a usted y a sus compañeros / mentores su opinión y asesoramiento. Tendrán muchos proyectos bajo sus cinturones, pero serán aprendices humildes y entusiastas.

Los grandes ingenieros también podrán adaptarse a las nuevas culturas de diferentes tecnologías. Por ejemplo, podrán pasar de Rails al desarrollo móvil sin exigir que cada código se pruebe con una cobertura del 99%. No estoy diciendo que uno no deba probar el código móvil, solo estoy dando un ejemplo de diferentes normas y señalando que los grandes ingenieros deberían aceptar las diferencias entre las comunidades lingüísticas y no ser fanáticos.

Los ingenieros realmente excelentes dejan que los ingenieros menos experimentados cometan errores y los inspiran a mejorar, en lugar de dictar exactamente cómo resolver un problema.

Los grandes ingenieros no solo son excelentes solucionadores de problemas, tienen un sentido de valor comercial y desarrollo de productos. Pueden deducir múltiples formas de resolver un problema y luego seleccionar la correcta para el producto y el negocio.

Los grandes ingenieros creen en las pruebas, pero saben cómo priorizar lo que se prueba y cuán exhaustivamente para que el código se envíe rápidamente, pero sigue siendo de alta calidad. Lo mismo vale para la optimización.

Los grandes ingenieros alientan a muchos interesados ​​en un producto y no se ven amenazados por nuevas ideas. Ven a otros ingenieros como socios. En esencia, son compañeros de equipo motivadores y divertidos con los que te gustaría trabajar en un proyecto paralelo fuera del trabajo.

Los grandes ingenieros se ven a sí mismos como solucionadores de problemas y no solo como programadores de un lenguaje en particular.

Los grandes ingenieros trabajan en cosas fuera del trabajo y tienen una variedad de intereses, tecnológicos y de otro tipo.

Los grandes ingenieros recogen la holgura sin asignar culpas.

Los grandes ingenieros encuentran maneras de mantenerse interesados ​​cuando hay momentos de calma.

Los grandes ingenieros aprenden del desbordamiento de pila (y tutoriales en línea, demostraciones, etc.), copian y pegan, pero también entienden lo que están copiando y pegando.

Los grandes ingenieros son buenos comunicadores y pueden comunicar ideas técnicas profundas a personas no técnicas sin hacerlos sentir estúpidos.

Creo que hay dos aspectos en esto.
1. Comprensión del problema comercial que se está resolviendo
2. Competencia técnica general

Muchos buenos ingenieros son buenos en 2), pero los efectivos también suelen ser buenos en 1). La comprensión del problema empresarial que se está resolviendo es importante porque esto establece el panorama general. Por ejemplo, podría ser un ingeniero “brillante” que trabaja en algo sin importancia para el negocio y, por lo tanto, no ofrece ningún valor. O podría tener una competencia técnica “aceptable” pero con gran comprensión y pasión por el problema comercial que está resolviendo. Me atrevo a decir que este último generalmente sale en la cima.

La ingeniería es una designación profesional, pero no todos los que se autoidentifican como Ingeniero de Software pertenecen a una organización profesional (como IEEE), y no todos los que se autoidentifican como Ingeniero de Software tienen un título de ingeniería, que son relativamente nuevos. En mi universidad, la Facultad de Ingeniería otorgó la opción cooperativa de Ciencias de la Computación y Matemáticas, pero técnicamente mi título es en realidad un BSc porque cambié de curso en mi último año.

Personalmente, me llamo ingeniero de software porque me mantengo al tanto de los desarrollos dentro de IEEE, OASIS y el W3C; y porque mantengo notas sobre todo lo que hago, en caso de que alguna vez necesite presentar evidencia del trabajo que he realizado por cualquier razón. Como digo, es una designación profesional. Mi profesión es ingeniería de software.

Resumí 10 mejores prácticas de ingenieros eficientes:

http://sent2null.blogspot.com/20 …

Nunca dejes de aprender.

Nunca dejes de codificar. La práctica hace la perfección.

Lea el código de otros grandes ingenieros.

Deja tu ego en casa. Sé humilde y sociable.

Comparta sus conocimientos e ideas con su equipo, organización, comunidad, etc.

Siempre escuche los comentarios de su equipo.

Suponiendo que tiene las habilidades necesarias para realizar el trabajo, el mayor requisito para un “buen” ingeniero de software es si puede:

1. Comprende el problema correctamente
2. Usa su conocimiento para resolverlo en el tiempo dado con los más altos estándares de calidad

Creo que básicamente se reduce a esto. Esto es estrictamente una opinión, pero para mí, la ingeniería es pensar por ti mismo y encontrar tu propia solución. Un programador es alguien que simplemente elabora el código sin pensar mucho más que hacer el trabajo y alguien más hace el diseño. Un ingeniero de software realmente se toma el tiempo para estudiar el problema y recomienda la solución adecuada, ya sea que se trate de un software para empezar. He tenido muchas situaciones en las que recomiendo usar algo que no requiera que escriba una sola línea de código.

Adaptabilidad. Aprende una nueva tecnología / lenguaje en un par de días.

Gran planificador Establece plazos, objetivos y se apega a ellos.

Muy bueno para resolver problemas. Conoce patrones de diseño, varios paradigmas y algoritmos.

Trabaja en un equipo correctamente y confía en sugerir buenas ideas / mejoras a los ingenieros de software superiores.

Y, obviamente, uno que sabe cómo probar el software correctamente.

Hay muchos otros, por supuesto, pero creo que estos estarían en el top 10.

La diferencia es la pasión. Pasión por la tecnología, lenguajes de programación y tener más conocimiento sobre el tema.

• Pasión por aprender nuevas tecnologías.
• Sea útil para todos y aprenda cómo hacer las cosas.
• Se confiable.

Cualquiera que tenga la energía para aprender más cosas. Curiosidad.