¿Qué es lo más efectivo que hiciste para mejorar tus habilidades de programación?

876

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.

Oded
fuente
18
Práctica práctica práctica. Y nunca se conforme con lo primero que le viene a la mente.
Mark Ransom
2
+1 para Mark Ransom ... ¡La dificultad viene cuando todavía no estás satisfecho con la centésima cosa que se te ocurrió!
Stimul8d
55
No perder mi tiempo en el sitio Programmers Stack Exchange me ayudó a mejorar enormemente mis habilidades de codificación.
Trabajo
3
@ Mark Trapp, ¿cómo es que esto no es constructivo?
plegado a la derecha el
1
@WTP: lee la descripción. "Esta pregunta no se ajusta bien a nuestro formato de preguntas y respuestas". - Como alguien que hizo esta pregunta, estoy de acuerdo. Fue preguntado en tiempos más relajados.
Oded

Respuestas:

753

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. ;)

cranley
fuente
41
Sé que parece realmente gratuito y potencialmente una mala reputación, pero si separas esos elementos en uno por respuesta, las personas podrían votar con cuáles estuvieron de acuerdo, permitiendo una "solución" más específica para el voto final de esta pregunta.
117
Ver cómo las personas más inteligentes manejan errores - que es cuando me entero de los más de ellos
82
Si se trata de una lista sin ningún orden en particular, ¿no debería ser una lista desordenada en lugar de una ordenada? : P
Jon W
3
Estoy de acuerdo con mmyers, solo porque no estés de acuerdo con alguien no significa que los estés ignorando. En realidad, es todo lo contrario: para estar en desacuerdo con ellos, realmente les estás prestando atención.
Cristián Romo
15
No estoy en desacuerdo con todo lo que dice Joel, creo que muchas veces tiene algunas cosas interesantes que decir. Mi comentario fue la lengua en la mejilla. Hay muchas cosas con las que estoy de acuerdo cuando se trata de Joel, pero aproximadamente una vez al mes me hace sacudir la cabeza y preguntar "¿Qué? ¿Hablas en serio?". Lo cual me encanta, ya que considero que esas son las cosas más desafiantes que me obligan a verificar realmente mi posición y lo que creo.
557

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.

Craig Trader
fuente
224
"Jack de todos los oficios, maestro de ninguno, aunque a menudo mejor que un maestro de uno". -Adam Savage
jms
99
Excelente consejo, votado. La "tecnología huérfana" en mi pasado fue mi Atari de 8 bits, que perdió ante el C64. Sin embargo, llegué a la misma conclusión: para citar a Heinlein, "la especialización es para los insectos".
17
Siempre hay compensaciones, y solo hay 86,400 segundos en un día: tendrá que decidir cómo quiere gastarlos. En mi caso, elegí pasar horas adicionales (más allá de mis horas de "trabajo") para aprender cosas que pensé que eran interesantes o que tendrían demanda en el futuro; deberás tomar tus propias decisiones.
Craig Trader
74
"La especialización es para los insectos". - Heinlein
Kelly S. French
31
¿Dónde está tu insignia "generalista"? ^^
Arnis Lapsa
459

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.

Ville Laurikari
fuente
54
Eso generalmente funciona en ambos sentidos. Entré en algunas compañías ahora como 'Aaron' y descubrí que una vez que los otros codificadores se animan, comienzan a correr por mi dinero y me animan a redoblar mis propios esfuerzos. ¡Buena publicación!
28
+1 para "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"
17
"nunca te detengas en la primera versión de trabajo" ??? - ¿Cuándo se supone que debes hacer el resto de tu trabajo? :)
44
Intenté ser Aaron, a veces funciona, pero a veces me equivoco. "Los que no pueden aprender de la historia están condenados a repetirla". Es bueno mantener nuestras mentes abiertas a nuevas ideas, pero es malo escuchar un n00b sobre aquellos que ya cometieron los errores por usted. Todos necesitamos un poco de escepticismo, ya que aprendemos de hacer preguntas a nosotros mismos y a los demás.
27
El problema es que muchas personas piensan que son "Aaron"
cinqoTimo
257

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í.

