Libro: Women in Science

IMG_20170307_113326

Titulo: Women in Science. 50 fearless pioneers who changed the world.

Autor: Rachel Ignotofsky

Editorial: Ten Speed Press

Hace unos días compré este libro con idea de practicar algo de inglés con mi hija de 7 años y pasar ratos juntos compartiendo algo que nos interesase a ambos. Con temática científica ligera, bonitos dibujos y en inglés sencillo, este volumen de poco más de 120 páginas (en realidad solo tiene texto por una cara para cada una de las 50 mujeres) cubría todo eso, por lo que me aventuré a adquirirlo en Amazon.

El contenido es exactamente lo que esperaba y parece que a mi hija le ha gustado bastante que le cuente cosas con dibujos bonitos y palabras en inglés que ella conoce o puede aprender con facilidad.

Sin embargo, he de reconocer que, aunque es un libro para niñas, me está gustando mucho como hombre adulto que soy. Los pequeños detalles biográficos que ha incluido la autora para cada una de las 50 mujeres y la calidad y cantidad de dibujos, unidos a un muy cuidado diseño (tirando a monocromo en cada mujer pero variando en color para cada una por ejemplo) lo han convertido en uno de esos libros que agradeces poseer, al estilo de “La historia del mundo en 100 objetos“.

Así que diría que es una muy buena compra si: a) tienes tiempo para pasar con tu hija, b) esta ha mostrado curiosidad por el mundo, c) le gusta dibujar y  d) no le asusta el inglés. Aunque probablemente se aprovecha más si tienes una formación “de ciencias” que te permita ampliar algunas de las cosas que se comentan en el libro (ej: cristalografía de rayos X). En mi caso, décadas de leer divulgación científica cubren ese aspecto pero imagino que mi caso es un poco de nicho.

Por otro lado, como padre e informático, me ha parecido muy gracioso que mi hija haya decidido empezar a leer el libro por Ada Lovelace… porque está pintada en rosa.

Para terminar, un consejo más y una cita del libro. El consejo: echa un buen vistazo al trabajo de Rachel Ignotofsky, me parece una pasada lo que tiene en su web o en Etsy.

La cita, del capítulo dedicado a  Heddy Lamarr, inventora y actriz de cine (y también pintada en rosa).

“[My father]” made me understand that I must make my own decisions, mold my own character, think my own thoughts” -Hedy Lamarr

 

Anuncios

Libro: El código del dinero

raimon

Libro: El código del dinero

Autor: Raimon Samsó

Editorial: Ediciones Obelisco

Apunté este libro en mi lista de lectura tras la recomendación que hizo del mismo Andrés Pérez en su blog Marca Propia. Al acabarlo tengo sentimientos encontrados y aunque me parece muy útil, me siento manipulado. Si tuviese que compararlo a otro libro (de autoayuda o crecimiento personal, claro) sería el de Dejar de fumar es fácil si sabes cómo: manipulador, efectivo para quienes ya están convencidos y un gran negocio para su autor y editorial (más de 50 ediciones). Todos ganamos.

La primera parte del libro es brainwashing puro, pero necesario para conseguir el estado mental adecuado que permite asimilar el resto del contenido y cuyo objetivo declarado es que podemos montar nuestros propios negocios para alcanzar la libertad y felicidad. Y que necesitamos hacerlo cuanto antes.

La segunda parte es un conjunto de buenos y estructurados consejos para emprendedores. Algo parecido a El arte de empezar de Guy Kawasaky, y la parte más práctica con diferencia, aunque esté mezclados con algo de coaching/manipulación y auto-venta. Acaba dejando un buen sabor de boca y con muchas ganas de empezar a trabajar en construir un mejor futuro.

Quienes hemos visto como es la vida del profesional autónomo o de los pequeños negocios, sabemos que es necesario una actitud diferente a la estándar (la de funcionario, búsqueda de salario fijo, etc.) y gran cantidad de sacrificio. No todo el mundo está hecho para esa vida a lo pastilla roja de Matrix: libre y con una misión. Este libro puede ayudar a quienes estén dándole vueltas a dar el salto, pero será una pérdida de tiempo para quienes solo quieran estabilidad y seguridad.

