Este gist incluye un fichero por cada charla, artículo, vídeo que me ha parecido interesante y quiero recordar una serie de notas que haya tomado de ese recurson interesante.
Last active
August 10, 2016 16:59
-
-
Save rchavarria/d1c2cfdaef6af035116c to your computer and use it in GitHub Desktop.
Lifestyle cards
Un articulo de J.B.Rainsberger sobre estas dos practicas. Se podria resumir algo así como que si haces suficiente pair programming no te hace falta code reviews, aunque hay ciertos aspectos del code review que podrían venirte bien.
- pair programing nos ayuda a encontrar fallos en la rutina
- code reviews para debatir más amplicamente cuestions de diseño, aproximación, técnicas
- tambien se pueden hacer code reviews 'on-line', como en una especie de code review haciendo pair programming, donde tamiben se modifique código
Pair programming viene bien para pequeños trucos, para compartir ese pequeño conocimiento que tenemos en nuestras cabecitas. Los code reviews vienen bien para discutir sobre el codigo de manera más general (y con una audiencia mayor, todo el equipo se puede beneficiar de una code review).
Pairing helps us with the tactics and code reviews help us with the strategy
También explica un juego para hacer con el equipo: ¿Qué es lo que no te gusta de este código? ("What's not to like about this code" game) Es una especie de code review, pero no se proponen solciones, solo lo que no nos gusta del código. De esta forma se practican ciertas cosas que son peliagudas en las code review, pero sin entrar a fondo, con lo que la gente va cogiendo confianza y las code reviews mejoran.
Me ha gustado mucho esta cita de Luis Artola en twitter Coding is designing
Coding is designing. And designing is a name (ubiquitous language) responsibilities (cohesion) and collaborators (coupling).
Es decir, diseñar software es nombrar responsabilidades y colaboradores.
Esta serie de consejos vienen del artículo :
Como destrozar una marca personal
- No tener un propósito: deberías tener un objetivo claro y bien definido, para que te conozcan por ello
- Identidad poco definida: la marca personal es, personal. si muestras cómo eres te tendrán en cuenta aquellos como tú y te alejará de aquellos a los que no quieres
- Creencias paralizantes: pereza, perfeccionismo, complejo de inferioridad o superioridad, ... son todas creencias que no te dejan avanzar. el enemigo eres tú mismo
- Propuesta irrelevante: no tienes que venderte tu, tienes que vender lo que tu haces. Debes de tener una propuesta de valor relevante, una propuesta que no puedan rechazar. Lo que haces debe satisfacer una necesidad clara
- Poca diferenciacion: debes encontrar el modo de sobresalir haciendo las cosas mejor que los demás y que se perciba así
- Falta de autenticidad: confianza, llevar mucho tiempo haciendo las cosas bien, no mintiendo NUNCA
- Incoherencia o inconsistencia: consistencia-> predecible, constante, no voluble. La coherencia es el resultado de ideas claras, principios sólidos y objetivos definidos.
- Falta de química: Si eres de los que quedan fuera (quiza porque no conectas con tu audiencia), empieza a revisar tu capacidad para encontrar factores en común con tu audiencia, los valores que transmites o tu lenguaje verbal y no verbal.
- Aislamiento: si no muestras tu valor es como si no existieses. Debes salir y mostrar lo que puedes hacer. Debes saltar al escenario y actuar
- Canales inadecuados: elige bien el canal por el cual quieres comunicar lo que haces
A través de un tweet de alguien, he llegado a este artículo de alguien de dentro de Runroom: De molinos y gigantes. En este artículo se habla de cómo dar y recibir feedback, algo muy importante en el mundo profesional. Estos son los puntos que el autor considera imprescindibles a la hora de dar un buen feedback para que motive a la mejora, que ayude y que haga sentir bien a la persona que lo recibe:
- Se positivo: enfoca las cosas desde el punto de vista positivo
- Busca el equilibrio: técnica del sandwich (cosas buenas, puntos a mejorar, cosas buenas)
- Especifica: 'me gustó mucho tu charla' no sirve de nada, especifica los puntos que más te gustaron
- Observa, no juzgues: juicio -> 'llegaste tarde', observación -> 'llegaste a las 9 y la hora de entrada es a las 8'
- Sugiere: puedes comenzar con 'en mi opinión, deberíamos tratarlo de esta forma...'
- Pide permiso: hay veces que hay que pedir permiso para dar feedback -> 'Perdona, te gustaría saber mi opinion sobre...?'
Este post lleva a otro acerca de cómo pedir que te den feedback: [https://hbr.org/2014/12/how-to-ask-for-feedback-that-will-actually-help-you]
Here’s how to increase your chances of hearing the truth:
- Indica que quieres un feedback que te ayude, no uno amable
- Dirige el foco hacia el futuro, no a lo que hiciste mal, si no a lo que podrás mejorar en el futuro
- Pide feedback constantemente, aprovecha cada oportunidad
- Escucha sin juzgar, tanto el positivo como el negativo. Agradece a la gente el feedback que te da y dile que ha sido de gran ayuda
- Escribe el feedback que te han dado en el momento en que te lo dan. Esto incluso dara tiempo a la otra persona a darte una segunda opinión
Update 27-01-2015 Más adelante, he encontrado este post sobre github que me parece que está relacionado: How to write the perfect pull request:
Offering feedback:
- If you disagree strongly, consider giving it a few minutes before responding; think before you react.
- Ask, don’t tell. (“What do you think about trying…?” rather than “Don’t do…”)
- Explain your reasons why code should be changed
- Offer ways to simplify or improve code.
- Avoid using derogatory terms, like “stupid”, when referring to the work someone has produced.
- Be humble. (“I’m not sure, let’s try…”)
- Aim to develop professional skills, group knowledge and product quality, through group critique.
Responding to feedback:
- Consider leading with an expression of appreciation, especially when feedback has been mixed.
- Ask for clarification. ("I don’t understand, can you clarify?")
- Offer clarification, explain the decisions you made to reach a solution in question.
http://blog.8thlight.com/ben-voss/2013/01/15/how-to-be-a-great-pair.html
TL;DR -> empatía, humildad y paciencia
- Los actos individuales no deberían ser alabados, ni tampoco perdonar a un gran programador que no trabaje en pareja porque creemos que lo va a hacer mejor solo. Programar es una actividad en equipo.
- Características de malas sesiones de programación en parejas:
- juicios sobre el diseño/implementación de una forma maliciosa
- o también en tono humorístico
- comentarios o preguntas no constructivas
- interrupciones solo para teclear algo (falta de paciencia)
- comenzar a implementar ideas propias sin ningún tipo de discusión
- Para programar bien en parejas hay que tener madurez emocional: empatía, humildad y paciencia.
- Antes de comenzar a escribir, discute ideas sobre el diseño o sobre los posibles caminos a tomar
- Pon cuidado en que tu pareja esté en buena forma mental, tranquilo y concentrado. Si no, ayúdale a que se tranquilice, ...
- Ayuda a tu pareja a entender tu punto de vista, haz preguntas sinceras, sencillas y sin malicia.
- Nunca veas tu turno de escribir como una competición o para demostrar que sabes más que tu pareja
https://zapier.com/blog/scale-yourself-scott-hanselman https://vimeo.com/39020426
- effectiveness vs. efficiency
- Do / Drop / Delegate / Defer it
- people will tell you what happened in the world
- pay full attention to what you're currently doing
- Anything longer (3-4 sentences) should be on a blog or wiki or on your product's documentation, FAQ or knowledge base
- Triage the inbox of your life
- Get Rid of Psychic Weight
Scale yourself, by Scott Hanselman
- "I just need to work late to catch up"
- Hope is not a plan, Hope is nothing but waiting and letting life happen to you
Effectiveness is doing the right things.
Efficiency is doing things right.
IMG : https://zapier.cachefly.net/storage/photos/3238539f6e1222e19ceb083fc6995ffb.png
- Do It
- Drop it
- Delegate it
- Defer it
- Don't check email in the morning
- Find your Robert Scoble (people will tell you what happened in the world)
- Remain in your flow :
- "anything important that happens in the world, will come your (way) many times"
- trabaja en lo que sea, pero con toda tu atencion en ello
- Conserve your keystrokes
- Keep your emails to 3-4 sentences, Hanselman says. Anything longer should be on a blog or wiki or on your product's documentation, FAQ or knowledge base
- Triage the inbox of your life
- Get Rid of Psychic Weight
- Whatever is "pending" in your life, drop it, Hanselman suggests on his blog
- Reserve Fridays for Reflection
- Rule of 3 Write down 3 things you'll do today, ... this week, ... this year. And do them!!
- you need to have a vision on Monday of what your week looks like, and on Friday you need to stop and look back on your week and think about the reflection
- Realize that Being Busy is a form of Laziness
- When I start reading the book, I have an idea about what it’s about
- While reading I take notes. I circle words I need to look up. I star important points that I think are critical to the argument. I underline anything that strikes me as interesting. I comment like a mad man in the margins
- At the end of each chapter I write a few bullet points that summarize what I’ve just read
- After some time (1 to N weeks) I pick the book up again, I re-read every scribble, underline, and comment I’ve made (assuming I can still read my writing).
- If something still strikes my interest, I write a summary with my own words (it’s ways to apply the knowledge)
- I’ll create a sort of mental summary of the book’s main arguments and gaps that I think exist
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment