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.

Anuncios

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.