Una de las mayores difícultades que he tenido después del cambio a una posición de gestión es la diferencia en la escala de gratificación con respecto a la que tenía por mi contribución individual (Individual Contributor).
Como ingenieros tenemos múltiples oportunidades de realizar pequeñas contribuciones en el día a día. Mezclar una rama y hacer un despliegue nos da la oportunidad de ver los resultados de nuestras acciones y su impacto durante ciclos bastante cortos. En empresas ágiles esto puede ser de días a pocas semanas. Es una generalización, ya hay mucho proyectos que pueden llevar largo tiempo para poner en producción pero suele haber oportunidades de ver el progreso que vamos consiguiendo. Ese momento que resuelves un problema y hace click!
En una posición de gestión podemos ver el progreso que realizan nuestros equipos pero la escala de los objetivos es mayor y los resultados se pueden ver en semanas o meses cuando pronto.
Por poner un ejemplo, recientemente mi equipo ha finalizado una importante migración de bases de datos que gestionábamos a un nuevo proveedor. Han sido en total unos 7 meses para conseguirlo. Empezó durante un proceso de auditoría interna. Nos dimos cuenta que había varias deficiencias a solucionar en el sistema para obtener una certificación de seguridad. Desde ese momento empieza la creación de un caso de negocio, evaluación del proveedor, obtener el presupuesto y pasar las evaluaciones de seguridad. Ya que tenemos que gestionar información privada de nuestros clientes esto ha añadido la necesidad de procesos adicionales para usar un nuevo sub-processor, los cuales no estaban definidos siendo este el primero. Así pues, una vez definidos estos se establece algunos requisitos legales adicionales para nuestro proveedor y plazos de notificación de clientes de los cambios. Todo esto ha requerido muchos emails e involucrar gran parte del negocio: Ingeniería, Producto, Finanzas, Legal y Gestión de cuentas. Finalmente esto ha llevado unos 5 meses hasta que hemos tenido el visto bueno y los contratos firmados. En este momento, ya podíamos empezar a trabajar en la migración aunque no podíamos usar los datos de producción hasta pasados 30 días.
Hicimos pruebas en otros entornos y fue todo bastante sencillo. Cuando empezamos a probar con producción surgieron varios retos, como siempre, esta vez debido a la gran cantidad de datos y su distribución así como alguna limitación del proveedor. Afortunadamente la buena comunicación entre desarrollado y sistemas consiguió solucionarlos en poco tiempo. Finalmente la migración se ha realizado tras dos meses de pruebas y ha sido completada con éxito. Ese día si que he estado contento! después de ver el nuevo sistema atendiendo peticiones y con el sistema anterior apagado. Y todo sin incidentes y con un mínimo downtime. Qué más se puede pedir?
Este ha sido realmente el primer proyecto donde mi contribución en código ha sido mínima, y mi participación ha sido realmente en la gestión del proyecto y las personas por completo.
Todos esos emails y obstáculos que iba sorteando fueron pasos importantes sin embargo no me dieron mucha satisfacción la verdad 😂.
Todo esto para decir que algo me “picaba” en Febrero y he conseguido rascarme en Septiembre.
Si has leído hasta aquí gracias.
Saludos
He tenido este post en draft durante demasiado tiempo. Empezó como una lista de 6 meses, no me gustaba y al año otro cambio y realmente como me suele pasar lo he dejado de lado por no ser ¨perfecto¨, también escribir en Castellano se me hace raro pero podría ser un cambio interesante para este blog.
Hoy está siendo un día lluvioso y tranquilo, no hay mucho que hacer, todos duermen en casa. El momento ideal vamos, así que allí va.
- El equipo es lo más importante. Debe primar el interés grupal sobre el individual.
- El trato debe ser justo e igualitario, pero no todos necesitan el mismo trato.
- Hay que entender las necesidades de cada uno de los miembros del equipo.
- Hay que ser claro con nuestras expectativas y nuestro modo de comunicarnos.
- En un ambiente multicultural es mejor ser directo y explícito.
- Cada cultura lee entre líneas cosas distintas. Hagamos visibles esas líneas.
- Aclarar nuestra posición desde el principio ayudará a evitar malos entendidos.
- Ser directo, pero bondadoso. Siempre desde el respeto.
- Si crees que te has equivocado, pide disculpas sinceramente.
- Es mejor tener una conversación difícil un momento, que pasar mil momentos difíciles.
- Es realmente importante demostrar el aprecio por el trabajo y las cosas bien hechas, aunque sea lo que esperamos de ellas.
- Hay que dar buenas y malas noticias y feedback, mejor no mezclarlo.
- Si hay algo que mejorar, seamos claros y no intentemos suavizarlo con lo bueno.
- Si hay algo que felicitar, no pongamos peros, ya habrá otro momento.
- Si somos generosos con el feedback, este es continuo y preciso, el equipo apreciará lo bueno sinceramente y aceptará mejor cuando este sea crítico.
- Los 1-1 son las reuniones más influyentes en la relación con cada individuo.
- Hay que aprender a escuchar y poner interés en la otra persona.
- La empatía es una habilidad y puede trabajarse y mejorar.
- Es importante tomar notas de las reuniones y hacerles seguimiento.
- Mientras más débil la relación, más importante es tomar notas.
- Los errores de hiring son los más caros.
- No te apures en contratar.
- Es malo tener prisa por contratar, es peor tener prisa por despedir.
- Ante la duda, ¡No hire!
- Primero la actitud, segundo los skills, aunque se necesitan los dos.
- Mejor junior con buena actitud que sénior con acritud.
- Si es sénior y tiene buena actitud, da gracias a la vida.
- Es más fácil enseñar la técnica, que enseñar a pensar.
- Todos en el equipo deben estar para ayudarse. Busca gente que pueda y quiera sumar.
- Marrón que te comes tú, marrón que evita el equipo.
- Hay que saber repartir los marrones.
- Si eres justo, lo aceptarán sin mucho problema.
- El manager debe llevar al equipo, no al contrario.
- Es importante mantenerse optimista y motivador.
- Es muy duro hacerlo consistentemente.
- Si tienes problemas habla de ello con tu propio manager. No cargues al equipo.
- Intenta ser el manager que te hubiera gustado tener.
- Trabajando en remoto la confianza lo es todo.
- Resultados == Confianza.
- Resultados == Flexibilidad.
- Como manager, se explícito en la frecuencia con que esperas recibir información.
- No pierdas de vista tus metas por el día a día.
- Las metas pueden cambiar y debemos revisarlas y ajustarlas durante el año.
- Las metas nos indican una dirección a seguir, no un camino fijo.
- Si alcanzas todas tus metas es porque no eran ambiciosas.
- Si no alcanzas ninguna es porque no eres realista.
- Mejor completar la mitad de las metas, que la mitad de cada meta.
- Tan importante como lograr las metas es el esfuerzo que ponemos en tirar en esa dirección aunque no lo logremos.
- No hay tiempo suficiente para hacer todo lo que queremos.
- Prioriza las tareas que te ayudan a lograr tus metas.
- Si trabajas mucho en tareas que no están alineadas con tus metas, piensa en cuál es la meta oculta y dale visibilidad.
- Todo el equipo debe ser partícipe de las metas y cada miembro debe ser responsable de algunas de ellas.
- Es normal tener dudas al cambiar a gestionar desde un rol individual.
- Es normal querer e intentar hacer los dos trabajos al principio, pero no es sostenible.
- Lo más difícil es aprender a no hacer el trabajo individual.
- Delega el trabajo pero no la responsabilidad. Debemos acompañar y supervisar al equipo.
- Cuando hagas trabajo de IC, enfócate en lo importante pero no urgente. No seas cuello de botella para los demás.
- Nunca harán el trabajo igual que lo harías tú. Enfócate en los resultados y los aspectos fundamentales.
- Si te molesta algún pequeño detalle insignificante, entonces no le des importancia y aprende a ignorarlo.
- No siempre hace falta tener que decir algo.
- La sensación de obtener un logro cambia de escala. Pasan meses o años para que se puedan observar los resultados de los esfuerzos.
- Tengo más aprecio por mis anteriores manager. Buenos y malos.
- Entiendo ahora que algunos tenían demasiada gente a cargo, muchos no querían estar en ese rol y los menos serían personas egoístas o ineptos.
Escribiendo este post he pensado en retrospectiva sobre algunas situaciones e interacciones con managers del pasado y veo que mi forma de actuar no fue correcta y ahora entiendo que estaba equivocado.
Ser manager es un rol que puede no ser apropiado según el momento de cada uno, teniendo tal influencia en la vida de la gente bajo su cargo y los resultados de la empresa quienes ejerzan ese rol deben hacerlo con vocación y convicción.
Ser manager es un reto, hay que estudiar y aprender mucho sobre los demás y sobre nosotros mismos. Después de dos años ya no tengo dudas sobre haber elegido el camino correcto para mi en el momento en que me encuentro.
Me considero muy afortunado por el equipo que tengo, y que me acompaña en este aprendizaje y que sinceramente espero no dejar muy traumatizado ;)
Si has llegado hasta aquí muchas gracias por leerme y espero que de algo te haya servido o te haya hecho reflexionar.
Suerte!
At work we manage a jenkins setup and rely on Google for authentication. One drawback is managing service users that do not have an email. We use those for interacting with the jenkins API in scripts.
When you use the Google Login plugin you no longer see the option to manage users in the UI, fortunately we can leverage the Jenkins Console and provision those users and generate the API tokens we need.
Let’s create some jenkins users and give them a username and password.
As programmers we spend most of our time (apart from meetings :p) editing text. I’m a very avid user of emacs. I’ve been using the editor since 2007 after a friend took the time to explain it to me. I had tried to use it at university but couldn’t understand how to use it, I tried also vim and it was even worse, so I ended up using something a bit friendlier like gedit back then. Anyway, this is not about which editor is better or worse but about sticking to something.
There are several things that will make your pair programming sessions work better. Things you can actively do and others best to avoid.
First of all, you need to give it an honest shot, especially if you’re not experienced in pairing. Pair programming is a skill and needs to be learned. Like learning any other thing the process can be tough, it can take you out of your comfort zone and get your mind resisting and wanting to do things as usual. So it’s important to be open about the experience and try to make the best of it.
I’m a big fan of magit and I’ve been using it for many years and I found some time ago the magithub extension, which is great and allows you to integrate with github, see your pull requests, open the browser for the current project, create PRs, etc.
I’ve always liked pair programming, since my college times. I remember doing coding exercises spending late nights at the computer lab and we were always working with your partners. And you would talk to everyone in the room trying to figure out how to solve things, you’d sit with people from other teams and share code. I didn’t know you’d call this pairing then.
Many companies keep their AWS accounts separated per environment, per team, etc and you can find yourself in a situation where you have users and credentials on many different accounts. From a security perspective this is not ideal as managing this can be very hard, people will change teams, leave the company, etc and cleaning up their access on all accounts can be very tedious and time consuming.
For a long time I’ve used my own command alias to navigate through my
work related projects and jump to them using the cx
Originally the x comes from Xing where I worked at the time. It also
happens that the letter x is located next to the c which makes it very
convenient like cd.
It’s been a while since I worked on the blog’s design. The design dated back to 2011 which is like an eon in Internet time and I didn’t particularly liked how it looked anymore so I decided to change it.
I normally don’t do any design work and CSS is not something I’ve enjoyed particularly but I’ve always used this space to work on that area.
Recently I’ve been using AWS Lambda at work for some projects and one of the limitations that you have is trying to use packages with compiled dependencies.
Compiling them on your machine won’t work and the “recommended” way is to start an EC2 instance and compile your dependencies there and then copy those to your machine back.
Fortunately AWS now provides a docker image for amazon linux which we can leverage to build our depencies. We can avoid launching an instance and get faster results.
This tutorial is an extraction from a talk I recently presented about docker and rails apps at the Barcelona on Rails user group. I’ll explain how to integrate docker into an existing rails app workflow.
Yesterday I had the opportunity to present a lightning talk on the Barcelona Docker Group about working with fig.
During the talk I presented a tool that is helping me focus on developing the different containers and make the changes to the Dockerfile and the apps themselves and leave out the details of using fig.
The tool is called guard-fig.
It’s been over 3 months since my change to the site operations team at Xing and time has really been flying by.
Everything is new and I really don’t know what to do many times and that I find very delightful. The investigation, learning, figuring out how to achieve something, reading forums or stack overflow and trying to fit a puzzle into your head. I think this is what I love the most about computers, that moment when you understand the machine, what it does and why it does it. It’s the hack, making the computer do what you want. Getting out of my comfort zone is helping me appreciate the basics more.
A couple months ago I started growing a vegetable garden at home with my girlfriend. It’s been a great experience. She’s always been into plants, we have lots of them around the house but never had we tried to grow food. I think the fact that I can get something out of the experience that is more than just aesthetic but also functional (I can eat the vegetables) has made it more appealing for me.
There have been some experiences so far that I somehow can relate with developing a software project.
I was invited with my friend Jean Carlos Meninno to give a presentation on the GDG DevFest Barcelona 2013. It was a great opportunity to talk about the work we’re doing recently for XING and the things we’ve been learning about developing large scale backbone applications.
Here you can find the slides: http://diasjorge.github.io/google-dev-fest-slides/
Hope you like them.
During my time working at XING I believe my single biggest contribution for the company is a side project I’ve developed called Xing scripts. This project started with a personal need for working with our development environment in a more automated way. I’m a big proponent of automating everything you can and so when I started working I realized that there were these tasks that I would do over and over again. Since I couldn’t bare doing all this manual work I started writing my own scripts.
Yesterday I was at work with a colleague and we wanted to merge a long-running branch we had. This branch was full of useless commits so we wanted to clean it up. We tried an interactive rebase but we got a lot of conflicts since git doesn’t know how to resolve merge conflicts that we had previously fixed. As you probably know this is no fun, so we did what any sane person would do and found a nice solution for this called git-rerere.
Recently I had to reinstall my computer at work since I had to update to Lion and I could only do a fresh install, so I decided to try to automate the installation process since some of my colleagues are going through the same and it seems like every time we have to waste many hours or days to solve the same issues over and over.
As a programmer, the impetus to go as fast as you can is to be taken with caution as it helps you move forward but it can also hold you back.
It is perhaps my experience but I’ve hardly had the opportunity to work on green field projects, but rather worked on legacy ones where most of the original developers were no longer part of the team or even none of them. Projects with little to no documentation and in some cases no tests at all. You probable know this feeling, it sucks, you want to do things but everything you touch breaks something else, where you obviously see that there was lack of care.
It’s been some agitated months lately for me, I quitted working at JustLanded after almost two years there and then went working for some consulting, the experience was not so great, actually it was really bad, the kind of experience that has made me learn to choose very carefully my future career moves and never again believe in marketing people. Fortunately I got an offer to work at XING offices in Barcelona, so I packed my stuff and moved there. Now this is a really good place to work, everything was as we talked, they’ve been very helpful with my relocation and the environment is great, lots of smart people that want to do a good job, so nowadays I’m very happy and enjoying my new city.
If you’ve ever forgotten to push your changes to the remote repository before trying to make a deploy, you will know that it can be really frustrating to think that everything has gone live when actually it has not. This little script will help you avoid this situations.
When using passenger with rvm I’ve had some issues with project specific gemsets, where bundler was unable to find the gems. After searching a lot I found out about using the “config/setup_load_paths.rb” file to tell passenger where to locate your gems, but then I had a new issue with rvm trying to use the system ruby instead of the ruby version of my .rvmrc file.
After going to the irc channel, I got some help that help me fixed my problem. The culprit was my rvmrc file.
As promised here are the slides for the “Conferencia Rails” workshop on process automation. Thanks to all the people that were there. I’m also releasing the redmine CLI I’ve created along with the CLI twitter client.
The presentation was created using the slideshow gem which generates an html document for you.
Slides To start the presentation just hit the “LEFT” arrow key. You can also find a pdf version here.
Hope you enjoy it.
Today I spent several hours with my friend Gleb trying to find a weird bug we we’re having importing some rss feeds.
We have a rake task that will grab an xml feed and import it to our system. When we call this rake task from the command line it would run fine, but if we run it from inside our application, we would get some wrong characters (you know, the usual ???) in the imported items.
If you’re using emacs to write your jekyll blog posts, there is a mode to help you with some common tasks. It is originally from metajack. Recently I thought it could be a nice addition to have syntax highlight support for jekyll posts, so I got my hands dirty and after some hours of lisp hacking (this was my first attempt at lisp programming) it was a reallity. It is based on nxhtml so you need it to work.
If you’re using capistrano-ext to deploy to a different server, using a custom environment, you’ve probably noticed that it always tries to run the migrations for the production environment, like this:
cd path_to_app/deploy/releases/20100309152738; rake RAILS_ENV=production db:migrateDigging through capistrano’s source I found the solution is really simple, just set the rails_env variable to the environment you want, in this example staging. So inside config/deploy/staging.rb
set :rails_env, "staging"Then when migrations get executed they’ll have RAILS_ENV=staging.
Recently I moved my blog to Jekyll, while being able to write stuff directly in my favorite editor EMACS, there was some functionality that I was missing from my previous custom blog engine, such as archives. Looking at how I could achieve this, I found Raoul Felix approach to the problem. Instead of patching jekyll, he wrote a small library that wraps around it, called jekyll_ext. Using it was really easy, and based on some of the extensions he created, I was able to provide this functionality in my site.
Although I had archives generated for me, I was still missing a way to display this information on my site, so I decided to create my own extension.
I’ve been developing some new mailers at work, and I’ve found it really helpful to be able to view the emails as they are sent to the users. So I’ve implemented a cucumber step to help me achieve that, inspired on a similar webrat step for web pages.
If you ever run into the situation where one migration doesn’t complete sucessfully, and you’re stuck with a column in a table or a new table, so you can’t drop the migration or execute the migration again, you can always call the migration methods from the console like this:
The problem we have is that this code
new Element('div', {'class':'klassName'})will work in firefox but in IE (tested on version 8) the className is never set, which was causing some problems with the elements styles.
A couple days ago I had to gather some information from a git repository, so I’m sharing this small scripts with you.
I recently had to implement some ajax pagination for a site. After googling for a while I found a solution, but I couldn’t customize the pagination url’s or I had to specify the paginator to use (will paginate’s default or mine for ajax), so I came up with this solution which fulfils all my needs.