Orgullosos de su trabajo, defienden con convicción que su profesión es un arte. Guitarristas del código, mentalidad creativa y corazón inconformista, la esencia de los Rockers Developers.
Con respecto a la reflexión:
Good developer develops features which create value for customers. Bad developer completes tasks. Good developer will never claim the requirements are incomplete, and will make sure to fully understand the features he’s working on. Bad developer will wait until the finest details are available. To emphasize: good developer is the CEO of the feature – he’s going to make sure he always has the information needed to accomplish the feature, and in case information is missing he’ll make sure he gets it.
David García
Ladies and Gentlemen, We are Floating in Space.
Desarrollador de acción, vocalista y guitarrista de vocación. En su momento no tuvo miedo a rememorar el postgrunge con su grupo Los Niños Muertos,ahora su guitarra es el teclado y su espectáculo, la discreción.
David opina sobre ello y nos cuenta que — se supone que estás ahí porque lo has elegido, haciendo eso que haces porque tu quieres. Puede ser que no tengas el control al 100%, pero tienes los vientos, las corrientes, incluso las estrellas, y sabes navegar ... ya sabes lo que hacer.
Si has llegado ahí de ese modo es imposible que no tomes partido en tu trabajo, que de algún modo no lo empujes con la visión que desde un principio tengas de la imagen final. Efectivamente eres "CEO of the feature" porque eres el responsable de tu trabajo.
Es todo un montón de obviedades, pero son las cosas que la rutina, el tiempo y la inercia te pueden hacer olvidar. Tenerlo presente es la clave para que tu modo de vida te aporte algo más que una remuneración económica, algo muy importante (ya lo sabemos), pero es que como decía, estamos en esto porque queremos, ¿no?.
Por otro lado, el riesgo de tener esa visión de tu trabajo es que siempre faltará algo, como tu principal crítico conoces mejor que nadie las imperfecciones y las cosas a mejorar. Es ahí donde es necesario enfrentarse a los conflictos de la gestión del tiempo y evitar estar en un "work in progress" continuo en cada tarea, un pecado en el que difícilmente caerá un mal desarrollador.
Creo que todo esto se aplica a muchos ámbitos, no solo desarrollo y no solo trabajo. —
Sergio Ruiz
Hay que intentar ir a comerse el mundo, no ser uno más del rebaño. Puedes conseguirlo o no, pero hay que ir a por ello con determinación, y yo no pienso parar de crecer.
Artista del código, guitarrista, aprendiz de japonés y mago. Demostró a los japoneses su manejo de JavaScript desarrollando 2 juegos en un semana. Le encanta investigar sobre nuevas tecnologías, teclear al ritmo de Led Zeppelin y maquinar estrategias heróicas jugando en su PC.
El autor no tiene duda en afirmar que “Good developer is an artist, a craftsman who enjoys the process of creation. Bad developer considers himself as a programmer, responsible for generating lines of code” y Sergio con plena seguridad opina que:
— Crear. Nuestra profesión es completamente creativa. Uno no tira líneas por tirarlas, tiene un fin en mente, unos usuarios, quiere que alguien utilice lo que él o ella han desarrollado, y quiere hacerlo perfecto. No hay mayor satisfacción en nuestro trabajo que ver a otra persona utilizar el producto en el que has colaborado y saber que has realizado un buen trabajo.
En el tiempo que llevo en el mundo de la consultoría rara vez he podido desarrollar como yo he querido: con tiempo, con calma y con buena letra. Suele haber alguien (la mayoría de las veces no técnico) que se reúne con el cliente para escuchar sus exigencias, y le ofrece desarrollos en tiempo récord para que dicho cliente no se vaya a otra consultora que tarde o cobre menos. Me parece muy bien porque la empresa consigue a dicho cliente, pero rara vez se tiene en cuenta al que va a tener que desarrollar eso.
Puedes ser muy bueno en tu área, pero a veces necesitas ser un superhéroe para hacerlo todo bien en el tiempo que te dan. O eso, o acudes a las famosas "ñapas". El desarrollo que te plantean, tú lo estimas en tres semanas y ellos lo han estimado (y cerrado con el cliente, que es lo peor) en una semana, por lo que te están obligando a realizar todas las tareas de análisis, diseño, desarrollo y testeo, en menos tiempo del que requiere, lo que conlleva a que alguno de esos puntos, si no todos, se vean afectados.
Al final terminas el trabajo a tiempo, por supuesto, porque eres bueno en lo tuyo y puedes con ello, pero puedes llegar a avergonzarte de cómo has tenido que resolverlo, teniendo en mente que con tiempo lo habrías refactorizado, testeado, documentado, y realizado tu pequeña obra de arte.
El usuario tal vez no se dé cuenta "de lo que hay debajo", pero tú sí lo sabes, y otra persona que sea curiosa también lo sabrá, y puede llegar a pensar "pues vaya código". Y bajo ese código, tal vez haya un artista frustrado que no ha podido realizar su obra a gusto, y al que han obligado a ser mediocre.
Así que ... nota para esas personas que se reúnen con los clientes: Siempre escuchad a vuestros programadores, porque son quienes saben cuánto se va a tardar y cómo se ha de hacer una tarea, y si son buenos, podrán demostrarlo.
Y nota para los programadores: No dejéis de luchar por estas cosas, no hay que quedarse callado, si queréis realizar un buen trabajo dejádselo claro a quien haga falta. Sois artistas, unos magos del código, no unos resolutores de problemas.—
Reflexión
Gracias a los dos por colaborar, me ha encantado el magnetismo de vuestras reflexiones. Después de leeros me quedo con dos titulares:
Efectivamente eres "CEO of the feature" porque eres el responsable de tu trabajo.
Los programadores son artistas, magos del código, no unos resolutores de problemas.
¡Ohhhhhhhhhhhhhhh yeahhhhhhhh!
Nota: Artículo relacionado con la serie de opiniones de los Soul Develpers, Gentelmen Developers y Natural Developers sobre los 9 puntos : "Good Developer, Bad Developer"