Como nota curiosa del libro, es de agradecer que el propio autor menciona muchos consejos que él mismo toma (pueden comprobarse, no son “historias”), demostrando así que no se trata de un conjunto de ideas vacías, sino que al menos en su propio caso funcionan.

A continuación, algunos extractos del libro, aunque recomendaría leerlo en orden de principio a fin y dejo fuera propuestas prácticas algo más elaboradas por ser demasiado extensas para encajar como extracto.

-o-

No importa a qué te dediques, producción o servicios, manual o intelectual, tu trabajo tarde o temprano se virtualizará, automatizará  o se subcontratará en donde cueste menos y se haga mejor. […] ¿Quién ganará más con todo esto? No te equivoques, no son las empresas, son también los consumidores (todos nosotros) al disponer de mejores bienes y servicios, a mejor precio.

-o-

Los sistemas educativos estimulan a estudiar para tener un empleo, pero la buena formación financiera enseña a no necesitar un empleo.

-o-

Tratar de evitar, o ignorar, los problemas financieros equivale a mantenerlos, porque los problemas no se resuelven por sí mismos.

-o-

El buen inversionista invierte más tiempo que dinero. El mal inversionista sólo invierte dinero y poco tiempo en averiguar qué está comprando. Siempre me ha llamado la atención lo rápido que las personas colocan el dinero que tanto tiempo les costó ganar en lo que desconocen. Invierte más tiempo en aprender a invertir, e invierte menos dinero.

-o-

Me encuentro con personas desajustadas con sus metas: desean un efecto pero detestan la causa [el precio y esfuerzo a pagar]. Como están desalineadas, no consiguen sus deseos y se sorprenden cuando afirmo que “querer” algo no sirve de nada, lo que vale es la acción disciplinada. Y lo que no vale es decirse “Bueno, ya lo haré algún día” porque ese día nunca llega.

-o-

Cuanto mayor valor entregues, mejor te irá y menos le importará a tu empleador o cliente el precio que les pidas.
Si simplificas las cosas que para la gente son complejas, te ganarás muy bien la vida. Vamos, “harás dinero”. La regla es muy clara: entrega valor masivamente. ¿Hay algo nuevo en ello? ¡Nada! Y aun así suena a nuevo. […] Hay excepciones, claro, puede que sí entreguen un gran valor a la empresa y a los clientes pero que no sean justamente correspondidos, en ese caso no se están entregando a sí mismos suficiente valor porque no se dan la oportunidad de trabajar en otro lugar.

-o-

Pregúntate (cada semana): ¿Qué puedo hacer para que mi producto o servicio sirva a más personas?
Tómate tiempo (cada mes) para pensar cómo puedes servir a diez veces más personas de las que atiendes en la actualidad (ya sea en tu empleo o en tu negocio). Cuando lo consigas, tu valor (como empleado o como profesional independiente) se habrá multiplicado.
Pregúntate (cada año): ¿Qué nuevo producto o servicio puedo suministrar que añada un valor masivo al mercado? Es de principiantes crear una oferta y después buscar su demanda, en el supuesto de que exista. Es empezar la casa por el tejado. No caigas en ese error. Sal ahí fuera y averigua qué problemas puedes resolver, o cómo podrías mejorar la vida de las personas en algún aspecto, y luego elabora tu propuesta.

-o-

Me gustan las paradojas porque son el principio del cambio de paradigma. He aquí las tres paradojas del emprendedor:
1.- Para ganar dinero, olvida el dinero: céntrate en servir.
2.- Para triunfar, olvida triunfar: céntrate en disfrutar.
3.- Para actuar, olvida el resultado: céntrate en el proceso.

-o-

¿Resultados o tareas? Yo lo tengo claro, ¿y tú? El emprendedor, el bueno al menos, no busca estar ocupado, persigue resultados. […] Por ejemplo, yo no escribí un libro (tarea), construí un best seller (resultado). ¿Ves la diferencia entre tareas y resultados? Ahora, sustituye las tareas de tu agenda por resultados (o al menos anótalos al lado de cada tarea) y verás cómo aumenta tu eficiencia.
Los resultados son importantes, las tareas suelen ser urgentes aunque no necesariamente importantes.