Swati
fuente
42
Y una de las mejores maneras de aprender qué NO hacer :)
AviD
99
Puedes ver cómo hacen algo. ¿Quizás lo hacen de una mejor manera que tú?
44
Tuve que profundizar en un proyecto realmente antiguo y completamente indocumentado, documentarlo, corregir algunos errores y portarlo a un nuevo sistema. Aprendí mucho, y no todo fue lo que no debía hacer. Aunque aprendí el valor de los comentarios.
Y mientras escribe la documentación, tal vez escriba algunos casos de prueba unitaria (si no existen). Entonces también sabrás cómo usar el código.
Dhable el
Tan cierto, esa fue la parte más difícil de mi trabajo durante mucho tiempo.
199

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.

Conocer
fuente
30
El triste hecho de que la mayoría de las personas no hace ejercicio ni se estira en absoluto de forma regular es un gran problema en el mundo de hoy.
Sneakyness
55
Extenderé esto, si puedo, a cualquier cantidad de excursión física. A veces, cuando no he hecho mucho trabajo manual durante un tiempo, empiezo a desear el cansancio físico. Es un poco novedoso cuando estás tan acostumbrado a estar mentalmente agotado y te ayuda a salir cuando estás pensando en círculos.
Stimul8d
1
Sí, ese es el gran problema hoy. No tenemos tiempo, especialmente en Pakistán, donde las horas de trabajo son mucho más
maz3tt
2
+1 como un recordatorio para mí mismo de hacer más ejercicio.
SingleNegationElimination
Me parece que un deporte es un gran motivador, para mí es el baloncesto.
Adel
181

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.

usuario13276
fuente
44
Estoy de acuerdo. Ensuciarme las manos en un proyecto ha sido probablemente el mayor contribuyente a mi mejora. ; )
Mike Grace
1
Exactamente. La mejor manera de convertirse en un mejor codificador es codificar. Puedes aprender todo lo que quieras de libros, podcasts y compañeros de trabajo, pero debes aplicarlo antes de que realmente lo entiendas. Codifique más y codifique más cosas diferentes. Porque no aprendes mucho repitiendo el mismo viejo truco.
Elegir proyectos desafiantes e intrigantes para hacer. Creo que la lucha por superar fuera de tu zona de confort realmente acelera tus habilidades. No fueron a la luna porque era fácil.
Kim Jong Woo
172

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.

Bill el lagarto
fuente
1
Puedo responder por eso.
1
Un instructor de la universidad me habló de la apertura cuando aún era estudiante. Me quedé por casi un año (medio tiempo) después de graduarme.
Bill the Lizard el
29
Como Douglas Adams escribe en la "Agencia de detectives holísticos de Dirk Gentley": "la mejor manera es tratar de explicárselo a otra persona. Eso te obliga a resolverlo en tu mente. Y cuanto más lento y tonto sea tu alumno, el más tienes que dividir las cosas en ideas cada vez más simples ".
2
Demasiado cierto. Enseñar fotografía me hizo un mejor fotógrafo. No mucho de un codificador aunque :(
CAD bloke
99
mutuo ista fiunt, et homines dum docent discunt - Seneca
135
  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

escopeta
fuente
Solo puedo estar de acuerdo; "Proyecto de mascotas en un idioma previamente desconocido" es bueno, puedo confirmarlo
Muy buena sugerencia para aprender algo medio familiar.
¡Gran sugerencia "algo con lo que tienes experiencia + algo que no tienes"! Gracias
sica07
Necesito una mascota ahora.
Adel
118

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. .

snogfish
fuente
16
¡Tengo que votarte solo por traer recuerdos maravillosos! Tal vez incluso lloré un poco :)
Charlie Flowers
3
Todavía traduzco mentalmente C / C ++ al lenguaje ensamblador 68K. Es sorprendente cómo eso te ayuda a escribir código eficiente para cualquier plataforma.
Bob Murphy
1
Ah, el 6502, trae buenos recuerdos. Aprendí mucho con ensamblador en este chip.
55
¡CADA estudiante de programación debe tener una exposición profunda al ensamblador temprano en su educación!
2
Hice lo mismo que un joven. Realmente enseñó cómo funcionan las computadoras, más que un lenguaje de alto nivel.
CAD bloke
110

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

