¿Qué hace el 1% superior de los ingenieros de software que el otro 99% no?

Answer 1

En general, el 1% de las personas superiores en cualquier campo, comparte muchas cualidades excelentes. Pero me limitaré a los mejores ingenieros de software del 1% para esta respuesta. Las cualidades diferenciativas son las siguientes.

1. Reconocer y resolver un problema: en general, estos tipos de ingenieros reconocen un problema con mucha antelación. Comienzan a pensar en varios enfoques para resolver un problema. Juegan con el problema en su tiempo libre. Antes de llegar a una conclusión o decisión, asignan tiempo suficiente para abordar un problema, cuáles son las razones reales para crear el problema, cuáles son las diferentes soluciones disponibles, cuáles son las consecuencias de cada solución, etc. Una vez que estén listos para su investigación , simplemente informan a las personas que existe tal problema y que es necesario resolverlo. Una vez que todos lo reconocen, se les ocurre una solución abstracta. En el proceso iterativo, hacen que la solución abstracta sea casi perfecta. Todo esto sucede antes de cualquier decisión tecnológica que tomen.
2. Sin límites: he visto a los mejores ingenieros del 1%, no asumas ninguna limitación. No se unen a ninguna tecnología en particular. A veces, para obtener las mejores soluciones, inventan nuevas tecnologías.
3. Comercialice sus soluciones / idea: creo que esto es lo más importante. El 1% de las personas principales comercializa su idea o soluciones muy bien. Y, en general, venden sus ideas a la alta dirección. Una vez hecho esto, de arriba a abajo, es fácil viajar. Esta calidad los hace ir y retener el 1% superior. Es realmente cierto que los demás deben saber cuán inteligente eres más que tú mismo.
4. Escribir libros: en general, el 1% de las personas escribe sus experiencias. Hay una causa noble para ayudar a otros. Realmente es un trato de ganar ganar. Ser autor de un libro / s, da mucha más credibilidad. Esto crea mucha confianza y construcción de marca. Además, ayuda a muchas más personas a crecer también.
5. Eventos públicos: el 1% de los mejores ingenieros participan en eventos públicos como hackathon, festivales tecnológicos o Oracle One, Google I / O, etc. Esto les da una plataforma para convertirse en una personalidad muy conocida. Establecen y dirigen comunidades. Participan en reuniones y ayudan a las personas a crecer.
6. Puesta en marcha : hoy en día, los mejores ingenieros del 1% se inclinan por crear su propia empresa. Estas personas conocen un problema y tratan de resolverlo por su propia empresa. Una vez que la startup crece, intentan venderla y ganar mucho dinero. Estos les dan posiciones más altas y buen nombre en la próxima compañía.

Answer 2

Obtenga una excelente educación. Obsesiona entender tu propia área de informática. Como programador, obsesionarse con la comprensión de los idiomas elegidos.

Siempre haga un gran trabajo en cualquier tarea que se le asigne, pero siempre úsela como una oportunidad para obtener una comprensión profunda del problema subyacente que se está resolviendo. Mi experiencia es que inicialmente lleva más tiempo que ” hacer que funcione “, pero creará una reserva de conocimiento que lo hará más rápido y más efectivo.

En tu carrera, esfuérzate por quedarte obsoleto en tu papel. Te permitirá obtener nuevos roles. Recuerde que la recompensa típica por ser el mejor programador es que la administración lo convertirá en uno de los suyos (su mayor recompensa posible). Está bien.

He convertido esa función de gestión en una función de programación repetidamente. Como líder de equipo, yo mismo escribí los componentes más interesantes. Fui ascendido a Director y me dijeron que comprara todo el software en toda la empresa. Lo que hice fue escribir un programa de IA para monitorear las compras de software y el uso del software. Me aseguré de que fuera resistente al fracaso, multiplataforma, y ​​que cualquier persona con un par de semanas de entrenamiento pudiera utilizarlo. Se lo mostré a mi jefe y a su jefe. ¡Auge! Me reemplazaron y estaba en nuevas vistas.

Por cierto, mostré mi software a nuestros proveedores de software y querían contratarme. Por supuesto, puede continuar cambiando de empleador, pero es posible que no le guste la interrupción.

Answer 3

Hoy en día hay muchos ingenieros de software. Sinceramente, diría que hay demasiados. En lugar de pasar tiempo escribiendo un buen código que no necesita ninguna solución, excepto las actualizaciones periódicas, la mayoría de ellos prefiere hacer exactamente lo mismo que se menciona en la tarea. Esta es una mala manera de hacer las cosas. ¿Por qué? Porque a menudo las personas no tienen idea de cómo debería funcionar. Para un ser humano normal solo el resultado importa. Y para un buen ingeniero no se trata solo del resultado. Se trata de encontrar la solución más óptima que no genere errores o problemas en el futuro. Como se mencionó aquí, y lo siento si repito la verdad bien conocida, pero la diferencia entre ingenieros buenos y promedio es:

1. Código limpio y suave que se basa en una solución óptima para una tarea actual. Verá, no puede simplemente escribir código pensando solo en el resultado final. Debe escribirlo pensando en posibles escenarios y resultados, contar cada uno de los “qué pasaría si”, etc.
2. Gestión del tiempo. Mucha gente seguramente puede decir que la mayoría de los ingenieros están perdidos en sus pensamientos, no pueden concentrarse o simplemente son vagos. No puedo decir que no tengan sentido. Es verdad. Para un ingeniero promedio. El bueno no se quedará sin hacer nada, esperando hasta que suene la fecha límite. ¿Por qué? Porque un buen código requiere mucho tiempo dedicado a ello. Una vez más, no puedes ser un buen ingeniero si estás perdiendo el tiempo sin hacer nada o haciéndolo mal, ¿verdad?
3. Un buen ingeniero no seguirá ciegamente ninguna palabra o sugerencia. Lo hará como lo ve. lo hará de la manera correcta. no verá la diferencia entre el resultado final imaginario que desea obtener y el resultado final proporcionado por el buen ingeniero. Pero, ¿cómo funcionará el software? Mucho más rápido de lo que puedas imaginar, será mucho más interactivo y repelente de lo que pensabas. Así que mi consejo aquí: nunca le digas a un buen ingeniero qué hacer. Solo dale una tarea y disfruta del hermoso resultado.

Por supuesto, hay muchas más cosas, pero esas son las más importantes para mí. Y mi empleador trata a los desarrolladores de aplicaciones siguiendo este canon. ¿Prefieres tener 100 desarrolladores promedio o una docena de dioses? Creo que la respuesta es bastante obvia aquí.

Answer 4