Developer Timeline 1996-2016

pope-john-paul-ii-and-fidel-castro-watching-time

Hace unos meses intenté convencer a algunos desarrolladores de que necesitaban aprender Git. Algo que desde mi perspectiva parecía obvio y urgente se tornó, pese a mis esfuerzos por argumentarlo, en imposible. Desde entonces he estado dándole vueltas al tema de la obsolescencia de las herramientas, técnicas y servicios que los desarrolladores usamos a diario y a como alternamos entre lo malo conocido y el hype del momento.

Esto me llevó a pensar en cómo “de-mostrar” a determinados perfiles técnicos de la necesidad de actualizarse, lo cual me condujo a confeccionar una “línea de tiempo” o mapa de tecnologías y herramientas de desarrollo .NET para poder observar el avance en determinados ámbitos como el control de versiones de código.

Gracias al intercambio de ideas de los Meetups en SwCraftersCLM y los ánimos que me han dado desde esta comunidad para publicar el “timeline de desarrollo”, he terminado una versión 1.0 que he colgado en Google Sheets para uso y adaptación de otros equipos de desarrollo, incluso de otros stacks tecnológicos. O aprovechando que acabamos el año, para pararse a pensar qué aprender en 2017.

El Excel es el siguiente: Developer Timeline 1996-2016

¿Para qué sirve?

La idea es poder usar la hoja como herramienta de 4 formas diferentes para varios objetivos:

  1. Para poder revisar en qué punto estamos de actualización técnica y ayudarnos a decidir si aprender o no una tecnología en concreto.
  2. En grupos de desarrollo. Para poder argumentar con datos objetivos frente a nuestros compañeros sobre la necesidad, o no, de reciclarnos tecnológicamente. Como mínimo debería facilitar el diálogo sin caer en el flame.
  3. En charlas. Para poder hacer una introducción simpática para todos los públicos sobre determinadas tecnologías como Core o SharePoint Framework añadiendo un contexto tecnológico más amplio que facilite el entendimiento de los problemas que resuelve.
  4. En organizaciones. Para poder establecer el nivel de actualización de una organización (la nuestra u otras) de una forma más o menos objetiva. En última instancia podría ayudarnos a decidir si embarcar en una empresa o desembarcar de la actual.

¿Qué contiene?

La hoja contiene varias categorías (eje vertical) y eventos relevantes para cada una de las categorías, repartidos por año (eje horizontal).

Me pareció adecuado empezar en 1996 por tener un intervalo amplio y “redondo”: 1996-2016. El año 1996 sirve además para poder establecer una línea base de “desarrollo viejuno”.

La información que contiene está orientada por mi experiencia y entornos de trabajo a lo largo de los años por lo que hay bastante de Microsoft, pero he tratado de mantenerlo flexible para poder adaptarlo a otros entornos aglutinando la mayoría de elementos específicos de Microsoft en su propia categoría.

Sobre las categorías, los datos y la selección

Hay muchos elementos que podría haber metido pero que finalmente he eliminado por claridad (versiones, irrelevancia…) y simplicidad.

Muchas fechas son aproximadas y en algunos casos discutibles. En general he tratado de tomar las más importantes como por ejemplo productos release en lugar de beta.

Hay bastante tecnología Microsoft debido a mi propio background y el público al que lo he enfocado, pero he tratado de mantenerlo flexible para otros stacks.

Este documento no pretende ser canónico, sino una herramienta ilustrativa de la evolución y periodos que vivimos los desarrolladores de software. Está pensado para ser modificado de forma sencilla por lo que he desistido (de momento) de hacer un gráfico SVG interactivo con D3 y JSON.

