Después de un par de años estudiando y programando en Perl, un día me llegó la gran interrogante: "¿soy un buen programador?" No hay un sistema 100% fiable para examinar a alguien y decidir si tiene un verdadero conocimiento de programación, pero desde mi punto de vista, eres un buen developer por una simple cosa: RESULTADOS. Así que estas son las cuatros habilidades que deberías poseer si te consideras un buen programador.
- Si comentas tu código más de lo estrictamente necesario no eres buen programador. normalmente no hace falta ningún comentario para que el código sea legible, si acaso unos buenos tests.
- si no sabes discutir sobre el código con personas no eres buen programador.
- si no disfrutas programando no eres buen programador.
Pensaba que iba a convertirse en la típica retahíla de acrónimos, plataformas, tecnologías o metodologías de moda que algunos "profesionales" o empresas exigen y se marcan a fuego en la piel. Pero lo que describe son cualidades indispensables.
Yo me preguntaría: ¿soy un buen programador profesional?
Recalco lo de "profesional" porque el programador, por encima de las cualidades específicas de su puesto, necesita tener las de todo trabajador en un entorno empresarial. A saber, entre otras:
-Responsabilidad.
-Capacidad de comunicación.
-Trabajo en equipo y cooperación.
-Honradez.
-Previsión y planificación.
Lo digo porque llevo muchos años en el sector y he visto a muchos "gurús" que se creen unos programadores cojonudos, por encima del resto de los mortales, pero a los que nadie quería en su equipo por carecer de una o varias (o todas) estas cualidades que señalo. No me sirve de nada un friki capaz de programar en binario con los ojos cerrados, si después no es capaz de transmitir su trabajo a sus compañeros, o reportar a su responsable sobre el progreso de su trabajo, o alertar de un problema que detecta.
La clase "programador" hereda de la clase "profesional", que a su vez hereda de la clase "persona".
¿Soy un buen programador? No lo sé. Suelen enviarnos a todos a la puta calle en cuanto acaba un proyecto con la misma facilidad con las que nos contrataron; sin importar si éramos buenos o malos. Cuando todos cobramos una miseria también se hace difícil saber si eres un buen programador. O cuando estás siempre con el miedo en el cuerpo a que te despidan y te sustituyan por otro si te atreves a quejarte de que no te pagan horas extra. Cuando todos los proyectos tienen un plazo de entrega ridiculamente corto. Cuando los comerciales no tienen huevos a decirle al cliente que sus especificaciones son estúpidas, sobre todo si el cliente es una administración pública. En resumen: Nunca he estado los suficientemente tranquilo y durante el suficiente tiempo para que un superior o yo mismo pudiera evaluar si soy un buen programador.
A mi modo de ver los cuatro puntos que señala el artículo son condiciones indispensables para ser un programador decente. Para ser bueno de verdad seguro que hace falta algo más pero, como ya he dicho, no lo sé.
Yo ya estoy pensando en estudiar hostelería o algo.
Bueno, el artículo es bastante obvio.
Yo añadiría unas cuantas cosas más:
Proactividad. Sé que se ha abusado mucho de esta palabra desde la dirección de equipos, pero en sí misma, es una virtud para un desarrollador, y una bendición para los QA que trabajen con él. Podría ser entendida como 'creatividad', pero va más allá. Se trata de adelantarse a las tareas. Y pongo un ejemplo: me ha tocado la última semana implementar el francés en un sistema de más de 100.000 lineas de código.
Al llegar a ciertas frases, resulta que el developer anterior aplicó una lógica tal que así: si no es español, es inglés, y si no es inglés, es español, y como soy más machote que nadie, paso de evaluar el isocode mediante un algoritmo escalable: si no es una cosa, es otra. Y al que tenga que meter una tercera (usease, muá) que se devane los sesos metiendo doses a un sistema binario. Obviamente, ni se puede, ni se debe: refactor, esa palabra maldita que hace temblar los cimientos de la misma Silicon Valley.
Otro grupo de frases debía hacerse desde diseño, con lo que les paso los copys. En este caso, curiosamente, unos días antes le llegó al mismo diseñador la tarea de cambiar los números que salían en esas frases para inglés y español. Vale. Pasa el rato y me llega el resultado de QA: las frases muy bien generadas, pero los números son los antiguos. Y lo mejor: son las cinco y 1 de la tarde y el diseñador ya se ha ido a su casa. Pues nada, me ves a mi abriendo photoshop para exportar unos pngs con el número güeno, porque el megadiseñador de la muerte ha puesto el automático mientras hacía la tarea y no ha recordado que dos dias antes tuvo que cambiarlas.
Adaptación. Pongo esto porque es donde muchos fallamos. Muchas veces nos encontramos inmersos en sistemas que controlamos, y de golpe y porrazo, nos cambian a otro. Por ejemplo, al cambiar de plataforma, de web a móvil, etc... Todo sistema tiene sus potencias y sus debilidades, igual que tú, como persona: se trata de saber encajar la potencia del sistema en el que trabajas con la potencia que tú como desarrollador puedes aportar al desarrollo del mismo. No ver muros: ver formas de saltarlos. Un servidor falla en esto, a veces. Tiendo a quejarme y a maldecir a windows, a Adobe, a Oracle, a Samsung... pero se trata de buscar la solución al problema, no centrarse en el problema, porque es una pérdida de tiempo.
Un lenguaje de programación no es sólo programar: es conocer las herramientas con las que programas, y saber usarlas. Eclipse es una herramienta brutal, pero si no sabes qué distribución y plugins usar para tus proyectos, no harás bien algunas tareas. Puedes programarlas muy bien, pero no sólo es necesario saber Java para hacer y mantener una aplicación Java con STS: hay que saber los modelos de build de maven, lo que es jenkins, lo que es json.... es decir, una visión global y conocimiento del entorno de trabajo.
Si haces webs y usas Aptana, (por ejemplo), te entrará la risa tonta cuando alguien te dice 'vengo de dreamweaver, eclipse no será tan difícil'. No se trata de dificultad, se trata de saber manejarte en el entorno en que te mueves.
Humildad. No es necesario ser humilde para ser buen programador, pero saber que no lo sabes todo, y aceptar que quien te rodea también sabe, no sólo facilita el trabajo en equipo, sino que te ubica en una posición ortodoxa que te da criterio a la hora de delegar ciertas tareas, o consultar su funcionamiento, a quien sabes que las hará mejor o más rápido, o que ya las ha hecho. No seas un programador Sith: el conocimiento lleva al orgullo, el orgullo lleva al sarcasmo, el sarcasmo a la soledad, y la soledad al olvido. El olvido romperá tus cadenas, pero nadie estará ahí para celebrarlo.
#10 Con la humildad haz tocado un punto indispensable. Conozco genios de la programación que por su carácter y dificultad para trabajar en grupo, pocos desean trabajar con ellos.
No soy developer, pero sí intento ser DBA (intento porque aunque en la práctica ejerza, me falta mucho trecho) Sin embargo he trabajado con algunos desarrolladores, unos muy buenos y otros muy malos. Ergo, concuerdo con varios de estos puntos: Un buen developer se mide por los resultados, no por las portadas de revistas en que aparezca o las charlas dadas. Igualmente, también estoy muy de acuerdo en que un buen desarrollador debe ser creativo y dar soluciones rápidas. Esto es muy importante, tanto como estar dispuesto a consultar a otros y no creer que lo sabe todo.
Hola, no soy programador pero tengo contacto por mi trabajo con ellos. Sin duda la preparación de la persona y su experiencia (supongo que como en todos los trabajos) es fundamental Buen artículo.
Lo de la consulta es fundamental, si en una entrevista de trabajo pregunto a alguien si ha utilizado hibernate y me dice "¿es un orm no? pues será igual que todos" o sobre cualquier otra cosa y me dice que lo mira y se pone con ello que no será tan complicado le contrato de cabeza, si le digo que si sabe spring 3 y me dice que sólo ha usado el 2.1.3 y que se tendrá que mirar un libro me echo a temblar
Falta la más importante: Conocimiento del problema a resolver. De nada sirve que seas creativo, que tengas conocimientos o que cumplas plazos si todo el trabajo se ha basado en medias verdades o directamente mentiras. Oh, cambios de última hora.
El graaaaan problema es que la mayoría de las veces el programador no tiene contacto directo con el cliente y el que recoge las especificaciones no es programador, no hace las preguntas adecuadas y el cliente no dice las cosas adecuadas.
Si mejoráramos en toma de datos el software mejoraría un 500%
Comentarios
Cuatro obviedades sin más.
- Si comentas tu código más de lo estrictamente necesario no eres buen programador. normalmente no hace falta ningún comentario para que el código sea legible, si acaso unos buenos tests.
- si no sabes discutir sobre el código con personas no eres buen programador.
- si no disfrutas programando no eres buen programador.
Siguiente entrega: "Soy gay?"
#6 Jajajajajaja
"Me gusta" +1
Pensaba que iba a convertirse en la típica retahíla de acrónimos, plataformas, tecnologías o metodologías de moda que algunos "profesionales" o empresas exigen y se marcan a fuego en la piel. Pero lo que describe son cualidades indispensables.
Yo me preguntaría: ¿soy un buen programador profesional?
Recalco lo de "profesional" porque el programador, por encima de las cualidades específicas de su puesto, necesita tener las de todo trabajador en un entorno empresarial. A saber, entre otras:
-Responsabilidad.
-Capacidad de comunicación.
-Trabajo en equipo y cooperación.
-Honradez.
-Previsión y planificación.
Lo digo porque llevo muchos años en el sector y he visto a muchos "gurús" que se creen unos programadores cojonudos, por encima del resto de los mortales, pero a los que nadie quería en su equipo por carecer de una o varias (o todas) estas cualidades que señalo. No me sirve de nada un friki capaz de programar en binario con los ojos cerrados, si después no es capaz de transmitir su trabajo a sus compañeros, o reportar a su responsable sobre el progreso de su trabajo, o alertar de un problema que detecta.
La clase "programador" hereda de la clase "profesional", que a su vez hereda de la clase "persona".
¿Soy un buen programador? No lo sé. Suelen enviarnos a todos a la puta calle en cuanto acaba un proyecto con la misma facilidad con las que nos contrataron; sin importar si éramos buenos o malos. Cuando todos cobramos una miseria también se hace difícil saber si eres un buen programador. O cuando estás siempre con el miedo en el cuerpo a que te despidan y te sustituyan por otro si te atreves a quejarte de que no te pagan horas extra. Cuando todos los proyectos tienen un plazo de entrega ridiculamente corto. Cuando los comerciales no tienen huevos a decirle al cliente que sus especificaciones son estúpidas, sobre todo si el cliente es una administración pública. En resumen: Nunca he estado los suficientemente tranquilo y durante el suficiente tiempo para que un superior o yo mismo pudiera evaluar si soy un buen programador.
A mi modo de ver los cuatro puntos que señala el artículo son condiciones indispensables para ser un programador decente. Para ser bueno de verdad seguro que hace falta algo más pero, como ya he dicho, no lo sé.
Yo ya estoy pensando en estudiar hostelería o algo.
#8 Puedes llegar a ser bueno si programas de forma recreacional, como hobby.
Programando a toda prisa con presiones, nunca.
Los mejores proyectos, en mi caso, salen en casa a mi ritmo sin agobios.
Bueno, el artículo es bastante obvio.
Yo añadiría unas cuantas cosas más:
Proactividad. Sé que se ha abusado mucho de esta palabra desde la dirección de equipos, pero en sí misma, es una virtud para un desarrollador, y una bendición para los QA que trabajen con él. Podría ser entendida como 'creatividad', pero va más allá. Se trata de adelantarse a las tareas. Y pongo un ejemplo: me ha tocado la última semana implementar el francés en un sistema de más de 100.000 lineas de código.
Al llegar a ciertas frases, resulta que el developer anterior aplicó una lógica tal que así: si no es español, es inglés, y si no es inglés, es español, y como soy más machote que nadie, paso de evaluar el isocode mediante un algoritmo escalable: si no es una cosa, es otra. Y al que tenga que meter una tercera (usease, muá) que se devane los sesos metiendo doses a un sistema binario. Obviamente, ni se puede, ni se debe: refactor, esa palabra maldita que hace temblar los cimientos de la misma Silicon Valley.
Otro grupo de frases debía hacerse desde diseño, con lo que les paso los copys. En este caso, curiosamente, unos días antes le llegó al mismo diseñador la tarea de cambiar los números que salían en esas frases para inglés y español. Vale. Pasa el rato y me llega el resultado de QA: las frases muy bien generadas, pero los números son los antiguos. Y lo mejor: son las cinco y 1 de la tarde y el diseñador ya se ha ido a su casa. Pues nada, me ves a mi abriendo photoshop para exportar unos pngs con el número güeno, porque el megadiseñador de la muerte ha puesto el automático mientras hacía la tarea y no ha recordado que dos dias antes tuvo que cambiarlas.
Adaptación. Pongo esto porque es donde muchos fallamos. Muchas veces nos encontramos inmersos en sistemas que controlamos, y de golpe y porrazo, nos cambian a otro. Por ejemplo, al cambiar de plataforma, de web a móvil, etc... Todo sistema tiene sus potencias y sus debilidades, igual que tú, como persona: se trata de saber encajar la potencia del sistema en el que trabajas con la potencia que tú como desarrollador puedes aportar al desarrollo del mismo. No ver muros: ver formas de saltarlos. Un servidor falla en esto, a veces. Tiendo a quejarme y a maldecir a windows, a Adobe, a Oracle, a Samsung... pero se trata de buscar la solución al problema, no centrarse en el problema, porque es una pérdida de tiempo.
Un lenguaje de programación no es sólo programar: es conocer las herramientas con las que programas, y saber usarlas. Eclipse es una herramienta brutal, pero si no sabes qué distribución y plugins usar para tus proyectos, no harás bien algunas tareas. Puedes programarlas muy bien, pero no sólo es necesario saber Java para hacer y mantener una aplicación Java con STS: hay que saber los modelos de build de maven, lo que es jenkins, lo que es json.... es decir, una visión global y conocimiento del entorno de trabajo.
Si haces webs y usas Aptana, (por ejemplo), te entrará la risa tonta cuando alguien te dice 'vengo de dreamweaver, eclipse no será tan difícil'. No se trata de dificultad, se trata de saber manejarte en el entorno en que te mueves.
Humildad. No es necesario ser humilde para ser buen programador, pero saber que no lo sabes todo, y aceptar que quien te rodea también sabe, no sólo facilita el trabajo en equipo, sino que te ubica en una posición ortodoxa que te da criterio a la hora de delegar ciertas tareas, o consultar su funcionamiento, a quien sabes que las hará mejor o más rápido, o que ya las ha hecho. No seas un programador Sith: el conocimiento lleva al orgullo, el orgullo lleva al sarcasmo, el sarcasmo a la soledad, y la soledad al olvido. El olvido romperá tus cadenas, pero nadie estará ahí para celebrarlo.
#10 Con la humildad haz tocado un punto indispensable. Conozco genios de la programación que por su carácter y dificultad para trabajar en grupo, pocos desean trabajar con ellos.
No soy developer, pero sí intento ser DBA (intento porque aunque en la práctica ejerza, me falta mucho trecho) Sin embargo he trabajado con algunos desarrolladores, unos muy buenos y otros muy malos. Ergo, concuerdo con varios de estos puntos: Un buen developer se mide por los resultados, no por las portadas de revistas en que aparezca o las charlas dadas. Igualmente, también estoy muy de acuerdo en que un buen desarrollador debe ser creativo y dar soluciones rápidas. Esto es muy importante, tanto como estar dispuesto a consultar a otros y no creer que lo sabe todo.
Hola, no soy programador pero tengo contacto por mi trabajo con ellos. Sin duda la preparación de la persona y su experiencia (supongo que como en todos los trabajos) es fundamental Buen artículo.
Lo de la consulta es fundamental, si en una entrevista de trabajo pregunto a alguien si ha utilizado hibernate y me dice "¿es un orm no? pues será igual que todos" o sobre cualquier otra cosa y me dice que lo mira y se pone con ello que no será tan complicado le contrato de cabeza, si le digo que si sabe spring 3 y me dice que sólo ha usado el 2.1.3 y que se tendrá que mirar un libro me echo a temblar
Falta la más importante: Conocimiento del problema a resolver. De nada sirve que seas creativo, que tengas conocimientos o que cumplas plazos si todo el trabajo se ha basado en medias verdades o directamente mentiras. Oh, cambios de última hora.
El graaaaan problema es que la mayoría de las veces el programador no tiene contacto directo con el cliente y el que recoge las especificaciones no es programador, no hace las preguntas adecuadas y el cliente no dice las cosas adecuadas.
Si mejoráramos en toma de datos el software mejoraría un 500%
Después de un par de años estudiando y programando en Perl...
Hay que tener valor...