The interview
To give you an idea of how relaxed my area interview to join Avature’s Framework team was, I’ll say that the first thing I told my interviewer was a joke about his nickname: Qcho—well, in my defense, it’s quite a funny one, isn’t it?
Next thing I knew, Qcho was telling me all about the company and his own role as Principal Engineer. He told me how he started as a developer and gradually began to take on more responsibilities, and how much he enjoyed being an “agent of chaos” (or at least that’s what I got from it, understanding chaos as the sort of disruptive thinking that triggers positive synergy and makes things evolve.) At that point, the talk was super fluent and I was beyond engaged with the being-an-agent-of-chaos part. I continued telling him about my own experience in development working in the industry for over 12 years at different places (software factories, product companies, consulting agencies). But while I continued talking, my mind was actually going somewhere else… Finally, I said it: “I really like the challenge, but you’re telling me that you work with PHP and I don’t know a thing about PHP.” To that, Qcho answers, “You’ll have a big learning curve ahead; we have a framework of our own and, in this team, you’ll work with PHP, but it’s just another language. What really matters is that you can apply your experience and knowledge to the object-oriented paradigm, and then PHP… you’ll learn it. If you like the challenge, let’s move forward!”
I started doing the numbers in my head: learning time, framework of their own, new industry, Technical Leader role, and a language I had never worked with before and wasn’t at all my favorite, nor the one I would choose to work. Way out of my comfort zone.
I was just about to say NO, when I suddenly realized that what I actually found scary was that I was facing something new, unexplored territory—the typical insecurities. And it was this realization that pushed me to say YES.
After I said yes
Once the interview was over, after all the doubts and my thrust to say yes (I could say I was “following my heart”, but it actually had more to do with acting fast when I’m scared, not going to lie), I realized that what they were interested in from my profile was not connected to my (lack of) knowledge of PHP—that was out of the question.
At that point, I relaxed and went over the talk with Qcho in my head and what he said was expected from me. What they had told me in previous interviews about my profile and mission at Avature started to make sense, and I began to think of what was coming next…
First impression
So I arrived at the Framework team. Everybody introduced themselves and I found a bunch of amazing, fun, and generous people, always ready to lend a hand. After that, I met with a teammate so that he could introduce me to the environments’ installation and all that stuff a developer needs to know. I quickly started to see things that caught my attention and had lots of questions, but patience: answers will come with time.
The moment finally came, that moment every developer waits eagerly, that moment when you open a project and finally see THE CODE. For those of you who aren’t devs, let me tell you how it feels: Remember when you were a kid and it was your birthday and that cool aunt who loved you so much came and said, “I got a little present for you”? You were so young and didn’t understand the little part of it. All presents are PRESENTS with capital letters to you. Because cool aunt knows what you want—she always knows. So you put all your expectations on that present, that amazing red package with a big blue bow. You start to slowly open it, expectations rise even higher, you undo the bow, tear the paper and… It’s clothes. Ok, not the PS5 you thought cool aunty would have known you wanted, but this was a possibility.
I see the code and lots of questions arise. I try to understand how all this cooperates to solve a functional unit. Confused, I hear a voice in my head telling me, “Ok, a factory. And this is a DAO. Mmm, good.” I slowly start to understand.
Getting to know each other
For months, I read things I didn’t completely follow, but little by little, with lots of help, reading, asking, and researching, I began to understand implementations in an abstract way. My contributions to the team were very conceptual at first, all connected to object-oriented design, all very far away from PHP, but at the same time they were just what the team needed.
I had my first problem to solve. I knew for sure what we had to do, what the team needed. But how did that coexist with what was already done? And what impact would it have on what we already had? To begin with, the strategy was obvious: I had to stop talking and start working with PHP to show the team what I was proposing and get everyone onboard. The strategies were the usual ones: balance to level off, example to motivate, and trust to build commitment.
That was when I had to face my first enemy, the relentless, the irrepressible, the one that could sabotage all my ideas and thoughts: a totally unknown language, both syntactically and semantically. In my case, it was PHP.
If there’s something I learned in high school, it’s that a thousand friends is not much, but one sole enemy is a lot. I had to transform myself, evolve into a new form in which PHP would take me as a friend. There was no way of winning if I did not understand it, if I did not play by its rules. So without further ado: time to study.
Becoming friends with PHP (and the lessons I learned along the way)
After a countless number of failures and after my head hit the wall—or the keyboard—a couple of times, I finally got to understand the development idea PHP proposed. I did lots and lots of testing and, once PHP started to respond to my ideas, I felt just like when Gonzalo Montiel scored that last penalty in the Argentina-France World Cup final. With tears in my eyes, I looked at PHP and I said, “I know you’re not NET, I know you’re not JAVA, and I’m not asking you to be like them. I’m just asking you to be as patient with me as I am with you, because we both know that when it comes to OOP we’ll seldom come to an agreement. And if we ever have issues, know that I’m trying and that, after all, I’m convinced we’ll eventually get along.” And that’s how my friendship with PHP started.
With the language already on my side, I started to deeply understand the issues the team was facing and get ready to tackle them. This was how I solved my first big challenge at Avature. And the best part is that it wasn’t the last one.
Once I was fully immersed in my Avature adventure, I learned to dismantle two big preconceptions I had (that’s what I call “the magic of leaving your comfort zone”—I invite you all to give it a try):
1. Working with a custom framework decreases years of experience
When a developer starts working in a company that has a framework of their own, the usual fears come up: “I’m not gonna learn about software development, I’ll just learn their own framework”, “I won’t understand it because it doesn’t look like anything I’ve worked with before”, or “After I’m out of here, none of this will ever be useful in my career.” Well let me tell you that according to my experience and Avature’s philosophy, this assumption is a mistake.
Let’s think it this way: a framework is a perfectible box of tools that can be used to solve a finite number of problems, which is the equivalent of having a toolbox at home. When you lack a certain tool, you evaluate the cost-benefit of adding it to your box and, if the balance is positive, you buy it. Now your toolbox (which has been perfected) solves one more problem (added to the limited number). There’s no toolbox that can solve an infinite number of problems, therefore, the problem is what rules and it will always tell you how many toolboxes you need and how they should collaborate with each other to solve it. It’s precisely this problem-solving experience and assessment of the tools available that make up the experience you’ll take with you and apply for the rest of your career.
2. Language X is bad.
Let’s get things straight: I’ve never ever seen a language hitting a developer (ok, bad joke). Languages have purposes, they’re not “good” or “bad” per se, they’re just built to solve specific problems, and there are as many types of problems as you can imagine.
If there’s something that helped me through my journey as a developer in the diversity of problems I tackled was being open to change, breaking all rules and starting all over again, learning from other people, listening actively, and understanding that what’s at stake are ideas and not people, and that an answer is worth nothing if there’s not a question before.
Seeing beyond the clothes (or the language)
To cut a long story short, and going back to that first impression, the clothes that your cool aunt gave you as a present are just like the language Avature brought to me: they might not be what you were waiting for or would have chosen, but after all, you realize that they serve a purpose. If you look at the context, you’ll see how much love there is in the packaging, how shiny the bow is, and how useful those clothes actually came in. And most importantly: your aunty came to celebrate your birthday with you and, on top of that, she brought you a present!
What’s my point here? That the language is just a detail if you dare go beyond. And if that’s not enough, think that this is not the first nor the last present you’ll receive, and—believe me—if you thank your aunt enough and give her a big hug, next year she’ll bring you the PS5.
Because after all, what matters the most is the love, effort, and dedication we put in what we do, the path we walk, and the lessons we learn along the way. Even though they might seem hard to see sometimes, they’re always there, waiting for you to discover them. My name is Enrique Candia and I see my future at Avature full of challenges and adventures.