¿Cuáles son algunas diferencias entre un programador que pasa sus años formativos solo haciendo TopCoder y uno que solo los pasa construyendo proyectos personales?

La misma diferencia que se puede ver entre Mark Zuckerberg y el ganador de la Copa de hackers de Facebook.

Bromas aparte, sigo pensando que es cierto en algún nivel. Al igual que Scott Danzig, dijo que trabajar en proyectos personales le da una idea de la arquitectura del sistema y otros componentes críticos. Creo que si empiezas a crear cosas desde cero o empiezas a optimizarlas, incluso aprendes algoritmos y estructuras de datos.

Por ejemplo, intente diseñar una biblioteca de gráficos de computadora desde cero. No utilice ningún código preexistente. En ese caso, tendrá que encontrar la mejor estructura de datos para mantener los valores de los píxeles. Los algoritmos serán útiles cuando intentes procesar esos píxeles. Esto debería permitirle aprender y apreciar las complejidades de las estructuras de datos y los algoritmos.

Además de las cualidades mencionadas anteriormente, trabajar en proyectos le permite perfeccionar sus habilidades sociales. Esto es especialmente cierto si trabaja en colaboración, lo que ocurre con frecuencia en la comunidad de FOSS. De hecho, si hay algo que he aprendido, es que la codificación es en realidad una parte muy pequeña, aunque crítica, de todo el SDLC. Hay varias fases que en realidad no requieren que se escriba una sola línea de código, pero son extremadamente cruciales para que su proyecto sea un éxito. Algunos de ellos son la recopilación de requisitos y la tormenta de ideas. Si no tienes los requisitos, ¿qué vas a crear.

Si desea crear una aplicación, necesita encontrar un problema potencial para resolver. Esto te enseña el espíritu empresarial. Esto te enseña a buscar lo que falta y no lo que está disponible.

La programación competitiva descuida todo esto. Es un deporte intelectual (aunque extremadamente adictivo). Las dos cosas que te enseña son la lectura de códigos y la resolución rápida de problemas. En la vida real, nadie le pone una pistola en la cabeza y le pide que codifique un problema (a veces se siente así, pero aún así es más relajado que la presión que siente en los SRM). En la programación de coincidencias, debe leer el código ofuscado, intentar decodificarlo, darle sentido y luego romperlo. Esta es una habilidad que te enseña la programación competitiva.

Una cosa en la que la programación competitiva es realmente buena es ayudarlo a conseguir trabajo. ¿Quieres un trabajo en Facebook? Califica para la ronda en el sitio de Facebook HackerCup. ¿Quieres un trabajo en Google? Califica para las finales en el sitio de Google Code Jam. Ayuda a despejar las primeras dos o tres rondas de entrevistas. Puede superar estas competiciones, y sus preguntas de algoritmo. Sin embargo, aún se evaluarán las cualidades que la programación competitiva no le enseña: patrones de diseño, OOAD, bases de datos, sistemas operativos, redes y otras cosas.

Entonces, como puedes ver, si trabajas en proyectos personales, aprendes muchas cosas diferentes. La programación competitiva es un gran pasatiempo, pero creo que debería mantenerse solo eso. El costo de oportunidad de ingresar al costo de otras vías de programación no hace que valga la pena el esfuerzo (al menos según yo).

El que hace TopCoder va a terminar mejor en conceptos como algoritmos y estructuras de datos, mientras que el que trabaja en proyectos personales tendrá una mejor percepción de la arquitectura del sistema, la configuración, las bibliotecas disponibles / proyectos de código abierto, la interfaz de usuario / experiencia. diseño, herramientas y procesos de ingeniería de software, y en realidad lograr que las cosas funcionen juntas.