Un buen desarrollador.

Últimamente me he topado y he pensado en varias de las cosas, que generalmente la escuela no te enseña, y que te convierten en un buen desarrollador, y es que por la naturaleza de una escuela (evaluaciones, tiempos, semestres, finales) es casi imposible trabajar en los detalles de un proyecto, casi siempre, al final, todo se limita a si funciona o no, si cumple lo que el maestro pidió o no.
Durante la carrera (y a veces fuera de ella) he escuchado muchas veces la frase "lo importante es que funcione", la realidad, en la vida profesional es otra, que funcione es sólo el primer paso, y generalmente es lo más sencillo.
Aquí presento una de las cosas que me parecen hacen a un programador pasar de los proyectos casuales a un trabajo más profesional, estoy seguro de que habrá otros, o probablemente haya quien no concuerde con ellos, ojalá puedan dejar sus opiniones en los comentarios :)

Testing

Hay malos programadores, buenos programadores y programadores que hacen testing del código que escriben. Hacer testing automático, puede resultar laborioso al principio, sin embargo, acarrea muchos beneficios, el más claro de ellos es, menos bugs, y es claro que si tu código fue probado, es menos probable que falle. El otro beneficio es que, todos los programadores hacen testing, sí, pero manual, cada que recargas la página para ver si funcionó lo que hiciste, o pones una variable por ahí de debugging para ver si se entró a un ciclo o una condición, estás haciendo testing, pero de nuevo, lo hacemos manualmente, automatizarlo significa que ahorramos tiempo, dejando que el mismo código pruebe el código.
Supongo que al principio es difícil, porque el código tiene niveles de complejidad, y así igual los tests, hay código que es más difícil de testear, y en ocasiones hay que ser tan creativo para escribir código como para testearlo. Ésta, es una práctica, que como todas, se desarrolla llevándola a cabo, practicando.

POO

No es que la programación orientada a objetos sea muy complicada, de hecho nos enseñan POO en todas las universidades, además de que hay N cursos en línea, artículos y más. Sin embargo, en mi experiencia, uno nunca deja de aprender conceptos de objetos. Al principio empezamos creando clases, tal vez después comencemos a heredar una que otra cosa, posteriormente a usar interfaces, a encapsular los datos, sobrecargar métodos; posteriormente tal vez empezamos a crear módulos, tal vez nos demos cuenta que un objeto sabe mucho de otro objeto y creemos clases que los relacionen. Aún después, te enteras de que existen cosas como la Ley de Demeter(http://es.wikipedia.org/wiki/Ley_de_Demeter), y otras más. 
Lo que quiero decir es que entre más objetos escribes, te vuelves mejor desarrollador, te vuelves mejor definiendo clases, métodos, alcance de los atributos, etc. etc. etc.

Escalabilidad

Por la naturaleza de los primeros proyectos que escribimos, no nos desarrollamos pensando en problemas de escalabilidad, rendimiento o velocidad. Más aún, cuando presentas un proyecto en la universidad, no serás sometido ni a 50 usuarios concurrentes, además de que al maestro no le importará si el sitio carga en 10 segundos, en 20 o en 2. En el mundo real, todo lo antes descrito pasa, y las empresas, startups, iniciativas, esperan estar preparadas para todo eso, esperan que su sitio esté online 100% del tiempo, esperan que su sitio sea veloz. Aquí es donde queda más claro que lo importante no es sólo si funciona, si no qué tan bien funciona, aquí es donde podemos darnos cuenta que hay niveles de funcionamiento, no todo lo que "funciona" está bien hecho.
Un proyecto de la vida real debe estar preparado para crecer, no necesariamente para millones de usuarios concurrentes, pero sí miles, o mejor aún cientos de miles. Y sobre todo, si al principio no está listo, debe estar diseñado para poder escalarlo después.

Mantenimiento.

¿Qué caso tiene definir bien o mal las clases de nuestro proyecto? O mantener conceptos como DRY(http://en.wikipedia.org/wiki/Don%27t_repeat_yourself) si a final de cuentas, si funciona o no, no necesariamente depende de eso... bueno, la respuesta es, mantenimiento. Por supuesto que me refiero a mantenimiento de software; en la escuela terminas un proyecto y listo, rara vez vuelves a saber de él. En la vida real, encuentras bugs en producción que tiran el sitio o la app, te mandan a resolver el error del código de otro programador, o a agregar un nuevo feature a ése proyecto de miles de líneas. Esas cosas pasan siempre, y en ese momento agradecerás al yo de tu pasado, o cualquiera que sea el anterior programador, el que haya diseñado el código apropiadamente, que haya utilizado patrones de diseño, etc. Básicamente que hayas escrito código limpio, porque si lo haces, agregar nuevas cosas o resolver errores será mucho más fácil.

¿Qué más?

Hay muchas más cosas que diferencían a un buen desarrollador de uno promedio, por ahora dejaré éstas por aquí (son las que consideré, sé que un buen desarrollador sabrá otras) ¿por qué? Es sólo algo que he visto mucho últimamente, es algo que sé las empresas pedirán cuando busquen contratarte, es algo que me ha hecho leer y revisar lo que he escrito antes, así que, nunca es muy pronto para empezar a aplicar buenas prácticas, así que no importa que tanto o poco código hayas escrito, puedes ya a empezar a convertirte en el futuro Facebook developer, Google developer, o quién sabe qué quieras hacer. Porque eso sí, programadores hay pocos, pero buenos programadores hay todavía menos, por lo que las empresas los pelean, los buscan, les ofrecen las maravillas del mundo, y estoy seguro que varios de ustedes querrán estar en esa situación ;)