Esta es una historia real, sobre mí mismo. ¿Cómo un ser racional llegó paso a paso a la locura?

Vestía traje, sentado en la oficina, con una vaga idea de negocio en la cabeza. Entonces, decidí aprender programación. Una vez escuché a varias personas alardeando de cómo usaban un lenguaje llamado Ruby para automatizar fácilmente el trabajo de oficina. Pensé: “Ja, Ruby”. Llegué a casa, busqué Ruby en Google. Quince segundos después, elegí un tutorial de Ruby al azar y empecé a aprender.

Una semana después, asistí a mi primer encuentro de hackers. Todos allí estaban hablando de Scala, Clojure, Go, etc. Pensé: “Cuánto han aprendido”. Me di la vuelta y tomé prestados tres libros de O’Reilly, y leí unas 50 páginas de cada uno.

¿Qué? ¿Me preguntas por qué no terminé un libro completo? Porque cada libro empieza siendo fácil de entender, pero luego comienza a hacer suposiciones: asume que ya tienes cierto conocimiento, asume que sabes usar tal herramienta, ¡y yo no sabía nada de eso!

Un amigo me dijo que debería aprender Emacs y me dio su archivo de configuración. Pasé varias horas aprendiendo la sintaxis básica de Lisp para poder configurarlo yo mismo.

Entonces una persona pasó a mi lado, me vio usando Emacs y preguntó: “¿Cómo puedes seguir usando Emacs? (imagina la expresión) ¿No sabes que Vim es mejor?” Pensé: “Ja, Vim”. Así que empecé a memorizar las innumerables combinaciones de teclado de Vim.

Los ingenieros suelen debatir este tema: ¿cuál es el mejor editor de texto? Lo consideran una guerra de religión: el criterio no son estándares objetivos, sino divisiones históricas.

En ese entonces, pensaba que si tecleaba más rápido, programaría más rápido. Así que abandoné la distribución de teclado tradicional y adopté la distribución Dvorak, imprescindible para programadores (como se muestra abajo). Objetivamente, es la distribución de teclado más eficiente para un programador.

Mirando la distribución de teclado anterior, ¿puedes decirme cuántas teclas de letras, números y caracteres especiales no cambiaron de posición? La respuesta es de un solo dígito.

Cuando logré iniciar Linux con éxito y pude teclear diez palabras por minuto, empecé a aprender Python mediante libros y los cursos de Udacity.

Después de siete meses de dura batalla, obtuve mi primer trabajo como ingeniero de software.

Cuando el CTO me entrevistó, le conté todas las herramientas que había aprendido y mis elegantes archivos de configuración. El CTO me escuchó cortésmente, asintiendo de vez en cuando. Después de que presumí de mis vastos conocimientos, me miró y dijo: “En realidad, la mayoría de las cosas tienen muchas soluciones, pero solo una pequeñísima parte de ellas tienen sentido”.

Hace cuatro años, la empresa donde trabajaba decidió construir su producto con Ruby on Rails. Ningún ingeniero objetó la elección del lenguaje; hoy, gran parte de su código original sigue funcionando. Todos los ingenieros usan MacBook porque es confiable y muy similar a los servidores Ubuntu Linux que usan en producción. Aquí nadie discute si Vim o Emacs es mejor; todos usan RubyMine, un potente IDE con una excelente configuración por defecto. Como todos usan exactamente las mismas herramientas, cualquiera puede elegir un asiento al azar y comenzar a programar en pareja con el compañero de al lado sin preocuparse por la configuración del entorno. Usar configuraciones idénticas facilita enormemente la colaboración entre desarrolladores.

Aunque yo no sabía Ruby on Rails, la empresa consideró que podía desempeñar el trabajo. Como sabía Python y Django, y había ganado un hackathon, la empresa pensó que eso demostraba mi capacidad.

Las primeras semanas fueron realmente difíciles. No solo por llegar a un equipo nuevo, usar un lenguaje nuevo, un framework nuevo y una base de código nueva, sino porque descubrí que quienes me rodeaban aprendían a programar con una actitud casi autodestructiva.

Pasé varios meses solo en bibliotecas y cafeterías, instalando herramientas a ciegas desde la línea de comandos, depurando controladores de Linux y resolviendo problemas insignificantes, como paréntesis que no coincidían. Me inscribí en todos los cursos en línea que se me ocurrían y en innumerables cursos MOOC. Creo que en realidad no aprendí nada, hasta que en una evaluación mensual subí al quinto puesto. Estas experiencias me dieron la impresión de que la programación es una batalla que nunca puedes ganar. Empecé a comprender que el pasado de los programadores aparentemente normales era en realidad muy oscuro; habían pasado por demasiado y reprimido demasiado. Hay que admitir que aprender a programar es una actividad antisocial.

El primer fin de semana después de dejar mi anterior trabajo, subí esta selfie. Ese día me levanté temprano y me puse un traje elegante; el traje era para recordarme: soy una persona que va a aprender a programar. El comentario de Facebook decía: “Mi nueva oficina: la mesa del comedor. Llevo una vida de 8 a 6, y solo descanso cuando es imprescindible”. En la vida, aprendí a hablar como un programador y a pensar como uno; ahora, ya me he acostumbrado a esa palabra.

