Lessons From a Veteran: Gabriel Aizcorbe on Unexpected Lessons
This post is part of a series interviewing veteran developers, asking them questions about their journey to tech mastery and sharing the advice they have for those getting started. Today we cover a lot of topics, from whether you should go into programming or IT to being specific about what you set out to learn to the lessons you’ll never learn until you start working.
And we’re learning about all of these things from Gabriel Aizcorbe. Gabriel got into IT when he received his first 8088 at 14 years old. From then on, his whole life was about computers, programming languages, and learning more. As a project manager with PMP and agile methodologies, he gained experience in all kinds of projects in the local and international markets. He has a deep passion for data and analysis and is striving to launch a startup devoted to data manipulation and analysis while he works as DBA/BI consultant.
Let’s hear about the lessons he’s learned on his journey.
Basic logistics: Stack? How long have you been doing it?
I’m a bit of an “un-stacked” person—more a “free soul,” if you will. I prefer to mix my own tools as I need to in order to achieve a goal. But, if I had to associate myself with a stack, based on the tools I use the most I would say Microsoft stack. Either way, I have enough flexibility to change to a MEAN stack or whatever else comes along. In the end, they are still development tools.
And since when? Well, I started self-teaching when I was 14 years old. But let’s say that, formally, my first big development job was at 25. So I’ve been working for more than 20 years.
What made you want to go into programming?
It was simply love at first sight, pure passion—it was nothing I thought intentionally about or calculated.
It all started one day when I was 8 or 9 years old. My father took me to his office, where they had new Apple computers, and some other NCRs programmable with punched cards (we’re talking about 1979 or 1980). From that moment, I wanted one, and I wanted to know how I could program them. And I really wanted to know everything about computers—in fact, about anything that could be programmed. I was fascinated by the idea of automating. (To this day, I am still fascinated on of my biggest vices: automate everything.)
So, I found an NCR manual and started learning how binary, hex, and octa code works, about flowcharts, and how to design a program. By the time I was 14, I had my first AT 8088 computer and I was super exited. Everything became a flowchart for me before any development. And, I have to say, it was a great advantage to have the structured mind and understanding of logic.
With that 8088, my first language I delved into was BASIC. But then I discovered the existence of assembler. It was love at first sight again. I learned quickly, and I dedicated myself to understand how tools programs and games worked. I even designed cheats in my game, which were on 360 Kb floppy disks (OMG! I’m getting old), to be able to reach the end with infinite lives or to eliminate the monsters.
Later I learned Turbo Pascal and C and created my own tools, utilities, and programs for my father to make controls on his Lotus 1-2-3 spreadsheets. (Fun fact, the first two or three versions of Lotus 1-2-3 were fully developed in assembler, and then they moved to C.) At that point, I can say that learning any language was very easy.
What were you most worried about when you made the decision to pursue a programming career?
I don’t know if I could say that there was something that worried me, but if there was something annoying, it was that the university was going too slow for what I wanted to achieve. My professors also didn’t delve as much as I wanted into the topics that interested me, so I spent quite a few hours in the library. And when internet access came … gosh, more love at first sight! (I’m an easy lover, as you can see.)
I always knew that IT in general—because I am passionate about all areas, except QA (ew)—was going to be what would accompany me all my life, and it hasn’t disappointed me once.
What surprised you most at your first programming job?
Wow, a lot of things. My first experience as a programmer in particular was surprising. It was a language that I had never seen before and I was the first to enter the team, so for several days I was completely alone in the office.
For the first time, I was facing an Oracle database, so since I had time, what did I do? I read manuals on how to work with Oracle and how to program PL/SQL. It was two very fun weeks until the rest of the team members started coming. And with them, more surprises came all at once. The interesting thing was the teamwork. I learned many things from the team, both from how people work and from the project manager, who later ended up being a very good friend to this day.
In short, new language, new database, and teamwork meant I was immersed in many new things in a fairly intense project. We ran against the year 2000 in a financial system. I was surprised often, and, like a sponge, I absorbed as much knowledge and experience from anything that crossed my path.
What turned out exactly as you expected it to when you got your first job?
Absolutely nothing, and that was an excellent lesson because—being my first job strictly and seriously related to programming—everything that happened there was going to be in one way or another a point of reference. The fact that nothing had gone as I had imagined taught me an important lesson: to keep my expectations in check.
I allow myself to imagine what I expect from a new situation, but I don’t live the experience through my expectations. Rather, I let things flow and surprise me. Otherwise I think that you tend to get an idea of how you want things to turn out, and when it doesn’t happen you get frustrated and lose the opportunity to see things that you really didn’t expect.
This is something that I have seen in colleagues and friends as well. They imagine or idealize certain aspects of a job, and then they are frustrated if something does not match their expectation. And they fail to see other advantages because the frustration of said expectation overshadows everything else.
What advice would you offer to people considering a career change to programming?
Well, I think you should make a change because of passion or curiosity. Don’t make a career in IT because of myths like these:
- IT professionals make a lot of money.
- There’s excess work for everyone.
- IT is one of the best professions because you can work from home or the company has a playground.
The truth is that you are about to start the most incredible journey of your life, and at the same time the most demanding, too. It’s possible that you don’t have any weekends, that you work until 3, 4, or 6 a.m., or even that you work 24 or 48 hours without stopping.
You are going to find the most frustrating obstacles on the way. You will also see that once you start “running” in this race, if you do not keep running every day you will lose the crest of the wave. What I mean by this is it doesn’t matter how much you know. You must continue studying every day, every week, every month, every year and not stop because technology does not stop. And if you stop, you will lose track.
There are many professionals in the world, so competition is fierce. Those dreams of making a lot of money or having a company playground will fade when you must spend hours at your desk and don’t have time to play videogames or sit in a beanbag.
You have to see the profession with realism. It’s beautiful wherever you look at it, but it’s also very demanding. It ‘s almost like being a doctor. You can receive an SMS at 4 a.m. that a server fell, the application stopped working, or there was a security breach. Anything can happen, but those things are fuel for you to train and unleash your creativity. Either you’re the type of person who is happy doing the same thing routinely or you are a restless person who will seek to automate and anticipate every problem in order to keep everything under control and move forward.
In any area of IT, you have the doors open to innovate and create. For me, there is nothing more fun than being able to invent things and solve problems every day.
Did you ever think that you’d made a huge mistake getting into this field?
Not at all, and that’s coming from someone who started different universities to try different things (economics, medicine, psychology). But in the end, I stayed with my career. As I said, I’m very curious and have many interests, but I wouldn’t exchange this for anything in the world. It has everything I need in my day to day, even though I had huge setbacks and some difficult times. But it always comes around when you feel passion for what you do.
What mistakes did you make that you think others following in your footsteps could learn from?
I know this may sound contradictory, but it’s a lesson I’ve learned, and I think it is important. As a curious person, I’ve spent a lot of time trying to know everything about IT. The problem is that when you know everything, you don’t know anything. I wasted time putting my attention on many things at the same time. With time, I realized this did not lead me anywhere, and I chose four or five things. Later, I realized that four or five things were still a lot. So, I decided to listen to my inner-self and figure out what I liked the most. I feel nostalgic about programming, but I know IT fulfills me because there’s not a day that doesn’t surprise me.
Who has influenced you the most so far in your programming journey?
Well, when I first started with my 8088, one of the main software manufacturers was Peter Norton. There were many low-level tools that were very useful to me (thanks, Peter), and I was very curious to understand how he had come to think of and create them. So, I set out to disassemble them to understand what they were doing and try to create my own tools.
So, I would say that Peter Norton (from whom I also have an assembler book) was certainly a great influence for me. And he influenced me in so many respects, from the point of view on how to develop tools to how to find tools niches to how to teach something (in my case, assembler). More importantly, I learned from him how to stay humble, as it’s almost certain that you know Bill Gates but you didn’t know Peter Norton, who was behind Norton AntiVirus and other things.
What programming reference materials can you not live without?
Books and the internet, but really what I consult most are my own notes. Normally, when I face a complex problem, I take note of all my steps in the process of solving the problem. That’s because I know that someday it may be useful again to me or to someone else. As a result, I have folders and folders of documents explaining how to do something. That solution may not be online because I created the solution along the way. I consult my scripts, code snippets, and personal documentation a lot.
What’s something that no training/bootcamp/degree could have prepared you for?
This is a long list, and many of these things aren’t really related to technology.
No university or course explains relationships with team members and managers and your relationship with the user. These relationships are as important in a project as the project itself. In fact, managing those relationships might be the most time-consuming task of a project. And at the same time, it’s what determines the success or failure of the project.
When we program, the machine always behaves more or less the same (but sometimes it can behave like the devil). A logic is a logic. 1 and 0 will always be 1 and 0. But when it comes to relations with users, the team, QAs, DevOps engineers, DBAs, and managers, everything is complicated. The emotions, beliefs and values, interests, and dozens of intangibles for each person involved all condition the progress of the project.
Even when you team up with other students in school, it will never be like it is in real life. You will have a feel of course, but it’s not the same. You need to work on your social skills in order to interact with everybody in the most fluent, simple way, and that’s not an easy task. Sooner or later, you’ll find that you need different “emotional algorithms” to connect with each person to make things work. So, train your social skills as much as your coding.