Me atendré a tres cosas en aras de la brevedad.

• Resolver problemas a un nivel superior.
  La mayoría de los problemas en el software son autoinfligidos, ya que la “solución” en un nivel crea requisitos onerosos más abajo. Un excelente ingeniero se dará cuenta de cuándo sucede esto y arreglará las cosas en el nivel correcto. Por ejemplo (extraído de la experiencia), no necesita diseñar un algoritmo de compactación hiper sofisticado si puede cambiar algo más para que no fragmente tanto las cosas en primer lugar.
• Resuelve problemas temprano .
  Es bien sabido que los errores son más fáciles de evitar que corregir, y más fáciles de corregir en etapas anteriores, pero la mayoría de los ingenieros no aplican estas lecciones. Descubrí que los mejores ingenieros valoran la creación de prototipos, la verificación de modelos, el análisis estático y la simulación. Los esfuerzos de depuración “heroicos” de última hora atraen toda la atención, pero la mayoría de las veces solo están compensando fallas anteriores. El programador silencioso cuyo código nunca necesita ese tipo de atención bien podría ser el mejor programador del equipo.
• Ayuda a otros a resolver problemas.
  Al compartir los beneficios de los dos hábitos mencionados anteriormente, un excelente programador hace que todo el equipo sea mejor. Como dice Michael O. Church, es multiplicación en lugar de suma. Es probable que aumentar la productividad de todos en un 10% valga mucho más que duplicar su propia productividad. También significa menos interrupciones de otros que piden ayuda. 😉

Answer 5

Mi primera inclinación fue rechazar: “No soy el 1% superior, tal vez el N % superior”, donde N es un número entero ligeramente más alto, porque la precisión falsa hace grandes alardes humildes. En realidad, me resulta difícil identificar al “1% superior” (dónde está esa línea, en qué lado estaría) porque depende de quién se cuenta en la población como “ingenieros de software” y quién no. ¿Contamos los científicos de datos que usan R? ¿Los analistas de negocios que escriben Excel? Aún así, creo que entiendo el nivel aproximado al que apunta, por lo que voy a tratar de responder su pregunta. Desea saber cómo convertirse en un ingeniero de élite (2.0 en una escala que pronto presentaré).

Para leer más, escribí un par de ensayos al respecto:

La trayectoria de un ingeniero de software … y donde todo sale mal.
El programador shodan

Me centraría en el segundo, y si no tienes tiempo para leer tampoco, entraré en la versión “Cliff’s Notes” de la teoría (y la escala de competencia de programador de 0.0 a 3.0) aquí. Primero, los programadores tienden a separarse en tres categorías muy amplias (y superpuestas):

• Sumadores (“nivel 1”, 0.0 a 1.4) que pueden resolver la mayoría de los problemas de programación, con tiempo suficiente. Estos tienden a ser los que hacen el trabajo de línea de negocio, escriben guiones para obtener datos y responden preguntas que les interesan a los ejecutivos o comerciantes, etc. Los buenos quieren avanzar más allá de este nivel, retirarse de los detalles parroquiales y trabajar en problemas “básicos” más generales.
• Multiplicadores (“nivel 2”; 1.5 a 2.4) que pueden seleccionar tecnologías, tomar decisiones arquitectónicas y escribir o mantener bibliotecas útiles. Tienden a tener contribuciones de código abierto a su nombre, hablar en conferencias y, a menudo, son de importancia ejecutiva equivalente para sus empresas.
• Multiplicadores globales (“nivel 3”; 2.5+) que construyen comunidades, crean plataformas y elaboran conceptos como MapReduce de Google. Sus ambiciones tienden a superar a la mayoría de las empresas, por lo que a menudo están en el mundo académico, consultan de forma independiente o reciben un alto salario en los laboratorios de I + D de las grandes empresas.

Estos tres niveles de abstracción no cuentan toda la historia y, por supuesto, algunas tareas de “sumador” son muy difíciles (como construir un sistema de comercialización de producción) y la mayoría de los programadores de “nivel 1” no pueden realizarlas. Luego está el problema completamente diferente de que las personas no calificadas reciban trabajo de “nivel 2” (o 3), como la arquitectura de un sistema de software complejo. Quizás una tarea difícil de L1 sea realmente 1.3 o 1.5 o incluso más. Esta es solo la teoría.

Para evaluar el nivel del programador y dar más de un continuo (de 0.0 a 3.0) agregamos un punto decimal y asumimos que, por ejemplo, un programador 2.0 tendrá éxito en el 95% de las tareas de nivel 2 (y también para L1 y L3). A 1.5, es 50%. En 1.0, es 5% (en relación con L2) y 95% de las tareas L1. Al construir el modelo, asumí una curva S logística, por lo que un programador 1.6 tendrá éxito en el 64% de las tareas L2; 1,7, 76%; 1,8, 85%; 1.9, 91%, pero no creo que se pueda tomar con precisión.

Con 0.7, puede realizar la mayoría de las tareas de codificación directa (aunque puede llevar mucho tiempo, y todavía no está seguro de lo que realmente está haciendo este “compilador”). 1.0 es el nivel en el que las personas generalmente se consideran “ingenieros de software” y 1.2 es probablemente el ingeniero empleado promedio, pero en las principales empresas de tecnología está más cerca de 1.6. Un SWE 3 típico en Google es 1.6-1.8 pero se le asigna un trabajo de nivel 1.2-1.4. Un padre SWE típico en Google es 1.8-2.0 pero se le asigna un trabajo de nivel 1.4-1.7. Puedes sentir un patrón. La mala noticia es que a menudo estarás sub-nivelado en ese tipo de lugar. La buena noticia es que la calidad de la mayoría del código en Google es bastante alta. Por otro lado, hay muchas compañías (generalmente no técnicas que aún dependen del software) que no tienen un solo ingeniero 1.5+ (o, al menos, ninguno que escuchen) y todavía necesita arquitectos … por lo que a menudo ve esas decisiones L2 tomadas por personas en el nivel 1.2-1.4 (o por gerentes no técnicos, lo que es peor) y los resultados son lo que esperaría.

Todo esto puede parecer una gran cantidad de palabrería, pero es útil para responder la pregunta. La definición de “1% superior” depende de a quién incluya en la población “programadora”; Estoy buscando algo más objetivo. Supongo que hay unos 200,000 programadores vivos en o por encima del nivel 2.0. Ese es el nivel en el que me voy a centrar. (2.5, 3.0, ni siquiera puedo responder). Entonces, ¿cómo se llega al nivel 2.0?

