• Qué hacer si presencias acoso en tu trabajo o comunidad

    Publicado por

    Oscar Swanros

    el

    a las

    Acabo de participar en un entrenamiento para prevenir acoso y discriminación en equipos de trabajo.

    Me pareció que esta información debería compartirse, así que tomé nota. Estas son 6 cosas que puedes hacer si presencias acoso en tu espacio de trabajo, incluso si no eres gerente o tienes una posición de liderazgo.

    1. Interrumpe la conversación. Haz algún comentario que desvíe la conversación e interrumpa el acto de acoso. Puede ser una broma, un cambio drástico de tema, o simplemente hacer un ruido que cambie el foco del grupo.
    2. Pregúntale a la persona cómo se encuentre. Acércate a tocar base, y pregunta si hay algo que puedas hacer para ayudarle.
    3. Aborda a la persona cometiendo el acoso. Especialmente en ambientes donde no estamos sensibilizados en cuestiones de acoso, es importante dar visibilidad y resaltar acciones imprudentes y dañinas. Asume que la persona es ignorante de efecto de su comportamiento, y ofrece una perspectiva diferente: “Sé que tal vez no quisiste decir esto, pero este fue el efecto de tu comentario.”
    4. Apela a la amistad y empatía con la víctima. Hazle saber que tiene aliados, y que no está solo o sola. Reconoce que presenciaste lo que sucedió, y que estás ahí para apoyarle en lo que necesite, aunque sea simplemente moralmente.
    5. Da retroalimentación directa y clara en el momento. “Aquí no hacemos o decimos eso, bajo ninguna circunstancia.”
    6. Niégate a ser parte de la situación, y llévate a otros contigo. El mensaje más valioso que puedes mandar es que no te vas a para ser audiencia de este tipo de actos. En cuanto te percates de que alguien está siendo acosado, retírate de la situación y busca que otros te sigan. A veces lo único que falta para que el cambio suceda es tener alguien a quien seguir.

    Ponerle un alto al acoso es responsabilidad compartida

    “Acoso” puede significar cosas diferentes dependiendo el contexto. Apela a tus valores, o las reglas de convivencia del grupo, para aprender a identificarlos. Pero hay un tipo de acoso que es incuestionable: calumnias, bromas sexuales, transgresión del espacio personal, comentarios hirientes o fuera de lugar.

    Si observas cualquier tipo de acoso y no haces nada para resaltarlo y detenerlo, también eres parte del problema.

  • Soy Engineering Manager: esto aprendí en mis primeros años

    Publicado por

    Oscar Swanros

    el

    a las

    A finales de 2019 decidí cambiar la dirección de mi carrera profesional y probar suerte como Engineering Manager.

    Para este entonces, tenía un poco más de 10 años de experiencia desarrollando software como contribuidor individual.

    Hoy me encuentro iniciando mi tercer año como Engineering Manager, y creo que es una buena oportunidad para reflexionar sobre estos primeros dos años. Te quiero compartir algunos aprendizajes que he adquirido, con la intención de que te sean de utilidad si es que decides seguir un camino similar al mío.

    Pero antes…

    ¿Cómo me convertí en Engineering Manager?

    Llegué al puesto de Engineering Manager con un set de ideas bastante claras sobre el tipo de líder que quería ser, así como de las estrategias particulares que emplearía para lograrlo. El tema de liderazgo y la psicología organizacional siempre me han llamado la atención, y continuamente estoy aprendiendo y educándome en estas áreas.

    Durante mi tiempo como desarrollador, tuve la oportunidad de experimentar de primera mano los beneficios de tener líderes que genuinamente procuraban mi bienestar y mi crecimiento. También me tocó tener jefes, de los clásicos que nadie debería tener. Pude ver, gozar, y sufrir, gran parte del espectro de los tipos de líderes que existen.

    También es importante compartir que adquirí mi experiencia profesional, principalmente en un ambiente de startups de Estados Unidos y Europa. Esto jugó un papel considerable en mi transición, pues mis primeros dos años como Engineering Manager fueron trabajando para empresas Mexicanas. A pesar de que soy mexicano, habiendo trabajado principalmente con personas extranjeras, sentí el cambio cultural.

    Lo que aquí te voy a compartir no son verdades universales ni reglas. Tómalas como lo que son: interpretaciones de situaciones que viví a través de mis valores, experiencias propias y deseos personales.

    Tus decisiones, por más pequeñas que sean, tienen grandes implicaciones

    Como gerente de ingeniería, tus decisiones tienen la capacidad de influenciar desde la composición técnica de tu proyecto, hasta aspectos fundamentales del negocio. Pero, mayormente, tus decisiones afectan la carrera profesional de las personas a tu cargo.

    Cualquier decisión que tomes, debes de factorizar el impacto a mediano y largo plazo que esta va a tener en la carrera de las personas con las que trabajas.

    Sí, el producto es importante. Pero sin un equipo sano, todo pasa a segundo plano.

    Tu trabajo como Engineering Manager es habilitar a tu equipo

    Es demasiado sencillo llegar a un puesto de Engineering Manager pensando que lo que se espera de ti es que asignes tareas, y te asegures de que se cumplan a tiempo. Y hay personas que podrían argumentar que sí, ese es el trabajo. Yo creo que es un poco más complicado que eso.

    El Engineering Manager, a diferencia de un Project Manager, se encarga de entender las necesidades y visión del negocio. Además, asimila las fortalezas, debilidades, y deseos de su equipo. El reto es alinear estos dos mundos de una manera coherente, sostenible y humana.

    Parte de tus responsabilidades es procurar que los proyectos salgan a tiempo y en forma. Pero no asegurarte. ¿Qué vas a hacer, obligar a tu equipo a que trabaje horas extras? ¿Preguntarles “cómo vamos” cada 3 horas? ¿Intentar comprar su felicidad con pizzas y refresco? Todos hemos tenido (o por lo menos escuchado de) gerentes que usan esas tácticas. Personas para las cuales lo más importante es la fecha, el cliente y su reputación, no su equipo.

    Reflexiona: ¿te gustaría (volver a) trabajar con una persona así?

    Por eso digo que el Engineering Manager procura que las cosas salgan bien. Entiende las necesidades de su equipo (las personas), tiene conciencia de un balance adecuado entre vida y trabajo, y además reconoce y asimila las capacidades de cada uno de los miembros de su equipo. Después toma toda esta información, y crea estrategias, procesos y formas de trabajo que produzcan resultados fiables, en tiempo y forma. En este video exploro un poco más este tema.

    Tienes que buscar un balance sostenible

    La analogía que me gusta utilizar para este punto es la de las mascarillas de oxígeno en los aviones. Antes de despegar, el personal del avión hace las demostraciones de seguridad pertinentes, y comentan al respecto: “en caso de despresurización, antes de intentar ayudar a otras personas, asegúrese de tener la mascarilla bien puesta usted”.

    El mismo consejo aplica para alguien en el rol de Engineering Manager.

    Como alguien que desarrolla software (y más si vienes de la cultura Latinoamericana), probablemente te acostumbraste a glorificar el trabajo duro y pensar que estar ocupado es un símbolo de que estás haciendo algo importante. Cuando tienes ese bagaje cultural y de repente te encuentras en un rol de gerencia, naturalmente vas a buscar formas de mantenerte ocupado.

    Pero como Engineering Manager, tienes que estar consciente de que tu rol es servir a tu equipo. Ayudarles a desbloquearse y a tomar mejores decisiones. Estar ahí cuando te necesiten. Y si no buscas un ritmo sostenible en tu rol, tu equipo lo va a resentir.

    Tener un Engineering Manager quemado es como estar conectado a wifi que no tiene internet: sería menos frustrante no tenerlo en absoluto.

    Lo que para ti pudiera parecer ayuda, para tu equipo se convierte en un perjuicio

    No solamente importan las decisiones que tomas, sino cómo las tomas. El equipo que manejas aprende de tu estilo de resolución de problemas. Si no eres cuidadoso, precavido, diligente, transparente y disciplinado, le estás enseñando a tu equipo que está bien tomar decisiones “al ahí se va”.

    Al inicio de mi carrera como Engineering Manager tenía lo anterior bien claro. A pesar de esto, no pude evitar caer (algunas veces) en la comodidad de tomar decisiones por mi cuenta y simplemente asignar tickets a mis equipos. No fue sino hasta después de un par de iteraciones, que me di cuenta de que la forma de trabajo que estaba impulsando no era sostenible. No solamente me estaba creando más trabajo, sino que además estaba afectando directamente el crecimiento de mis equipos.

    Fue ahí cuando “hizo clic” la idea de que para ser un buen Engineering Manager, tenía que preocuparme más por habilitar a otras personas, que por hacer el trabajo yo mismo.

    El feedback loop es muy largo

    Tus decisiones deberían de estar basadas en el bienestar, sostenibilidad y productividad de tu equipo. Y los resultados de los cambios que implementes para fomentar una cultura de trabajo positiva tardan bastante ser aparentes.

    Si tomas una decisión en función de prevenir el burnout de tu equipo, por ejemplo, el rango de tiempo para darte cuenta de si la estrategia está funcionando o no, podría ser de meses. No solo porque los cambios organizacionales son complejos y tardados, sino porque es muy difícil tomar una medición discreta del bienestar de una persona. Aunque tengas 1on1s recurrentes con cada miembro de tu equipo, las variaciones de estado de ánimo de una semana a otra pueden ser bastante grandes — y no siempre gracias a factores que tú puedas controlar.

    Es por eso que como Engineering Manager tienes que enfocarte en las tendencias que ves en el equipo, no en datos discretos. Todos tenemos días malos, y si ves que alguien no la está pasando tan bien en tu equipo, no necesariamente tienes que hacer algo de manera inmediata (a menos que la situación lo amerite). Pero cuando ves que alguien ya lleva varias semanas pasándola mal, es momento de cambiar algo.

    Cambiando el paradigma

    Creo que hoy, más que nunca, es importante que humanicemos nuestro trabajo, y dejemos de glorificar las horas extras y el sacrificio del bienestar mental y emocional de las personas. Y considero que el Engineering Manager tiene un papel fundamental en esta transición.

    Convertirme en Engineering Manager ha sido un proceso interesante. He aprendido mucho sobre mí y mis sesgos. Me he enfrentado a mi propio ego, y me ha ayudado a entender que el mundo en el que vivimos tiene muchos más matices de los que pensaba.

    ¿He tenido mis momentos difíciles? Sí. ¿He cometido errores? También.

    Pero también he aprendido, y he crecido. Y si reflexiono un poco sobre estos primeros dos años en esta carrera, siendo honesto, considero que lo estoy disfrutando más de lo que disfruté mis primeros dos años como desarrollador.

    Algunas reflexiones extras:

    • No todas las empresas necesitan Engineering Managers. Hay algunas empresas que simplemente necesitan un Project Manager con nociones de ingeniería de software, pero no un Engineering Manager. Asegúrate de que sabes qué es lo que realmente necesitan.
    • Ser Manager significa algo diferente para cada empresa. No te quedes simplemente con el título, indaga un poco más en cuáles son realmente las tareas y expectativas del puesto.
    • Ser Manager no es para todos. Muchas personas creen que la progresión natural de una carrera en esta industria apunta hacia puestos de gerencia, pero no es así. Ser bueno escribiendo software desafortunadamente no te hace buen manager.
    • Para ser Manager, necesitas renunciar a tu identidad como desarrollador. Ve este video para saber más.

  • ¿Cómo le hacen los que no pueden usar Git en su trabajo?

    Publicado por

    Oscar Swanros

    el

    a las

    Un usuario de Reddit escribe sobre su experiencia trabajando en un lugar donde ni siquiera han escuchado hablar de Git:

    Esta mañana, gasté 3 horas reescribiendo lo que hice ayer, porque mi compañero lo eliminó accidentalmente en la carpeta de Windows Server que usamos para desarrollar. No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git. ¿Alguno de ustedes ha trabajado en algún lugar así y encontrado una manera de sobrellevarlo?

    Obviamente, las respuestas recomendándole que huyera de ahí lo más rápido posible no se hicieron esperar.

    Hace casi 22 años, Joel Spolsky publicó en su blog su popular checklist para determinar si un equipo de desarrollo de software es bueno o no: 12 Pasos Hacia Mejor Código. La primera pregunta es: ¿Tu equipo usa manejador de versiones?

    Aunque es fácil caer en la tentación de burlarse del creador del hilo en Reddit, me gustaría reflexionar sobre su situación.

    Recordando que muchas personas crecimos con la idealización del trabajo duro, no es difícil ver cómo esa forma de pensar podría llevarnos a la progresión lógica de que cualquier cosa que le haga al programador la vida más fácil significaría que entonces la empresa no lo está aprovechando al máximo. Estoy seguro de que podrás identificar alguna persona en tu vida (probablemente alguien mayor, o “de la vieja guardia”) que defendería esta retórica. “Los programadores de verdad compilan su propio IDE.” Esto es lo que pasa cuando personas con esta mentalidad dirigen empresas.

    (Dándoles el beneficio de la duda: es probable que esta persona esté trabajando en una industria donde únicamente se pueden utilizar tecnologías aprobadas y validadas por algún tipo de organismo o estándar. En este caso, entendería que, por regulación, no estuviera permitido que usaran tecnologías de código abierto.)

    Por otro lado, es probable que el autor original del hilo simplemente se encuentre rodeado de gente que ignora la existencia de los controladores de versiones, así como sus beneficios. Un par de veces en mi vida me he encontrado con personas que encuentran abrumadora la idea de tener que aprender otra tecnología (Git) además del lenguaje de programación en el que están especializándose. Así que simplemente hacen lo que pueden con lo que saben: ponen su código en Dropbox, Google Drive, y listo. No es hasta que salen problemas que el valor de usar controladores de versiones se vuelve aparente.

    La parte clave de su mensaje es esta:

    No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git.

    Apostaría que la persona que escribió esto encaja en el siguiente perfil: alguien joven, al inicio de su carrera en software, con grandes aspiraciones, en su primer trabajo formal. Probablemente, la empresa sea de una industria vieja (finanzas, construcción, legales, donde las cosas se hacen por regulación) que se está intentando renovar, y lo están haciendo contratando programadores, pero sin crear una cultura de desarrollo de software.

    No conozco al autor del hilo, pero no me sorprendería si tuviera una carrera próspera en su futuro. Después de todo, está demostrando una capacidad que (desafortunadamente) no todos tienen: la de cuestionar el statu quo. No se está quejando, está haciendo una pregunta para educarse y crecer. Está buscando datos, consejos y soluciones.

    Algunas lecciones que me gustaría que todos nos lleváramos de esta experiencia:

    1. No en todas las empresas se puede desarrollar software. Ve esta porción de una de mis charlas para entender más sobre esto.
    2. Algunas empresas solamente quieren programadores, no desarrolladores.
    3. Desarrollar software es mucho más que escribir código.
    4. Se vale preguntar, cuestionar y decidir si la situación en la que estás es en la que quieres estar.

  • El Open Source no se trata de ti

    Publicado por

    Oscar Swanros

    el

    a las

    Rich Hickey, creador de Clojure, escribiendo en GitHub Gist:

    Ser usuario de algo que es Open Source, no te hace merecedor de nada en absoluto. No necesitas contribuir. No tienes por qué exigir nuevas características. No te mereces la atención de otros. No significa que tus quejas tengan un valor para el producto. No te mereces esta explicación.

    Si tienes expectativas (de otros) que no están siendo cumplidas, esas expectativas son tu propia responsabilidad. Eres responsable de tus necesidades. Si quieres algo, hazlo.

    Hace un tiempo escribía sobre como ser desarrollador Open Source parecía no ser tan buena idea hoy en día. El Gist que publica Rich no es nuevo, tiene por lo menos unos 5 o 6 años, pero demuestra la tendencia hacia el burn-out que muchos administradores de proyectos Open Source hoy están reportando.

  • Cómo jugar un rol activo en tu educación continua

    Publicado por

    Oscar Swanros

    el

    a las

    Me puse a reflexionar, y me di cuenta de que, por lo menos en mi caso, durante mi proceso de formación, nunca se me inculcó la importancia de invertir en educación. Claro, se me mencionó que la educación continua era importante. Pero nunca se me dijo que una de las formas de mantenerme educado continuamente era “aventándole dinero al problema”.

    Suena raro, ¿no? Hasta parece obvio.

    Me dio curiosidad saber cuánto dinero invierten las personas en su educación al año.

    ¿Cuándo inviertes en educación al año?

    USD $500 (MXN $10,000) es también más o menos lo que había estado invirtiendo anualmente en mi educación, en promedio, hasta 2020.

    En mi caso, creo que interpreté la idea de “educación continua” como “aprende lo más que puedas de las situaciones que se te presenten”. Que es un consejo sabio, y lo aplico. Pero nunca me pasó por la cabeza que podía influenciar directamente la calidad de la educación que recibía, incrementando la cantidad de dinero que le destinaba a ello.

    Hasta que lo intenté. Dejé de buscar cantidad, y me enfoqué en calidad.

    Hoy en día prefiero mil veces tomar el toro por los cuernos y trabajar con un especialista en sesiones individuales de coaching, que comprar 10 cursos diferentes a un 95 % de descuento (tú sabes de qué plataforma hablo) — simplemente para nunca realmente darme el tiempo de ver los videos y hacer mi tarea.

    Cada uno de nosotros aprende de manera diferente. Yo encontré que me funciona mucho más tomar clases en vivo, acompañado de una cohorte de alumnos, que suscribirme a una plataforma de videos y verlos por mi cuenta. Descubrí que me funciona más comprar libros físicos y tenerlos a la mano de manera tangible, que buscar PDF gratuitos y leerlos en mi iPad.

    Muchas personas confundimos cantidad con calidad. Creemos que simplemente comprar libros, videos y suscripciones, cuenta como educación. No leer, ejecutar o participar. Comprar.

    Tener acceso a más información no es lo mismo que tener mejor educación.

    ¿Tú cuánto inviertes en tu educación al año? Y si tuvieras que duplicarlo, ¿simplemente invertirías más? ¿O invertirías más y mejor?

  • Video: El costo de especializarte

    Publicado por

    Oscar Swanros

    el

    a las

    Otro clip tomado de la participación que tuve en The Dojo, el canal de mi amigo Héctor, hace unos meses. En este, hablo sobre lo que tuve que sacrificar para especializarme como desarrollador de iOS, y las implicaciones que eso tuvo en mi vida. El artículo de Paul Graham que menciono se llama Bus ticket theory of genius.

  • Incrementa el valor de tu documentación con arte ASCII

    Publicado por

    Oscar Swanros

    el

    a las

    Aquí hay otro ejemplo de cómo la documentación aumenta el valor de tu código. John Regehr recopiló imágenes de cómo en algunos proyectos de código abierto se usa arte ASCII para explicar el código de manera más clara.

    En su artículo, escribe:

    Las personas tienden a ser visuales: usamos imágenes para entender problemas. Los lenguajes de programación más populares, por el contrario, operan en un espacio completamente abstracto, dejando una gran brecha entre programa e imagen.

    Un ejemplo tomado del compilador de Swift:

    Puedes utilizar apps como Mondraw para crear este tipo de documentación. Recuerda el Triángulo de la Documentación de Código, y que agregar documentación no es una admisión de que no fuiste lo suficientemente inteligente para escribir “buen” código.

     

  • El Triángulo de la Documentación de Código

    Publicado por

    Oscar Swanros

    el

    a las

    Hace un tiempo propuse que deberías escribir código que se documente solo, y luego agregarle documentación. En el artículo original, escribí:

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

    Hoy me encontré una idea que aumenta mi punto: El Triángulo de la Documentación de Código.

    Documentación de Código:¿Qué, cómo, por qué?
    Documentación de Código:¿Qué, cómo, por qué?

    Este modelo mental nos dice que toda pieza de código está documentada en 3 dimensiones distintas, cada una respondiendo una pregunta muy particular.

    • ¿Qué?: Tu código, en sí, explica lo que estás haciendo.
    • ¿Por qué?: Los comentarios que le agregas a tu código, explican tu proceso de toma de decisiones y la razón de tus soluciones.
    • ¿Cómo?: El contexto dentro del cual estás desarrollando tu programa; la descripción original del problema.

    Si te enfocas en escribir código que “se documente solo”, en un futuro no sabrás por qué llegaste a esa solución, ni cómo esa solución es apropiada para el problema original.

    Recuerda, agregar documentación a tu código (en forma de comentarios, glosarios, RFCs, pruebas, etc.), 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 vas a ser tú.

  • GitHub Copilot ahora disponible de manera general

    Publicado por

    Oscar Swanros

    el

    a las

    Hace un par de días, GitHub anunció que Copilot está ahora disponible de manera general.

    Cualquier persona, hoy puede pagar $10 USD mensualmente por un compañero de pair programming creado con inteligencia artificial.

    Buen momento para recordar lo que escribí hace casi exactamente un año:

    Con el aspecto técnico resuelto (parcialmente) por inteligencias artificiales, las discusiones técnicas dejarán de ser la parte más importante del desarrollo. Los “programadores” ahora se dedicarán a tener discusiones sobre la ética y seguridad del código generado por la computadora. Las tareas técnicas serán resueltas, en su mayoría, gracias a la ley de Moore. Desarrollar software ya no se tratará de programar.

    Aún habrá trabajos para escribir código, pero requerirán una alta especialización. Las personas que sigan escribiendo código lo harán para crear la infraestructura que soportará al resto del ecosistema: compiladores, IA, generadores de código, redes, etc.

    Si estás en la industria del software y piensas que tu único trabajo es programar, heads up. Le acaban de poner fecha de caducidad a tu carrera. Y tienes de dos: o te pones a refinar tus soft skills, o comienzas a especializarte en tecnologías fundamentales.

  • Comunicación: la diferencia entre tener privacidad, y guardar secretos

    Publicado por

    Oscar Swanros

    el

    a las

    El término “comunicación” es tan amplio y dependiente del contexto del trabajo y la industria en la que uno se desempeña, que muchas organizaciones deciden simplemente no ponerle mucha atención. Adoptan una mentalidad de que “lo que importa es que las cosas se hagan, pero no importa cómo.”

    Adam Thomas escribió brillantemente al respecto (traducido por mí):

    La cultura de comunicación de tu empresa tiene un gran impacto en el resto de tu negocio. Cultivar una atmósfera de confianza es esencial para el éxito. El nivel de confianza que las personas en tu organización depositan en sus líderes y en ellos mismos, afecta la productividad, la salud de tus compañeros y la retención a largo plazo del equipo.

    En su artículo, Adam menciona que existen principalmente dos tipos de empresas: las que quieren hacer las cosas en privado, y las que quieren hacer las cosas en secreto. La diferencia es sutil, pero el diablo está en los detalles.

    Cualquier información que se comparta llamadas, mensajes directos o canales privados se pierde en el limbo. Esto le resta visibilidad al equipo, se pierde la trazabilidad del proceso de toma de decisiones, y en muy poco tiempo, la confianza del equipo se ve mermada por esta opacidad.

    A muchos líderes les cuesta trabajo ver más allá de la meta puntual que tienen en frente, e ignoran las consecuencias de fomentar una cultura de comunicación que hace que los miembros del equipo se sientan asediados, estresados e inseguros.

    Personalmente, estoy consciente de estos problemas y lo fácil que es caer en una situación donde el comportamiento por defecto es ocultar información. En mis equipos procuramos que cualquier llamada que tengamos con otros miembros quede resumida en un mensaje donde se listen los acuerdos a los que se llegaron. También, usamos canales de Slack públicos por defecto, y todos tenemos la expectativa de mover cualquier pregunta que nos hagan por DM a un canal público.

  • Legislatura en Washington obliga a que las vacantes incluyan información de salario completa

    Publicado por

    Oscar Swanros

    el

    a las

    El Proyecto de Ley 5761-S, en la legislatura de Washington, dicta que las descripciones de vacantes deberán incluir detalles completos de la compensación que recibirá la persona contratada.

    Puedes leer el documento final aquí. A considerar es que esto solamente aplicaría para compañías que tengan 15 o más empleados.

    Espero que esto se vuelva práctica estándar eventualmente.

  • Un lenguaje de programación no es una tecnología

    Publicado por

    Oscar Swanros

    el

    a las

    Me encontré este Tweet:

    Y creo que es una excelente oportunidad para recalcar un punto que a muchas personas se les escapa: un lenguaje de programación no es lo mismo que una tecnología.

    Los lenguajes son herramientas que te permiten razonar sobre problemas puntuales de maneras muy particulares.

    Por ejemplo, intentemos razonar sobre el concepto del “paso del tiempo”. Para los que hablamos Inglés y Español, vemos el pasado como algo que está a la izquierda, y el futuro como algo que está a la derecha del presente. Los que hablan Árabe, al revés, ponen el pasado a la derecha y el futuro a la izquierda. Y los que hablan Mandarín, ponen el futuro arriba y el pasado abajo.{{{L. Boroditsky, “Does Language Shape Thought?: Mandarin and English Speakers’ Conceptions of Time”, Psicología Cognitiva 43: 1-22 }}}

    Un lenguaje no solamente te permite resolver problemas particulares, sino que, además, cambia la manera en que entiendes el problema en primer lugar. Puedes hablar Mandarín perfecto, pero si te sigues refiriendo al pasado como algo que sucede a la izquierda del presente, no te van a entender cuando trates de explicarle el paso del tiempo a alguien en China.

    Hay una distinción, sutil, pero importante, sobre lo que queremos expresar, y el contexto en el que lo expresamos.

    Cuando el autor del Tweet original dice que “el lenguaje de SQL se ha mantenido vigente por más de 40 años” no se refiere a que no ha habido avances en la tecnología que le da el contexto necesario al lenguaje. SQL es un modelo mental tan poderoso para resolver problemas de organización, administración y escritura de datos, que trascendió su tecnología y se convirtió en un estándar de la industria. Hoy, si sabes SQL, puedes programar bases de datos utilizando diferentes tecnologías, como Oracle, MySQL, Access, PostgreSQL, Sybase, Microsoft SQL Server, y más.

    Ahí es justamente donde yo dibujaría la línea. Si sabes SQL, un lenguaje que sigue siendo relevante después de 40 años, no significa que no tienes que preocuparte por el contexto en el que vas a usarlo. Ese contexto hoy en día es mucho más amplio y tiene muchos más matices que cuando la tecnología original fue inventada. Y la primera pregunta que cualquier persona experimentada te haría si le pides consejo porque quieres usar SQL para administrar una base de datos es, ¿tienes la certeza de que una base de datos relacional es la solución adecuada?

    SQL permanecerá vigente indefinidamente mientras haya necesidad de resolver problemas de bases de datos relacionales. Pero la tecnología fundamental, el contexto en el que el lenguaje realmente brilla, puede cambiar, mejorar, empeorar, y sí, hasta desaparecer.

    Saber cómo expresarte en un lenguaje de programación no es una bala de plata. Incluso me atrevería a decir que tener dominio de únicamente un lenguaje puede llegar a ser contraproducente. Porque para ser eficiente y efectivo programando, no solamente tienes que saber expresar la solución a un problema — también debes poder determinar si la solución que quieres expresar es la adecuada para el contexto de tu problema.

    Es decir, tienes que saber si estás intentando usar Mandarín para explicarle a un Chino que ayer está a la izquierda.

  • La diferencia entre trabajar en producto vs. consultoría

    Publicado por

    Oscar Swanros

    el

    a las

    Toda la diferencia entre el trabajo de producto vs. el de consultoría está en los incentivos que determinan el cómo se trabaja.

    Hacer consultoría se trata de completar proyectos para un cliente. El objetivo es entregar a tiempo y cumplir con un contrato.

    Si trabajas en consultoría, lo que importa es entregar en tiempo y forma, lo que significa que la calidad y exactitud técnica del desarrollo no es prioridad. Después de todo, hay una gran posibilidad de que una vez que se llegue a la meta, y el cliente esté satisfecho, no será necesario revisarlo ni mantenerlo a largo plazo. Se le resolvió el problema al cliente, se entregó a tiempo y con los requerimientos cumplidos, y ahora puedes pasarte a pensar en el siguiente proyecto sin voltear atrás.

    Trabajar en desarrollo de producto se trata de resolver problemas para un usuario. El objetivo es agregar valor.

    Al desarrollar un producto, lo que estás buscando es crear tecnología para resolverle un problema a tu usuario. Muy probablemente (si trabajas en un startup, por ejemplo) no habrá una guía para encontrar la forma óptima de agregar valor. Tendrás que experimentar, investigar, innovar. Pero más importante, trabajar en producto tiene la implicación de que el mismo equipo será el responsable de arreglar cualquier cosa que se rompa, y de saldar cualquier deuda técnica que se adquiera.

    La fuente de frustración más grande que he experimentado es cuando he intentado desarrollar un producto como si trabajara en consultoría, y viceversa. Pero dejo esa historia para otra publicación.

  • No todas las empresas quieren contratar un “Ingeniero Senior”

    Publicado por

    Oscar Swanros

    el

    a las

    Un verdadero Senior no va a caer en la trampa de simplemente ir a implementar cosas sin pensar en sus posibles consecuencias e implicaciones a largo plazo. No va a aceptar mediocridades, y va a presionar para mejorar procesos — no solamente dentro de su área.

    Pocas organizaciones están preparadas para lidiar con el “pushback” que esto representa.

    Muchos que dicen querer contratar ingenieros de este nivel, en realidad lo que quieren son desarrolladores “nivel Mid” con muchos años de experiencia resolviendo cierto tipo de problemas. Pero no Senior.

  • Cómo programar una base de datos realmente útil

    Publicado por

    Oscar Swanros

    el

    a las

    Un sistema operativo es más que una interfaz gráfica y un conjunto de API: es una manera de ver el mundo. La forma en que está diseñado e implementado modela la forma en que sus usuarios interactúan con él.

    Las decisiones técnicas de la implementación de un sistema operativo informan, de manera directa o indirecta, como sus usuarios piensan acerca de las capacidades y potencial del sistema con el que están interactuando.

    Por ejemplo, Windows y macOS, a nivel técnico, manejan de manera completamente diferente el ciclo de vida de una aplicación. En Windows, el proceso termina al cerrar la ventana. En macOS, un mismo proceso puede tener múltiples ventanas abiertas, y cerrar una ventana no afecta el ciclo de vida de la aplicación que la mantiene. Un usuario relativamente avanzado, como tú, puede estar consciente de las implicaciones de usar cada estrategia de manejo de memoria y emitir un juicio sobre cuál ofrece más ventajas sobre la otra. Pero un usuario normal lo único que sabe es que en Windows cerrar una ventana significa que el progreso que ha hecho en su documento se va a perder, mientras que en macOS no.

    Creo que es una buena analogía para entender la importancia de tener cuidado al momento de diseñar, implementar y mantener una base de datos.

    Las discusiones sobre qué motor de base de datos deberíamos emplear, si implementar una relacional o una basada en documentos, son bastante comunes. Las que intentan entender si el modelo de datos que estamos construyendo tiene sentido lógico, es semánticamente correcto y qué tipo de valor añade al negocio, no lo son tanto.

    Una base de datos es útil en la medida en que los datos que almacena puedan ser manipulados, actualizados e interpretados. Los desarrolladores de software estamos muy acostumbrados a pensar en bases y modelos de datos únicamente como componentes transaccionales de nuestro proceso de desarrollo. “Tengo esta información aquí que necesito preservar de alguna manera”.

    Lo que nos falta concientizar, en muchos casos, es que otras personas, como analistas de negocios, científicos de datos y tomadores de decisiones, y otros desarrolladores, dependen de que la data que nosotros manipulamos y almacenamos sea accesible.

    Al igual que un sistema operativo influye en la percepción de las capacidades de una computadora, un modelo de datos moldea la forma en que otras personas resuelven problemas. Considera que la persona que va a utilizar tu base de datos está viendo su universo a través de tus decisiones de diseño e implementación. Aunque técnicamente tengas la información guardada, no va a servir de nada si esta no es accesible.

    Si el lenguaje es el medio a través del cual los humanos razonamos sobre las ideas de nuestro día a día, los datos son la memoria que nos ayuda a generar consciencia sobre las decisiones que hemos tomado. Y para poder tomar mejores decisiones, necesitamos tener mejores datos — no solamente más datos, sino más y mejores datos.

    Aquí te dejo algunos consejos puntuales que puedes comenzar a implementar desde hoy para que tus datos sean más accesibles:

    Comienza por tener buenas bases técnicas

    Date cuenta de que no hay motor de base de datos que sea una bala de plata. Lo que te funciona para resolver cierto tipo de problemas, no necesariamente funcionará para otros. Habiendo dicho esto, es importante que sepas que tienes toda la flexibilidad del mundo para implementar soluciones combinadas. Por ejemplo, para el módulo de contratos puedes usar una base de datos no-relacional, orientada a documentos. Mientras que en tu módulo de analítica puedes utilizar una base de datos distribuida como Cassandra, y en tu módulo de perfiles de usuario una un poco más tradicional como PostgreSQL.

    Sigue las mejores prácticas de cada tecnología que implementes. Si tienes bases de datos relacionales, normaliza tus tablas en caso de que esto agregue valor para tu caso de uso (si estás haciendo un sistema de analítica, mientras menos normalización mejor). Si tienes una base de datos basada en documentos, embebe los modelos que tengan relaciones para evitar joins a nivel aplicación.

    Recuerda que una buena base técnica es únicamente el primer paso para tener modelos de datos accesibles.

    Identifica tus datos y tus metadatados

    Recuerda que hay dos tipos de datos:

    • Datos de primer grado (el contenido de un correo electrónico)
    • Y datos que describen los datos de primer grado, también conocidos como metadatos (quién le mandó el correo a quien, a qué hora, a través de qué cliente de correo electrónico, etc.).

    La forma en que razono sobre estos tipos de datos es la siguiente: los datos de primer grado me permiten operar el día a día de mi negocio. Los metadatos me dan una visión de más alto nivel para detectar patrones de comportamiento de mis usuarios — incluso problemas potenciales que cuando se comiencen a ver reflejados en los datos de primer grado, será mucho más difícil corregir.

    Aprende a identificar estos dos tipos de datos, y pregúntate si deberías de mantenerlos de manera integrada, o los metadatos deberían vivir en su propio repositorio de información. Toma tu decisión, y procura que este mismo patrón se siga en el resto de tu organización.

    Procura la precisión semántica

    “Precisión semántica” es solamente una manera rebuscada de decir que es primordial que todos los involucrados estén hablando de la misma idea en un momento dado.

    Por ejemplo, ¿tienes claro qué es un “usuario activo” para tu negocio? En tu base de datos, este concepto pudiera estar simplemente representado por una tabla Users con una columna is_active, pero probablemente para el negocio un usuario activo es la relación intermedia entre la tabla de usuarios y la tabla donde están almacenados los contratos de servicio.

    Una discrepancia así de sencilla en el significado de un factor tan básico del negocio, puede ocasionar muchísimos problemas. ¿Cómo podrás refactorizar el código de la aplicación que interactúa con usuarios sin causar efectos secundarios imprevistos? ¿Cómo podrá el negocio estar seguro de que los datos que reporta a los inversionistas son realistas?

    Es importante que la forma en que diseñas tu base de datos esté informada por las necesidades del negocio. Después de todos, van a ser el negocio mismo el que se va a beneficiar o perjudicar como resultado de las decisiones técnicas que tomes. Ignorar esto es una receta para causar fricciones innecesarias y malentendidos entre equipos, además de que inherentemente estarás contaminando los datos que estás recabando.

    Por eso recalco que se necesita precisión semántica — tanta como sea posible.

    Aunque trabajes en un equipo de ingeniería, si tu trabajo es diseñar o mantener una base de datos, déjame decirte que tu rol está más cercano al negocio de lo que crees. De hecho, hasta cierto punto, la persona que diseña o mantiene una base de datos funge un punto de conexión entre el negocio y el equipo de desarrollo, pues está influenciando a través de sus decisiones técnicas a ambas partes sobre cómo razonar sobre los problemas que tienen enfrente.

    Procura que tu base de datos sea un reflejo semánticamente preciso con respecto a lo que tu negocio necesita.

    Haz que la data esté disponible par quien la necesite

    Apóyate de herramientas como Panoply, Metabase o Tableau para habilitar la interpretación de los datos que mantienes.

    Dependiendo de tu organización, es probable que no todo mundo necesite (o tenga permiso para) ver toda la información cruda. Procura tener una gobernanza de datos bien establecida para que haya forma de identificar si cierto dato en particular necesita ser visto por un stakeholder en particular.

    Como parte del protocolo de manejo de datos con los equipos con los que trabajo, usamos réplicas de nuestras bases de datos para cuando otras unidades del negocio necesitan acceso a los datos crudos. Pero nunca les damos acceso a las instancias de producción. Esto puede variar de organización a organización.

    Si sigues estos consejos, estarás haciendo algo porque tu trabajo no solamente sea correcto técnicamente, sino que además harás que sea útil y agregue valor a la organización. Toma en cuenta que esto es únicamente una parte de la ecuación, porque en mi mundo ideal, la gente de negocio sabría más de desarrollo de software. Y los desarrolladores de software se interesarían más por el negocio para el que trabajan.

    Pero vamos paso a paso.

    Gracias a Xavier Carrera por su feedback y ediciones en este artículo.