• Del autor
  • Principios y algoritmos de concurrencia

Ricardo Galli, de software

~ De software libre, internet, legales

Ricardo Galli, de software

Archivos de etiqueta: programación

El mejor consejo que puedo dar a un joven ingeniero

24 jueves Mar 2016

Posted by gallir in desarrollo, personal, programación

≈ 14 comentarios

Etiquetas

consejos, programación

En unos meses cumplo 25 años desde que presenté mi proyecto final de carrera de Ingeniería en Informática («la tesis» le llamaban en mi universidad) y algo más de 15 desde que leí mi tesis doctoral. Llevo años pensando en escribir sobre cuál fue el mayor error de mi carrera profesional y curiosamente -o no- me parece el mejor consejo -doble- que puedo dar, no hacer lo mismo:

No te adelantes, no te dejes seducir por puestos de dirección, gestión o representación. Durante los primeros 20 años de carrera sólo preocúpate de aprender y practicar para ser un experto de élite en el área en que estás trabajando. Cuando la domines creerás que lo sabes todo pero en realidad no sabes nada, aprende una nueva y repite el proceso: ganarás tanta humildad como conocimiento.

Ya llegará el momento -si lo deseas- de ocupar cargos de dirección o gestión, cuando seas un profesional reconocido: tendrás ya mucha experiencia en proyectos, sabrás bastante de la psicología y sus problemas sociales, tomarás mejores decisiones y serás de ayuda -que no un gestor molesto- y la gente a tu cargo te respetará y confiará desde el primer día. Afortunadamente con el dominio del software en tantas áreas se puede vivir bien como un buen ingeniero con experiencia. Además -desafortunadamente- es muy difícil encontrar ingenieros de alta calidad y con conocimientos en diferentes áreas.

No puedo dejar de poner otros que aprendí con errores que ahora intento no volver a cometer:

  1. Cuando trabajes en grupo, sobre todo si estáis intentando solucionar un problema, no eches la culpa de nada a tus compañeros, déjales que se equivoquen -es parte de la búsqueda-, colabora y asume las responsabilidades aunque no hayan sido tuyas.
  2. Por el contrario, si alguien nunca asume una responsabilidad o error, o culpabiliza a otros hasta de que no le dejan hacer nada, intenta que quede fuera del equipo. O que al menos no moleste.
  3. Participarás en proyectos interesantes y en otros que son marrones. En realidad todos pueden ser interesantes, depende de la actitud con que los encares: siempre hay cosas que mejorar y aplicar ideas creativas. Tengo el ejemplo reciente de un compañero que le tocó uno de esos proyectos marrones hasta que se dio cuenta que podía reducir los tiempos de ejecución de batches con threads concurrentes, se lo pasó pipa aprendiendo y practicando. No sólo le quedó un programa mucho más rápido y eficiente,  ahora él es un profesional mucho más formado y capaz que hace un par de meses.
  4. Puedes ser un doctor o un graduado en el MIT, pero a la hora de verdad tu compañero autodidacta y tú ejercéis de ingenieros. Trátalo como tal, los títulos formales solo sirven como carné de autoridad para la universidad ;), entre colegas no cuentan, solo lo que has demostrado saber hacer.
  5. Lee mucho código de terceros, fundamentalmente de las librerías, módulos y programas que usas habitualmente. Es una de las mejores formas de aprender.
  6. No dejes de leer, no solo de libros técnicos específicos, también de historia de la informática y ciencia, un poco de filosofía y psicología, álgebra, estadística y algo de cálculo.
  7. No te contentes con dominar una herramienta o lenguaje, aprende cómo funciona toda la pila que lo sustenta: el hardware, el sistema operativo, la máquina virtual o compilador, el API, las librerías, etc. Aprende C o ensamblador, son clarificadores de cómo funcionan las máquinas y todo lo que hay por encima.
  8. Domina al menos tres lenguajes diferentes que cubran: compilados, dinámicos, y funcionales.
  9. Tus programas nunca serán perfectos ni lo suficientemente buenos. Con el paso de los años te avergonzarás de tu propio código. Esto es bueno, has mejorado.
  10. Cuando programes piensa en los lectores de ese programa: escribe y comenta en inglés, que el código sea elegante, si el código te parece espagueti o ilegible descártalo y empieza de nuevo, no dejes de refactorizar mientras programas. No tengas miedo de descartar programas, no es tiempo perdido. Programar es como escribir un libro pero más complejo, si hasta los mejores autores siempre descartan capítulos o textos completos, ¿por qué tú habrías de acertar a la primera?
  11. No empieces a programar como un mono, pasa horas pensando, camina, conversa con colegas, pregunta, haz un prototipo, descártalo y vuelve a empezar hasta que esas primeras líneas no te den asco ni te generen desasosiego por lo que se viene: todo lo contrario, deberían entusiasmarte a seguir programando.
  12. De todas las ideas o propuestas, elige siempre la opción más sencilla (el KISS). Si no hay ninguna que sea claramente sencilla es porque falta pensar más. Si durante el desarrollo te das cuenta que hay soluciones más simples para hacer lo mismo (es muy habitual), descarta y comienza de nuevo.
  13. No hagas optimizaciones prematuras ni tampoco diseño de lo desconocido. Lo primero genera código más difícil de verificar y lo segundo complica el sistema con funcionalidades que nunca se usarán.
  14. Si cuando sale una nueva tecnología eres capaz de darte cuenta en qué podría servirte pero te ríes del hype y buzzwords es señal de que estás madurando como profesional.
  15. Si además de acabar tus proyectos en tiempos razonables y con programas fiables, los haces con buen humor, te acaban ilusionando hasta los más coñazos y festejas como un crío cuando pudiste solucionar una tontería que te tomó horas, ya eres un buen profesional. O al menos no un coñazo de profesional. Que es casi lo mismo.

