Phantom reference objects, which are enqueued after the collector determines that their referents may otherwise be reclaimed. Phantom references are most often used to schedule post-mortem cleanup actions.
Suppose the garbage collector determines at a certain point in time that an object is phantom reachable. At that time it will atomically clear all phantom references to that object and all phantom references to any other phantom-reachable objects from which that object is reachable. At the same time or at some later time it will enqueue those newly-cleared phantom references that are registered with reference queues.
In order to ensure that a reclaimable object remains so, the referent of a phantom reference may not be retrieved: The
getmethod of a phantom reference always returnsnull.JavaDocs
Y una vez más me he topado con el ego de un señor programador.
Hoy empiezo así, contundente y claro, porque no es la primera vez y probablemente no será la última. Uno de los propósitos de esta serie de posts era abrir melones del mundo de la programación. Situaciones incómodas que hemos vivido todos y que por alguna razón del universo se habla muy poco de ellas. Vamos a hablar del ego de los programadores.
Quiero destacar primero unas palabras de la frase con la que he iniciado el post ya que aunque me ha salido bastante directa, contiene varios detalles que suelen estar presentes en todas las discusiones que he tenido. Las enumero y nos metemos en faena: Ego; Señor; Programador.
Ego
¿Qué pasa con el ego? ¿Por qué la gente en este mundillo tiene tantos problemas relacionados con esto? Y hablo de problemas tanto por exceso como por falta. El año pasado estuve en una charla de Midudev (la grabación no es la mejor, no se si la ha dado en más sitios, perdonad) en la que habló de esto y resonó mucho conmigo. Llevo tiempo queriendo hacer una charla relacionada pero lamentablemente aun no he tenido la oportunidad,así que me toca desahogarme con vosotros.
Midu en la charla hablaba del famoso síndrome del impostor (del que también me gustaría hablaros en algún momento) y sostenía que todas las personas siempre habían sufrido este síndrome alguna vez, y que si no, eran poco menos que Llados. Ya en ese momento estuve en desacuerdo con esa afirmación (si todos lo hemos sufrido, ¿quienes son los impostores?, porque haberlos los hay) pero tras reflexionar sobre esto, me he dado cuenta que en el mundo tech hay mucho personaje suelto. La charla estaba enfocada en el síndrome del impostor y cómo combatirlo pero ¿para cuando la charla de cómo combatir el síndrome de Llados?
Está guapo hacer cosas importantes y proponer soluciones que resuelvan el problema de ese momento. Probablemente, esas ideas sean luego exportables y se puedan aplicar en muchos más sitios. Eso no quiere decir que tu solución siempre sea perfecta, que no tenga ninguna fuga o que no tenga puntos de mejora. El software evoluciona cada día ya que como hemos comentado en otros posts, las versiones y dependencias cambian y tenemos que adaptarnos a ellas.
La arquitectura del software se dedica a pensar más que a programar. Es muy típico ver en empresas pizarras blancas con varios desarrolladores apiñados en torno al rotulador debatiendo sobre cuál es la mejor forma de hacer el sistema de logging. Todas las soluciones van a poder ser mejoradas en algún momento y aunque nos empeñemos, siempre hacemos cosas tapándonos la nariz y mirando para otro lado porque nos conviene por alguna razón. No es lo ideal pero es el desarrollo del software. Cuando el tiempo aprieta y tienes que sacar el producto adelante, muchas veces hay que sacrificar la calidad.
Reconocer este punto es la clave. Todos somos humanos y podemos tener fallos. Si recibimos feedback sobre algo que tiene que ser mejorado por alguna razón, no hace falta que reaccionemos como si estuviesen matando a nuestro primogénito. Siempre desde el aspecto constructivo, aportar ideas enriquece a los equipos y ayuda a construir un futuro más sano y mejor.
Señor
Como parte del “colectivo” de señores veo esta problemática. Los datos de igualdad en el mundo tecnológico siempre han arrojado datos apabullantes sobre la falta de presencia equilibrada entre mujeres y hombres. Los datos empeoran si ascendemos en la responsabilidad, donde se ve claramente un complejo techo de cristal por diversos motivos. Para coronar el pastel, este orgullo o prepotencia que existe en el sector y que trato de visibilizar en este post, nunca lo he recibido por parte de una mujer.
Este ego que hace a las personas estar por encima del bien y del mal, no aceptar críticas constructivas sobre su trabajo o simplemente que haya que tomar su palabra como verdad absoluta es característico del género masculino. En mis años de carrera no me ha pasado nunca eso con una mujer así que habría que revisarse un poquito.
Dejo esto aquí ya que no soy yo el que tiene que profundizar en el tema pero sí que me gustaría visibilizar un poco la situación.
Programador
Yo estudié el Grado en Ingeniería de Tecnologías y Servicios de Telecomunicación en la Escuela Técnica Superior de Ingenieros de Comunicación de la Universidad Politécnica de Madrid. Un nombre muy pomposo para decir “Estudié Teleco en la ETSIT de la UPM” en el mejor de los casos y, “soy teleco” en el peor. Como dice el título, yo no hice una ingeniería (de las de antes) sino que estudié un “grado” en ingeniería, lo que me convierte en graduado. Esto viene de que con el cambio a Bolonia, las antiguas ingenierías que duraban 5 años (creo que dependía un poco de cada una pero eso era lo normal), se convertían en un combo de Grado (4 años) más Máster (2 años). Y ojo, no cualquier máster, si no uno que llaman habilitante y te equipara con el antiguo “ingeniero”.
Otro día os cuento más cosas de las peripecias de teleco pero traía esto a colación ya que a mi, desde el primer día, me dijeron que tenía que estar orgulloso de ser ingeniero y más aún de teleco. Vueltas que da la vida, nunca he ejercido de teleco y no creo que lo vaya a hacer. La realidad es que trabajo desarrollando software, algo que se asocia más a la carrera de informática. Sin embargo, yo sí que estoy considerado “ingeniero” por haber hecho esta carrera.
Hace muchos años, cuando mi buen amigo Antonio Leiva sacó su programa Architect Coders (muy recomendable si quieres aprender bien a desarrollar en Android), le llovieron unos cuantos palos porque decía que los alumnos serían “ingenieros android”. Partiendo de que no hay una titulación universitaria que sea ingeniería de Android, no entiendo por qué la gente se le echó encima. Parecía que estaba minusvalorando el desarrollo de software si no lo hacía un ingeniero o que a tremendo honor sólo se podía acceder a través de una carrera universitaria.
Antonio enseña a la gente a resolver problemas de Android y un ingeniero es una persona que aplica sus conocimientos técnicos a resolver un problema. Por lo tanto, aplicando la lógica que aprendí en el bachillerato, me parece una afirmación bastante acertada. Claro, tienes que dejar el orgullo ego a un lado y que no se te caigan los anillos porque gente “no ingeniera” acceda al mismo puesto que tú e incluso haga mejor el trabajo que tú.
Por lo tanto, tener un título o haber hecho cosas fabulosas en el pasado, no debería garantizarte nada. No importa cuál sea tu pasado o donde hayas trabajado y estudiado. Las empresas te van a pagar para resolver un problema y deberías enriquecerte de las ideas de todas las personas que te rodeen.
Una nueva esperanza
A modo de epílogo, quiero compartiros que esta persona se disculpó, reconoció su error y quiso ayudar con el problema. Esto no es muy común por lo que es de agradecer que se muestren reacciones de este estilo de forma autónoma (hasta donde yo se). Aunque es lo correcto y no tenemos que hacer una fiesta cada vez que alguien se porta bien, es importante que no hagamos leña del árbol caído y darle espacio a la gente para que corrija sus propios errores.
Nos vemos!