Libros gratis y de calidad para este verano

6758_Prog_WinStor_Apps_HTMLOtro año más, Eric Ligman ha publicado en su blog una entrada con más de 150 libros para que podamos ponernos al día en las últimas tecnologías (Windows 10, Azure, SharePoint, HTML, CSS, JavaScript, CRM, Office 2013, Lync, Windows Server….

No solo son totalmente gratis (sin pedir el email, ni ningún tipo de información, sólo descarga desde la propia página), sino que además, se encuentran en los principales formatos de ebook: pdf, mobi, epub, etc.

¿Quién dijo que formarse es caro?

Buena lectura, y feliz verano.

Anuncios

El necesario estrés

Hablando el otro día con un compañero de trabajo, me contaba una interesante metáfora.

Había un pescador que pescaba atunes, pero los tiburones diezmaron la pesca. Y para evitar arruinarse, tuvo una gran idea. Decidió crear una piscifactoría, criar los atunes en cautividad, y venderlos para así obtener grandes beneficios. Pronto se dio cuenta de que los atunes no se vendían tanto como él pensaba. El motivo era que tenían demasiada grasa. En cautividad, los atunes se criaban gordos, y no tenían un incentivo que les hiciese hacer ejercicio.

Recordando cómo era la pesca en el mar, pensó que los atunes libres se crian con un sabor perfecto, y hacen mucho ejercicio porque deben sobrevivir. Así que decidió traer un tiburón y soltarlo en la piscifactoría. Pronto, los atunes ganaron en calidad, mejoraron su sabor, y se criaron más sanos y produciendo unas mejores ventas. Incluso considerando las pérdidas producidas por el ataque del tiburón, merecía la pena.

Al final, el motivo era la introducción de un nivel de estrés pequeño, pero suficiente para que los atunes se vieran en la necesidad de sobrevivir, criarse ágiles y sanos.

Al final, la moraleja que comentaba con este compañero es clara: un poco de estrés es bueno. Sin un incentivo, sin la adecuada presión…la gente se relaja. Y demasiada relajación, no nos lleva a los éxitos, ni provoca que la gente se estimule en mejorar su código, su planificación, sus pruebas…

Al final, PON UN POCO DE ESTRES EN TU VIDA. ¿Pero sin pasarse, eh?

Orgulloso de tus éxitos, no de tus contactos.

Hoy estaba leyendo este artículo en el blog de HBR (Harvard Business Review).

Casualmente, este artículo está en la línea de un tema que ya estuve comentando recientemente en otro post: y es que hay que estar orgullosos y por tanto poner en nuestro currículum, los éxitos profesionales, no tanto nuestras afiliaciones a marcas conocidas o de prestigio.

Por ejemplo: hablar o hacer publicidad de ser empleado de IBM o tener relación con esa empresa, no es un éxito como tal. Es usar una afiliación o relación profesional con una marca conocida. Está bien tratar de vincular nuestra labor profesional con un gran número de marcas de prestigio, o de sentirse orgulloso de ello, pero eso no puede estar por delante de nuestros éxitos. Si no tenemos éxitos profesionales de los que hablar…mal asunto.

Y no me refiero a que no podamos mostrar orgullo en público o jactarnos de nuestra relación con una marca, empresa o institución prestigiosa. Eso está bien. Pero parece ser que se tiende a hablar más de ello que de los éxitos y logros.

Yo no quiero en mi equipo de trabajo a una persona que haya trabajado en megaproyectos o que haya estado vinculado por el motivo que sea a grandes empresas, marcas de prestigio, etc. Yo quiero gente que haya superado retos, que haya enfrentado grandes problemas, y que pueda demostrar su éxito ante tales situaciones (su éxito, o al menos que haya podido salir airoso gracias a sus habilidades profesionales). A veces un pequeño éxito (o ausencia de fracaso) ante los problemas grandes, es mejor que un gran éxito ante un problema pequeño. Y quiero explícitamente saber si lo hizo solo o en colaboración con otras personas. No me valen los que tratan de venderme que fueron los responsables de tal o cual proyecto, cuando quizás la acción la realizaron él y otras 20 personas.

Como comentaba en mi anterior post, es esta ocultación deliberada de información la que provoca que al final todo el mundo sea el líder, héroe y único responsable de llevar a cabo grandes hitos en desarrollo, pruebas, implantación, gestión de equipos, etc.

Cómo no hacer un currículum

Vemos habitualmente currículums mal escritos, con información falsa, o alterada para dar una sensación de mayor experiencia y profesionalidad, de mayores éxitos de los logrados, etc.

Seguidamente vamos a ver algunos de los “errores” más habituales en los CV. Pero antes, veamos uno de los peores:

1. Desviar la atención. Esta técnica permite, cuando no se tiene experiencia o éxitos que comentar, desviar la atención en un punto supuestamente positivo, pero que no aporta nada realmente. Por ejemplo: si no tenemos ningún logro o éxito significativo que comentar en nuestro actual empleo, pero hemos tenido una buena evaluación o hemos sido promocionados de categoría, hay quien lo pone en el currículum, lo magnifica, y oculta de este modo la atención sobre otros elementos que podrían disminuir la buena impresión global. Es normal que un recién licenciado, ante la falta de otra información adicional, diga: “saqué matrícula de honor en el proyecto de carrera”, o que diga las notas o hitos principales en su titulación. Vale, es normal, no tiene otra cosa de qué hablar. Lo que no es tan normal, es que gente que promulga experiencia y saber hacer, a la hora de la verdad ponga en el currículum este tipo de frases que contradicen dicha experiencia y saber hacer.

Viendo los currículums de gente con falsa experiencia, se suele encontrar frases como:

    • “Experiencia multidisciplinar”. Vale, la palabra suena bien, pero no me dice nada sin el matiz apropiado.
  • Conocimiento y ¿experiencia? en diversas tecnologías y lenguajes de programación (por supuesto, siempre tratando de dar pocos detalles al respecto, y siempre de forma vaga respecto a los proyectos y a los períodos de aplicación). A ver señores, en nuestra vida laboral, y llevo en esto más de 15 años, no manejaremos más allá de 4 o 5 lenguajes principales. El resto, por supuesto que hemos estudiado, o usado puntualmente docenas de lenguajes. Pero el uso puntual no da el conocimiento, y la experiencia en los lenguajes se pierde en pocos años.
  • Buenas evaluaciones de rendimiento recibidas en la empresa. ¿!!! Sí, bueno, claro que alguno de mis antiguos jefes me alabó, me subió el sueldo, o me subió de categoría (normalmente no todo a la vez)…¡pero no lo digo en el currículum! Mi profesionalidad no se mide por las subidas salariales que he recibido, sino por los retos superados (aunque es un reto que te suban el sueldo, creo que no estamos hablando de eso).
  • Han llevado equipos de más de 20 personas ¿? Bueno, sí, una vez llegaron a estar 20 personas contando al fontanero, la secretaria, y la de la limpieza. Quizás han contado a todos los que han pasado por el proyecto, pero nunca estuvieron todos de forma coincidente. Pero sería más exacto decir de 3 a 20 personas, o usar la media del período. Incluso he visto gente de proyectos SCRUM con jerarquía nula, hablar de que han llevado “N” personas…¿pero llevar qué de qué? ¿Pues no era SCRUM? ¿No erais todos los del proyecto “iguales”? Seguro que si revisamos el currículum de los 20 del proyecto, resultará que todos han sido los jefes de los otros 19!!

Por supuesto que todo ayuda, pero no puede este tipo de información ser nuestra principal identidad.

A mí todo esto me da una sensación horrible. Un currículum no puede estar tan vacío. Se supone que habla de nosotros. Y si lo mejor que podemos decir de nuestra profesionalidad es que nuestro jefe nos hizo una revisión anual positiva…o que nos subió muchas veces el sueldo…pues cásate con tu jefe!

En serio, debemos siempre hablar de:

    • Éxitos. Pero éxitos tangibles: logré “x” mediante “y”. Ejemplo: puesta en el mercado de una nueva aplicación desarrollada por nosotros mismos (o explicitar nuestro papel en su desarrollo),  logrando una cuota de mercado “X”, o logrando como clientes a los “TOP” del sector. O: desarrollo e implantación de una solución de xxxx que logró estar en el mercado durante casi 10 años y tener más de 20 grandes clientes del sector.
  • Formación: certificados relativos al puesto que estamos, o al que queremos optar. Si somos analistas funcionales, a buenas horas me va a servir un certificado de programación. Claro que está bien, y aporta, pero si veo a un jefe de proyecto obteniendo certificados de programación, voy a tener serias dudas de si realmente ejerce como jefe de proyecto. Del mismo modo que si yo veo a un analista recién certificado o con cursos de ITIL, CMMi, PMBOK, etc., voy a pensar que en realidad, ejerce de jefe de proyecto (o que se prepara para dicho cargo, lo cual es loable). 

Continuemos con mentiras habituales en los currículums (fuente: link): 


2. Estudios no realizados. Dos de cada diez españoles han declarado que han falseado su nivel de estudios en su currículum. Se pretende con ello ganar puntos ante el seleccionador. Es una de las mentiras más fáciles de detectar, porque lo normal es que se soliciten los diplomas y certificados que correspondan a la formación declarada. Una de las más frecuentes es asegurar ser un experto en un determinado programa informático sin serlo. Se trata de un grave error ya que se quedará en evidencia al comenzar a trabajar y tener que manejar dicho programa.


3. Mentir en el dominio de idiomas. También es habitual indicar que se tienen conocimientos de idiomas que en realidad se desconocen. O bien poseer un nivel más elevado del que se tiene. En este caso, es inútil indicar tener más nivel del real, pues lo habitual es que, para chequearlo, el entrevistador se dirija al candidato hablando en el idioma que dice conocer. Además, hay que tener en cuenta que muchas empresas suelen hacer pruebas de nivel para verificar dichos conocimientos.


4. Exagerar las funciones anteriores. El 43% de los españoles añade en su currículum vítae más responsabilidades de las que ha asumido en sus anteriores empleos. Un ejemplo: alguien que ha trabajado como vendedor, pero que asegura haber sido responsable de equipo o director comercial de una determinada empresa. En este sentido, hay quien exagera también los años de experiencia ejercidos en una determinada función. Un ejemplo de ello puede ser asegurar que se ha trabajado en una empresa durante varios años cuando en realidad sólo fueron 15 días.


5. Empresas en las que nunca se ha trabajado. Un 18% de candidatos miente acerca de las empresas para las que ha trabajado. Según el estudio de CareerBuilder, se han dado casos de candidatos que han mentido diciendo haber trabajado en una determinada empresa sin saber que quien le entrevistaba fue director de la misma. También, con el fin de engordar el currículum, hay quien declara haber trabajado en empresas que no existen. Son más difíciles de detectar las mentiras cuando las empresas en las que se dice haber trabajado han desaparecido.

Si has llegado hasta aquí, te habrás dado cuenta que seguramente tú también has hecho algo de esto alguna vez. ¿Y? Pues nada. Esto son malas prácticas, pero no significa que cada cual lo vea justificado para un fin. Desde luego, que por traer el pan a sus hijos, la gente está dispuesta a todo. Y más con los tiempos que corren. Seguro que a vosotros se os ocurren, o habéis visto más malas prácticas como estas. El problema, simplemente reside en que los currículums se usan de modo comparativo. Y como tantas cosas en esta vida, los honestos, los experimentados, están en desventaja.

De todas formas, se puede dar la vuelta: se pueden usar estas ideas, de forma sutil, para destacar auténticas buenas prácticas y experiencias, auténticos hitos y logros personales, para un buen currículum. Y ese era al final, el objetivo de este post.

Top Mantra de los Arquitectos (II)

Este artículo es el segundo de una serie de dos. Para ver el anterior, clic aquí.

Tenía pendiente terminar este artículo que ya inicié hace algún tiempo. Vamos a ello. Estábamos hablando del Top 10 de los Mantras de un arquitecto de software. El post anterior repasaba los mantras del 1 al 5. Vamos a los números 6 al 10.

Mantra #6: ¿No estás en la capa de datos? Entonces no pongas SQL!
Tal y como establece SoC (Separation of Concerns), intenta poner cada cosa en su sitio, sin mezclar. Pon el código de acceso a datos y los detalles como connection strings, bien lejos. Tarde o temprano, tendrás que ocuparte de ellos, pero considera por separado las lógicas de negocio y presentación de cara a la persistencia. Siempre que sea posible, delega la persistencia en una herramienta ORM.

Mantra #7: la mantenibilidad es lo primero
A pesar de que ya hablé en mi post sobre los mitos de la mantenibilidad, Dino Exposito tiene más razón que un santo al establecer que si hay que elegir un atributo para el software, como arquitectos, ha de ser la mantenibilidad, por encima de la escalabilidad, seguridad, rendimiento y testeabilidad. Si código y la arquitectura son mantenibles, el resto se puede conseguir más tarde (no así al contrario)

Mantra #8: el input del usuario es pura maldad
Tal y como comenta Dino en su libro, si existe una forma en que los usuarios hagan algo mal, encontrarán la forma de hacerlo. Si te suena esta afirmación a la ley de Murphy: SI, así es.

Mantra #9: Optimización Post-Mortem
Tal y como indica Dino (y estoy totalmente de acuerdo), empezar a diseñar un sistema con la optimización en mente es un error. Yo voy a ir un poco más allá: es un signo de inmadurez. Y me refiero a inmadurez profesional, a falta de experiencia. Tratar de que un sistema crezca siendo óptimo desde el principio es una buena forma de perder el foco de lo que realmente es importante. Es mucho más importante (ver mantra #7) que sea mantenible, ya que ante cualquier cambio, podemos optimizarlo. Un software muy optimizado desde el principio, seguramente no será mantenible y por tanto, ante cualquier cambio (que los habrá, no os preocupéis), dejará de ser óptimo. Y por desgracia, en esa situación, ya poco habrá que hacer.

Mantra #10: La seguridad y testeabilidad, han de estar “por diseño”.
Aquí poco hay que decir. Es tan radicalmente cierto, que incluso hay un estándar de la International Organization for Standardization (ISO) que explícitamente, lo establece. Un sistema, por mantenible que sea, es muy complicado (y por tanto caro) que sea seguro a base de hacer cambios. Lo mismo la testeabilidad. Si no empiezas diseñando para que sea testeable, con sus pruebas unitarias, con la arquitectura adecuada…no podrás de repente implantar la testeabilidad.

Y nada más. Que os recomiendo encarecidamente este libro. Es de los pocos, junto con los del eterno Steve McConnell, que merecen la pena comprarse y leerse más de una vez. ¡Ah, y no me llevo comisión por decir esto, eh! Más info del libro:

 

by Dino Esposito and Andrea Saltarello

Microsoft Press. (c) 2009

Microsoft .NET: Architecting Applications for the Enterprise