Las categorías en que he agrupado los eventos son las siguientes:

  1. Papas: Los papas de la Iglesia Católica Apostólica y Romana que hemos tenido desde el 96. Me parece interesante mostrar que hasta las organizaciones más antiguas y tradicionales experimentan más cambios que algunas personas o empresas.
  2. Efemérides: Evento de relevancia nacional o mundial. Permite replantearse la cantidad de tiempo que ha pasado entre tecnologías y los grandes cambios que han sucedido en la sociedad.
  3. Películas: Estrenos de cada año. Me parece un detalle simpático para tratar de poner en contexto el tiempo que ha pasado, en particular entre fans de Marvel como yo, y la cantidad de proyectos que pueden llevarse a cabo en 5 o 10 años.
  4. JavaScript: Aun hay gente que no quiere saber nada de JavaScript o quiere quedarse en la versión del ’99. Visibilizar la cantidad de hitos que ha tenido debería facilitar el NO poder ignorarlo.
  5. Autenticación y Autorización: Todavía tengo que explicar las diferencias entre autorizar y autenticar. En el panorama actual y dado que es necesario conocer estos temas para realizar cualquier aplicación moderna, me parece grave y por eso le he dado su propia categoría.
  6. Servicios web: Esta categoría trata de servicios web y trata de poner de manifiesto que la diferencia entre SOAP y REST en realidad son pequeñas y que deberíamos mirar más allá del hype al evaluarlas. También pone en el mapa los webhooks, que parece que son grandes desconocidos a pesar de su utilidad y antigüedad.
  7. Formatos de datos: Me pareció apropiado añadir esta categoría tras la de servicios web para señalar que son dos cosas independientes y que ya va siendo hora de aprender a usar JSON. O usar Markdown en lugar de HTML en según que contextos.
  8. Front End: Esta categoría podría ser una hoja aparte, pero he tratado de incluir estándares de facto y orientarme a desarrolladores back o full stack. He añadido asteriscos a temas de W3C para recordar que… “es complicado” asegurar en qué estado están.
  9. Gestión de código: Esta es la razón por la que comencé a confeccionar el Excel y por eso tiene un componente “fuerte” de productos Microsoft, pero dejando claro que el estándar a día de hoy es Git. De hecho, es importante mencionar que Microsoft lleva años migrado todo su código abierto a Github.
  10. Servicios de terceros: Incluyo una lista de servicios de terceros relevantes para perfiles técnicos. Estos deberían contrastar con la antigüedad de algunas de las herramientas de algunos técnicos. Si, por ejemplo, alguien usa Dropbox (2008) o Google Drive (2012), no podrá argumentar que Git es demasiado moderno (2005).
  11. Microsoft Stack: categoría específica para los que usan el stack de Microsoft, por lo que en adaptaciones a otras empresas debería adaptarse. El “baseline” es Outlook porque me pone nervioso ver que no se sabe usar a nivel básico (carpetas, convocatorias, respuestas automáticas…) y es una herramienta que todos usamos a diario para trabajar en empresas, en particular con el stack Microsoft.
  12. S.O.: Sistemas operativos desde el ’96. Con especial detalle en el ámbito Windows, claro. Porque todavía hay quien quiere volver a W7 por pura resistencia al cambio.
  13. Dispositivos Móviles: He tratado de sintetizar el panorama en dispositivos móviles. Al estar tan unidos hardware y software he mezclado ambos elementos. Evidentemente Windows Phone/Mobile se queda fuera.
  14. Lenguajes: Es interesante ver que los lenguajes de back-end son bastante estables, pero no inmutables.
  15. Entorno de ejecución: Parece que todo es alguna variedad de la máquina virtual de Java o el que tiene que funcionar sobre el CLR de .NET y no solo no es así, sino que el panorama parece que va a cambiar cada vez más. Estuve tentado de introducir Docker también, pero los contenedores son otra historia y aun me parece pronto para añadirlos, quizá el año que viene o quizá en otra categoría de DevOps.

Como nota curiosa no he notado nada interesante en 2003 pero si muchos eventos importantes en 2009: el embrión de Azure y Office 365 (BPOS), Android 2.0 (la primera versión buena), Windows 7 (el más querido), ECMAScript 5 (el JavaScript de la nueva web), Bitcoin (y la explosión del blockchain), GO (del que Javier nos dará una charla pronto) y Node JS (¿el nuevo Java/PHP?) del que vimos como se usaba en producción en las Lambdas del AWS de BrainSINS en el último Meetup.