Mis colegas casi nunca veían errores de sintaxis, porque su IDE los resolvía por ellos. Cuando se topaban con un mensaje de error y no podían resolverlo en unos minutos, enviaban un mensaje instantáneo a otro compañero pidiendo ayuda. Se acercaban sin problema al escritorio de alguien y empezaban a programar en pareja. Los programadores de aquí no son demasiado egocéntricos ni se consideran una élite. Tampoco piensan que programar es algo doloroso. Solo hay conversaciones constructivas entre amigos adultos.

Las herramientas que usan los miembros de un equipo son altamente consistentes. En proyectos de pasión y hackatones, los desarrolladores pueden usar nuevos frameworks de JavaScript, como Angular.js. Pero en un equipo real, los miembros se centran principalmente en usar tecnologías existentes para mejorar el producto. Desde ese punto de vista, son conservadores.

En ThoughtBot verás una situación similar. En ThoughtBot, todos se adhieren a un pequeño y eficiente conjunto de herramientas (Rails, Vim, Postgres y Redis). Como el conjunto es pequeño, es fácil para los ingenieros convertirse en expertos en esa área; y como todos usan el mismo conjunto, la interoperación entre ellos se vuelve muy fácil.

La verdadera pregunta es: si los equipos eficientes son más productivos con un conjunto de herramientas pequeño y fijo, ¿será también mejor para las personas que aprenden a programar usar un conjunto pequeño y fijo? Los cursos de programación en línea y los bootcamps claramente piensan que sí.

Pero como individuo, hay tantas herramientas entre las que elegir que es realmente difícil decidir. Lo sé porque lo he vivido. El conjunto de habilidades de un buen programador se puede representar con una forma de T: abarca muchos campos, pero solo es realmente experto en pocos. Sin embargo, con la acumulación de años, la T se convierte lentamente en una forma de guion bajo.

He conocido a muchas personas que aprenden programación y quieren aprenderlo todo de entrada, ser buenos en todo. Al final, todos fracasaron y abandonaron su sueño de convertirse en programadores. No quiero que esto te pase a ti.

Necesitas concentrarte más.

Sin más preámbulos, a continuación presento algunos grandes errores que los principiantes suelen cometer:

• Pasar de un lenguaje a otro, saltar de un framework a otro, o engañarte creyendo que puedes dominar todos los lenguajes y frameworks.
• Usar herramientas de nicho para configurar tu entorno de desarrollo, en lugar de elegir herramientas tradicionales y confiables.
• Aprender herramientas como Docker y Famo.us solo porque son novedosas, aunque aún no domines tecnologías más básicas.

Si tuviera que resumir mi consejo en una palabra, diría: enfoque.

Te pregunto: ¿usarías la palabra “enfoque” para describir tu plan de aprendizaje de programación? Si crees que tu plan es lo suficientemente enfocado, bien, puedes dejar de leer ahora y volver a tu plan para empezar a aprender, porque no quiero decir nada que pueda hacerte perder el enfoque.

Si tu plan no es lo suficientemente enfocado, también tienes suerte: haz lo que te digo y podrás enfocarte, pero te tomará unos minutos tomar algunas decisiones difíciles. ¡Espera, no se vayan!

Bien, todavía estás aquí. A continuación, las decisiones difíciles que debes tomar.

1. Elige un tipo de software: aplicación web, aplicación móvil, juego o embebido. Recomiendo las aplicaciones web porque son flexibles, hay muchos recursos para aprender y las oportunidades laborales son innumerables. Si tu interés no está en las aplicaciones web, cierra esta página, escribe “getting started in _____ development” en el cuadro de búsqueda de Google y revisa los resultados uno por uno.
2. Elige un lenguaje de programación: JavaScript, Ruby o Python. Cada uno tiene sus puntos fuertes y cuenta con herramientas correspondientes para construir aplicaciones web (Node.js, Rails o Django, respectivamente). A menos que sepas con claridad cuál deberías aprender, te recomiendo JavaScript, porque es el más usado.
3. Elige un curso en línea. Aquí tienes algunas opciones: si te interesa JavaScript, busca en FreeCodeCamp.com o NodeSchool.io; si te interesa Ruby, busca en TheOdinProject.com o TeamTreehouse.com; si te interesa Python, busca en Udacity.com. Confía en la sabiduría de quienes diseñaron estos cursos y completa el curso en el orden sugerido, sin saltarte nada.
4. Compra un MacBook nuevo o usado, o instala Ubuntu Linux en tu computadora actual. Para cualquier otra herramienta que necesites, instálala siguiendo las recomendaciones del curso en línea.

Una vez que tomes estas decisiones, el resto del camino será muy sencillo. Solo mantente sobrio, no te dejes seducir por las nuevas herramientas que te rodean. Todos los días de la semana, estudia un poco el curso en línea, aunque sea solo media hora. Confía en las decisiones que tomaste hoy. Por último, recuerda: con paciencia, cualquier persona capaz puede convertirse en un coder excepcional, y por supuesto, tú también.

Fuente: http://code.csdn.net/news/2822796