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!


About Learning How to Learn course

I’ve just finished the Learning How to Learn course and I wanted to summarize some key ideas for myself and also encourage any reader to follow the course. If you’re a successful learner lots of the ideas will be familiar to you, no Coca-Cola formula disclosed but I think it will be valuable for you listening to them in a more elaborated way and you might also learn some new things. I really enjoyed this course.

  • Focused versus diffused mode of thinking.

You’ll learn how you need to work both modes of thinking, both are important and key for success.

If you just try to learn in the focused mode you might have trouble trying to work creative ideas, link ideas to others that would seem unrelated at first and creativity in general.

When you’re in the focused mode it’s like distractions do not exist, all your CPU is dedicated to a single task, it let us focus on the information we’re working on being very efficient processing it and memorizing what we need. However, often you need to see a bigger picture as big as you might need, you start focused on a problem that seems to have no solution and you leave your mind fly and start touching related ideas, like zooming out from the problem, that’s when sometimes “magic” happens and you understand something relevant to the problem that you weren’t able to see just being focused on the problem. This is the diffused mode.

This is what happens when you manage to find a solution to a problem after having a walk, after sleeping, while you’re moving your chair around instead of keep staring at the code… I’ve seen this often in cases where you are trying to fix a bug and you’re in that moment where you think “This cannot be happening, it’s impossible”. Then is when you go to the kitchen or start looking at the sky or go home and keep thinking about the problem at the gym, and at some point, you realize that there’s something you had missed that could actually be the problem and it is!! I think this is also related to the rubber duck debugging as it lets you change to diffuse mode thinking while you explain the problem to a mate.

More about focused vs diffuse mode.

  • Procrastination.

This a topic I’ve been interested in for some time. Some ideas I already knew are explained like trying to start with tasks you don’t like first so that you get an “energy boost”, trying to focus on process instead of product so that you enjoy with the routines and avoid thinking too much about long-term goal and trying techniques like Pomodoro.

It explains a nice analogy, saying that you do lots of things in zombie mode, and you usually don’t feel procrastinate doing them, you feel that you need to procrastinate when you know that you need some effort, even if it’s a task about something you want. Thinking about the product enforces procrastination. The good news as it’s said in the course is that once you start, the “pain” stops and you can try things like pomodoro in order to advance.


  • Learning

It’s explained how important practice is, the importance of testing yourself (like in an exam) and how productive it is versus just relearning the material. Actually, it talks about the risk of over-learning that you can avoid testing yourself soon so that you know whether you’re already ok with the subjects. Related to that there is an interesting concept called Einstellung.

It also explains the “interleaving technique”, something I already knew but never applied too well but might try to do better in the future: it’s about learning a subject and reviewing it like exponentially in time so that your brain saves the information in the “hard disk” instead of just “RAM” (or even L2 cache). As I’ve said I’ve typically studied a subject for some time and moved on to another instead of keeping reviewing the learned subject before the current one.

The course also talks about the importance of memorizing and practicing, understanding is not enough, it’s like the eureka moment is good but you need the practice to be able to work with the concepts and having there in your mind long term.

It also explains that sleeping is very important so that your brain can organize what you’ve learned and you can be in good shape the next day. It explains that there are some metabolic processes that block you’re learning and you need rest in order to control them. It also explains how important it is recalling for learning. This is something that my father did great, I remember how he asked me each lesson and that was key for learning, it was not that when being asked or being tested you’re only checking whether you’ve learned, you’re actually learning at that moment and enforcing consolidating concepts in your brain.

The course also explains the concept of “chunking“: you study some concept or idea, you understand it, practice and link it to other concepts, like a part of the puzzle. You can memorize a concept but it will be useless, it will be a variable that is GC collected as it’s linked to nothing. Those chunks are formed from small pieces to form bigger ones, and your diffuse mode of thinking can try to find new relations among all of them. That’s what experience is about when you’ve been working on lots of projects in different areas and you see how all of them in some way guide you to new decisions in next projects.

There are other interesting concepts shown related to learning like the “illusion of competence”: when you think you’ve learned something but you’ve just read a lot about it but you haven’t really learned it. They also talke about a related concept that is well known in our profession: The Impostor Syndrome.

It also mentions that some techniques like highlighting text can be worse than just writing some personal notes on the side of the book and writing a map of the ideas. E.g in you’re listening, instead of starting from the top of the paper, just start from the middle, write some ideas, link them…

Finally, it also mentions the importance of metaphors and how you replace some metaphors by better ones.

Practice, practice and practice:


  • Memorization

In a world where all the information is on your smartphone, do we really need to memorize things or we just need to understand?

It happens you can’t learn without some level of memorization, and It has been studied that being able to memorize important things is also positive for creativity. It’s also related to practice, you’ll memorize those things that are important as part of your practice. The course mentions some techniques to help memorizing like the Memory Palace , mnemonics, acronyms…


  • Tips for tests

It also explains some tips for tests. Apart from encouraging good sleep before exams it promotes checking first all the questions to see the whole picture and starting from a difficult exercise but jumping to an easier one if you’re blocked after one minute. This practice surprised me as I think I’ve always started doing the easy ones and then going for the trickiest ones but their explanation made sense as that way your brain is already working on the difficult ones at the same time you’re working on the easy ones, just encouraging your diffuse mode I guess…

  • Some interesting resources

You can explore more about this course contents in this mindmap by Rodolfo Mondion who has also written about this course:

The course is also very good pointing to valuable resources, e.g:







Analyzing FastestWebsiteEver

Checking https://github.com/diracdeltas/FastestWebsiteEver was on my TODO list. Let’s see some details in Wireshark and review some TCP/IP details.

Captura de pantalla 2017-09-30 a las 3.19.38.png

You can check http://packet.city/ if you want to avoid setting up the service yourself.

So you open Wireshark and you start capturing. Visit http://packet.city and you can use a Wireshark filter for the resolved IP for packet.city.

Captura de pantalla 2017-09-30 a las 2.11.30.png

The project states that it is “the greatest website to ever fit in a single TCP packet”.

Is it true? Let’see what it needs: I can see 9 packets and some details.

First 3 packets (handshake)

Captura de pantalla 2017-09-30 a las 3.03.49.png

Like any normal TCP connection we start with a 3-way handshake:

  • First, my laptop sends a SYN packet with an Initial Sequence Number which can be seen 0 in Wireshark but that’s actually a relative over a random. This is my laptop requesting proof that its message can get through.

Captura de pantalla 2017-09-30 a las 2.28.14.png

  • The server needs to send an ACK packet (to prove SYN received) and its own SYN (to prove it can reach the client). We can see it’s actually done in the same sent packet: SYN-ACK

Captura de pantalla 2017-09-30 a las 2.30.49.png

  • My laptop receives the SYN-ACK: as its an ACK it knows it can send a packet to the server and as its a SYN it knows that the server needs an ACK, so it sends such ACK.

Captura de pantalla 2017-09-30 a las 2.35.54

  • Once the server receives that ACK handshake has finished and the channel is considered feasible. However it might have been like, but this is the minimum to start trying to communicate.

Packet #4 (GET)

We’ve finished with the 3 first packets. The fourth one is the GET request.

Captura de pantalla 2017-09-30 a las 2.41.10

Captura de pantalla 2017-09-30 a las 2.48.50.png

Notice that Push flag is enabled (PSH) and also ACK as with any exchanged packet during the communication.

In HyperText Transport Protocol we can see the sent HTTP request:

Captura de pantalla 2017-09-30 a las 2.52.48

#5 and #6 packets

Captura de pantalla 2017-09-30 a las 3.04.41.png

Packet #5 is an ACK:

Captura de pantalla 2017-09-30 a las 3.00.10

Next packet is the HTTP GET response:

Captura de pantalla 2017-09-30 a las 3.02.55.png

I guess this is what the project describes as “send response immediately after TCP session init”

I think PSH is enabled because Nagle’s algorithm is disabled as the project describes too.

In Hypertext Transfer Protocol section we can see DEFLATE compression is being used, again exactly as described in README.

Captura de pantalla 2017-09-30 a las 3.13.12.png

See that Response is “200 k” instead of “200 OK”: 1 byte saved there.

Content encoded is 1163 bytes (1547 bytes decoded), far from needing fragmentation:

The maximum would be 1460 bytes for content and 40 bytes for IP and TCP headers.

In this case, the frame is 1292 bytes, TCP segment length is 1226 bytes and HTTP Content-Length is 1163 bytes, in detail:


  • Frame header (14 bytes): 7 bytes for preamble, 1 byte for SFD, 12 bytes for source and destination MACs and 2 bytes for packet type (IP) –> 22 bytes (14 ignoring preamble and SFD)

Captura de pantalla 2017-09-30 a las 9.49.08.png

  • IP header (20 bytes): 1 byte for ip.version (4), 1 byte for ip.dsfield, 2 bytes for ip.len (Length), 2 bytes for ip.id (ID), 1 byte for ip.flags (0x02, ip.flags.df (Don’t Fragment  )is set), 2 bytes for ip.frag_offset (Fragment Offset), 1 byte for ip.ttl (TTL), 1 byte for ip.proto (Protocol), 2 bytes for ip.checksum (Header checksum) and 8 bytes for ip.src and ip.dst.


  • TCP header (32 bytes): 4 bytes for tcp.srcport and tcp.dstport, 4 bytes for tcp.seq (Sequence Number), 4 bytes for tcp.ack (Ack Number), 2 bytes for tcp.flags, 2 bytes for tcp.window_size_value, 2 bytes for tcp.checksum, 2 bytes for tcp.urgent_pointer, 12 bytes for tcp.options

Captura de pantalla 2017-09-30 a las 10.17.44.png

  • HTTP (1226 bytes): 15 bytes for “HTTP/1.1 200 k\n”, 21 bytes for http.content_length_header, 26 bytes for http.content_encoding_header, 1 byte of “\n” and 1163 bytes for Content (encoded)

About the HTTP response content, it’s easier seeing the source code in the browser, there you’ll see:

Captura de pantalla 2017-09-30 a las 3.16.04.png


Last 3 packets

Finally last 3 packets. Server resets the connection with RST packet. I guess they could use FIN but RST is quicker. More about FIN vs RST.

Captura de pantalla 2017-09-30 a las 3.21.41.png

That’s all 🙂



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.