PS: Ahora veo que me falta algo fundamental, siempre explica a tus colegas por qué haces algo o tomas una decisión. En el código o tomando un café.

 

Las cosas que no soporto que diga un programador

01 domingo Feb 2015

Posted by gallir in programación, universidad

≈ 46 comentarios

Etiquetas

informática, programación

…y quizás tampoco las soportan los demás programadores.

En mi ordenador funciona

Si el código no funciona en un ordenador con toda las dependencias adecuadas instaladas es un error de tu programa, sin dudas, no hay excusas. Nunca digas esta frase, sólo demuestra que todavía no estás preparado ni para asumir la responsabilidad de tu propio código. Si eres alumno demuestra que no te interesa aprender sólo aprobar con el menor esfuerzo posible… además de tomar como tonto al profesor, como si nunca hubiese oído esta excusa (la oímos decenas de veces cada vez que se presentan prácticas).

Sigue leyendo →

¿Qué tecnologías utilizarías?

19 lunes Ene 2015

Posted by gallir in personal, programación

≈ 13 comentarios

Etiquetas

go, java, perl, PHP, programación, python, scala

Hoy un viejo conocido me hizo esta pregunta:

. @gallir a día de hoy si te planteases construir menéame, que tecnologías utilizarías? (suponiendo que la idea siguiese siendo única)

— César Aguilera (@Cs4r) January 19, 2015

Estuve a punto de contestar pero me di cuenta que soy incapaz, y que tampoco debería. Lo haré al final, como una cuestión muy personal y después de un rant de matizaciones.

Sigue leyendo →

Lo que se aprende, o debería, en la carrera de informática

28 jueves Mar 2013

Posted by gallir in ciencia, programación

≈ 46 comentarios

Etiquetas

docencia, programación, universidad

En mi apunte anterior «Lo que demanda el mercado…» critiqué la obstinación de algunas autoridades universitarias, especialmente las de la mía, en su posicionamiento extremamente conservadora contra el GNU/Linux… y cómo el tiempo les ha quitado la razón (yo diría que debería haberles avergonzado). A pesar de los dos enlaces que puse en la posdata, muchos interpretaron que pensaba que la universidad debe enseñar GNU/Linux porque tiene más salida laboral. Otros opinaron (sobre todo en Twitter) sobre lo poco que se aprende en la universidad de las últimas tecnologías [de moda].

Hace cinco años escribí un apunte muy largo sobre este tema: Sintonizar universidades y empresas, pero ¿qué debe saber un ingeniero? (y hay más, de gente más importante y valiosa que yo, como ¿Qué deberíamos enseñar a los nuevos desarrolladores? de Bjarne Stroustrup), ahora intentaré ser muy breve para contestar a esos dos temas.

Sigue leyendo →

Comprar el libro

Principios y algoritmos de concurrencia

gallir@twitter

  • RT @jpartej: Un Airbus interceptado esta tarde por un falsa alarma de bomba. Seguramente un F-18 del Ala 15. 22 hours ago
  • Siglos de educación pública y universidades y todavía estamos discutiendo si hay que becar (también) al talento. 1 day ago
  • No es tema del dinero público, todo lo que hace un gobierno es a costa de nuestro dinero. Es la frivolidad del tema… twitter.com/i/web/status/1… 1 day ago
Follow @gallir

RSS Notas recientes

  • Se ha producido un error; es probable que la fuente esté fuera de servicio. Vuelve a intentarlo más tarde.

Archivos

Comentarios recientes

PM en Cuidado con las «clever soluti…
Me matan si no traba… en Cuando el periodismo cede el c…
surco en Cuando el periodismo cede el c…
pancho pérez (@lonch… en Cuando el periodismo cede el c…
Fernando en Cuando el periodismo cede el c…
@beoxman en Cuando el periodismo cede el c…
gallir en Cuando el periodismo cede el c…
Jan Smite en Cuando el periodismo cede el c…
Alejandro en Cuando el periodismo cede el c…
Galletor en Cuando el periodismo cede el c…

Meta

  • Registro
  • Acceder
  • Feed de entradas
  • Feed de comentarios
  • WordPress.com

Licencia

Creative Commons License
Esta obra está bajo una licencia de Creative Commons.

Blog de WordPress.com.

  • Seguir Siguiendo
    • Ricardo Galli, de software
    • Únete a 28.667 seguidores más
    • ¿Ya tienes una cuenta de WordPress.com? Accede ahora.
    • Ricardo Galli, de software
    • Personalizar
    • Seguir Siguiendo
    • Regístrate
    • Acceder
    • Denunciar este contenido
    • Ver sitio web en el Lector
    • Gestionar las suscripciones
    • Contraer esta barra