Mirando hacia atrás en mi carrera y mi vida como programador, había muchas maneras diferentes de mejorar mis habilidades de programación: leer código, escribir código, leer libros, escuchar podcasts, ver screencasts y más.

Mi pregunta es: ¿Qué es lo más efectivo que has hecho para mejorar tus habilidades de programación? ¿Qué recomendarías a otros que quieran mejorar?

Espero respuestas variadas aquí y no hay una sola respuesta de "talla única". Me gustaría saber qué funcionó para diferentes personas.

En ningún orden específico ...

• Trabajando con personas mucho más inteligentes que yo

• Siempre escuchando lo que otros tienen que decir, independientemente de si son junior, intermedios, senior o gurú. El título del trabajo no significa nada.

• Aprender otros marcos / idiomas, y ver cómo hacen las cosas, y compararlas con cosas que ya sé

• Leer sobre patrones, mejores prácticas y luego examinar mis cosas antiguas y aplicar esos patrones cuando sea necesario

• Programación en pareja

• En desacuerdo con todo lo que dice Joel. ;)

Decidir SER un 'Jack-of-all-Trades'

Al principio de mi carrera, era un experto con una base de datos particular y un lenguaje de programación. Desafortunadamente, esa base de datos en particular perdió las 'guerras de bases de datos', y descubrí que mis opciones de carrera eran ... limitadas. Después de eso, conscientemente decidí que nunca me dejaría encerrar así de nuevo. Así que estudié todo lo que pude tener en mis manos: Windows, Unix, C, C ++, Java, C #, Perl, Python, Access, SQL Server, Oracle, Informix, MySQL, etc. Cualesquiera que sean las herramientas y tecnologías nuevas o inusuales, yo se convirtió en el 'ir al hombre' - "Pregúntale a Craig, si no lo sabe, lo aprenderá". Como resultado, he trabajado en todo tipo de proyectos, desde sistemas integrados para telemetría ambiental hasta sistemas de comando y control para defensa antimisiles.

El único problema que he tenido es con compañías que insisten en hacerme una especialidad, cuando mi especialidad es ser generalista. [EDITAR: También conocido como Polymath o Renaissance Man o multi-especialista. ]

Algo a tener en cuenta ... ¿cuál es la vida media del conocimiento en alta tecnología? Sigue la ley de Moore: la mitad de todo lo que sabes quedará obsoleto en 18-24 meses. Un experto que elige la disciplina equivocada puede ser fácilmente socavado por la prensa de la tecnología; un generalista solo tiene que agregar algunas habilidades más y recordar las lecciones del pasado al aplicar esas habilidades.

Siempre pensé en mí mismo como un programador bastante atractivo. Luego, un nuevo tipo, llamado Aaron, fue contratado en nuestro equipo. Aaron era obviamente mucho mejor que yo en la mayoría de las áreas. Él también era más joven que yo. Me hizo darme cuenta de que realmente no había mejorado mucho en los últimos años. Era un hacker ad-hoc, y mediocre en eso.

Esto me alertó de intentar conscientemente mejorarme a mí mismo y especialmente a la calidad del código que escribo.

Aaron me llevó a aprender muchas cosas. Me enseñó que la mayor parte del código que escribo tendrá que mantenerse y ampliarse durante al menos varios años, por lo que debería escribir el código con eso en mente. Debería escribir pruebas automáticas para mi código. Aaron siempre estaba hablando de cómo nunca debería parar en la primera versión funcional, sino refactorizar y refinar hasta que el código sea elegante. Descubrí que los idiomas y las herramientas que estaba usando tenían mucho margen de mejora.

Lo más importante que aprendí de Aaron fue que nunca dejara de aprender.

Después de un par de años, Aaron dejó la compañía. Me senti vacio. Los últimos años con él me habían llevado a niveles completamente nuevos de habilidad, y me di cuenta de que ahora era mucho mejor que el resto del equipo. Seguían escribiendo códigos incorrectos y cometían los mismos errores que antes. Traté de enseñarles, pero no tenían interés en aprender. De hecho, estaban molestos porque alguien sería tan arrogante para decirles qué errores estaban cometiendo.

Entonces, unos meses después, dejé la compañía también. Me mudé a una empresa más pequeña con un equipo muy talentoso. Todos allí querían aprender más, y me encantó.

Me alegro de haber conocido a Aaron. Sin él, probablemente todavía estaría trabajando en la vieja compañía con la vieja pandilla, yendo a ninguna parte y pensando demasiado en mí mismo.