• Presupuesto de 7 a 14 años. Sí, llevará tiempo. (He estado programando, lamentablemente no continuamente, durante 8 años; supongo que estoy 1.9-2.0 y tomó trabajo.) Tienes que escribir código, leer código, experimentar con nuevas tecnologías, ver algunas arquitecturas fracasos y (uno espera, pero no nos adelantemos porque la mayoría de los “arquitectos de software” son imbéciles con poder político) ven uno o dos éxitos arquitectónicos. Creo que probablemente pueda obtener hasta 0.7-0.8 (fluidez básica del código) en un Javascript dedicado para el verano, y 1.0-1.1 en otro año si realmente se sumerge. Más allá de eso, 0.1 punto por año es un clip bastante agresivo. La mayoría de los empleadores le asignarán trabajo por debajo de su límite de capacidad, por lo que es posible que deba robarle una educación a su jefe (leer documentos sobre el tiempo de trabajo, experimentar con nuevas tecnologías). Recuerde: siempre es mejor pedir perdón que permiso.
• Estudia vorazmente. La informática es un campo profundo, y para ser bueno en eso, necesitas al menos un conocimiento práctico de todo. Si cree que el código de ensamblaje o el álgebra lineal o el tipeo estático fuerte es “aterrador” o “demasiado profundo”, nunca llegará a 2.0. Eso no significa que debas ser un experto en todo porque no puedes. No puedes tener áreas de “No iré allí”. Probablemente no quiera escribir código de ensamblaje a mano muy a menudo, pero si toma la actitud de que es “magia negra” o “trabajo duro” o “impuro”, entonces obstaculizará su aprendizaje. (Usted ve que algunos programadores de Java adoptan esta actitud hacia los lenguajes de memoria manual como C.) Probablemente usaría Haskell (un lenguaje de alto nivel con un tipo de escritura estático fuerte) dada una pizarra limpia; pero me he expuesto a Clojure, C e incluso Python (bibliotecas de ciencia de datos) porque cubren temas importantes de la informática. No puede tener el “¿Esto estará en la prueba?” mentalidad. Tienes que sentir curiosidad por todo lo relacionado con CS. (La curiosidad matemática ayuda). También debe aprender sobre la industria misma. ¿Por qué fallan tantos proyectos de software? ¿Qué errores (técnicos y no técnicos) conducen a eso y cómo podrían evitarse? ¿Qué hace que un buen CTO de inicio? ¿Qué cosas vale la pena construir y qué patrones traicionan una marcha de la muerte?
• Construye cosas cuando no sabes que tendrás éxito. ¿Cómo te conviertes en un programador competente? O arquitecto? ¿O hacker de kernel de Linux? Práctica. Si sabe que puede hacer algo, entonces no aprenderá tanto como si hubiera alguna posibilidad de fracaso. Los empleadores lo quieren en un nivel de dificultad donde tendrá éxito el 95% del tiempo. Diría que su mejor aprendizaje está en el rango de “estiramiento” del 65-75%. Eso significa que eventualmente está obteniendo resultados exitosos, pero vacilando un poco. Hay progreso, pero no es sencillo y definitivamente tienes que trabajar.
• Red, no para trabajos sino para ideas. No pienses en “hacer contactos” como algo que haces después de que te despiden. Somos criaturas sociales y los programadores no son diferentes. La mejor manera de convertirse en un gran programador es hablar con otros grandes programadores, y luego tener una idea de qué problemas han resuelto y cómo. Sería cauteloso en las conversaciones de IA / aprendizaje automático en 2014 (algunas son muy buenas, pero hay muchos poseurs en “ciencia de datos”; eso probablemente cambiará en 3 años), pero los grupos de usuarios de Haskell y Clojure atraen a una gran multitud.
• Salto de trabajo cuando dejas de aprender. La mayoría de los programadores se estancan alrededor de 1.2. ¿Por qué? Porque no son empujados, y no tienen oportunidades de trabajar en cosas difíciles. O bien, las cosas “difíciles” que obtienen pertenecen al código heredado difícil / feo, no a la informática en sí. Es útil pasar ~ 3 meses en uno o dos módulos heredados malos para aprender sobre errores arquitectónicos, pero no más. Finalmente, querrás trabajar en proyectos exitosos y estar rodeado de personas fuertes. Si alguna vez deja de crecer, es hora de seguir adelante. ¿Sabes cómo la gente termina estancada? Un día a la vez. Así es como te conviertes en un gran programador. Un día a la vez (durante aproximadamente 4,000 días).

Answer 6

Hay muchas respuestas geniales aquí. Pero solo les pido una cosa a mis desarrolladores.

Haga que su código sea tan simple de entender y coméntelo tan bien que su reemplazo pueda ser productivo lo más rápido posible.

Porque como gerente no me importa qué clase de código ninja crees que eres, si eres bueno eventualmente te irás para tu próximo desafío, y alguien más tendrá que continuar con tu trabajo. Así que haga que su legado sea bueno y asegúrese de seguir siendo una leyenda en estas partes por todas las razones correctas .

Answer 7

Me gustó el descargo de responsabilidad de Michael O. Church, también lo usaré para mí:

Mi primera inclinación fue rechazar: “No soy el 1% superior, quizás el N % superior”, donde N es un número entero ligeramente superior

Entonces, como ingeniero de N % superior, describiré lo que creo que estoy haciendo bien con el siguiente ejemplo de una tarea muy pequeña que hice hoy en el trabajo .

Quería averiguar la dirección IP de una instancia de AWS EC2 que estoy usando, y sabía que los demás y yo tendremos que hacerlo con bastante frecuencia.

Podía iniciar sesión en la consola de AWS utilizando la autenticación de dos factores, hacer clic varias veces y obtener la dirección IP, pero sentí que era una forma horrible de hacerlo, especialmente si tendré que hacerlo varias veces a la semana.

Así que decidí escribir un guión corto para eso. Sabía que podía usar Python (con la biblioteca boto3 para acceder a AWS EC2), pero sentí que no era la mejor manera posible: ¡no sería una frase!

Tenía herramientas de línea de comandos de AWS en mi máquina de desarrollo y sabía cómo ejecutar el comando “aws ec2 describe-instancia” con los argumentos correctos (¡no triviales!) Para que coincidan con mis etiquetas EC2. Tuve eso de algún tiempo en el pasado donde lo descubrí para otra tarea que necesitaba automatizar.

AWS CLI devuelve resultados en formato JSON donde uno de los campos internos era “PrivateIpAddress”, el que necesitaba. Podría usar un conjunto de herramientas familiares: grep, awk, sed, sort, uniq para componer un script bash de una sola línea. De hecho, ese fue mi primer intento, que funcionó, pero todavía sentía que había una mejor manera.

