As usual, I started digging into his arguments, to find where my information (or his) was wrong, to find the cause of the gap in the concepts.
We talked how we started in IT. We both did almost the same path: Assembling machines, administrating servers, fixing data, fixing applications, creating applications.
Suddenly, he said "I was a programmer, receiving the specifications from the functional analyst, but I quit programming, I needed to evolve".
I could heard a huge "crack" inside my head. There it was! The source of the difference!
But first, let's talk a bit about how "programming role concepts" evolved
He was talking about the "functional analyst" and "programmer" roles.
This difference sounded too old for me, but he was talking about them as if they were very actual.
For me, from the beginning of my career I never could understand why these roles were separated. To create a program, there is a big component that is personal. Like painting a picture. How is it possible that you paint something someone else saw? By painting following instructions there is a big chance the result is not what the instructor was told that someone else (the business) saw. No matter how good painter you are.
The functional analyst, a guy who usually didn't know about the business, nor programming, was an unnecessary intermediary, and, within my experience, it was the main factor to explain why a lot of software projects failed. And the time gave me the reason: One of the Agile pillars is that the customer must be in the developers team, showing them constantly the reality, so they can paint it. A user story is not a set of instructions, it is an agreement on how the customer and the developers sees the reality. The paintings now, are pretty much closer to the reality than years ago, aren't they?
Nowadays, the programmer talks to the business. Where is the functional analyst? it's the programmer that plays that role as well. It could be something like: Programmer + Analyst = Developer.
But this is not that clear to everyone. To my colleague, he still have this roles separated in his mind, and he never took the opportunity to see if this reality had changed. Why would he? He was not in that place any more anyway.
Because he had stopped coding, to evolve. This is the main clue to understand where he was standing.
When he decided to become a "functional analyst" he left the "software creation" path. He assumed that he already knew how to program, and he could no learn anything else. He could not evolve there.
But, couldn't he? Software Engineering has been evolving for years, and still it is. Why he could not? The answer is pretty simple: He was not interested in.
And this is a common pattern. People who made the same path, maybe driven by circumstances, but not choosing to be there, or loosing the interest in the way, but still stuck in the job. They are there, just waiting for the opportunity to leave, to "evolve". (This evolving excuse is a very common one I've heard several times.)
Now, what happens in a corporation, when you have a lot of people doing technical stuff, but thinking on stopping doing it as soon as possible? What happens when you have developers that are doing their job in its minimal expression, just waiting to become a supervisor or a manager? In other words, what happens when you have people doing what they don't feel passionate about?
For them, it is the same to repeat hundred of lines of code instead of encapsulating. Because, it's easier to copy and paste than refactoring. Some of them don't even know what that word means. The excuse is "it's faster to do this way"
For them, writing a store procedure that does everything is better than thinking on separateness of concerns. The excuse is "it is faster to do this way".
For them, hardcoding code is better than thinking on ways to make the program more flexible. The excuse is "it is faster to do this way".
The excuse is always the same . They say the want to do it faster, but what they really want is to do it with the less possible effort. Because, if they tried to do it better, it would mean that they would be spending time doing something they don't love to.
And these people, eventually will reach a higher position. Predicating their lack of interest, that will be heard and followed by other employees. Increasing the technical debt.
Here relies the main difference of what my colleague and I think about the technical lead duties: I want to be a TL to teach people to love what they are doing, the same way I do. He wants to be a TL because he wants to stop doing what he is doing now.