Dos cosas:

1. Leer el código escrito por diferentes personas.
2. Escriba documentación para el código escrito por otras personas.

Escribir código es extremadamente fácil; cualquier otra persona que conozca puede hacer eso. Pero leer el código de otra persona y descubrir lo que hace fue un mundo completamente nuevo para mí.

Ve al gimnasio regularmente.

En serio, mi cerebro funciona mucho mejor cuando estoy en forma. Los problemas se vuelven más fáciles y menos abrumadores, burlarse es mucho menos una tentación, y trabajar las cosas paso a paso no parece una tarea tan ardua.

Programación. Trabajando en proyectos interesantes. No hay nada como entrar y trabajar en cosas. Especialmente bajo presión. Siempre le digo a cualquiera que me pregunte cómo programar, solo encuentre un proyecto genial (incluso si tiene que inventarlo) y trabaje en él.

Tomé un trabajo de medio tiempo como tutor de estudiantes de CS en mi universidad. Realmente te obliga a entender algo a un nivel completamente diferente cuando tienes que explicárselo a otra persona.

1. Soy un gran admirador del sistema "aprender un lenguaje de programación cada año". Un año le da suficiente tiempo para superar el sesgo de "está bien, conozco la sintaxis, así que ahora sé el idioma", y lo obliga a ir un poco más lejos y comprender lo que es beneficioso en ese idioma, y ​​programar en un estilo nativo para ese lenguaje (con lo que quiero decir, no terminas escribiendo aplicaciones java usando la sintaxis Ruby). Cada lenguaje cambiará su forma de pensar acerca de la programación. Sabía cómo usar la recursividad, pero pensar en la recursión no sucedió hasta que tomé una clase de prólogo (imagino que un lenguaje funcional como ML tendría el mismo efecto).

2. Comience un proyecto de mascotas. Mi ecuación personal para un buen proyecto de mascota es, algo con lo que tengas experiencia + algo que no = aplicación que te resulte útil. Por ejemplo, Migratr (mi propio proyecto de fin de semana con cafeína) comenzó como "Sé C #, pero nunca he codificado contra una API web. Y quiero mover todas mis fotos a Zooomr". Podría haber sido tan fácilmente como "He codificado contra las API web antes, pero no sé C #"

Publicar su proyecto de mascota es una experiencia educativa increíble en sí misma. De repente, todo lo que prácticamente nadie enseña, pero se supone que todos deben saberlo (para mí fue configurar su propio sistema de prueba, aprovechar al máximo los sistemas de control de versiones, cómo mantener el ritmo cuando nadie más establece sus plazos, cómo interactuar con su usuarios y cómo saber cuándo decir "no" a las solicitudes de funciones), todas esas cosas salen a la superficie y te obligan a auto-educarte en un nivel que no estabas antes, al menos no leyendo distraídamente las llamas en dzone sobre el Pros / contras de la forma de hacer las cosas "foo" vs "bar".

Hacer estas dos cosas cubre ambos extremos del espectro. Aprender un nuevo idioma te hará un mejor programador. El proyecto favorito te hará un mejor desarrollador: P

Me enseñé asamblea. ¿Lo hice en un viejo chip 6502 cuando tenía 13 años? 14? Hace mucho tiempo Pero no puedo pensar en nada que mejore su desarrollo más que bajar al nivel de bits.

El ensamblaje de aprendizaje le da una idea de la forma en que las computadoras 'piensan' en un nivel fundamentalmente más bajo, y la elegancia en este nivel es sorprendente ... no hay movimientos desperdiciados, no hay 'disposición' de datos. Desarrollar a este nivel le enseñará eficiencia y perfeccionará sus habilidades de pensamiento crítico y lógica. ¡También lo curará de cualquier hábito descuidado que tenga con bastante rapidez!

El chip 65xx tenía tres registros (el acumulador, X e Y) y no tenía instrucciones de nivel de máquina para multiplicar o dividir. Recuerdo codificar una rutina para calcular el daño de batalla, mirar el libro y de repente me di cuenta de que tendría que escribir mi propia biblioteca de matemáticas. Pasé un par de semanas escribiendo 1 y 0 en todo mi cuaderno, tratando de descubrir qué significaba realmente 'dividir' y 'lugares decimales'.

He estudiado C ++, pascal, .NET, muchos otros desde entonces ... pero ninguno de ellos me ha enseñado tanto, me intrigó tanto o me dejó con la sensación de 'wow' que hizo mi antiguo comodoro. .