Recordé encontrar una herramienta llamada jq [1], un analizador JSON de línea de comandos. Ejecutó “man jq” y se desplazó por los ejemplos básicos de uso. También miré el tutorial de jq en línea y descubrí rápidamente cómo acceder a los valores en las cadenas de matriz / dict. Hice algunos intentos para obtener la sintaxis correcta y terminé con los argumentos correctos. La cadena de resultados todavía tenía comillas dobles alrededor de ellos, lo que no quería. Podía canalizar fácilmente la salida a través del comando “tr”, pero sentí que había otra forma. No tenía ganas de pasar por toda la página man, así que google-stack-overflowed y descubrí que el interruptor “-r” de jq haría ese trabajo.

Aquí está la frase (limpia) con la que terminé:

  aws ec2 describe-instancias --filters = "Nombre = etiqueta: Nombre, Valores = mi-etiqueta- *" |  jq -r '.Reservations []. Instances []. NetworkInterfaces []. PrivateIpAddress'

Aquí hay un resumen de lo que creo que hacen los mejores ingenieros de software del 1%:

1. Decida qué problema trabajar, si es que lo hace (¿debería automatizar esto?)
2. No use de forma predeterminada las herramientas de su zona de confort (me encantan Python y sed, pero no fueron las herramientas adecuadas para el trabajo)
3. Sepa que debe haber una mejor manera y búsquela
4. Tener conocimiento sobre las herramientas existentes (sabía sobre aws CLI, bash utilities y, afortunadamente, sobre jq)
5. Siga ampliando su conjunto de herramientas personales (he descubierto el filtro de etiquetas aws cli en el pasado)
6. Profundamente sé que hay cosas que no sabes
7. Sé rápido en todo lo que haces. Todos los pasos que describí me tomaron alrededor de 15 minutos en completar. Pasar horas en la optimización de este script menor no sería un buen uso del tiempo. Si no tiene tiempo para hacerlo en el trabajo, tómese el tiempo para completar la experiencia de aprendizaje cuando esté en casa.
8. Ahorre tiempo buscando en Google y desbordando la pila, está perfectamente bien hacerlo.
9. Domina uno de los pocos editores verdaderamente poderosos (uso vim)
10. Comparta con sus compañeros de trabajo, para que todo el equipo pueda beneficiarse de su logro

Notas al pie

[1] jq

Answer 8

1. Invierta en herramientas de aprendizaje y construcción. Todavía tengo que conocer a un ingeniero superior que no adquirió el dominio de su editor (EMACS, vi, etc.), el sistema de control de fuente, los depuradores (aunque lamentablemente va a desaparecer) y el entorno de programación. Por el contrario, los programadores mediocres pueden (por ejemplo) editar código en EMACS pero no lo tratan como un entorno de desarrollo, ya sea para acelerar el ciclo de edición / compilación / depuración o para reducir la carga de memoria (al descargar el conocimiento de dónde funciona una función es mediante el uso de TAGS o alguna herramienta de metabúsqueda). Los mejores ingenieros no solo entienden todas las características básicas, sino que generalmente hacen un uso intensivo de los lenguajes de extensión y la personalización de su entorno.
2. Dar crédito a quien crédito merece. Nuevamente, si usted es un ingeniero superior, no necesita acumular crédito y puede reconocer felizmente el trabajo de otras personas. Esto hace que otras grandes personas quieran trabajar con usted, y es un ciclo autocumplido.
3. Impaciencia. En lugar de querer pasar tiempo en reuniones, los mejores ingenieros escriben código y pasan tiempo escribiendo código en lugar de hablar de ello. Jeff Dean, Pengtoh y Amit Singh han realizado cambios importantes en el código de la infraestructura de Google sin dudarlo. Como dijo una vez Bill Coughran: “Entras una mañana y descubres que el universo ha cambiado”.
4. Comprensión total de la pila. Los grandes ingenieros de software no se detienen en una abstracción o límites de módulos. Penetran esos límites y atacan problemas o errores hasta que los resuelvan. Una vez me senté al lado de Pengtoh mientras él buscaba un código que se portaba mal y descubría un error en el ensamblaje que el compilador estaba generando. Luego descubrió una solución estable para ese error. Si te intimidan las abstracciones o respetas demasiado los límites del módulo, no habrías encontrado ese error.

Si haces todos esos 4, hay cero posibilidades de que no seas uno de los mejores 1%.

Answer 9

Impecables habilidades de prueba. – nadie quiere depurar tu código por ti. Es su trabajo, así que considere que su firma se está poniendo en todos y cada uno de los programas que codifica. Es tu reputación en la línea.

Impecables habilidades de escucha. – a veces el usuario realmente no sabe lo que quiere o cómo transmitirle el problema. Su trabajo es realmente escuchar lo que necesitan o están tratando de lograr. A veces habrá una persona intermedia entre usted y para quien realmente está programando. Si tienes la oportunidad, habla directamente con la persona que necesita tu código.

Impecable a tu palabra. – si dice que va a hacer algo en una fecha determinada, haga que suceda. Solía ​​calcular cuánto tiempo tomaría algo si todo salía a la perfección. Luego multiplicaría esa cantidad de horas por 3. Muy raramente llegaba tarde a un proyecto. Ese amortiguador aseguró mucho tiempo para problemas inesperados o fallas de diseño y me dio la reputación de poder hacer las cosas.

Impecable para tus compañeros de trabajo. – no solo no sabes cuándo la persona sentada junto a ti podría convertirse en tu jefe, sino que también podrías necesitar a alguien que te ayude con la lógica o la información. Sé amable con todos. Aprenda cuáles son las habilidades de todos los demás.

Impecable para la gestión. – Honestamente va un largo camino. La gerencia realmente necesita saber lo bueno y lo malo. Recuérdeles que usted es el mensajero y que está allí para ayudarlo. Y, cuando se le pregunta cómo resolver algo, SIEMPRE tiene 3 opciones diferentes sobre cómo resolverlo y las ventajas y desventajas de todos ellos. El tiempo, la calidad, la cantidad y el costo son para que ellos decidan, es por eso que las opciones los ayudan.

Answer 10

Sugeriría dos cosas principales que distinguen al 1% (o 10x) ingenieros de software de todos los demás.

Primero, resuelven el problema en lugar de hacer lo que se les pide. A menudo, los clientes o jefes no saben particularmente lo que debe suceder, solo saben lo que está mal. Desafortunadamente, también es bastante común que las personas sin tecnología supongan que conocen una solución y le pidan a alguien que la implemente.