Grant Johnson
fuente
Secundo eso ... apenas puedo leer algunas de mis cosas viejas.
Unkwntech
28
Cuando reviso cosas viejas mías, tengo un impulso casi irresistible de eliminar todo el archivo. A veces todo el directorio.
Christopher Mahan
+1 para objetividad. Revisar su antiguo código no le dirá cómo mejorar, solo si ha mejorado y cómo, o por el contrario, si no lo ha hecho.
He hecho esto: escribí todo este intérprete de guiones en VB6, lo escribí durante dos años; podría hacer ventanas, manejar sus eventos, etc. Se hizo tan grande y fuera de control que ya no podía agregarlo sin romperlo todo. Eso fue lo último que escribí antes de abandonar la programación de libros sobre programación. Ahora estoy mucho mejor uf . Posterior de la lectura en ese proyecto monstruo me di cuenta de lo lejos que he llegado
Carson Myers
3
@ Christopher Mahan: Y en muy malas ocasiones, todo el volumen.
Thanatos
93

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.

lamcro
fuente
2
Además, maldita sea, 1. Estaba empezando a preguntarme dónde estaba esta elección.
Thanatos
87

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.

Fishtoaster
fuente
8
Si quieres mejorar en algo, no hay nada mejor que hacerlo.
Jeff Siver
44
+1 - Esto me recuerda a Finding Forrester : "La primera clave para escribir es ... escribir"
Wizard79
2
No hay otra respuesta. Realmente no puedes decir que sabes lo que estás haciendo hasta que hayas escrito un montón de código no trivial y te hayas quedado con algunas iteraciones de producto con los hombres de negocios + los clientes. No sabe / realmente / sabe qué tan bueno es su código hasta que es hora de hacer que cambie para cumplir con los nuevos requisitos.
blucz
1
Definitivamente lo mejor que hice para mejorar mi programación fue conseguir un trabajo.
Matt Ellen
1
Mi conjetura es que la pregunta implícita "además de la programación" ...
UncleZeiv
81

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.

Christopher Cashell
fuente
77
Y probablemente tenga menos habilidad porque parte de su conocimiento se volvió obsoleto ...
72

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

baudtack
fuente
11
una combinación de los dos es en realidad lo que funciona mejor para mí; leer el código de otras personas y refactorizarlo para que sea más legible es un gran ejercicio
Leyendo un buen código, por supuesto ... y entendiéndolo. Y modificarlo, o escribir pruebas para ello.
44
Leer el código es interesante, pero en realidad no se mete debajo de tu piel hasta que realmente lo haces.
Debes HACERLO para aprenderlo. Es como andar en bicicleta ...
70

Programado en pareja con personas muy diversas y obstinadas.

Heath Borders
fuente
La única "experiencia" que tengo con la programación en pareja son las veces que tengo que ayudar a mis colegas. Programo mucho más feliz cuando hay otra persona conmigo para discutir los problemas que enfrento y cómo los resolveré.
mhitza
67

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á.

Nasir
fuente
15
Touch Typing es la habilidad más importante. Los mayores crímenes en la programación han sido cometidos por aquellos que intentan guardar algunas pulsaciones de teclas.
55
Esto supera a todas las otras respuestas, en mi opinión. Escribir te ahorra toneladas de tiempo, lo que significa que puedes pasar más tiempo ingresando código y probándolo. Significa que puede escribir los ejemplos en un libro en lugar de simplemente asentir con la cabeza, seguir adelante y olvidar. Intentar ser un programador con caza y picoteo es como tratar de ser un pianista de concierto haciendo cosquillas en los marfiles con los pies.
Kyralessa
2
He visto personas golpear 15 flechas hacia arriba para recuperar un comando de 2 caracteres. Bastante triste. Es como algunos niños sin IDE ... completamente incompetentes.
77
Para ser contrario aquí, nunca aprendí a tocar la letra. Intenté aprender una vez, pero inmediatamente comencé a sentir dolor en mis muñecas, apoyándolas en el escritorio para asumir que la posición correcta de las manos estaba presionando el importantísimo túnel carpiano. Así que creo que mi selección de tipeo tiene al menos algunas ventajas ergonómicas. Y lo he estado haciendo durante tanto tiempo, solo miro intermitentemente el teclado, por lo que no hay pérdida de productividad real. De todos modos, la mayor parte de mi tiempo no lo paso ingresando caracteres, sino leyendo el código y descubriendo cómo resolver mejor los problemas a medida que surgen.
Eloff
2
Las posiciones de las manos no son importantes; lo importante es que puede escribir sin tener que mirar. En mi computadora portátil no descanso mis muñecas.
56

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