Mirando hacia atrás a las cosas viejas que escribí y dándome cuenta de lo malas que eran.

Leer

• libros, no solo sitios web
• para la superación personal, no solo para el último proyecto
• sobre mejorar su comercio, no solo sobre la última tecnología
• lee el código, no solo en lo que estás trabajando.

Simplemente desarrolle el apetito por la lectura.

Programación.

En serio, hay libros, hay katas de codificación, hay sitios como este, pero creo que la mejor manera de mejorar como desarrollador es trabajar en un proyecto real, con clientes reales y volubles con requisitos reales y siempre cambiantes con ingeniería real problemas. No hay sustituto para la experiencia.

Creo que lo más importante que puede hacer es hacer un esfuerzo consciente para mejorar. No hay una sola bala de plata, debe seguir buscando nuevas fuentes de información, nuevas experiencias y más práctica.

Y la segunda cosa más importante, piensa en lo que estás haciendo, por qué lo estás haciendo y cómo puedes hacerlo mejor. Lo mismo con proyectos anteriores. Mire hacia atrás a lo que ha hecho y cómo podría hacerlo de manera diferente ahora. Piense en lo que podría haberse hecho mejor o en dónde podría mejorarlo.

Veo dos grandes ejemplos de esto en el trabajo todos los días. Tengo un compañero de trabajo al que le encanta aprender y quiere ser el mejor desarrollador que pueda. Utiliza cualquier tiempo de inactividad para leer blogs, leer libros, discutir técnicas de programación y hacer toneladas de preguntas. También ha mejorado notablemente en el último año. Otro compañero de trabajo hace su trabajo, y lo hace bastante bien. Pero eso es todo lo que hace. Se apega a lo que sabe, no hace mucho esfuerzo para mejorar, no trabaja en ningún proyecto fuera de los existentes, y después de 4 años, tiene exactamente el mismo conjunto de habilidades y capacidad de programación que tenía cuando conocí él.

Muchas personas han sugerido escribir código. Debo decir que leer el código de otras personas es mucho más beneficioso.

Programado en pareja con personas muy diversas y obstinadas.

Las cosas básicas que me ayudaron como programador:

• Aprendí Touch Typing.
• Aprendió a superar la timidez y hacer preguntas.

Escribir para un programador es esencial. Todos han tenido un compañero de trabajo "programador" que escribió usando exactamente dos dedos y tuvo que mirar el teclado para todo. No es divertido. Aprender a escribir con letra le dará un gran impulso a su productividad como programador.

Y si no preguntas, nadie te lo dirá.

Contribuir / participar en proyectos de código abierto fue, con mucho, lo más importante para mí.

Puede leer todos los libros, el código y los proyectos de código abierto que desee, pero necesita comprender el aspecto del usuario final del desarrollo de software. Necesitas salir de la cámara de eco. Así que abordaré un par de puntos no técnicos que ayudarán a su carrera técnica.

1. Aléjese del teclado e interactúe con el usuario final y vea, a través de sus ojos, cómo usan el software. Los usuarios finales generalmente no son técnicos, por lo que ven el software como un trabajo mágico, mientras que el software es un conjunto lógico de pasos. Los dos mundos son completamente diferentes. Entonces, lo que te parece fácil y lógico puede parecer críptico e intimidante para los demás.

2. Prueba, prueba, prueba. Gran parte del software que he visto en grandes corporaciones utiliza casos de prueba. Demonios, usan JUnit, xUnit y todos los demás lenguajes de prueba de unidades que existen. Pero el problema que he visto es que la mayoría de los programadores nunca ven cómo se ve su software en Producción. Aprenda cómo los usuarios (o sistemas, si estos son trabajos por lotes) interactúan con su aplicación, biblioteca o interfaz para averiguar qué tipo de información aborrecible le arrojan. Esto lo ayudará a generar buenos casos de prueba y dejar de asumir que su programa siempre recibirá el conjunto de datos correcto.

Esquema aprendido

Escribiendo código y mucho.

Aprendizaje de expresiones regulares.

Competir en concursos de algoritmo TopCoder .

Haga todo lo posible: cree su propio proyecto, sus hitos, sus recursos, dependencias, requisitos y plan de prueba. Le obligará no solo a mejorar sus habilidades de programación para operar dentro de parámetros específicos, sino que también servirá para resaltar exactamente dónde más necesita mejorar. Realice actualizaciones periódicas sobre su progreso, ya sea a través de un blog o de actualizaciones de proyectos más formales, para que pueda ver exactamente dónde ha estado y hacia dónde espera ir.