En resumen

Como decía el personaje de Will McAvoy en The Newsroom: El primer paso para resolver un problema es reconocer que hay uno (minuto 5:00, pero el speech completo es impresionante).

Mi intención inicial era mostrar como Git es una herramienta indispensable para el desarrollador de .NET de hoy, comparándola con eventos relevantes del pasado reciente de forma objetiva y amigable.

Aunque parece que he conseguido construir esa herramienta, creo que he generado algo más potente, una especie de minicuadrante de Gartner del desarrollador .NET (y en general) que podría servir para animar a algunos técnicos a reciclarse, y que me ha ayudado a ampliar mi visión estratégica para 2017 así como a mejorar mi planteamiento como arquitecto de soluciones y líder técnico. O como mínimo me ha aclarado panorama bastante ahora que parece que todos andamos perdidos de stack en stack y de framework en framework especialmente en el mundo Microsoft.

Para terminar

Al revisar mis propios artículos me parece reconocer que en el universo Microsoft, 2016 es una repetición de 2012. Da para otro artículo, pero si estás más o menos al día creo que podrás ver las semejanzas entre el panorama actual (Azure, Office 365, Hololens, ARM, Open Source…) y el que describí en 2012 en: El desembarco de Normandía.

Y si te ha interesado este artículo, es muy probable que te interesen mis artículos: Breve historia del desarrollo de software de 2012 y mi predicción sobre el futuro de Blackberry, iPhone y Palm en 2007: La muerte de Blackberry.

10 Tweets sobre gestión de proyectos

Hace unos días, leí una serie de tweets de Marc Hedlund, mencionando 10 consejos sobre gestión, con los que estoy muy de acuerdo y de que una forma u otra trato de aplicar cuando me toca el rol de gestor, o que espero cuando soy “gestionado”.

No está mal recordarlos de vez en cuando y tenerlos a mano en un post como este.

Ahí va el texto completo:

I get a lot of requests for management advice and I enjoy talking about good management. Management is hard. Doing it well matters.

I looked back over the management questions I get the most often; here are the most common pieces of advice I give out, in ten tweets.

Just tell them already. One of the best things you can do as a manager is be completely blunt about what you see. Tell them now.

Trust is the currency of good management. You cannot be a great manager if the people with whom you work do not trust you.

Regular one-on-ones are like oil changes; if you skip them, plan to get stranded on the side of the highway at the worst possible time

You have to be your team’s best ally and biggest challenger. You can’t be a great leader by care-taking alone. Push for their best work.

Repetition feels silly but works wonders. Start each conversation repeating the overall goal and connecting it to the discussion.

“My team wants to work on ___ because it is more fun for them, is that okay?” No. Never. Quoting @jasonk: “Winning is fun.” Go win.

Clarify the problems your team needs to tackle. Stay all the way away from specifying the solutions. That’s their job, not yours.

You can’t know how the company looks from any other seat than your own. Practice with people in other seats to communicate and manage well.

We talk a lot about diversity and inclusion. Here’s my unpopular opinion: you, as a manager, have to force it to happen, or it won’t ever.

Usually when people ask, “Should I fire this person?” the answer is yes. But usually they do it dramatically more brutally than needed.

Y por si te interesa seguir los comentarios y aclaraciones que siguieron a los tweets, el comentario original es este:

La que he liado – Un contexto y una disculpa

William-Adolphe Bouguereau (1825-1905) - Two Sisters (1901)

Hace unos días uno de mis tuits generó bastante actividad, entre el debate y el enfado, dependiendo del momento y del participante (no me excluyo).

No es la primera vez que esto sucede en Twitter. Ni soy el primero en provocar o sufrir esto, ni es algo raro o especial como pueden atestiguar Edin Kapić, MVP de Microsoft y una de mis referencias favoritas de esa comunidad, o Roberto Luis Bisbé al que también sigo al resultarme interesantes sus contenidos. Trato de tomarlo como uno de los gajes de la exposición pública y la tendencia al malentendido del medio escrito, inmediato y limitado a los 140 caracteres que es Twitter.

Que Edin (por partida doble), Roberto y yo compartamos este dudoso honor, no significa que seamos equiparables, amigos, ni nada por el estilo, simplemente son tres ejemplos recientes de “la-que-he-liado” en la comunidad Microsoft, en Twitter. De hecho solo he hablado en persona con Edin en un DevCamp de Apps para SharePoint 2013 de Microsoft en 2013 y con Roberto en la Iberian SharePoint Conference de 2013. Para mi, ese fue un buen año de asistencia a eventos en horario laboral.

Los que me conocen saben que vivo en Toledo, por lo que mi participación física en eventos en Madrid, donde suelen darse estos, es complicada sin una aprobación de mi empresa para hacerlo en horario laboral. Máxime cuando tengo una pequeña de 6 años a la que idolatro. Eso convierte el texto de este blog y mi perfil de Twitter en los únicos medios desde los que puedo “hablar” o al menos expresarme en público con otros desarrolladores (y otras personas con intereses similares a los míos), en particular de Microsoft, fuera de mi oficina. Fuera del mundo Microsoft lo tengo más sencillo con los Meetups de Software Craftsmanship CLM.

Entiendo que otras personas tienen otros entornos, medios y motivaciones: cada uno tiene su contexto. Y en ese contexto se enmarcan las opiniones que vertemos. De nuevo Twitter no es el mejor modo de conocer este contexto, siendo lo óptimo las relaciones cara a cara durante años, pero eso requiere de unas circunstancias laborales y personales que no tengo.

Iba a usar este texto como inicio para hablar de Eventos técnicos, Ferias, Comunidades Técnicas, Meetups, Open Spaces y demás elementos que parece que mezclamos en algunos eventos como el pasado Techsummit. Es algo en lo que me apetecía pensar (y por lo tanto escribir) tras la discusión desencadenada, pero parece que este prólogo me ha quedado demasiado largo y no estoy seguro de cuando podré terminar de escribir mis opiniones al respecto debido a mis circunstancias personales y profesionales.

En cualquier caso, me gustaría terminar este post ofreciendo mis disculpas a quien quiera que haya podido sentirse ofendido con mis palabras en esa discusión en particular y en las futuras. Al fin y al cabo todos formamos parte de la misma comunidad, y por lo tanto todos queremos lo mejor para esta. De eso no tengo duda.

¿Continuará?…

Igualdad y desarrollo de software. ¿A quién le conviene?

wp_20150201_001

Hace unos días asistía en Twitter a la conversación de varios desarrolladores, MVP, técnicos, etc. acerca de la visibilidad de las mujeres en el evento para desarrolladores Codemotion. Espoleados por nuestro particular Pepito Grillo de la comunidad Microsoft en España Edin Kápic, los comentarios no se hicieron esperar por parte de desarrolladores, MVP o evangelistas de Microsoft como Isabel Cabezas cuya opinión como representante femenina tiene especial valor.

Al final, entre tanto hilo y con la limitación de espacio que caracteriza a Twitter parece que teníamos muchas preguntas e interés en el tema de mujeres y desarrollo de software pero pocas respuestas.
Como parte doblemente interesada por ser desarrollador y padre de una hija a la que me gustaría ver en “ciencias” (STEM), quiero hablar solo un poco (el tema es extremadamente complejo por lo que parece absurdo intentar ir más allá en solitario) de mis opiniones y dudas acerca de si es necesario o siquiera buena idea esforzarse en aumentar la presencia femenina en el sector.

Empezaré diciendo que la vez que más abiertamente he escrito sobre el feminismo fue comentando en junio el documental CodeGirl  y que cobra mayor relevancia con cada evento que persigue la igualdad estadística entre sexos. Y no lo he hecho más a menudo porque es un tema “caliente” que podría volver fácilmente un texto en un problema para el autor, pero con una hija estos temas cobran cada vez más importancia. También, quizá por haber leído Universidad y Ciencia en España, de Clara Eugenia Nuñez  y La Tabla Rasa de Steven Pinker, me surgen serias dudas sobre si es buena idea lanzarse a movilizar mujeres y hombres a la búsqueda de la igualdad estadística, en parte por si estamos resolviendo un problema equivocado y en parte por si provocaremos efectos secundarios no deseados.

