Red de conocimiento informático - Conocimiento informático - Cómo superar los obstáculos de codificación

Cómo superar los obstáculos de codificación

Ericsson propuso que lo importante no es la experiencia en sí, sino el “trabajo duro”, es decir, desafiar constantemente cosas más allá de las propias capacidades. Algunos entusiastas ávidos pasan mucho tiempo jugando ajedrez, golf o instrumentos musicales, pero es posible que siempre permanezcan en el nivel amateur, mientras que un estudiante bien capacitado puede superarlos en un período de tiempo relativamente corto. Vale la pena señalar que pasar mucho tiempo jugando al ajedrez (incluso participando en varias competiciones) parece ser más eficaz que un entrenamiento dedicado para mejorar el nivel. El principal valor de la formación es descubrir los puntos débiles y mejorarlos de forma específica.

"Estudiar mucho" significa lidiar siempre con problemas que están justo al límite de tus capacidades, es decir, cosas que es muy probable que fracasen para ti. Si no experimentas algún fracaso, probablemente no crecerás. Debes desafiarte constantemente y superar tus límites.

Estos desafíos pueden presentarse a veces en el trabajo, pero no necesariamente. Separar el ejercicio del trabajo profesional a menudo se denomina "kata de código" en el mundo de la programación.

El concepto de Code Kata fue propuesto por David Thomas, uno de los autores de "Programmer's Training: From Trader to Expert". Este concepto se refiere principalmente a la práctica repetida de una tecnología o habilidad específica para dominarla. ——Nota del traductor

La llamada rutina es una serie de movimientos. Este concepto está tomado de las artes marciales.

Si desea ver algunos ejemplos de rutinas de codificación (es decir, formas de trabajar duro para aprender y perfeccionar sus habilidades de programación), el artículo de Steve Yegge tiene algunas buenas sugerencias. Él los llama "ejercicios prácticos":

1. Haga una lista de todas las habilidades relevantes que tiene y luego resalte las que seguirán siendo útiles dentro de 100 años. Dale a cada habilidad una puntuación sobre 10.

2. Enumera los programadores que admiras. Intente incluir a las personas con las que trabaja, ya que aprenderá algunas habilidades de ellas en el trabajo. Anota de 1 a 2 puntos brillantes en ellos, que son las áreas que esperas mejorar.

3. Consulte la columna "Ciencias de la Computación" en Wikipedia, busque la categoría "Pioneros en el campo de la informática", seleccione una persona de esta lista, lea sus obras y abra cualquiera de sus enlaces interesantes.

4. Dedica 20 minutos a leer el código de otras personas. Vale la pena leer tanto el código excelente como el código incorrecto. Lea ambos alternativamente. Si no puede sentir la diferencia, pídale a un programador que respete que le muestre qué hace que un código sea excelente y qué hace que un código sea malo. Muestre el código que leyó a los demás y pregúnteles qué piensan.

5. Enumere sus 10 herramientas de programación favoritas: aquellas herramientas que cree que utiliza con más frecuencia y que debe tener. Elija una de estas herramientas al azar y dedique una hora a leer su documentación. Durante esta hora, intenta aprender una nueva característica de esta herramienta que no conocías o descubre una nueva forma de utilizarla.

6. Piénsalo, además de programar, ¿en qué eres mejor? Piénselo de nuevo, ¿cómo llegó a ser tan hábil y profesional? ¿Qué inspiración tiene esto para tu trabajo de programación? (¿Cómo se aplican estas experiencias a la programación?)

7. Saque una pila de currículums y pase una hora en la misma sala con un grupo de entrevistadores. Asegúrese de que cada currículum haya sido visto por al menos 3 entrevistadores y haya recibido una puntuación de 1 a 3 puntos. Analice los currículums que los diferentes entrevistadores juzgan de manera diferente.

8. Participar en una entrevista telefónica. Luego, escriba sus comentarios, ofrezca su perspectiva y luego charle con la persona que realiza la entrevista telefónica para ver si llega a un consenso.

9. Realiza una entrevista técnica, y la persona entrevistada debe ser un experto en un campo del que no sabes mucho. Permítale asumir que la audiencia no sabe nada en el campo, así que pídale que comience con lo básico. Trate de entender lo que dice y haga preguntas si es necesario.

