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.