• El mejor consejo que puedo dar a un joven ingeniero

    From Enric Lleal Serra@1:2320/100 to All on Mon Apr 18 14:30:26 2016
    * Originally in ESP.SOFTWARE
    * Crossposted in ESP.PROGRAMACION


    �Hola All!


    Ya hac�a d�as que quer�a compartir esta entrada de Ricardo Galli[1], pero nunca

    encontraba el momento. Aqu� est�:


    *El mejor consejo que puedo dar a un joven ingeniero*
    24 Jueves Mar 2016
    Posted by gallir in desarrollo, personal, 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:

    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.

    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.

    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.

    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.

    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.

    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.

    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.

    Domina al menos tres lenguajes diferentes que cubran: compilados, din�micos, y funcionales.

    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.

    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?

    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.

    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.

    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.

    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.

    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�.

    [1]https://gallir.wordpress.com/2016/03/24/el-mejor-consejo-que-puedo-dar-a-un-

    joven-ingeniero/





    -
    A reveure!!
    Enric
    __________________________________________________________________
    FidoNet: 2:343/107.1 | beholderbbs.org | fidonet.cat | .es | .ws
    InterNet: kishpa(at)kishpa(dot)com | kishpa.com | GPG#0xDCCB8CFC

    ... Bajo presi�n las cosas empeoran. (Ley termodin�mica de Murphy)
    --- crashmail + golded + binkd
    # Origin: Black flag & crossed bones : Eye Of The Beholder BBS! (2:343/107.1)
    * Origin: LiveWire BBS - Synchronet - LiveWireBBS.com (1:2320/100)