I knew Rafael Almeida even before we met by change at college. This is surely one of the best programmers I know. He makes magic happen in his code, while also holding extremely high code quality standards. Rafael has helped my in my programming path in many ways, so I interviewed him so his word can also help others.
Debug and Communication Skills
WLAD: What ability you see as the most important for a programmer?
Ralmeida: There are important technical skills and non-technical skills, also known as soft skills. Out of the technical skills, besides obviously knowing how to program, there are many important ones, but maybe the most important is to know how to debug through an effective process. Regarding soft skills, certainly the most important is communication, knowing how to explain things. That applies in everything, from documenting to explaining things to both technical and non-technical personnel. I think that’s much more important than things like good office policy.
WLAD: Indeed! I agree with you regarding communication and debugging skills. So let’s extend the question, how do you think a novice programmer can develop these two key abilities?
Ralmeida: Communication is simple, but it isn’t easy. First you need to write well, write good emails–even the email you write to your colleague or boss is an opportunity to practice your communication. The way to learn how to communicate is to communicate more with an effort to do it well. The easiest way to practice is by writing: do nice documentation, write good emails. These are the low-hanging fruits when it comes to learning how to communicate.
Regarding debugging, that’s something much more abstract because there are several ways to debug. Some people prefer code instrumentation to pinpoint where the problem is coming from. Other programmers prefer to postpone instrumenting, and try to inspect the code, running it with the mind, trying to adjust their mental model of the code, challenging the assumptions created when they were first writing that code. They read the code thinking, “Does this code fragment really do what I think it does?”
When I worked at Invent Vision, a business based on computer vision, they had a peculiar work environment where we had very little opportunity to test the code in actual production. We could code in the company’s lab, but for deploying it we had to do it in the factory, right beside a smelter, wearing a helmet, in a very hostile environment. So we ended up learning: in this scenario we had to instrumentate the code with a logging system so we could analyze errors. But in the end I think we learned to make a mental debug before doing the instrumental debug.
That sometimes means reading the code while making notes on paper, testing in your mind what can happen. Many programmers today begin programming in ways that it’s very easy to debug, such as on the web. You have your website up, and you can open a console on the server and debug on the spot. The popular tendency is to make a more instrumental debug, because it’s simple and offers low risk.
In many other fields, it’s not like that. Imagine when people started programming, when everything was made using punched cards? You couldn’t stop and open up the computer to check what was happening. This kind of mental debugging isn’t really encouraged in today’s context, but it’s a very useful skill, because it can save you a lot of time. If you code well in the beginning, you can debug by testing your mental model of the code before instrumenting it. Obviously, if everything fails, you instrument it, but I think the ability to stop and think about the code can’t be underestimated.
Career
WLAD: That’s great. Well, you spoke a bit about your work field. Summarize your professional experience, and tell us a bit about the work you are doing right now.
Ralmeida: Actually, I’ve done a little bit of everything. I started to code when I was like 10, maybe older. A lot of people in this field begin very early. I wasn’t even in high school, and I started learning just before the burst of the Internet bubble. So, at that time, the thing was basically to learn HTML and Javascript, so my first programs were basically Javascript scripts. Shortly afterwards I started to make small freelance works here and there. I remember I had a website with a friend, a small portal, and in it I started to program in PHP too. So I started as a web programmer. Then I went to high school and did technical school. I got an internship when I was in my second year, also in web programming, but this time I worked with something more well structured. It was an advertising company, where things are more fast-paced, so it wasn’t super structured, but way more than freelance work you do at home. There I worked with ASP.net, PHP and classic ASP, and on I went.
At this time, I also managed servers as a freelancer, so I ended up learning a bit about devops too. That’s a new trend for programmers: to understand at least a bit about the operational aspects of the servers. And service administrators are learning a bit of programming to automate some tasks. Programming and sysadmin are getting closer and closer these days.
And then I got into college. Soon after I started working at a company called Buzzero, also doing web programming. There I also did some backend work, creating a hierarchical data model to describe the content of the the company’s courses, and some data crawling.
Then I joined a lab called e-Speed at the university, where I also did web development. As an undergrad in the lab you end up doing lots of operational tasks – coding websites and stuff–but I also learned a lot about data mining and parallel computing, even though I didn’t get my hands really dirty in these topics myself (like some of my undergraduate friends). We had very intense contact with these fields, even while not working directly on it. So I got a nice overview of distributed parallel programming, and data mining.
Then I went on to work at Studio Sol. There I also worked with a focus on web programming, but I did other things, such as musical algorithms. I did the algorithms to transpose guitar tabs that is used by Cifra Club (Brazil’s largest guitar portal). That algorithm works in a website, so it’s technically web development, but it was a heavily algorithmic task–I didn’t even make much browser tests until the final stage of the feature, when the overall system approach was mostly consolidated. I was there for a bit more than a year, at first as an intern, then as an employee. As intern I did more backend stuff, heavier algorithms . I made a study using machine learning to filter web comments. It wasn’t put into production servers, but it gave us a few hints for better dealing with comments; it was a very interesting exploratory step. Then I started to work with frontend, developing abilities that so far I hadn’t: the diligence to deal with elements in the screen, polishing everything up to the last pixel, really brushing pixels.
After Studio Sol, I started to work in a startup, PasseiDireto. I was basically a crawler builder, a data hacker. They needed several data from college courses from all over Brazil to feed their system, which was a social network. So I did the crawlers that got in the university’s websites, found the documents that contained the list of courses per major, using a semi-automated process, and created programs to parse these lists into a structured format, that the company then fed into the database.
Then I went to the company I mentioned earlier, Invent Vision, where we did computational vision systems for the industry. Basically we had a camera in the production line, and using it we coded software to measure parts, to inspect parts to see if they came with the right stamp, or if they fell within the correct range of measure, or if too much smoke was coming out of the machine. I was there for almost a year.
Then I went to the company I’m currently working for, Toys Talk, a toy manufacturer. There we have interactive toys with tablet and smartphone integration. Now I’m working specifically in the field of augmented reality, developing games using digital interactions with toys. I also work with a little bit of infrastructure, for instance, logging gaming events in a server, implementing marketing analytics that kind of stuff.
I forgot to say, but at Studio Sol and at the company I work for now I also did some authentication and cryptographic systems, to ensure security of APIs, authenticating products, and stuff. Basically that’s the overview from my career.
Computer Vision and Algorithms on Music
WLAD: Wow, that’s a lot of stuff, I’m impressed! I didn’t know you had done so much. Of all of these experiences, which one do you find most interesting in terms of professional development?
Ralmeida: There were many interesting jobs, but in terms of fondness for the product, it was in Studio Sol. There the work had a musical context. I’m also a musician, and I really love music, even more so in an analytic view. Because of that it was very fun to work there: to make an algorithm to manipulate guitar tabs, to help make a metronome app, these things were very fun in the pure technical aspect.
From the computer science perspective, I’d say it was the computational vision company. In there, it really wasn’t simple. For instance, a big part of the work when we developed a new system was to come up with a mathematic model of how you were going to perform your measurements. A simple example is to measure the radius of a bar, like an anti-roll suspension bar, for example. You have the image from the camera, but according to the angle and distance of the camera, what you see in the camera’s image is only the apparent radius – the real radius depends on the distance of the camera, because there may be parts of the bar hidden behind the bar itself. So you have to make a mathematical model to convert the apparent radius into the real radius, given the distance between the bar and the camera and fixed information from the scene. A significant part of the work there was about mathematical models that were used to generate the outputs.
Another aspect there was the integration with industrial systems. The system was connected to the production line. It received a message once a part arrived, and it had to inspect the part and send a message saying whether the part is approved. Then the manufacturer’s control software would activate the appropriate conveyor to handle the part.
And I didn’t mention the computer vision algorithms, I had to work with several of them to handle the scenes. Normally the scene is under a semi-controlled environment. The algorithm runs 24/7, so things vibrate, move, the sun shines on it, sometimes there is reflection, the clarity of the ambience changes a lot. I think in technical terms that job was the most challenging, for involving so many aspects.
WLAD: Great. Another question, in your career as a programmer, have you ever made a big mistake that had to be fixed? What was the most catastrophic mistake you made, and how was it fixed?
Ralmeida: The biggest mistake I ever made…let me see…. Most systems I worked with were web-based, so unless I did things like dropping the database, there weren’t a lot of irreversible things I could do. And I never accidentally dropped a database in a production environment, I’m lucky to never have caused such a catastrophe. I remember I made a few mistakes, sometimes in algorithm design, sometimes silly math omissions, such as forgetting to treat a division by zero.
Most of the mistakes I made were these silly ones, but sometimes any mistake you make, no matter how silly, takes a very long time to fix. Once I forgot a division by zero, so when there was no parts in the conveyor, a zero would get at the algorithm, causing a crash. In these cases the whole production line in the factory halted. I had to open up the laptop to see the algorithm there in the factory with my client, debug it, fix it, recompile it and restart everything. It was a large system, so it took about half an hour to compile. All that happens very close to the foundry oven, so it’s complicated.
Academic Education
WLAD: You’ve applied mathematical models and computer vision algorithms in the real world, so I wanted to ask you, how do you think the university does its job to prepare programmers, not to work as an academic research or as professors, but to fix problems in the industry? Does it prepare you well? What are its good and bad points?
Ralmeida: It depends on the university. I’ll answer considering the best universities, to simplify. Let’s suppose the question is whether the best universities prepare well. I consider UFMG, the university I studied in, to be an example of a good university. If there is a university in the state that prepares the students well, it’s there.
I think there are two great areas where the university can help. First, to really teach the main skill programmers use: coding. You need to learn to program in order to code in the real world. If the university teaches technical skills with enough depth, the student will have a good advantage over those who learn how to code on their own, especially those who don’t challenge themselves so much. If you are well challenged by the university, you will have a very good advantage in the labour market.
Secondly, earning a bachelor’s degree is a huge personal project on its own. To achieve it you have to develop your resilience, delivering projects on time and dealing with difficult things that must be learned in order to progress in the course.
I think learning how to learn is one of the most important things you can get out of college. Even if you were unlucky enough to earn your bachelor’s in something completely unrelated to your life’s work, college still helps. That’s because in there you are learning how to learn, developing your head towards learning, confronting things in fields you’ve never seen, being able to understand and digest it. So college isn’t mandatory, but it helps a lot.
Hiring Coders
WLAD: When you have to hire a programmer or intern to work on your team, what are the factors you consider, or what do you see as indicators that show a candidate has potential?
Ralmeida: To this day, hiring strategies from tech companies are debated. Well-established companies such as Google, Microsoft and others are often criticised regarding their hiring process. Each company has a different one, and it’s hard to say which is right and which is wrong. But one thing is understood to be essential by all tech companies: making sure the candidate knows how to program.
A lot of bigger companies without much hiring experience hire without making sure the candidate knows how to code. Sometimes the hire is only based on the interview with a manager, or worse, with a non-technical manager, or even worse, only with the HR personnel. I don’t know how it is nowadays, but a few years ago I heard stories of that happening. That’s evidently a shot in the dark: you can hire a good guy who really knows how to program, or you can hire someone who passed through the cracks, who has the right keywords in his resume and good communication skills, but when actually confronted with programming challenges, he simply doesn’t know how to act.
So I think the first thing to be done in a programming interview is to ask the person to program, even if it’s like the FizzBuzz problem, which is absolutely simple for anyone who knows how to program, even if only the basics. I think it’s a big surprise that the FizzBuzz test is representative. For a test to be representative, it has to filter out many candidates; if everyone can pass the test it’s a useless one. And the big surprise with the FizzBuzz test is that it is indeed useful: there are a lot of people who can’t pass even such a simple programming test.
WLAD: I don’t know that test. What’s the name of it again?
Ralmeida: FizzBuzz. It’s a very simple test. It’s based on a little game that helps teaching children division. In the game, it goes like this: players count from one and up in turns. For example, if you and I are playing, I say one, you say two, then it goes back to me, etc. But if it’s your turn to say the number it is divisible by three, you say “Fizz” instead of the number. If it’s divisible by five, you say “Buzz”, and if it’s divisible by both, you say “Fizz Buzz”.
The programming test is basically creating a program that plays this game with itself, printing the numbers or the words. So, the beginning of the output would look like:
1
2
Fizz
4
Buzz…
It’s a simple thing, but some people that call themselves programmers can’t create a program to do this. When I was taking part in the hiring process in our company (the one that works with digital interactions), we used tests that were a bit more complex, that involved simple graph algorithms, because these are very important in gaming.
Even if you don’t have the budget or the time to apply a more elaborate test to your candidates, you should ask the guy to program at least something simple in the interview, even if only on paper or whiteboard. It’s also important to assess the cultural fitness of the person, how excited he or she is about the job, how well he or she would relate with future co-workers. The cultural fit is something abstract; it’s up to the person conducting the interview to “feel” if the candidate will work well or not.
These are the two important points: first, be sure that the person knows how to program, even if only on the whiteboard, even if only by a phone call, and second, investigate the candidate’s cultural fitness in the way you prefer.
WLAD: Are you studying something related to IT or programming right now?
Ralmeida: Yes, I’m looking at some new stuff. I’m starting to play around with WordPress. Despite the fact that it’s very powerful, I had never stopped to learn it. I’m making a few blogs and marketing websites for companies with it. You know, when we learn deeply to program we always have the pride of making things from scratch: open our code editor and start doing it. As time goes on we begin to value things we didn’t code ourselves from scratch. We realize we can learn how to use these tools to save time. I think that’s important. So I started to learn a bit of WordPress. I’ve been studying some theoretical topics too, to keep my mind active: The most recent one has been Markov Models, in order to learn some musical algorithms I’m interested in implementing. I also recently studied statistics, to review my basics, and some algorithms to do things with Hidden Markov Models.
WLAD: What’s your favourite programming language for small projects, for a quick hack, something improvised, and why do you like that language?
Ralmeida: For small projects, unless I have a very strong reason not to, I prefer using Python because it’s a highly convenient language. I saw a definition, can’t remember where, that says Python is the pseudo-code that runs. It’s very simple, the language is very expressive, and it’s fun to program in it. Whenever I can, unless there is a strong motivation not to, I go Python.
Coding with Music vs. Noise
WLAD: When you are programming, do you like to listen to music? If yes, what kind, and why? What is the effect you think it makes on your work?
Ralmeida: It depends. The truth is, I use music mostly to control my level of excitement. Sometimes I’m not so engaged with the work, and when I play heavy metal, depending on what I’m doing, it can recharge me. If it’s something that involves a lot of text, sometimes an interface or a documentation task, or sending an email to explain something, listening to music with lyrics isn’t so good for me as it takes away my concentration from the things I have to write. In these cases I play instrumental music, or classical music, or maybe a modern instrumental, such as Yngwie Malmsteen. Basically it’s that. Many people use music to help concentrating too. With me it doesn’t always work. When the environment is noisy or if it’s hard to concentrate for any reason, I prefer using white noise or Brownian noise, because it muffles external sounds, letting you concentrate.
WLAD: Wow, where do you get this white noise from?
Ralmeida: I use a website called Simply Noise, but there are countless apps and sites for that too. I don’t like the white noise itself so much because it has a higher pitch, and it’s wheezier. Brownian noise is a bit better. It has an overall lower frequency, so it doesn’t block all sounds, such as phones ringing or dogs barking too high; it can’t mask these. But the sound of people talking lies exactly in the frequency range this noise has, so it totally disappears. It’s quite a pleasant noise to hear. It sounds a lot like the noise from the rain, I like it.
WLAD: I don’t have any experience with Brownian noise; I’ll try it later. I’ve seen interesting research concluding people get more creative working with noise than in complete silence.
Ralmeida: Man, I use noise for a lot of stuff. To concentrate in noisy environments, to sleep in noisy environments, it’s a wonder.
The Bottomline
WLAD: We covered a lot of stuff, do you have any final tips to give to our readers, a tip for someone who is beginning their careers?
Ralmeida: For people who are starting their careers, I think the most important is to get practice and learn to evolve alone. Self-learning is something really present in our profession.
There is an article, I don’t remember the source, which discusses the differences between the skills you learn just in case, and just in time. Just in case are those things you learn, for example, in college. You are going to learn Calculus I, II and II, and probably you’ll never use it directly in your job. When you are in a company that uses a framework you don’t know, and you learn the framework to use it, that’s an example of just in time learning. Both skills have their advantages. You learn the just-in-case ones to expand your mind, increasing your capacity to learn hard things, and that’s something that helps learning just-in-time skills too. So don’t neglect learning things you find interesting, even if you don’t see immediate direct practical applications for them in your daily routine. Learning them is going to improve your mental skills, your mental agility, so later on you can learn the stuff you need more efficiently.
If you are still beginning, read a lot of code. Today it’s really easy to get interesting code; we have very complex projects freely available in Github, for example. Reading code is very important but that’s often neglected, especially by novice programmers. You will have to use that ability, even though many times you won’t want to.
Usually when a programmer picks some code that isn’t his, he feels an almost supernatural force of wanting to rewrite it, to make it look the way he thinks is best. And many times, unless that is done in controlled refactoring, doing that on a large scale is a bad idea – history shows it. Take Netspace, for instance. They decided to rewrite their web browser engine from scratch, and because of this, they lost important market timings. Learn how to deal with the not-invented-here syndrome – that’s something very important.
When coding, you have a mental model in your head, and you pass it on to the code. Reading code it’s the opposite: you have to figure out what the mental model from the person who wrote it was, at the time it was being written. That is a skill you must practice whenever you can; it’s going to be very useful for your career.
Learn how to evolve your programming skills alone. On many websites, like Project Euler and Google Code Jam, you can pick some problems which are a bit more complicated that are going to twist your head. And that will save your skin many times later, because you’ll learn the patterns and where you can use them.
If you haven’t received formal teaching in computer science, maybe learn the most common data structures, so you can recognize when they can be useful so you can apply them. If you’ve already learned them, move on to other fundamentals, such as basic algorithms, architecture, parallel programming, etc. And always try to practice, for example, in Project Euler; it’s a great opportunity.