10. Tener la oportunidad de participar en entrevistas técnicas de otras personas. Durante este período, simplemente escuche y estudie con atención.

Mientras el candidato intenta resolver problemas técnicos, usted también debería intentar resolverlos mentalmente.

11. Encuentre a alguien con quien pueda intercambiar problemas prácticos. Cada dos semanas, intercambien problemas de programación. Dedique de 10 a 15 minutos a intentar resolver estos problemas y otros 10 a 15 minutos a discutirlos (si se pueden resolver o no).

12. Cuando escuche alguna pregunta de la entrevista que no pueda resolver de inmediato, regrese a su asiento y envíese la pregunta por correo electrónico como recordatorio en el futuro. Encuentra algo de tiempo durante esa semana para abordarlo en tu lenguaje de programación favorito.

Lo que me gusta de la lista de Steve es que parece completa. Cuando algunos programadores piensan en "ejercicio", siempre piensan en algunos problemas de codificación. Pero en mi opinión, la programación se trata más de personas que de código. Por lo tanto, existe un límite en cuanto a cuánto puede mejorar sus habilidades personales resolviendo todas las preguntas oscuras de las entrevistas de programación del mundo.

En cuanto a "aprender mucho", también me gustan muchas de las sugerencias presentadas por Peter Norvig en el artículo "Aprenda usted mismo a programar en diez años" (dedique 10 años a aprender a programar usted mismo):

1. Habla con otros programadores. Leer el código de otras personas. Esto es más importante que cualquier libro o curso de formación.

2. ¡Empieza a escribir programas! La mejor manera de aprender es aprender haciendo.

3. Tome cursos de programación como parte de un programa de pregrado o posgrado.

4. Encuentre proyectos en los que trabajar que requieran trabajo en equipo con otros programadores. A medida que avanza el proyecto, aprenda a identificar a los mejores y peores programadores.

5. Trabaje con otros programadores en proyectos, aprenda a mantener código que usted no escribió y aprenda a escribir código que otros puedan mantener.

6. Aprenda una variedad de lenguajes de programación diferentes, especialmente aquellos que tienen una visión del mundo y un modelo de programación diferentes a los que conoce ahora.

7. Comprender el impacto del hardware sobre el software. Sepa cuánto tiempo le toma a su computadora ejecutar una instrucción, cuánto tiempo le toma recuperar una palabra de la memoria (con o sin caché), cuánto tiempo le toma transferir datos a través de Ethernet (o Internet), cuánto tiempo le toma leer desde el disco ¿Cuánto tiempo se tarda en recuperar datos consecutivos o saltar a otra ubicación en el disco, etc.?

También puedes inspirarte en las 21 rutinas prácticas de codificación de Dave Thomas (CodeKata.com), o prefieres unirte a un "dojo de codificación" local (CodingDojo.org).

No puedo ofrecer una lista de sugerencias tan larga como Steve, Peter o Dave para "estudiar mucho". Soy mucho menos paciente que ellos. De hecho, en mi opinión, las "rutinas de programación" sólo requieren dos pasos:

1. Comencé el blog CodingHorror.com a principios de 2004 como una forma de mi propio esfuerzo por aprender. Comenzó muy humilde y resultó ser lo más importante que he hecho en mi carrera. Entonces, tú también deberías bloguear. Al final, las personas que "escuchan y llegan al mundo" suelen ser aquellas que pueden escribir y comunicarse eficazmente. Sus voces son las más fuertes, están fijando las reglas del juego y liderando las tendencias mundiales.

2. Participar activamente en proyectos famosos de código abierto. Toda esa charla suena genial, pero ¿eres un conversador o un hacedor? No te limites a hablar, esto es muy importante porque la gente te juzgará por tus acciones, no por tus palabras. Intenta dejar algo tangible y útil a la vista del público para que puedas decir: "Yo ayudé con ese proyecto".

Cuando puedas escribir un código excelente y cuando puedas explicar esos códigos al mundo con palabras maravillosas. En otras palabras, en ese momento sentiré que has dominado la rutina de codificación más increíble.

El artículo proviene de Jianshu