This entry intends to be a description of my professional trajectory as a software developer living in Mexico.
The university years
Like most of my classmates I came from a non-computer school so I knew close to nothing about computers. Due to my tight budget I got my first PC at the end of my first semester, so I passed my first programming courses by using my friends computer, and actually making him program for me since he was two semesters ahead of me. I never really got programming that semester so I kind of hated it.
In the course of my years at the university I gradually started understanding what programming was all about, to tell the computer what to do so that it does something useful for you. That I could understand.
I have always been a really slow thinker, so my coding skills were not up to the challenge when it came to class projects and I almost always failed at delivering them on time but somehow I never failed at passing my courses.
I rediscovered mathematics after failing at calculus, those were my first days in a library in which I actually studied and learned something. Unfortunately it seems it was too late for me and I never really could develop above average skills in math though I find them utterly interesting, beautiful and AWESOME!
In retrospective I believe that's what made me value programming in latter years, when the true origin of computers was revealed to me. Mathematicians spent their better years trying converge to a formal definition of what an algorithm was, and that enabled them to develop the theory of computation which grew naturally from mathematics.
Of course most most students ignored this as it could be seen from the fact that many of my classmates could say things like: "Computers don't have anything to do with mathematics I don't know why they want us to learn this stuff." when referring to our discrete maths course.
I had the fortune of meet a couple of persons that really influenced me in developing this taste for maths and science in general, in my first semester I met Prof. Miguel Olvera who remind me you can get goose bums from understanding gradients, rotational, and deducing Kepler's equations of planet motion.
Then in my third semester I met Dr. Genaro MartÃnez who technically taught us nothing from the syllabus (Data Structures) but it was thanks to him that I discovered I actually liked doing research. I learned what a Turing machine was and the theory of automata and formal languages. Thanks to him I never really knew what the heck a ADT (Abstract Data Type) was until later.
He used to invite us to summer research camps with Dr. Harold V. McIntosh in which every student was given the freedom to investigate on a topic of his interest as long as show the results of their work at the end of the summer. Professor McIntosh really gave me perspective, that was the first time I met a person with a lifetime interest in science who actually had done real science in multiple fields (physics, computation & chemistry). After a couple of summers I knew it was possible to have an appreciation for science even if you yourself were not able to work as a scientist. Science became very important to me.
From then on the later half of my university years were disappointing because I felt I wasn't in the right place, I wanted to work on math, but I didn't want to start all over because I didn't have the financial resources and I really didn't have the courage to switch to math because I knew my maths sucked.
I needed to find a job as quick as possible since money was scarce and a very needed resource, so I finished the university and went directly to work as a code monkey, or that was the idea...
My first job and running away from programming
At this moment I didn't want to work as a programmer because most of my acquaintances explained to me how bad the working conditions were, the non-payable extra-hours, working on weekends, pressure from your boss and all that stuff. So I found a job as a Quality Assurance Analyst in which I really didn't need to write code at all and that was good... for a time.
As it became obvious, a friend of mine and I were the only people with programming experience in the team who could automate some very time consuming tasks and we started programming to avoid doing things manually. The time came when I had to learn how to automate funcional and performance tests.
The working conditions were just as bad as I have heard. I couldn't make sense of it: why is it that programmers and pretty much all the technical guys are the ones with the worst working hours even when the business actually depends on their ability to create solutions and fix things? Many of my colleagues were mistreated by their bosses in a way that was beyond what I could bare, fortunately I was not officially a programmer so I was actually quite relaxed and comfortable in my job.
Since I was not technically neither a tester nor a programmer there was no ladder to climb for me there, I was stuck in a position that didn't exist, a hybrid between tester and programmer, so I decided to quit and work as a developer.
The return to the source
In interviews I had to justify my move from QA to programming and this was my rationalization:
"I have been in the world of testing what other people builds, and now I have the urge to build things my self."
Even though I didn't believe it at the time, it was good enough to get me my first job as a developer. This was a very small company that builds software for brokerage firms. I had my first encounter with purely writing code as my main activity during the day and it hurt ... a lot. Finally a couple of months later the AHA! moment came and everything went much easier after that.
The cool thing about that company is that they developed stuff in multiple programming languages, C#, Java, Tawk, Ruby, C++, Perl, JavaScript. The projects were assigned depending on their priority so it was common for some developers to have to switch languages many times in a day. That made my fear of learning a new language go away.
I started to understand the meaning of the phrase: "using the right tool for the job"
I changed jobs two more times, now as a developer, going through a mix of different technologies like Bash/KSH, XSLT&XML, Web Development with JSF and Hibernate, Javascript, Objective-C with Cocoa Touch which is my current main programming language.
The more I worked as a developer, the more I like the process it self, research, analyzing, designing, and testing... I still hated the development part of it. I had solved the problem, it was not a job for me to implement the solution.
The more contact I had with code from other developers the more unsatisfied I was with the quality of my code and their code, so I started to get strict about some things like:
- comments: I tried to write comments so that if I ever needed to go back an change something I didn't have to re-read all my code to find what to change. Reading code is in many occasions slower that reading good comments,
- readability & length of lines of code: I tried to write code that was easy to understand with just a glance and that meant short and simple sentences,
- the size of methods & modularity: divide your goal in as many goals as you can and make each subgoal as simple as possible, this leads us to the next,
- reusability: if you have small modules that do simple tasks, chances are high that they will be useful in the future and that will make your life easier,
- cleanness: don't include unrelated code. Make each module as independent as possible and as agnostic as possible, another way to say this is try to use loose coupling when coding, your module shouldn't care who is calling it to be able to perform it's task correctly,
- elegance & concreteness: your code should be pleasant to read and convey a sense of elegance such as that you see in mathematical proofs, in fact you can see each program as a proof to a theorem, the shorter and the more concise the better, one should not have to write more code than what is absolutely necessary to solve the problem at hand but don't get me wrong this doesn't mean you will write less code, just that the final product should be as concrete as possible.
- refactoring: improve your code, abstract, simplify, generalize. Usually you end up writing many times more code than you would normally do, but it's for a good cause, refactoring improves cleanness, reusability, size of methods, modularity & readability and you should try to do it as much as possible. After a number of iterations your product will have better organization and perhaps a smaller footprint.
- version control: be it centralized or distributed you should try to have a way to know the history of your code. It comes in handy for solving bugs, adding or removing features managing different versions of your product, etc. Besides is an excellent source of information on developer performance, you can get all kind of useful stats from a repository.
- unit testing: the latest but not less important is automated unit testing and all the possible techniques to make unit testing as useful as possible. You shouldn't need to load in memory the whole system just to test a small submodule. Always try to create code that is easily testable in an automatic manner so you can find bugs faster.
I really started to improve my code quality and I'm still working on it but all of these truths that I learned from more experienced programmers such as Donald Knuth became the source of a lot of frustation as you will find out soon...
Of finding love and deception
After I reconciled my self with writing code, I saw everything with new eyes, it no longer was necessary to fight the code, I could make reading and writing it a pleasurable experience.
The problem was that I was the only one seriously concerned about code quality.
As it turns out I have never worked in a IT company but only in the IT area of financial firms and those are two very different stories. An IT company has to find ways to enforce quality in their products, since in many cases the code is The Product. In contrast an IT area of a financial firm is usually not so worried on how things are being done, but that they're being done on schedule.
In Mexico there are no big IT companies, and most of the people coming out of universities go to work in the financial sector: banks, brokerage firms, bonding companies, or end up working for consulting companies whose clients are financial institutions. It's all about money.
The main reason to go to the financial sector is that the paycheck is bigger, though the work conditions are markedly worse than in other sectors. Bad infrastructure, connectivity limitations due to security concerns, awful office space, uncomfortable chairs and very high levels of stress among other things.
To all of this you have to add the very lacking educational level with wich students come out. My algorithms and data structures knowledge sucks and it hasn't improved much in the almost 6 years I have been working in IT, four as a software developer.
Even though most of us programmers in the financial sector are payed above average our level is rather low when it comes to code quality. That plus the fact that research, analysis and design are terms unknown or even Taboos when it comes to developing software. I cannot ask my boss for more time to design, or test without getting strange looks, even my colleagues believe that if the code compiles and runs then there's nothing else to do and you can forget about it.
Developers are kept in ignorance about design and analysis, working in independent cells. Many times each cell reproduces the work already done by other cell, and this goes on ad nauseam.
Most developers I know have not improved their code quality even after 8-10 years of experience in the industry. Their code is abstruse, hard to read, monolithic, uncommented, hard to maintain, etc, etc. I believe it's mainly due to the fact that the incentive to change that is little or non-existant, as I've said before no boss I have ever had cares really much about the how, they just want their application ready for a given date.
And the problem is...
All of this becomes a problem when you want to take the next step and jump to the next level, when you are genuinely interested in working for a company that makes a difference, you don't have the level required to be accepted easily.
The last two or three months I have been sending my resume to foreign companies with the hope to acquire international experience, improving my skills and improving my quality of life but so far I have only tasted the bitter truth of my situation. I currently don't have the level those companies need.
I'm still struggling to accept the possibility that the knowledge gap is really that big when it comes to software developers.
... and that my friends is the bitter truth about being a Code Monkey in Mexico.