Renuncia a mi último trabajo.

Creo que cuestionar constantemente lo que estás haciendo es lo más importante. Nunca piense que su código es perfecto, siempre trate de mejorarlo.

Parece que tuve 2 o 3 veces cuando pensé que mi código era perfecto, luego me di cuenta de que tenía un largo camino por recorrer.

Supongo que lo más importante fue cuando comencé a ver mi propio código como consumido por otros programadores y no por una máquina. Es fácil escribir código que su máquina pueda procesar, pero es difícil escribir código SECO y comprensible.

Y no me refiero a solo entender "¿Qué hace esta línea?", Me refiero a hacer que sea trivial descubrir "¿Cómo encaja esta clase con todas las otras clases?", Mientras que la interfaz de clases está tan bien formada que es prácticamente imposible mal uso

Dicen que el 70% del buen código es verificación y manejo de errores. Cuando comencé a programar de esa manera, mi código mejoró mucho. Pensar en lo que puede salir mal y luego manejarlo de inmediato ha marcado una gran diferencia. Se siente como hacer todo lo que la comprobación apenas está en el camino de conseguir el código en funcionamiento, pero acorta el tiempo de principio a fin por un factor de 2 a 4.

¿Quiénes son estas personas "ellos" y dónde viven "ellos"?

Mi habilidad de codificación mejoró mucho cuando comencé a preguntarme antes de implementar algo, ¿cómo voy a documentar esto ?

"Cosa" aquí debería tener toda la granularidad posible. Desde el método hasta el producto completo. Por ejemplo, a nivel de método, evita agregar un método en la API que no se ajusta o no está claro, antes de escribirlo. Y si realmente necesito implementar un método que no puedo documentar (fácilmente), es una señal de que hay un problema de diseño en alguna parte ...

Automáticamente, la actitud " si no puedo explicarlo, no lo escribo " filtra el código incorrecto y, por el contrario, una vez que sé cómo documentar una cosa correctamente, se vuelve más simple y limpio de implementar.

Aprende y practica constantemente lo que aprendes.

Por medio de:

1. Proyectos personales: desde que comencé a programar he estado haciendo proyectos personales. Desde pequeños juegos, procesamiento de imágenes, esteganografía, implementación de especificaciones de tipo de archivo, implementación de varios protocolos desde cero o implementación de varios programas a lo largo del tiempo.

2. Leer libros: decidí leer y seguir varios libros en mi tiempo libre. Hay muchos libros bien escritos de expertos que esperan para ser leídos. La profundidad que puede obtener de un libro no tiene comparación, por ejemplo, leyendo varias publicaciones en el foro.

Este suele ser mi orden cronológico de aprender cualquier tecnología nueva:

1. Lea regularmente buenos blogs (Atwood, Martin Fowler, etc.), manténgase al día con las novedades tecnológicas, siga información sobre nuevas e interesantes tecnologías. Estos pasos me permitirán decidir si encuentro algo interesante para explorar más.

2. Lea el libro correcto o cualquier otro recurso para aprender para su nivel (por ejemplo, para principiantes si desea aprender patrones de diseño, sugeriría 'Patrones de diseño de Head First'). También tengo preferencias específicas para libros .

3. Lanza un proyecto de juguete o dos usando lo que aprendí. No me preocupa la utilidad del proyecto. Mi intención es solo explotar mi aprendizaje. (por ejemplo, un proyecto de calculadora para OOP estaría bien)

4. Vería si pudiera usar las cosas en el trabajo . (por ejemplo, aunque no usamos subversión en el trabajo, lo uso como mi repositorio local, utilicé Ruby para una tarea que de otro modo sería demasiado monótona y requeriría mucho tiempo)

5. Esta es la mejor parte que creo que la mayoría de la gente se pierde. Sesiones de intercambio de conocimientos. Dé una o dos sesiones a otros miembros del equipo, por ejemplo. Creo que la enseñanza es una de las mejores maneras de aprender realmente la tecnología. Le garantizo que su nivel de comprensión de la tecnología será múltiple, ya sea que su audiencia lo entienda o no. :-)

Hackear algún proyecto de código abierto durante unos meses; cuanto más grande, mejor. Cuando estás interactuando con algunas personas muy diversas y geográficamente diversas que no te conocen, no puedes evitar aprender de tus errores mucho más rápido; creo que es un cierto factor de vergüenza. Además, si identifica a una o dos personas realmente inteligentes, puede obtener información valiosa, si no conocimiento puro, de ellos.