Un ejemplo, tal vez su jefe se le acerca y le pide que presente su sitio web con un CDN. Lo que realmente está diciendo es “el sitio es lento para nuestros usuarios, y alguien me dijo que los CDN hacen las cosas más rápido”. Es muy posible que el almacenamiento en caché de recursos estáticos en una CDN ayude, pero también es posible que haya otros 20 problemas que causen la degradación del rendimiento.

El ingeniero normal hace lo que le dicen y agrega un CDN. El ingeniero del 1% se da cuenta de que el problema real es la velocidad del sitio e instrumenta la aplicación para rastrear el rendimiento y ver dónde radica el problema real.

Segundo, eligen el nivel correcto de abstracción para la tarea. El código que debe existir a perpetuidad y que muchos ingenieros deben mantener debe tener un estándar mucho más exigente que un script que está pirateando para probar una corazonada. Es tentador ser perezoso y poco abstracto (p. Ej., Copiar + pegar código, usar números mágicos, etc.) o exagerar (p. Ej., Crear una jerarquía de clases multinivel para tener en cuenta los casos de uso que probablemente no hayan ganado) t surgen). Tiendo a respetar a los ingenieros que entienden el alcance del trabajo y pueden elegir un nivel adecuado de abstracción para la tarea en cuestión.

Answer 11

Ok, he sido el mejor programador de General Instruments en ese momento y me contrataron para Rockwell International (hicimos la informática y las cosas electrónicas para el transbordador espacial).

Ahora, supongo que la publicación de Michael O. Church es buena desde su perspectiva. Pero también, hasta cierto punto, por qué, como él mismo dice que ni siquiera parece estar cerca del 1% superior, y es por eso que creo que es una buena lectura.

A) No me costó 7-14 años y no estudié vorazmente, no trabajé de salto cuando no pude aprender más, solo hice las cosas por mi cuenta. Y nunca me pregunté qué se necesita para llegar a la cima. Acaba de suceder. Fui el mejor ingeniero entre aproximadamente 200 en mi primer año. ¿Súper inteligente o genio? Para nada, déjame asegurarte que (lo digo en serio, super inteligente no te llevará allí).

B) Más adelante en mi vida contraté ingenieros, arquitectos, directores de tecnología y todo lo demás. En un caso para webstock: la primera plataforma de comercio electrónico, luego para Blueroads, la compañía de gestión de canales más exitosa de la actualidad. Ese fue en realidad el momento en el que necesitaba saber lo que necesitaba buscar para contratar las mejores armas. Tuvimos que competir con dos competidores que tenían 70 y 65 veces el dinero en el banco, respectivamente. Tuvimos éxito y superamos a ambos con un equipo de ingeniería estelar.

C) OK, puede llamarme “desarrolladores anti cristo” cuando lea la lista a continuación, porque es contrario a todo lo que aprendió. Pero también puede preguntarle al cofundador de Andy Bechtolsheim de Sun Microsystems, el fundador de Mitch Kapor de Lotus que codificó sin ayuda 1-2-3, Marc Benioff de Salesforce.com y escuchará una historia muy similar. Ahora, esto es lo que contraté y tuve mucho éxito:

1) Pensamiento abstracto: aprendí eso en Rockwell (contratamos a 1,000 ingenieros en ese entonces). Pensamiento abstracto = inteligencia = ser capaz de resolver un problema que nunca antes había tenido al solo pensarlo.

2) Savvy con una herramienta específica. No busqué un programador con una lista de 50 palabras de moda, sino aquellos que (en nuestro caso) fluyeron por sus venas. O saber todo sobre MySQL tal vez no tenía idea de que DB2 existía.

3) Tiene muchos amigos que también adoran la codificación, el diseño y la arquitectura. Aquellos que están en los respectivos grupos de LinkedIn, Google, Yahoo, tienen habilidades de redes y pueden pedir a otros que resuelvan cualquier problema.

4) Da una mierda sobre los frameworks, cablea una aplicación antes de comenzar a codificar todo ese jazz: aquellos que piensan y codifican y repensan e iteran y tienen todo el código en su cerebro parecían ser lo mejor de lo mejor. Implementan el marco después del hecho para que otros codificadores útiles puedan hacer lo que mejor hacen: codificar una parte de la acción.

5) Tiene conciencia de pila completa. Literalmente son dios del universo que crearon. Y si varias personas tienen esa habilidad y se comunican bien, usted tiene ese equipo de crack que hace que todo suceda, en muy poco tiempo.

Axel
http://appearoo.com/axels

Answer 12

El 1% ingeniero realmente entiende un sistema de software. No solo partes del código, sino el sistema en su conjunto. Él o ella puede ver las fallas que no son directamente aparentes al leer piezas individuales de código, sino las que están rotas por diseño o las que involucran muchas partes de un sistema.

Esta capacidad de “ver” la estructura general del código es lo que permite a estos ingenieros marcar la diferencia. A menudo eliminan más código del que agregan, lo que devuelve la forma del software. Donde la mayoría de los programadores necesitan diagramas o diagramas de flujo para comprender lo que está sucediendo, los mejores ingenieros tienen una imagen mental de la base de código que los guía y les permite realizar refactorizaciones que tocan todas las partes de una base de código. No tienen miedo de tocar las partes arriesgadas.

Me gusta pensar que la película The Matrix trata realmente sobre el viaje que hace un programador durante su carrera. Neo comienza a aprender algunos trucos y es moderadamente eficiente, pero al final finalmente comprende realmente el sistema subyacente, la arquitectura general y todas las dependencias entre los componentes. De repente, capta el funcionamiento de la matriz, visualizada adecuadamente por Neo ‘pensando / viendo código’. Aquí es donde se convierte en 1% y gana la capacidad de marcar la diferencia.

Answer 13

Tener grandes habilidades de comunicación.

El desarrollo de software es como escribir un ensayo. Desea dividir todo el problema en piezas individuales, cada una con un propósito claro y distintivo. El orden de las piezas debe fluir naturalmente para ser digerido fácilmente. Si bien puede impresionar a algunos usar vocabulario y gramática avanzados para ser más concisos, debe recordar que las personas leerán su trabajo en los próximos años y que la claridad sobrevivirá a la prueba del tiempo. Al mismo tiempo, no escriba tan simplemente que la pieza se vuelva demasiado detallada. Esforzarse por mantener un equilibrio perfecto.

Todos los escritores hacen un punto, pero los buenos escritores lo hacen transmitiendo su mensaje de una manera fácilmente digerida y disfrutada por sus lectores. Te harán imaginar fácilmente paisajes detallados y relaciones complejas a través de las palabras. Del mismo modo, todos los programadores se comunican con las computadoras. Pero los buenos también se comunican de manera efectiva con otros programadores. Las estructuras y procesos de datos complejos se simplifican gracias a la modularidad y simplicidad de su código.

Las habilidades claras de comunicación son indicativas de un proceso de pensamiento claro.

Esto y sentido común: no reinventar la rueda, no ser centavo y tonto, no optimizar prematuramente (porque es la raíz de todo mal) y tener un poco de humildad.

Answer 14

Hacen las mismas cosas que el 1% de los mejores artistas en cualquier campo. Haré que mi respuesta sea específica para las SE.
1.) Perfeccione su oficio y manténgase actualizado sobre las habilidades, tecnologías y mejores prácticas en su campo y en la industria en la que trabaja.
2.) Comprenda que no “pone código”, “escribe programas” o “desarrolla software”, “resuelve problemas de negocios” de la manera más efectiva y eficiente posible. Para hacer esto, debe aprender sobre el negocio que respalda para conocerlo casi tan bien como aquellos por quienes se utilizarán sus soluciones.
3.) Usted no es un “proveedor de software”, es el socio técnico en el negocio. No “satisface a los clientes”, apoya a los “socios comerciales”. Para hacerlo, debe cultivar una relación con aquellos que tienen la responsabilidad comercial de administrar los procesos que sus soluciones de software deben mejorar. Esa relación debe basarse en el respeto mutuo y en un reconocimiento claro de los roles y responsabilidades que desempeña cada “socio”, y en la confianza de que cada uno aporta las habilidades, el talento, el conocimiento y el compromiso necesarios para resolver el problema comercial en cuestión. Debe tener y mostrar confianza en los demás y ellos deben tener confianza en usted.
4.) Usted no “entrega y / o instala software”. Mejoras el negocio. Para hacer eso, debe comprender y desarrollar el conocimiento y las técnicas comerciales para identificar y medir esas mejoras para que usted y sus socios puedan demostrar el grado en que tienen éxito en sus esfuerzos tecnológicos.
5.) Comprenda dónde encaja su parte de la tecnología con todo el sistema. Su parte puede funcionar perfectamente según las especificaciones, pero si el sistema falla, usted falla. Para hacerlo, debe asegurarse de comprender y tener siempre en cuenta el impacto que tiene lo que está haciendo en todo el sistema. Eso requiere que también comprenda que el “sistema” NO es solo el componente técnico. El sistema consta de las personas, procesos y equipos con los que interactúa el software (admite o depende de él). Infórmese sobre los principios y prácticas de Sistemas e Ingeniería y Arquitectura Empresarial. Si no está familiarizado con estos, incluso si cree que está en el 1% superior, no lo está y no puede estarlo.
6.) Todo lo anterior se relaciona con su función principal. Su función secundaria es anticipar y resolver los problemas de sus jefes antes de que sean problemas. Dondequiera que se encuentre en la organización, adopte el lema de “sin sorpresas”. Asegúrate de que tu jefe nunca se sorprenda y nunca reciba “la llamada”. Si no sabe cuál es “la llamada”, aprenderá esto de la manera difícil a medida que asciende al nivel del 1%. Todos lo hacen, es inevitable. Aprende de cualquier experiencia que sea (a veces es más que solo una).
7.) Si bien no puede hacer nada para mejorar esto, reconozca que el 99% de las personas, que probablemente lo incluye a usted, no están en el 1% superior intelectualmente. Ayuda mucho si es así, ya que aumenta enormemente la probabilidad de que termine en el 1% superior de los artistas, pero no es necesario ni suficiente. Sin embargo, si no tiene la suerte de nacer con esa capacidad nativa, compense esto buscando y aprendiendo a aprovechar los consejos y la experiencia de los demás. No tienes que saberlo todo. Solo tienes que saber lo suficiente para saber que no, y conocer a suficientes personas que, colectivamente, lo hacen.
8.) Actuar consistentemente en los siguientes dos principios; Primero, cualquier éxito que logre no es suyo. No reclame el crédito. Dar reconocimiento público al equipo. Segundo, cualquier falla es suya y usted debe asumir la responsabilidad personal por ellas sin tirar a nadie debajo del autobús para “salvarse”. Nadie será engañado. Puede sufrir contratiempos temporales por hacer esto, pero desarrollará una fuerte lealtad a largo plazo que lo llevará mucho más lejos. todos en la cima están parados sobre los hombros de otra persona. No te dejarán hacer eso de mala gana.

Espero que esto ayude.

Answer 15

¡Esta pregunta parece muy popular! Muchas respuestas ya se pueden ver excelentes respuestas. Sin embargo, no hay demasiados consejos. Así que ahí voy…

Antes de comenzar, revisé la respuesta de Michael O. Church y fue lo que me llamó la atención. Excelente respuesta Michael. Ha prestado una atención muy detallada a la segregación de ingenieros de software (SE). Así que déjame comenzar desde este punto.

Conocimiento comprensivo:

Computer Science (CS) [El campo teórico sobre el desarrollo de software (SD) junto con SD] es un campo muy vasto . Cuando digo vasto, es una colección de conocimiento enorme, gigantesca, gigantesca, brobdingnagiana, con sus diversas ramas y ramas secundarias que se extienden hasta donde alcanza la vista. Y este estado ni siquiera es estable. Se expande constantemente y forma nuevas alianzas con otras ramas de la ciencia, lo que resulta en una interconexión de conocimiento similar a la tela de araña.

Cuando seas nuevo, estarás confundido, asustado y finalmente te dejarás llevar y serás humilde ante el tamaño del universo. Acéptelo y comience a moverse y a estudiarlo con asombro y asombro.
Tendrá que aceptar esta enormidad y rodearla en un intento muy débil de dominar su existencia. Esto se puede lograr clasificando los tipos de conocimiento como lo ha hecho Michael con los tipos de SD (¿Se puede hacer algo similar para varias ramas y tipos de dominio como codificación, teoría, IA, clasificación booleana y otras con diversas actividades y temas en CS?) . Comience a adjuntar etiquetas (similares a las etiquetas de blogpost o grupos de Quora) a las ramas CS y sub ramas. Esto lo ayudará a encontrar referencias en un momento posterior cuando sea necesario y hacer referencias cruzadas con otra información.

Aprendizaje:

Aprendizaje es un término muy vago para estudiar como lo describió Michael. A partir de la cantidad de conocimiento, necesitará una cantidad significativa de tiempo para estudiar una porción muy pequeña de la misma. Este será tu próximo paso. Limite el campo y el dominio de CS en el que siente que tiene interés y que probablemente desarrolle pasión por. Si está confundido, continúe, continúe de todos modos e intente ensuciarse las manos con la codificación. Esto debería solucionarlo de inmediato.
La capacidad de aprendizaje implica dos puntos:

Estudiar: Esto debería implicar su codificación, campo de estudio inmediatamente aplicable a usted y su trabajo. Esta etapa tiene tres requisitos que son:

• práctica
• práctica
• práctica

La importancia de la práctica de codificación no puede ser exagerada . Comienza a practicar en tus proyectos favoritos. Siempre habrá una mejora que un ojo detallado puede detectar en cualquier producto. Esto se debe a la increíble capacidad de los productos digitales para ser personalizables a nivel de bits. Revise todo con un ojo crítico para obtener mejoras positivas.

Leyendo:
Dado que SD se ocupa de problemas del mundo real, deberá conocer los requisitos comerciales. Esto implica desde el estudio de especificaciones hasta la obtención de un núcleo de conocimiento de nivel de dominio para su trabajo. Déjame aclarar esto. Si necesita desarrollar un algoritmo de secuenciación de genes, es su responsabilidad comprender completamente el tema, repasar los conceptos básicos, remitir los documentos de la conferencia y recibir el asesoramiento de expertos de las PYME respectivas que incluyen obtener información de contacto. Por lo general, esto debe hacerse dentro del plazo comercial especificado para enviar un plazo estimado para su finalización. Esto es extremadamente difícil, mientras que la actividad de estimación del tiempo del proyecto es un arte en sí mismo, digno de discusión en otra publicación. Hay muchas maneras de hacerlo, pero todas comienzan por leer y estudiar campos relacionados con su trabajo.

Code Reading :
Esta actividad consiste en leer el código de los proyectos y las personas que encuentre interesantes para tener una mejor idea sobre ellos. Este hábito, aunque difícil e inicialmente torpe, le inculcará una mejor documentación del código y disciplina de formato mientras expande sus horizontes. También lo ayudará a encontrar amigos, compañeros, mentores que tendrá usos invaluables para beneficio mutuo. Esto requiere disciplina pero practíquelo.

Escritura:
Escribir implica escribir tus pensamientos. El atributo clave de un gran SD (o de hecho cualquier gran líder) es su capacidad para comunicarse efectivamente (sí, el mismo cliché de gestión). Esto es muy importante para colaborar con muchos codificadores que lo califican como más importante que sus habilidades de codificación para el éxito del proyecto, incluso en el trabajo del programador. Algunos programadores incluso han atribuido la escritura como una inspiración a partir de la cual comunican pensamientos a la máquina a través del código. La clave para entender SD es que, a diferencia de lo que se muestra en los medios convencionales, es de naturaleza muy social, donde las conversaciones tienen una opinión ligeramente diferente a las tradicionales.

Revisión de código:
Este es un subconjunto de lectura de código. Este paso implica que revise el código de su socio de proyecto de trabajo / afición y viceversa. Esto ayuda principalmente a sincronizar sus pensamientos mientras señala las diferencias de código en estilo y algoritmos, elevando así los estándares de código del equipo al mismo tiempo que orienta a los juniors y brinda una visión general de la estructura del proyecto.

Herramientas:
SD no es más que la creación de nuevas herramientas. SD ama sus herramientas. Esa es la razón por la que tenemos muchas versiones del mismo producto. En el curso de su carrera, tendrá que lidiar con innumerables herramientas para hacer el trabajo. Puede crear uno o más bien modificar uno existente. El problema surge cuando necesita optimizar el rendimiento. Luego cavas profundamente debajo de su capó y entiendes qué versión está más cerca de tu necesidad. ¿Suena cansado? ¡Será mejor que ames tus herramientas!

---

Por encima de la materia se trataron detalles específicos de la DE. Esta sección trata aspectos más amplios de SD como punto de vista .

Perspectiva: así es … así es como se hace …

Su pregunta es muy amplia en su naturaleza. Mientras que el contenido anterior trata el tema de SD, ahora podemos tratar cómo encajan exactamente las diferentes respuestas.
Esta pregunta tiene muchas respuestas. Todos son muy diferentes, pero responden la misma pregunta. Todos ellos son buenos. ¿Cuál elegir y por qué son tan diferentes?
Es una cuestión de perspectiva. Como todos los demás temas, el hecho único rara vez corrobora con la verdad. La verdad tiene múltiples lados, algo así como el cubo de Rubik:

Al igual que el cubo anterior, la verdad y, por lo tanto, la información se compone de varios hechos (que se muestran por los lados de los cubos). Todos los hechos juntos producen una verdad comprensible. Igual es el caso con cualquier información. En CS / SD, todas las respuestas a esta pregunta son algunas facetas que son parte del conocimiento completo que se desea. Por lo tanto, todas estas respuestas son valiosas y deben leerse y reflexionarse. Algunas respuestas responden SD con sus modelos mentales de clasificación, otras con experiencias personales respaldadas con sus ejemplos (por ejemplo, la respuesta de Anónimo). Todos ellos nos ayudarán a comprender todas las facetas de SD. Después de leer estas respuestas, es muy importante reflexionar sobre ellas. Esto lleva a que nuestro cerebro procese previamente la información requerida en segundo plano, que puede recuperarse rápidamente cuando sea necesario. (consulte otras preguntas de Quora sobre los patrones de estudio y cómo las personas inteligentes recuerdan cosas)

Finalmente algunos consejos generales sobre este viaje:

• Este será un viaje largo y arduo . Prepárate para trabajar muy duro y salir de la zona de confort de tus sujetos para estudiar el mundo. El único propósito de los programas de software es habilitar y aumentar las capacidades humanas. SD en sí mismo no es un propósito. Uno debería disfrutar haciéndolo por diversión, pero necesita una relevancia en el mundo real. Se trata de cambiar el mundo y ayudarte a mantener la concentración.
• SD rara vez se pone a trabajar en el proyecto de sus sueños mientras le pagan. Pero realice proyectos que nos interesen y participe en foros de código abierto. Trabaja en las habilidades en uso en el trabajo y cuáles te parecen interesantes. Concéntrese en aprender más que apuntar y pagar. La promoción mientras está mal preparado puede ser mortal para sus ambiciones SD.
• Aprenda sobre la evolución de CS a partir de su historia. Le ayudará a comprender las raíces de la filosofía de CS que tiene una presencia significativa incluso hasta el día de hoy, como será evidente a través de muchas peculiaridades. CS es un campo único con una cultura hacker muy fuerte. Obtendrá una mejor idea de la publicación a continuación.
• La Catedral y el Bazar: Eric Raymond hizo un trabajo fantástico al señalar todos los aspectos de la historia y la evolución de la cultura de los piratas informáticos CS tempranos en el estado actual. También echa un vistazo a Cómo convertirse en un hacker.
• No participe en disputas innecesarias sobre pequeñas sintaxis de códigos sin sentido y batallas de idiomas. SD tiene el molesto hábito de ser un apasionado de sus herramientas, es muy obstinado y, por lo tanto, está listo para sacar provecho de asuntos aparentemente pequeños. Esto solo agotará su tiempo y energía y hay una buena posibilidad de que otra persona no retroceda.
• Finalmente, la paciencia es una virtud. Úsalo. Roma no se construyó en un día. Aprende a programar en diez años ( http://www.norvig.com/21-days.html )

Trabaje más duro, manténgase enfocado, trabaje en red para ideas (gracias Michael) y esté listo para cuando la oportunidad toque la puerta.

PD
Consulte el libro Codificadores en el trabajo : Reflexiones sobre el arte de la programación ( http://www.codersatwork .com /). En él, el autor entrevistó a muy buenos SD (tipo de programadores Top 2%) con sus hábitos de SD, filosofía, herramientas favoritas, idiomas, sus ideas sobre qué factores contribuyen al éxito y el fracaso del proyecto y sus arrepentimientos. Entrevistas muy interesantes y honestas sin ningún comentario por parte del autor que pocas notas y observaciones vinculadas. Un libro de SD para SD 😛

Answer 16

Los mejores ingenieros con los que he trabajado saben:

1. Qué no hacer: la capacidad de reconocer un camino atractivo para resolver un problema que finalmente causará más problemas de los que resuelve y evitarlo. Codificar lo incorrecto a velocidad warp se ve muy bien en una reunión de scrum, pero no te lleva a ningún lado hacia ningún objetivo.

2. Cómo funciona toda la pila, no solo una pequeña esquina, y puede pensar en las implicaciones de un cambio en partes lejanas del sistema y tomar decisiones basadas en eso.

3. Cómo leer el código de otras personas y comprender rápidamente lo que hace, o hacer conjeturas muy educadas sobre lo que un sistema * debe * hacer para comportarse como lo hace, lo que significa que pueden diagnosticar problemas en una fracción del tiempo todas las causas posibles una por una

4. Lo que no saben y las formas en que los instintos de uno pueden desviarnos (por ejemplo, al hacer suposiciones sobre el rendimiento) y saber cuándo medir la realidad en lugar de confiar en el instinto.

5. Una amplia variedad de idiomas y tecnologías.

6. Lo que no vale la pena saber porque puede encontrarlo sobre la marcha si realmente lo necesita: qué dejar para más adelante para aprender lo que necesita ahora para resolver el problema en cuestión.

Answer 17

Creo que la realización más importante es que ser ingeniero de software no se trata solo de programar . Hay mucho más que eso.

Escribí una respuesta bastante detallada a su pregunta aquí, ¿Qué hace el 1% superior de los ingenieros de software que no hace el otro 99% ?, incluyendo muchos consejos prácticos y no solo agitando las manos 🙂

Answer 18

Hablaré de mi experiencia como ingeniero de 25 años que trabaja en Oracle: Sun Microsystems.

Como joven ingeniero, busco al menos dos ingenieros de software principales en mi equipo. Estas son las cualidades que observé en ellas:

1. Interpretación despiadadamente precisa de las especificaciones. Dado que fabricamos hardware y software de sistema, debemos ser precisos. Por lo tanto, los ingenieros que producen códigos precisos son muy valiosos. Muévete rápido, romper cosas arruinará los bancos que ejecutan nuestras máquinas.
2. Claridad en el proceso de pensamiento y comprensión del espacio del problema. A veces, se toman mucho tiempo para articular claramente lo que están pensando y ver todos los casos de esquina.
3. Capacidad para ver a través de abstracciones. ¿Por qué estás usando Python para este problema? Si no puede venir con una razón sólida, quédese con lo que ya estamos usando.
4. Depuradores (bajo su guía me siento como un depurador jedi ahora)
5. No tiene miedo de asumir nada (incluso si el proyecto no está claro)
6. Código de arranque día tras día
7. Escriba una prueba por inserción de código (oh sí, la calidad de nuestras pruebas rivaliza con el código en sí … y esto es antes del control de calidad)
8. Cumpla los plazos de manera oportuna.

Mi experiencia ha sido que la experiencia en idiomas viene con la práctica. No es necesariamente un buen indicador de la capacidad de programación.

Además, la mayoría de las entrevistas de pizarra son basura. Ponen a prueba las habilidades de memorización más que la capacidad de crear códigos y comprender el espacio de diseño.

Las personas con gran Unix-fu son superproductivas (cuando se desarrollan en una plataforma Unix).

Answer 19

1. Escriba código por diversión y no solo por dinero. Obtienen su alto de ella.
2. Lea mucho código escrito por otros programadores.
3. Me encanta trabajar con jugadores ‘A’. A veces pueden liderarlos y a veces aprenden trucos de comercio de ellos.
4. Encanta asumir problemas desafiantes. Amor estirando su cerebro en la búsqueda de la solución. Al igual que a un atleta superior le encanta empujar los límites de sus límites físicos, los mejores programadores hacen lo mismo con los límites mentales.
5. Puede entrar en la zona. Vital para poder codificar durante largas horas.

Answer 20

Hay algunos puntos, sin ningún orden en particular:
* Aprecia múltiples idiomas, comprende las ventajas y limitaciones
* Aprecia todos los paradigmas de programación (de procedimiento, OO, funcional, etc.)
* Se preocupa profundamente por los objetivos del software, la razón de ser del software
* Utilice el control de versiones; resuelve bastantes necesidades en una explosión
* Nunca deje de mirar hacia atrás y revisar el código; incluso muy antiguo código muy propio
* Sea totalmente agudo en aspectos algorítmicos y opciones de diseño
* Sé totalmente experto en bibliotecas y herramientas para un idioma determinado
* Esté preparado para refactorizar el código y mejorar la ortogonalidad a la primera oportunidad
* Tener la habilidad suficiente para reescribir su idioma favorito en sí mismo (auto-anfitrión)
* Tener la habilidad suficiente para reescribir en su idioma favorito los compiladores de otros
* Se mantiene actualizado con los desarrollos actuales del lenguaje, errores, noticias, etc.
y por último pero no menos importante:
* Sabe cómo hacer más con menos ; ¡Esto no se puede enfatizar lo suficiente!