En cuanto a mi opinión sobre las mujeres en el software, aunque muchos comentan que todas las desarrolladoras de software con las que han trabajado eran estupendas, yo diré que también las he encontrado muy malas, pero parecen trabajar mejor en equipo en general. De todos modos no he tenido ocasión de trabajar con tantas como hombres ni de lejos así que aquí tengo un sesgo clarísimo, y eso señala un problema o una característica social o del sector que valdría la pena explorar.
Sobre mujeres dando charlas, la única vez que he insistido en que alguien nos diese una charla técnica fue de una compañera de front-end. Ella pensaba que “no era tan buena” pero yo veía evidente que sí y creo que el tiempo acabó dándome la razón. En ningún caso quería incluir mujeres (era interna) sino aprender de los más competentes y en este caso era ella.

Por último, pongamos algunas cosas sobre la mesa:

  1. Hay un interés económico claro y reconocido de aumentar el pool de desarrolladores disponibles para la industria (lean algunos comentarios, son interesantes).
  2. Hay un interés claro de determinadas empresas en aumentar la diversidad de desarrolladores (más allá del sexo) en sus plantillas en pro de la “innovación”. Sea lo que sea eso.
  3. Como sociedad, parece que España es una de las mejores del mundo, muy lejos de la estadounidense.
  4. Desarrollar software no es fácil, y requiere de una dedicación seria con una necesidad de renovación constante que no todo el mundo (sea del sexo que sea) está dispuesto a asumir y mucho menos a disfrutar. Recordemos que los jóvenes quieren ser funcionarios.
  5. Los Estados Unidos son una sociedad diferente, con problemas diferentes a la Española, de los cuales no deberíamos importar soluciones sin más, sin un poco de espíritu crítico, a riesgo de generar nuevos problemas o romper cosas que funcionan, como la sanidad pública.
  6. Hay despidos en empresas técnicas como Microsoft a nivel mundial o HP localmente.

Por tanto, mi opinión actual es que tenemos varias economías nacionales con intereses claros en aumentar y diversificar el pool de desarrolladores. Tenemos también una oleada de problemas “del primer mundo” y soluciones extraídas de la sociedad estadounidense que están siendo importadas prácticamente sin espíritu crítico por colectivos interesados como son políticos (votadme mujeres de 18 a 35 años), empresas de eventos (mujeres, venid a mi evento de pago) y empresas/profesionales de formación (hágase rica programando con mi curso). Sobre la formación además parece que estamos ante una burbuja.
Y por último tenemos a los desarrolladores sin distinción de sexo o edad, que parece que tenemos un incentivo económico para NO aumentar el pool de desarrolladores. Con ello algunos esperan conseguir sueldos un poco más altos (acordes a lo que esperaríamos en otras economías del entorno) o al menos evitar despidos como los de HP por poner un ejemplo. Este último caso deja claro que no hay escasez real de mano de obra técnica, sino de mano de obra barata.

Todo esto debería dar bastante que pensar y hace que me plantee decenas de preguntas. Tantas que he desistido de intentar articularlas o mencionarlas aquí con idea de centrarme en la más importante.

¿Qué problema queremos resolver realmente?

O a nivel más personal y concreto ¿cómo va a hacer más felices a mi mujer y a mi hija el aumento de mujeres desarrollando software?

A la primera pregunta la única respuesta evidente es que queremos abaratar costes a empresas (no a autónomos, ojo). Por favor, si alguien tiene otra, que me la diga, porque yo no soy capaz de dar una alternativa.

A la segunda pregunta no parece que aumentar el número de mujeres desarrollando vaya a tener un efecto beneficioso sobre el futuro de mi hija. A priori, siendo mujer te puede ir mejor si está dispuesta a aprovecharte del sistema y de los sesgos (leyes, micromachismos) aunque imagino (que no veo) que puede tener sus ventajas aumentar el número. Pensando en efectos secundarios lo que veo es un escenario de sueldos peores y mayor competencia, por lo que estaríamos ante la típica carrera hacia el abismo.

