A Tech Lead HOWTO

I’ve been working in a Tech Lead role position for something more than 2.5 years. Some notes I can write here that would have been useful for me and hopefully for someone reaching this page:

  1. Read this HN question comments: https://news.ycombinator.com/item?id=10395046
  2. Create a roadmap, parallel to the team projects. Make sure you have a long-term plan in mind.Having-a-Social-Media-Game-Plan-Higher-Profits.jpg
  3. Your team needs to fulfill the projects maintaining a good working environment, otherwise, they’ll burn out soon. The opposite is true too, it does matter having the happiest team if projects don’t evolve as they should.Happy_minions.jpg
  4. Be patient, start just with little improvements as you understand your area. Avoid revolution feeling, people don’t like too many changes at the same time.
  5. Coding is probably not the most important thing you’ll do for your team. First months it will feel awkward but you’ll get used to it once you understand your responsibilities.
  6. Understand your area top-down, from architecture to code so you’ll probably won’t be an expert in every repo but you probably should be an expert of how everything glues together, how the architecture works and how it should evolve.
  7. 1:1s are one of the most important things you’ll do, make sure most of the 1:1 time is just informal, the projects sync part should be just the first 5 minutes. Try fixing calendar events for them.1-1s.png
  8. Overcommunicate: tell important things to the team as a group and repeat it again in each 1:1 and see if your message is being understood. Always ask for the opinion, especially in 1:1s, your mates will often help you to do things better.
  9. Be data driven, make sure you can see the state of everything with data, you should not need to do ad-hoc queries or launching dirty scripts to gather important health data. Your important telemetrics and KPIs should always be available to be reviewed. However, if you find yourself checking a metric a lot for certain thresholds, just create an alarm!Data-driven-business.jpg
  10. You’ll need to keep caring about your craftsmanship and it will be more difficult than ever as you won’t be coding most of the day. However, you should make sure you keep improving technically, not just growing in soft skills. Try maintaining pet-projects, courses and try to contribute to team code in small priority tasks from time to time.
  11. Be involved in code reviews and read every pull request if possible, that’s where you’ll feel how good work is evolving. However, avoid micro-manage, especially to senior mates, just be a helpful safety net if needed. Avoid commenting in CRs if you have nothing important to say, avoid the “here comes the boss comment” syndrome.03
  12. Detect any block and tackle it with most urgency. It’s one of your main responsibilities. Ask for blocks in every standup.
  13. Be the tech proxy for your team so that they can focus on their tasks. Be ready to be interrupted, learn how to optimize context changes. Actually, make sure your team understands you’re approachable and they can ping you if any problem without waiting, you’re there to be interrupted at any time if needed.
  14. Supervise estimations. Avoid being always dummy conservative, think carefully about risks and if any high risk then yes, be conservative with estimation. But if you’re estimating a task your team already did in the past, it should be pretty straightforward (and perhaps should be automated?)
  15. Try introducing and welcome changes to how things are done but be careful about when those changes are applied as if they impact a project, it can be difficult to justify. Related to this, avoid taking the easy route of just saying always “NO” to new things just to avoid risks, as your platform should evolve as part of your plan.main-qimg-fbef4b8b75dbb14bf216652c98ef2232
  16. Measure technical debt, buy it consciously and fight it as part of your plan with priorities.
  17. Improve your soft skills. You’ll be more time talking to people than to your IDE.
  18. Be always constructive with feedback, as a criticism without action points to follow is not a solution.
  19. Be the Toxic-comments goalkeeper. Try favoring a positive environment. However, don’t confuse toxic comment with a constructive critic.24293_1.jpg
  20. Tech Lead position is quite prone to workaholism. Go home! Read this post by Rafael López: https://badoo.com/techblog/blog/2017/04/11/leads-go-home-and-take-your-reports-with-you/


Good luck!


An easy Vim IDE setup: using Vundle

Are you bored of messing up with your own custom .vimrc which is eventually broken or difficult to maintain?. Well, there are lots of projects in order to have a vim plugin environment well setup, I’ll just show one of them. I’m following the steps you can see in https://github.com/jez/vim-as-an-ide install instructions:

  1. First, let’s get Vundle:
mv ~/.vim ~/.vim.beforeVundleBackup
mv ~/.vimrc ~/.vimrc.beforeVundleBackup
mkdir ~/.vim && mkdir ~/.vim/bundle/
git clone https://github.com/gmarik/Vundle.vim ~/.vim/bundle/Vundle.vim

With that, you already have the bare minimum to work with Vundle.

       2. Follow this to get a proper font: https://github.com/jez/vim-as-an-ide/commit/457f2e2

If your using iTerm2 basically you need to download the solarized.zip file and load preset from the iterm2-color-solarized folder.

Captura de pantalla 2017-05-27 a las 8.42.20.png

Import both: “Solarized Dark” and “Solarized Light” and you can decide later which one is more convenient.

In iTerm2 make sure this is your terminal type (more info):

Captura de pantalla 2017-05-27 a las 9.07.01.png

     3. Now it’s time to get the vimrc:

wget https://github.com/jez/vim-as-an-ide/raw/master/vimrc.vim && mv vimrc.vim ~/.vimrc

     4. Now runvim +PluginInstall +qall

And that’s all, now your Vim should look like this:

Captura de pantalla 2017-05-27 a las 9.10.37

Now you already have a pretty good vim setup and you’ll be able to install new plugins easier.

e.g I can install a SML plugin just adding this to the .vimrc:

Just remember to run this every time you run a plugin:

vim +PluginInstall +qall

Implication, conditional, equivalence and biconditional: NL and code

This blog post is my attempt to explain these topics: implication, conditional, equivalence and biconditional.

I’ll also try to discuss examples both in natural language and code.

I’ve studied them in Mathematical Language subject and Introduction to Mathematical Thinking.


In natural language we often hear expressions or statements like this one:

If Athletic Bilbao wins, I’ll take a beer

Continue reading Implication, conditional, equivalence and biconditional: NL and code

Forks: wsdl2html_ivmos y wallahack_ivmos



¿Qué hacer si tus pull requests no son aceptadas pero no quieres que esas aportaciones queden perdidas en ramas de tu fork? En mi opinión, para eso precisamente son los forks y es una de las ventajas del software libre. Lo suyo es probar primero una pull request, tratar de aportar al proyecto, es lo más práctico ya que el coste de mantener tu propio fork es considerable. Sin embargo a veces no es posible hacer que tus cambios lleguen al proyecto original y las razones pueden ser varias. Es algo que me ha ocurrido recientemente con dos pull requests:



Esta pull request entre otras cosas añade soporte a la utilidad wsdl2html para que se pueda autogenerar documentación en html a partir del proyecto. En este caso entiendo perfectamente porqué la pull request no se aceptó. Mi aproximación es muy específica para el caso de uso que me interesa: generar comentarios de un proyecto Java en el cual el WSDL se genera con JAX-WS en lugar de escribirse directamente. Genero los comentarios a partir de esos ficheros Java, lo cual es no es una forma útil si trabajas directamente con el WSDL.



Esta otra pull request sin embargo es bastante más triste. Sencillamente el autor nunca me contestó. Extendí la utilidad Wallahack, que permite consultar Wallapop haciendo scrapping de forma que puedes escribir scripts que busquen resultados periódicamente. Por ejemplo usé este fork durante un tiempo para detectar anuncios nuevos de ordenadores antiguos. La diferencia principal entre mi fork y el proyecto principal es que puede parametrizarse y tiene un par de arreglos que lo hacen usable.

En ambos casos no tengo suficiente tiempo ni interés para darles más evolución, por ello sigo la convención de renombrar sencillamente a {originalName}_ivmos.


What should I do if my pull request aren’t accepted and I don’t want those changes to be lost as branches in your fork? IMHO, that’s actually the reason forks make sense and a main advantage of open source. You should try a pull request, with the needed effort to make it successful as maintaining your own fork can quite a pain. However sometimes it’s not possible and your pull request is not accepted. That’s something I’ve seen at least 2 times I’m telling you about:



This pull request is a branch which adds support to wsdl2html project. In this case I understand perfectly why the PR wasn’t accepted. My approach is very specific to the use case I had: generating comments from a java project where WSDL was generated with JAX-WS instead of being written manually. I generate the comments from those java files, which is an approach that does not make sense if you have worked directly with the WSDL (comments should be there).



This other PR is sad though. It was simply never answered. I extended Wallahack, which is a java tool which queries Wallapop web so that you can write scripts that poll periodically for results. For example, I used it to check whether new old computers had been posted recently.

In both cases I don’t have time to invest more time on them, that’s why I follow the convention of renaming the forked project to {originalName}_ivmos instead of using a new fancy name.

Product Hunt Madrid | Tuenti & Fever | Campus Madrid


Product Hunt Madrid es un evento de descubrimiento y crítica de productos y servicios digitales. Los productos se presentarán desde tres perspectivas: las decisiones de diseño tomadas, el stack tecnológico y el modelo de negocio. De esta forma la comunidad tecnológica de Madrid aprenderá cómo funcionan los mejores productos digitales del mundo.

Hace una semana estuve contando lo que hacemos en Tuenti con mis compañeros Laura Andina (UX) y Luis Javier Álvarez (Product).

Conté cómo trabajamos los equipos de ingeniería y algunas lecciones que hemos aprendido estos años.


Product Hunt Madrid is an event where Product Managers, Engineers and Designers show their products: how they’re built and how they build them. Products are presented from three views: key design decisions, tech stack and business model. This way Madrid community can learn from the experience of successful digital products.

One week ago I talked about Tuenti product with my mates Laura Andina (UX) and Luis Javier Álvarez (Product).

I talked about how we work in Engineering team and a few lessons we’ve learned these years.

Introducción a WebRTC y VozDigital


La semana pasada impartí el workshop “Introducción a WebRTC y VozDigital” en las oficinas de Tuenti para The Evnt (@TheEvnt).

A continuación los slides, el repositorio GitHub con el material y el vídeo de la sesión. Espero que sirva de ayuda a quien pase por aquí buscando dar sus primeros pasos con WebRTC.



Last week I gave the workshop “Intro to WebRTC and VozDigital” in the Tuenti offices for The Evnt (@TheEvnt).

Here you have the slides, the Github repo with the material and the recorded video of the session (spanish only sorry). I hope it can be valuable for those trying to learn WebRTC.