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.
Archivo de la etiqueta: desarrollo
La diferencia entre trabajar en producto vs. consultoría
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 que dicen querer contratar Seniors lo dicen en serio
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. Un Senior 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 Seniors, en realidad lo que quieren son desarrolladores “nivel Mid” con muchos años de experiencia resolviendo cierto tipo de problemas. Pero no quieren Seniors.
Software Libre: ¿Vale la pena involucrarse?
El mundo del desarrollo de software libre ha estado en las noticias últimamente. Desde la vulnerabilidad de Log4j que mandó a todo mundo a actualizar sus servidores, hasta las controversias por grandes compañías construyendo servicios y productos encima de productos de código libre sin honrar la naturaleza del mismo.
Con iniciativas como GitHub Sponsors, las compañías que dependen del software libre buscan incentivar que las personas que mantienen los proyectos sigan trabajando en ellos. Sin embargo, el panorama no se ve tan alentador para aquellos que tienen que lidiar con las implicaciones de mantener proyectos que son usados por millones de personas.
Gavin Howard, escribiendo en su blog:
Esto es deprimente, por decir lo menos. Es deprimente porque no veo otra alternativa más qu dejar de escribir software. Después de todo, no puedo encontrar trabajo, no puedo hacer dinero trabajando en software libre, y el código que escriba puede terminar dañando a más personas de las que ayuda.
Mi interpretación del problema es que el propósito del software open source se ha pervertido a lo largo de los años. Inicialmente, la idea era poder colaborar para crear mejores soluciones. Durante un tiempo, cuando se construían las bases de la industria de la tecnología, eso era una realidad. Hoy en día, el que una solución sea de código abierto se utiliza como excusa para no dedicar tiempo a entender sus fundamentos.
¿Cuándo fue la última vez que realmente te dedicaste a entender la solución que un paquete de NPM implementaba? No importa, porque es de código abierto, y seguramente alguien más encontrará lo que está mal en ella — si es que hay algo mal, en primer lugar.
La comunidad de código abierto aporta muchísimo beneficio a la industria. ¿Cómo se logrará hacer que reconozca estos beneficios y corresponda de igual manera a la comunidad que habilitó su creación en primera instancia?
Aquí una idea de cómo puedes comenzar a influenciar un cambio positivo: si el producto en el que trabajas depende de una pieza en particular de código open source, pídele a los líderes de tu organización que asignen una parte del presupuesto para contribuir económicamente al mantenimiento de ese proyecto. Si la persona encargada no tiene habilitado un perfil de GitHub Sponsor, estoy seguro de que estará más que contenta de recibir un wire transfer mensualmente con la contribución de tu empresa.
Las 4 fases del conocimiento: aprende a identificar en cuál estás
La semana pasada participé en un taller donde aprendimos el valor de escuchar sin intentar resolverle los problemas a otras personas. En la explicación que dio el facilitador, compartió un concepto que me voló la cabeza: las fases del conocimiento.
Durante el taller, usó esta idea para recalcar la importancia de mantenerse receptivo ante los sentimientos de los otros.
No lo había escuchado nunca, pero se me hizo una forma extremadamente práctica de entender cómo es que el conocimiento se vuelve parte de nuestra vida. Y hoy te quiero compartir ese concepto para que lo utilices cada que quieras aprender algo nuevo.
El conocimiento puede existir en 4 fases dentro de nosotros: Punto Ciego, Aprendizaje, Aplicación y Encarnación.
Las fases del conocimiento: Punto Ciego, Aprendizaje, Aplicación y Encarnación
Cada una de estas 4 fases se vive de manera consciente o inconsciente.
- Punto Ciego: Inconsciente. No sabes lo que no sabes. Asumes y supones, pero no te cuestionas por qué de las cosas. Simplemente, aceptas la realidad tal cual. Caes en dogmas y vas por la vida sin preocuparte por los efectos de tus acciones en el mundo que te rodea.
- Aprendizaje: Consciente. Por alguna razón, te diste cuenta de tu punto ciego y estás buscando, de manera consciente, expandir tu conocimiento. Estás estudiando, investigando, encontrando maneras de desbloquearte. Haces preguntas, investigas y te vuelves más receptivo a nuevas ideas.
- Aplicación: Consciente. Estás cristalizando tus aprendizajes de la fase pasada. Tomas lo que estudiaste, lo que aprendiste, y lo aplicas para terminar de asimilar el conocimiento. La aplicación de lo que has aprendido, a su vez, genera más preguntas. En esta fase es donde descubres tu propia versión de la verdad.
- Encarnación: Inconsciente. Lograste dominar tu craft y ahora puedes ejecutarla sin pensar — logras aplicar tu conocimiento de manera inconsciente. En esta fase es donde el conocimiento se vuelve sabiduría. Vuelves a no saber por qué sabes lo que sabes.
Si tienes la suficiente astucia, te darás cuenta de que este no es un proceso lineal, sino cíclico. Cuando logras encarnar el conocimiento, en tu mente se libera espacio para poder ponerle atención a otros aspectos de tu vida. Es ahí donde descubrirás más puntos ciegos, y podrás comenzar el camino de nuevo.
Esta forma de pensar también encaja perfectamente con el efecto Dunning-Kruger (el inverso del síndrome del impostor): “mientras menos sabes, más crees que sabes.” Te hice una gráfica.
La próxima vez que rechaces una idea, pregúntate:
- ¿Es este mi punto ciego?
- ¿Hay algo más que pueda aprender de este tema?
- ¿Podré aplicar lo que aprenda de esto?
Hacer soporte es trabajo de un desarrollador
Si tomas tu carrera en software en serio, deberías de buscar hacer soporte regularmente.
Como ingenieros tendemos a creer que hacer soporte no nos corresponde. Después de todo nosotros ya cumplimos escribiendo el programa; que el lidiar con los clientes se lo lleve el equipo dedicado a eso. Pero hoy estoy aquí para decirte que podrías obtener muchísimos más beneficios si cambias tu actitud, y si en vez de evitar hacer soporte, lo buscas.
Hacer soporte es parte integral del desarrollo profesional de cualquier ingeniero de software.
A través de la exposición a comentarios, preguntas, frustraciones y retroalimentación en general de las personas usando tu producto, ganarás más empatía por tus usuarios. También tendrás una mejor actitud cuando estés intentando arreglar problemas en tu producto, porque tendrás mejor visibilidad de cómo tus decisiones afectan a otras personas — directa, o indirectamente.
Además, afilas tus habilidades de comunicación a la hora de reportar bugs por tu cuenta. Algo cambia cuando parte de tu trabajo es intentar exprimir información de un cliente que solamente manda un “no funciona” con una captura de pantalla de un 404. Tu próximo reporte de un bug será mucho más claro, conciso y completo. Te lo garantizo.
Hacer soporte no es sencillo. Tienes que aprender a leer entre líneas para entender qué es lo que realmente te están reportando. Pero los beneficios de desarrollar esas habilidades son tangibles. Después de cumplir un tiempo haciendo soporte, tendrás un mejor entendimiento de lo que realmente valoran tus usuarios. Así, cuando vuelvas a trabajar en crear tu producto, sabrás exactamente a qué ponerle atención y cómo darles más valor agregado.
Ser un ingeniero de software encargado de hacer soporte es un ejercicio de humildad. Te darás cuenta de que tus preconcepciones sobre cómo se usaría tu producto son erróneas, y de que, por más que te cueste aceptarlo, no puedes predecir cómo alguien va a interpretar tus propuestas de solución. Eres humano, y hay cosas que ignoras. Esos espacios en tu conocimiento se hacen más obvios cuando te toca ayudar a otra a persona a desbloquearse.
Haz soporte. Te conviene.