Así que, aunque me parece normal y deseable que grandes empresas se envuelvan en la bandera de la inclusión para mejorar ingresos, yo no veo ningún incentivo para que los trabajadores apoyen iniciativas de este tipo, fuera de los sectores de formación, organización de eventos y política (que no es poco). E incluso yendo más allá y reconectando con el tema que abría este post, me pregunto si tienen sentido los eventos técnicos presenciales a día de hoy o si deberían cambiarse a un formato más inclusivo para todos como es el remoto vía Hangouts y similares. Quizá las hololens y otras tecnologías puedan aliviar a eso y permitir que las minorías que no pueden o no quieren viajar a los eventos, formen parte de estos.

Para terminar este artículo, me gustaría dar algo de visibilidad a la iniciativa de Codemotion y a Isabel Cabezas para que aquellas mujeres que quieran dar una charla sepan que son bienvenidas en el Codemotion 2017. Yo por mi parte intentaré organizar una mesa redonda en el Meetup que hacemos regularmente en Toledo, acerca de la inclusión de niños (tenemos padres y tíos) y mujeres (no se animan a venir) en el mundo de desarrollo software.

PD: he tenido que reescribir este artículo tantas veces, para evitar problemas, no dispersarme demasiado y hacerlo digerible, que casi voy a tener que coger unas vacaciones en cuanto lo publique.

Libro: Seveneves. Siete Evas.

seveneves

Título: Seveneves. Siete Evas
Autor: Neal Stephenson
Editorial: Ediciones B

Este verano empecé a leer una muestra digital de Seveneves, una página llevó a la otra ya acabé comprando y devorando la novela completa en un par de semanas. Algo que no me pasaba con Stephenson desde Snowcrash.

El libro es una recopilación de una enorme variedad de temas “clásicos” de la ciencia ficción que forman amalgama maravillosa y extraña: el fin del mundo, el viaje al espacio, la supervivencia tras el apocalipsis, un desastre global (en realidad varios), la colonización de otros planetas, ingeniería genética, sociedades aisladas, guerra en el espacio, robots, líneas evolutivas paralelas, terraformación, feminismo, mega estructuras… hay de todo y en cantidad.

La forma en la que Stephenson puede abordar tantos temas sin que sea un desastre es curiosa: ha dividido el libro en 2 partes, “presente” o futuro cercano y futuro lejano (5.000 años después), eso le permite explorar el impacto de eventos en principio sin importancia o que pueden pasar desapercibidos, pero amplificados y perpetuados por determinados contextos y el azar. Y por supuesto puede tratar diferentes temas en diferentes “épocas” lo que hace la historia más “sencilla” al no tener que mezclarlo todo con los mismos personajes y en la misma línea temporal. A todos los efectos son dos novelas de una misma “saga”.

De entre todos los temas que trata, la destrucción de la humanidad se trata de una forma bastante interesante, pero la supervivencia en el espacio ser torna (a pesar de la mecánica espacial) en absolutamente emocionante. En cuanto a la parte que transcurre en el futuro, la temática de las mega estructuras me parece bastante clásica, pero el tipo de armamento que imagina Stephenson me parece bastante radical y refrescante para un lector veterano de la ciencia ficción, aunque la tecnología en sí no sea relevante para la historia.

Muy en la línea de Snowcrash, Stephenson se muestra muy gamberro en una amplia variedad de contextos que no comentaré para no destripar el libro, pero que me han provocado bastantes carcajadas o sorpresas mayúsculas por lo inesperado de las salidas que tiene para ciertas situaciones. Muy radicales pero creíbles.

Espero que Neal Stephenson siga en esta línea con sus próximas novelas, ya que una vez terminé el Ciclo Barroco y vistas las críticas de sus posteriores obras he evitado activamente leerle. En resumen, si te gustó La Era del Diamante, Snowcrash o Zodiac, este libro es una muy buena opción.