• Haz código que no necesita documentación. Y documéntalo.

    Publicado por

    Oscar Swanros

    el

    a las

    Los programadores tenemos tendencias egocéntricas.

    Entendemos (o creemos entender) cómo funcionan las computadoras. Y eso nos hace sentir especiales. Y si somos tan especiales para entender cómo funcionan las computadoras, cualquier persona que no entienda mi código no es tan especial como yo.

    Documentar qué estás haciendo, y por qué, puede ser un golpe al ego. Pero uno que vale la pena. Que documentes algo no es una admisión que no fuiste lo suficientemente inteligente para escribir “buen” código, sino un acto de compasión. Demuestra tu interés porque la siguiente persona que modifique tu código pueda enfocarse en agregar valor al proyecto — y muy probablemente esa siguiente persona seas tú.

    La idea de que “tu código debería de documentarse solo” no es un get out of jail free card para no documentar tu código. Las ocasiones en tu carrera profesional donde escribir documentación no agrega valor a tu trabajo son muy pocas. Tan pocas, de hecho, que no se me viene ninguna a la mente. ¿Tal vez cuando estás trabajando en un proyecto propio? Pero hasta Damian Conway dijo que “la documentación es una carta de amor que le escribes a tu yo del futuro”.

    Escribir documentación no tiene que ser aburrido ni estar limitado a únicamente escribir comentarios.

    En orden de accesibilidad, puedes escribir:

    1. comentarios en tu código.
    2. READMEs
    3. glosarios
    4. RFCs o documentos de diseño
    5. pruebas
    6. Documentos de arquitectura

    Te invito a que veas la documentación como un tema de accesibilidad, y no de exactitud. ¿Qué opinarías de alguien que dice que no debería haber rampas en las banquetas de una ciudad porque no necesita caminar para transportarse? Reflexiona.

  • Ser bueno técnicamente es solamente una parte de lo que te toca hacer

    Publicado por

    Oscar Swanros

    el

    a las

    Ser bueno técnicamente en X o Y tecnología no te hace bueno en todo lo demás que conlleva trabajar en esta industria. Necesitas ponerle más atención a eso.

    Es muy de programadores creer que como somos buenos en X, automáticamente somos buenos en Y. Pero eso está muy lejos de la realidad.

    Puedes dominar Linux, y carecer aún de la empatía necesaria para poder ser líder de un proyecto.

    Puedes ser un experto en Ruby on Rails, y necesitar ayuda para saber cómo arreglar una discusión en tu equipo.

    Puedes haber escrito el libro sobre trabajo remoto y aún así regarla horriblemente… porque nunca desarrollaste el hábito de resolver problemas desde la empatía y la compasión.

    Y ejemplos como estos hay miles. Todos hemos conocido alguien muy bueno en la parte técnica, pero que funcionalmente es más un blocker que un apoyo (o una molestia, cuando menos) para el equipo.

    Un líder…

    • con actitud de “quítate yo lo hago”…
    • que responde preguntas de manera condescendiente…
    • que no protege a su equipo…

    … pero que es muy bueno en Linux. ¿… yay?

    El argumento de que necesitas ponerle más atención a tus soft skills no es una negación de que la tecnología es importante. A final de cuentas es la parte operativa que te toca desempeñar.

    Y es ahí donde se abre la discusión.

    ¿Cómo le vas a hacer para darte cuenta de que la parte técnica es únicamente eso, UNA PARTE, de lo que te toca hacer en esta industria?

    Encontremos la respuesta juntos.

  • ¿Qué hace competente a un programador?

    Publicado por

    Oscar Swanros

    el

    a las

    Saber más lenguajes de programación, arquitecturas o tecnologías no te hace un programador competente.

    Más allá de sus contribuciones con compiladores, sistemas distribuidos y sistemas operativos, Dijkstra nos dejó el aprendizaje más grande de todos en su clase de 1972, The Humble Programmer: la característica más importante de un programador realmente competente es su humildad.

    Si eres un programador competente entonces eres consciente de que no lo sabe todo. Así que te aproximas a cualquier tarea que se te asigna con humildad, y no caes en las trampas de tu ego — no te complicas por la simple motivación de hacer notar que sabes más o eres mejor.

    Estar en lo correcto se siente bien. Y creo que hay un lugar y un espacio para hacerlo — a final de cuentas reconocer nuestros éxitos es también parte importante del crecimiento. Pero hacerlo en exceso es una receta para el delirio.

    Hay una línea muy delgada que todos los profesionales de esta industria debemos de trazar. Esta línea te ayuda a identificar si estás intentando resolver un problema para agregar valor real o para satisfacer tu propio ego.

    Si no eres consciente de la razón por la cual estás resolviendo algo, es muy fácil que caigas en la trampa del ego.

    También, si no tienes la humildad para reconocer cuando estás resolviendo algo por ego y no por avanzar tus objetivos, te conviertes en un bloqueo para tu equipo.

    Lo que te hará mejor desarrollador no es saber más lenguajes de programación, frameworks o arquitecturas. Es tener la humildad de aceptar que no lo sabes todo, e intentar resolver tus problemas partiendo de esa premisa.

    Contrario a la idea con la que probablemente creciste, aceptar que estabas mal o que no sabes algo no significa que eres incompetente. Significa que tienes la humildad de reconocer tus errores y la integridad de aprender de ellos. Mientras más pronto lo admitas y te hagas consciente de ello, más rápido te moverás hacia la respuesta correcta.

  • La falsa seguridad de los desarrolladores de software

    Publicado por

    Oscar Swanros

    el

    a las

    Probablemente te llueven ofertas de trabajo en LinkedIn — simplemente por listar el lenguaje de programación de moda como una de tus habilidades. Si es así: cuidado, esa seguridad que sientes es falsa.

    Saber más lenguajes, tecnologías y metodologías no significa que tienes mejores prospectos para crecer profesionalmente.

    Una trampa común para las personas que van iniciando en desarrollo de software es creer que su valor real en esta industria es el stack de tecnología que dominan. Así como yo, tú probablemente en algún momento sentiste orgullo en decir que desarrollabas X tecnología, y nada más. Pero te tengo que decir algo: el stack tecnológico, por más variado, amplio, profundo y dinámico que sea, es meramente un detalle de implementación. Cualquiera puede aprender cualquier lenguaje de programación, y volverse suficientemente bueno, con suficiente dedicación.

    Una carrera profesional, al contrario de un simple trabajo, no se construye de manera lógica, lineal o transaccional.

    Todos los carpinteros saben usar martillos, serruchos, sierras. ¿Por qué hay carpinteros más exitosos que otros? ¿Es porque saben usar el martillo mejor con más estilo? ¿O porque agarran el serrucho de una manera muy particular?

    El carpintero más exitoso, que se da el lujo de decir con qué clientes sí quiere trabajar; aquel que es reconocido por la manera en que materializa su visión de cómo se debería de ver un mueble, no llegó a esa posición por tener el mejor martillo. Ese carpintero se dio cuenta de que lo que realmente importa (y por lo que le pagaban) era todo lo demás. Entregar a tiempo, cumplir su palabra, saber negociar… no ser el mejor usando una herramienta en particular, sino saber qué herramienta usar para lograr su objetivo.

    ¿Cuándo fue la última vez que escuchaste alguien en una posición importante en esta industria presentarse listando las tecnologías que dominan? Y aquí estamos muchos, creyendo que llegaremos lejísimos y tendremos una carrera siendo nada más un “Ruby Developer”.

    Desarrolladores de Ruby encuentras en todos lados. Un verdadero profesional de la industria que sepa Ruby es algo mucho más raro.

  • 7 razones por las que tu carrera en desarrollo de software no ha despegado

    Publicado por

    Oscar Swanros

    el

    a las

    Si estás leyendo esto es probable que te sientas estancado o estancada en tu carrera. Sí, has estado desarrollando software, tal vez profesionalmente, por algún tiempo. Pero ese breakthrough aún no llega.

    Aquí hay 7 cosas que estás haciendo, y que te están metiendo el pie sin que te des cuenta.

    1. No tienes bien definido qué quieres hacer, o en quién te quieres convertir. Te gustaría dominar cierta tecnología, pero no tienes claro por qué, ni para qué usarás ese dominio una vez que lo obtengas. Básicamente estás aprendiendo por aprender.
    2. Estás construyendo en aislamiento. Crees que la solución es más importante que el proceso, cuando en realidad en el desarrollo del problema es donde se encuentran los verdaderos aprendizajes. Nada crece en un vacío.
    3. Estás acumulando conocimiento. Le das más valor a aprender cosas nuevas, que a aplicarlas y experimentar. En algún momento tienes que cerrar tus 200 cursos de Platzi y ponerte a resolver problemas reales. goto: 1.
    4. Te quedas con la textura de las discusiones, e ignoras el bigger picture. ¿Qué importa más, si ganó tu propuesta o si la solución acordada impacta de manera positiva al equipo?
    5. Le das demasiada importancia a los detalles de implementación. Sí, es importante el framework que quieres usar, o la arquitectura con la que quieres resolver el problema. Pero nada es más importante que resolver el problema a la mano.
    6. Aún le tienes miedo a tu ego. No quieres fallar en público, le temes a compartir tu proceso, y prefieres llegar con soluciones ya armadas. Crees que la opacidad de tus respuestas es una ventaja, porque te hace esencial. En realidad te hace un punto de fallo dentro del equipo.
    7. Estás aplicando demasiada lógica. Tratas a las personas con la misma frialdad con la que diseñas algoritmos. No es sorpresa que la tengas difícil a la hora de generar capital social.

    Haz pequeños ajustes en estas 7 áreas, y verás cómo por arte de magia las oportunidades de crecimiento profesional comienzan a aparecer ante ti.

Ayudo a personas que trabajan con software a mejorar sus carreras profesionales.

Los miembros tienen acceso a Pathways, pueden comentar en las publicaciones, interactuar con la comunidad, y muchos otros beneficios. Conoce más.

Agrégame a tu lector RSS, o suscríbete a mi newsletter para recibir los nuevos artículos que publique.

Pregúntame algo