usuario13643
fuente
53

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.

típico
fuente
Cierto. Podrías probar tu (hasta ahora) versión final dejando que un grupo de personas que conoces que no son técnicas lo prueben y escuchar sus comentarios al respecto (asegúrate de elegir uno que no diga "¡Es bueno!", Porque esto obviamente no te ayuda en lo más mínimo.)
48

Esquema aprendido

mbishop
fuente
Sí, ese fue el grande para mí también. También fueron importantes la escritura táctil y la programación de pares.
46

Escribiendo código y mucho.

Oded
fuente
Todos comenzamos a escribir código malo. Si escribes lo suficiente y trabajas en ello, mejorarás. Las revisiones de código ayudan, pero la mejor manera es revisar su propio código.
Lectura de código y mucho.
Stefan
3
Leer y escribir mucho código ... El código abierto es una gran ayuda para nosotros;)
Oded
45

Aprendizaje de expresiones regulares.

Vhaerun
fuente
¡Acabo de hacer esto hace cuatro meses cuando comencé a enseñarme a mí mismo perl! ¡Mi habilidad para usar vim y unix en general se disparó! Asombroso.
sixtyfootersdude
Las expresiones regulares no solo son útiles, sino que también te hacen pensar de una manera diferente.
Tikhon Jelvis
+1. Completamente de acuerdo. Me sorprende que la gente se sorprenda con bastante frecuencia haciendo cosas bastante básicas en vi, sed o grep.
39

Competir en concursos de algoritmo TopCoder .

Paul Reiners
fuente
14
Encuentro TopCoder un poco problemático. OK, lo hace mejor para pensar en algoritmos, pero se ve obligado a trabajar con un estilo incorrecto (todo el código en una clase) y bajo presión de tiempo, por lo que probablemente no hará comentarios ni pruebas. Quizás el Proyecto Euler es la mejor opción.
3
No estás obligado a trabajar con mal estilo; puedes tener tantas clases como quieras. Además, es mejor que pruebe si desea aprobar de manera consistente, ya que una solución que falla en un caso de borde único obtiene cero puntos.
2
@hstoerr - sin mencionar el hecho de que los competidores son recompensados ​​por hacer que su código sea difícil de leer (su solución es más difícil de desafiar)
Shane Fulmer
77
(perdón si esto suena ofensivo) Encuentro que las personas a las que no les gusta Topcoder (u otros concursos similares) intentan inventar razones por las que hacerlo te hará un programador terrible. Está bien si no te gustan. Pero inventar razones espurias no es útil en mi humilde opinión. Ningún concursante serio en TC ofusca intencionalmente el código (en realidad es motivo de descalificación si es atrapado). Veo que muchas personas que no compiten escriben códigos incorrectos todo el tiempo. Los concursos de algoritmos no apuntan a enseñar buenos hábitos de codificación (aprende eso de otro lugar), sino que apuntan a enseñar / desarrollar algo mucho más profundo.
MAK
2
TopCoder es una forma de mostrarte cuánto mejor podrías ser.
38

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.

Magsol
fuente
36

Renuncia a mi último trabajo.

mihn
fuente
2
¡yo también! (necesita algunos caracteres más ...)
66
Si nos diga por qué, esto podría incluso ser una respuesta. ;-)
2
El proyecto de apoyo que se realizó con el marco interno (basado en EJB2) no fue mi idea de diversión. No hay cosas nuevas, solo basura vieja. Y la perspectiva en un nuevo trabajo no es mejor. :(
mihn
He estado allí, hecho eso.
Allbite
+1 Buena suerte consiguiendo un trabajo que no es un callejón sin salida.
Tomek Szpakowicz
29

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

Bill K
fuente
29

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"?

Harold Bamford
fuente
28

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.

kabado
fuente
28

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.

Brian R. Bondy
fuente
10
+1 por mencionar libros. Mucha experiencia no vale mucho si todo se gasta haciendo las cosas mal.
mbillard
27

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. :-)

rpattabi
fuente
24

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.

Robar
fuente