The freeCodeCamp Podcast

Canadian software engineer Bill Sourour recounts a tragic experience early in his developer career when writing code for a pharmaceutical company. He explores developer ethics, the responsibilities developers have, and the challenges they face in sticking to their values.   Written by and read by Bill Sourour: https://twitter.com/billsourour   Original Article: https://medium.freecodecamp.org/the-code-im-still-ashamed-of-e4c021dff55e    The Future of Programming by Bob Martin: https://youtu.be/ecIWPzGEbFc    Business Insider Story: "Programmers are having a huge discussion about the unethical and illegal things they’ve been asked to do” http://www.businessinsider.com/programmers-confess-unethical-illegal-tasks-asked-of-them-2016-11?op=1   CBC Interview http://www.cbc.ca/radio/the180/stop-subsidizing-seniors-good-judges-can-make-bad-decisions-and-which-canadian-city-is-the-most-american-1.4028473/creating-a-code-of-ethics-for-coders-1.4028677   Code Newbie Interview https://www.codenewbie.org/podcast/the-ethics-of-coding   Developer Ethics on FCC Guide https://guide.freecodecamp.org/developer-ethics   Learn to code for free at: https://www.freecodecamp.org   Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q   Transcript: 

If you write code for a living, there’s a chance that at some point in your career, someone will ask you to code something a little deceitful – if not outright unethical.

This happened to me back in the year 2000. And it’s something I’ll never be able to forget.

I wrote my first line of code at 6 years old. I’m no prodigy though. I had a lot of help from my dad at the time. But I was hooked. I loved it.

By the time I was 15, I was working part-time for my dad’s consulting firm. I built websites and coded small components for business apps on weekends and in the summer.

I was woefully underpaid. But as my dad still likes to point out, I got free room and board, and some pretty valuable work experience.

Later, I managed to help fund a part of my education through a few freelance coding gigs. I built a couple of early e-commerce sites for some local small businesses.

By age 21, I managed to land a full-time coding job with an interactive marketing firm in Toronto, Canada.

The firm had been founded by a medical doctor and many of its clients were large pharmaceutical companies.

In Canada, there are strict limits on how pharmaceutical companies can advertise prescription drugs directly to consumers.

As a result, these companies would create websites that present general information about whatever symptoms their drugs were meant to address. Then, if a visitor could prove they had a prescription, they were given access to a patient portal with more specific info about the drug.

The home page of edfactscanada.com circa 2001, via The Internet Archive

One of the projects I was assigned to involved a drug that was targeted at women. The graphics and general style of the website made it clear that the client wanted to specifically target teenage girls.

One of the features of this website was a quiz that asked girls a series of questions and recommended a type of drug based on their answers.

Remember, this website was posing as a general information site. It was not clearly an advertisement for any particular drug.

When I received the requirements, they contained the questions for the quiz, along with multiple choice answers for each question.

Missing from the requirements was any indication of what I should do with the answers at the end of the quiz. So what rules determined what treatment the quiz would recommend?

I spoke to the Account Manager about this. She emailed the client and got me the requirements. With those, I proceeded to code up the quiz.

Before submitting the website to the client, my project manager decided to give it a quick test. She tried the quiz, then came over to my desk:

“The quiz doesn’t work,” she said.

“Oh. What’s broken?” I asked.

“Well, it seems that no matter what I do, the quiz recommends the client’s drug as the best possible treatment. The only exception is if I say I’m allergic. Or if I say I am already taking it.”

“Yes. That’s what the requirements say to do. Everything leads to the client’s drug.”

“Oh. Okay. Cool.”

And she was off.

I wish I could tell you that when I first saw those requirements they bothered me. I wish I could tell you that it felt wrong to code something that was basically designed to trick young girls. But the truth is, I didn’t think much of it at the time. I had a job to do, and I did it.

Nothing that we were doing was illegal. As the youngest developer on my team, I was making good money for my age. And in the end, I understood that the real purpose of the site was to push a particular drug. So, I chalked this tactic up to “marketing.”

The client was extremely pleased with the site. So much so that their rep invited me and the entire team out to a fancy steak dinner.

The day of the dinner, shortly before leaving the office, a colleague emailed me a link to a news report online. It was about a young girl who had taken the drug I’d built the website for.

She had killed herself.

It turned out that among the main side effects of that drug were severe depression and suicidal thoughts.

The colleague who had emailed me didn’t show up to dinner.

I still went. It was difficult and awkward. I never mentioned the news report. I just ate my steak quietly and tried to force a smile when I could.

The next day, I called my sister. She was 19 at the time. We had discovered while working on the project that she had actually been prescribed the very drug I was building a site for.

When we first talked about it, we thought the whole thing was a neat coincidence. Now, the tone of our conversation was very different. I advised her to get off the drug ASAP. Thankfully, she listened.

There are a million and one ways for me to rationalize my part in later suicides and severe depression. Even today, there is ongoing litigation with former patients.

It’s easy to make an argument that I had no part in it at all. Still, I’ve never felt okay about writing that code.

Not long after that dinner, I resigned.

As developers, we are often one of the last lines of defense against potentially dangerous and unethical practices.

We’re approaching a time where software will drive the vehicle that transports your family to soccer practice. There are already AI programs that help doctors diagnose disease. It’s not hard to imagine them recommending prescription drugs soon, too.

The more software continues to take over every aspect of our lives, the more important it will be for us to take a stand and ensure that our ethics are ever-present in our code.

Since that day, I always try to think twice about the effects of my code before I write it. I hope that you will too.

Quincy reads his popular article on how to choose your first programming language when you learn to code.

He discusses Python, Java, JavaScript, Ruby, and C++ in terms of:

- the job market for the language - the long term prospects for the language - how easy the language is to learn - what projects you can build while you’re learning (and share with friends so you can stay motivated)

Read by Quincy Larson (https://twitter.com/ossia)

Article link: https://fcc.im/2yCMatt

Learn to code for free at: https://www.freecodecamp.org

Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q

Transcript:

Most people’s journey toward learning to program starts with a single late-night Google search.

Usually it’s something like “Learn ______”

But how do they decide which language to search for?

“They always joke about Java on Silicon Valley. I guess I should learn that.”

Or:

“Haskell. So hot right now. Haskell.”

Or:

“That Go gopher is just so gosh-darn cute.”

And then there’s the rest of us. We’ll probably search for something like:

“Which programming language should I learn first?”

Few questions are so commonly asked that they get the full infographic treatment. But this is one of them:

Deciding on your first programming language can be a fun process — kind of like one of those “Which Quentin Tarantino character are you?” personality quizzes.

But before you run off to learn Ruby because you enjoyed playing with Play-Doh as a kid, let me remind you: the stakes are pretty high here.

It will take you hundreds of hours of practice to become even remotely competent with your first programming language.

So you should consider the following factors:

- the job market for the language

- the long term prospects for the language

- how easy the language is to learn

- what projects you can build while you’re learning (and share with friends so you can stay motivated)

Every year brings new programming languages, and with them, new academic papers. And new web comics.

Seriously. Check out this gem from last month:

When it comes to choosing a first programming language, there’s no shortage of options. To narrow it down a bit, here are the most common Google searches related to learning programming, over the past 12 years:

Java has had its ups and downs.

Python has gradually risen to become the most popular choice.

But tucked away below these is the Little Engine That Could, slowly choo-choo’ing up in popularity over the past few years. And that engine is JavaScript.

Before I talk about these programming languages, let me clarify:

I’m not arguing that any one language is objectively better than any other

I agree that developers should eventually learn more than one language

I’m arguing that first they should learn one language well. And — as you can probably guess from the upside down text in my headline — that language should be JavaScript.

Let’s kick things off by exploring how programming is currently taught in school.

Computer Science 101

Universities have traditionally taught programming under the umbrella of computer science, which itself is often seen as an extension of mathematics, or tie-in to an electrical engineering degree.

Of course, as you may have heard by now:

“Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter.” — Eric S. Raymond

As of 2016, many universities still treat programming like it’s computer science, and computer science like it’s math.

As a result, many introductory programming courses focus on low-level-of-abstraction languages like C, or mathematically-focused languages like MATLAB.

And department chairs generally stay the course, pointing to annual programming language leaderboards like the TIOBE Index, or this one from the IEEE:

Most of these leaderboards look virtually identical to how they were 10 years ago.

But change does happen. Even in academia.

In 2014, Python overtook Java as a the most popular language of instruction at top US Computer Science programs.

And yet another change is bound to… eventually… happen.

Because if you look at the languages actually used by the workforce, it paints a very different picture:

JavaScript is by far the most popular language used by the 49,397 developers who responded to Stack Overflow’s 2016 Survey.

More than half of all developers use JavaScript. It’s vital to front-end web development and increasingly relevant for back-end development. And it’s rapidly expanding into areas like game development and the Internet of Things.

Job postings also mention JavaScript more than any programming language other than Java:

Data from the world’s largest job posting aggregator, Indeed.com

It’s no accident that we built our open source community’s curriculum around JavaScript. Over the past two years, more than 5,000 people have used Free Code Camp to get their first developer job.

I’m not advocating JavaScript because I teach it. I teach JavaScript because it’s the surest path to a first developer job.

But is JavaScript right for you? Is it worthy of being your first programming language? Let’s explore those factors I mentioned earlier.

Factor #1: The job market

If you’re learning to program purely out of intellectual curiosity, feel free to skip this factor. But if you — like the vast majority of people learning to program — want to use this skill to get a job, this is an important consideration.

As I mentioned earlier, Java is mentioned in more job postings than any other programming language. JavaScript is a close second.

But here’s the thing about JavaScript: even though it’s been around for 20 years, it only recently became a serious tool that companies like Netflix, Walmart, and PayPal would build entire applications around.

As a result, plenty of companies are hiring JavaScript developers, but there just aren’t that many on the job market.

There are 2.7 Java developers competing for every open Java position. Competition for PHP and iOS jobs is similarly fierce.

But for every open JavaScript position, there are only 0.6 JavaScript developers. It is very much a sellers’ market for developers with JavaScript skills.

Factor #2: The long term prospects

The average JavaScript project receives twice as many pull requests as the average Java, Python, or Ruby project. And on top of this, JavaScript is growing faster than any other popular language.

Source: The GitHub’s 2016 State of the Octoverse

JavaScript’s ecosystem also benefits from a heavy investment of money and engineering talent from companies like Google, Microsoft, Facebook, and Netflix.

For example, TypeScript (a statically-typed superset of JavaScript) has more than 100 open source contributors, many of whom are Microsoft and Google employees being paid to work on it.

This type of inter-company cooperation is harder to find with Java. Oracle — who effectively owns Java through its acquisition of Sun Microsystems — often sues companies who try to expand upon it.

Factor #3: Difficulty to learn

This is a parody of an XKCD comic.

Most programmers would agree that high-level scripting languages are relatively easy to learn. JavaScript falls into this category, along with Python and Ruby.

Even though universities still teach languages like Java and C++ as first languages, they’re considerably harder to learn.

Factor #4: Projects you can build with it

This is where JavaScript really shines. JavaScript runs on any device that has a browser, right there in the browser. You can build basically anything with JavaScript, and share it anywhere.

Because of JavaScript’s ubiquity, Stack Overflow co-founder Jeff Atwood coined his now-famous law:

“Any application that can be written in JavaScript, will eventually be written in JavaScript.”

And with each passing month, Atwood’s Law holds strong.

Java once promised to run everywhere, too. You may remember Java Applets. Oracle officially killed them off earlier this year.

Python suffers from much the same problems:

“How can I give this game I made to my friend? Even better, is there a way can I put this on my phone so I can show it to kids at school without them having to install it? Um.” — James Hague in Retiring Python as a Teaching Language

By contrast, here are some apps that members of our open source community built in their browsers on CodePen. You can click through and use these right in your browser:

- 1970s style Simon game

- Conway’s Game of Life

- Star Wars-themed Wikipedia Search

- A roguelike dungeon crawler game

Learn one language well. Then learn a second one.

If you keep jumping from language to language, you won’t get far.

In order to move beyond the basics, you need to learn your first language well. Then your second language will be much, much easier.

From there, you can branch out, and become a more well-rounded developer by learning lots of languages:

C is a great way to learn how computers actually work in terms of memory management, and is useful in high-performance computing

C++ is great for game development.

Python is awesome for science and statistics.

Java is important if you want to work at large tech companies.

But learn JavaScript first.

OK, now I’m going to attempt the impossible — I’m going to try and anticipate objections from the comments section.

Objection #1: But isn’t JavaScript slow?

JavaScript is — for most practical purposes — as fast as high-performance languages.

JavaScript (Node.js) is orders of magnitude faster than Python, Ruby, and PHP.

It is also nearly as fast as high-performance languages like C++, Java, and Go.

Here are the results of the most comprehensive recent cross-language benchmark:

Objection #2: But JavaScript isn’t statically typed

Like Python and Ruby, JavaScript is dynamically typed, which is convenient. But you can get into trouble. Here I intend for exampleArray to be an array. I set its values, then check its length — meaning the number of elements it contains.

exampleArray = [1, 2] -> [1, 2] exampleArray.length -> 2

But then I accidentally assign it to be a string.

exampleArray = “text” -> “text” exampleArray.length -> 4

These kinds of errors happen all the time in dynamically typed languages. Most developers just put checks in place to prevent them, and write tests accordingly.

If you absolutely must have static typing in your first programming language, then I still recommend you learn JavaScript first. Then you can quickly pick up TypeScript.

“Typescript has a learning curve, but if you already know JavaScript, it will be a smooth one.” — Alex Ewerlöf on TypeScript

Objection #3: But I really want to make a mobile app

I still recommend learning JavaScript first.

JavaScript features several tools for making native mobile apps, such as Angular Cordova and React Native.

In order for your mobile app to actually do anything interesting, it will probably need a proper back end, which you’ll want to build with a proper web development framework, like Node.js + Express.js.

Also, it’s worth pointing out that the mobile app development’s best days may very well be behind it.

For starters, as much as people use mobile apps, nearly half of all developer jobs are web development. Compare this with a mere 8% of jobs that involve mobile app development.

The occupations of 49,525 developers, based on responses to the 2016 Stack Overflow survey.

The grand vision of “there’s an app for that” has not come to pass. Instead, most smartphone owners have stopped downloading new apps.

Sure — they still use apps. Mostly Facebook, Google Maps, and handful of others. As such, much of the demand for mobile app developers is concentrated in a few large employers.

The outlook for those mobile development jobs is hard to forecast. Many aspects of developing, maintaining, and distributing mobile apps are easier with JavaScript. So companies like Facebook and Google are investing heavily in better tools for building these using JavaScript.

As of 2016, pretty much all development is web development. Everything touches that big platform that is “the web.” And the next wave of devices that you’ll talk to around your home, and cars that pick your kids up from school — they’ll all be piped together using the web, too.

And that means JavaScript.

Objection #4: Isn’t JavaScript a toy language that was written in 10 days?

JavaScript has a quirky history. You will undoubtedly hear people crack jokes at its expense.

Well people love to hate on C++, too. And like JavaScript, C++ has succeeded despite this hate, and now it’s pretty much everywhere as well.

So if anybody ever gives you a hard time for learning JavaScript instead of elite-language-of-the-week, just remember the famous words of the guy who created C++:

"There are only two kinds of programming languages: those people always bitch about and those nobody uses." — Bjarne Stroustrup

Beau talks about his year of incredible productivity, during which he a degree and certifications, and taught himself to code - balancing his studies against an active family life.

Beau's original article: https://fcc.im/2j0vxBr

Read by Beau: https://twitter.com/carnesbeau

Learn to code for free at: https://www.freecodecamp.org

Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q

Transcript:

“The standard pace is for chumps. The system is designed so anyone can keep up. If you’re more driven than ‘just anyone’ — you can do so much more than anyone expects. And this applies to ALL of life — not just school.” — Derek Sivers, founder of CD Baby Learning to code can be challenging — especially when you also have a job and a family with small kids. Despite those things, I decided that the standard pace was not for me.

My goal in writing all this is not to brag — though I am extremely proud of these accomplishments. My goal is to convince you that the standard pace isn’t for you, either.

I’ve done a lot in the past year. I earned two Oracle Java Certifications, two CompTia Certifications, and freeCodeCamp’s Front End Certification. Each of these take most people many months of preparation, but I did them all in three weeks each.

And last but not least, I completed all the coursework necessary to earn a second Bachelor’s degree in software development from an accredited university, in less than six months.

I did this all while working full-time, spending time regularly with my wife and two young kids, and volunteering in my community.

One of the keys to accomplishing all of this was an amazing and supportive spouse. 😍

But there were also some other things that helped.

What’s Your Motivation?

After being a K-12 teacher for five years, I realized I did not want to teach in a school the rest of my life.

I loved the teaching part of teaching, but I hated the forcing-kids-to-do-things-they-don’t-want-to-do part of teaching. Classroom management in my urban school district was very stressful for me. I was also becoming disenchanted with the whole educational system. We seem to be preparing students for jobs that will no longer exist.

I had always been interested in coding and even sometimes taught my students basic coding using Scratch and Code.org. I decided it was time to learn enough to do it full-time.

Wanting a new job was great motivation. Everyday I spent at my teaching job was an incentive to keep pushing myself towards my goal.

Research, research, research

It’s important not to rush into learning. Not all schools or learning resources are equal, and the wrong choice can make a big difference in your ability to meet your goals.

I tried to determine what learning method would work best for me and my family. While I know there are many ways to break into the tech industry, I decided on a somewhat traditional route: a Bachelor’s degree. I knew I had some classes already that would transfer into a new program. I looked into many school options but I decided on Western Governors University for the following reasons:

It is all online so I would not have to take time from my family for transportation. You can work at your own pace, so I knew I could finish very quickly. As soon as you finish all the assignments and exams for one class, you can go immediately to the next class. The cost is low — about $3000 per six months. It is reputable, accredited, and has been recommended by President Obama and Bill Gates. The degree included industry recognized certifications. I knew those would add to the credibility of my education. Beating ambitions goals

At first, my goal was to finish my entire Bachelor’s degree in one year. One month into the program, I decided to revise my goal and finish in six months.

It was at this point that I did what helped me most in my goal to finish quickly: I made a schedule of the exact day I would finish each class so I could finish within 6 months.

I scheduled between 1 and 3 weeks for each class, depending on class requirements. I also made plans at that time about how I would finish each class very quickly. It was very helpful to have many subgoals throughout the learning process to make sure I stayed on track.

 

Section of actual spreadsheet I used to plan for classes.

Ambitious goals are important. These provided me additional motivation to push myself. A study by the Journal of Consumer Research showed that ambitious goals make people happier. I ended up meeting or surpassing all my self-imposed deadlines and that definitely made me happy!

Detailed schedule

I created a detailed weekly schedule to help me spend a lot of time learning without neglecting my family and other responsibilities. I scheduled in family time, volunteering time, time with friends, and even a weekly date night!

 

The schedule I created at the beginning of my degree. I have an even more detailed schedule now.

A detailed schedule helped me make sure that my life stayed balanced. However, there is one thing I did not put on my schedule: television.

I watched only 3 episodes of television the entire time I worked on my degree. I had such a tight schedule to keep so I could meet my goals so I did not have time for TV. Also, any time spent watching television meant less time with my family. Since graduating, I have continued to limit television so I can focus on coding.

It was important for me to give things up in order to accomplish my goals.

Ignore the haters!

Every student at Western Governors University is assigned a mentor. Students have weekly calls with their mentors to help keep them on track. Whenever I shared my goals with my mentor she tried to encourage me to be a little more reasonable.

Well, instead of being more reasonable I decided to set more ridiculous goals. I know she had good intentions but I decided to ignore her warnings and stopped sharing my goals with her.

I have found that it is sometimes helpful to not share goals with certain people if they are not going to be encouraging.

Maximizing time

Besides my scheduled time to learn software development, I also found ways to fit in even more studying. For instance, I used most of my lunch breaks to study. Also, I often carried notes in my pocket that I could review whenever I had a free moment.

Another thing I did (and still do) was to take days off my teaching job to work on my classes or programming projects. While completing my degree, I planned my days off to line up in my schedule when I knew I had harder classes to pass.

I try to be constantly reevaluating my schedule and how I spend my time so I can have greater effectiveness.

I used to code a lot after my kids went to bed. However, I noticed that by the end of the day, my brain just did not work as well. I switched up my sleep schedule so I now go to bed around 9pm and wake up at 4am to code (and create training videos). This may sound a little crazy but it has greatly increased my productivity.

Learn what others do

I spent a lot of time on the Reddit page for my college and various forums reading about what others did that helped them with their classes. For the industry certifications, there were even more resources available to help. This allowed me to better plan the quickest way to finish.

There is almost always someone out there who has gone before you, and it’s important to identify them and learn from them.

Learning from others was also very helpful while going through the freeCodeCamp curriculum. Experienced people in the community are always willing to help or offer suggestions in their forums and community chat rooms.

Just ship it!

 

Shipping means to send out a completed product.

There were many times when I wondered if I needed to put in more time working on projects or studying. Then I would realize that I didn’t have time if I wanted to meet my self-imposed deadlines.

My deadlines forced me to act before I felt completely ready, and this definitely paid off.

I’ve found that it’s more important to get projects out there than to make them perfect. If you try to make sure everything is just right, you may never finish. When in doubt, just ship it!

The 80/20 Rule

 

The 80/20 rule states that for many events, roughly 80% of the effects come from 20% of the causes. When learning software development, this means that about 20% of the learning content will contain about 80% of what you will actually use. You can save a lot of time if you just focus on the top 20%.

For my degree, I only read between 20–30% of the required content. According to the 80/20 rule, this was enough to understand over 80% of the subject matter.

The trick is determining which 20% to focus on. I would often ask myself, “If I were designing the exam, would I include this material?”

Really, when learning anything, you should ask yourself if it is part of the 20% of learning content that will give you 80% of value.

This relates to the idea of just-in-time information. It’s usually not beneficial to learn something that you don’t plan to use in the near future, especially when your memory is as bad as mine. 😊 When working on projects I try to learn what I will need just for that project.

Employers often care more about projects you’ve created than how you learned to code. Keeping this fact in mind will help you decide how to best use your time.

Keeping things moving forward

I didn’t take any time off from learning once my degree was finished. I realized the importance of projects, so I went straight into freeCodeCamp and started creating personal projects to build up my portfolio. I was able to continue to apply all of the strategies that I used while completing my Bachelor’s degree.

I also continued to use these strategies when I decided to start creating JavaScript training videos. Now I’m posting JavaScript training videos almost every day on the freeCodeCamp YouTube channel.

If you’re interested in the specific things I did for each class to finish my WGU degree quickly, you can check out this blog post.

I hope some of the strategies I used can also be helpful to you, even if your life is as busy as mine.

Remember: the standard pace is for chumps. You can do better!

Cecily Carver, a developer at Google, recounts her coding journey and the many lessons she learned along the way. Read by Ava.

Cecily's article: https://fcc.im/2A5kphQ

Read by Ava: https://twitter.com/avasond

Learn to code for free at: https://www.freecodecamp.org

Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q

 

Transcript:

Before you learn to code, think about what you want to code

Knowing how to code is mostly about building things, and the path is a lot clearer when you have a sense of the end goal. If your goal is “learn to code,” without a clear idea of the kinds of programs you will write and how they will make your life better, you will probably find it a frustrating exercise.

I’m a little ashamed to admit that part of my motivation for studying computer science was that I wanted to prove I was smart, and I wanted to be able to get Smart Person jobs. I also liked thinking about math and theory (this bookblew my mind at an impressionable age) and the program was a good fit. It wasn’t enough to sustain me for long, though, until I found ways to connect technology to the things I really loved, like music and literature.

So, what do you want to code? Websites? Games? iPhone apps? A startup that makes you rich? Interactive art? Do you want to be able to impress your boss or automate a tedious task so you can spend more time looking at otter pictures? Perhaps you simply want to be more employable, add a buzzword to your resume, or fulfill the requirements of your educational program. All of these are worthy goals. Make sure you know which one is yours, and study accordingly.

There’s nothing mystical about it

Coding is a skill like any other. Like language learning, there’s grammar and vocabulary to acquire. Like math, there are processes to work through specific types of problems. Like all kinds of craftsmanship and art-making, there are techniques and tools and best practices that people have developed over time, specialized to different tasks, that you’re free to use or modify or discard.

This guy (a very smart guy! Whose other writings I enjoy and frequently agree with!) posits that there is a bright line between people with the True Mind of a Programmer and everyone else, who are lacking the intellectual capacity needed to succeed in the field. That bright line consists, according to him, of pointers and recursion (there are primers here and here for the curious).

I learned about pointers and recursion in school, and when I understood them, it was a delightful jolt to my brain — the kind of intellectual pleasure that made me want to study computer science in the first place. But, outside of classroom exercises, the number of times I’ve had to be familiar with either concept to get things done has been relatively small. And when helping others learn, over and over again, I’ve watched people complete interesting and rewarding projects without knowing anything about either one.

There’s no point in being intimidated or wondering if you’re Smart Enough. Sure, the more complex and esoteric your task, the higher the level of mastery you will need to complete it. But this is true in absolutely every other field. Unless you’re planning to make your living entirely by your code, chances are you don’t have to be a recursion-understanding genius to make the thing you want to make.

It never works the first time

And probably won’t the second or third time

When you first start learning to code, you’ll very quickly run up against this particular experience: you think you’ve set up everything the way you’re supposed to, you’ve checked and re-checked it, and it still. doesn’t. work. You don’t have a clue where to begin trying to fix it, and the error message (if you’re lucky enough to have one at all) might as well say “fuck you.” You might be tempted to give up at this point, thinking that you’ll never figure it out, that you’re not cut out for this. I had that feeling the first time I tried to write a program in C++, ran it, and got only the words “segmentation fault” for my trouble.

But this experience is so common for programmers of all skill levels that it says absolutely nothing about your intelligence, tech-savviness, or suitability for the coding life. It will happen to you as a beginner, but it will also happen to you as an experienced programmer. The main difference will be in how you respond to it.

I’ve found that a big difference between new coders and experienced coders is faith: faith that things are going wrong for a logical and discoverable reason, faith that problems are fixable, faith that there is a way to accomplish the goal. The path from “not working” to “working” might not be obvious, but with patience you can usually find it.

Someone will always tell you you’re doing it wrong

Braces should go on the next line. Braces should go on the same line. Use tabs to indent. But tabs are evil. You should use stored procedures, but actually you shouldn’t use them. You should always comment your code. But good code doesn’t need comments.

There are almost always many different approaches to a particular problem, with no single “right way.” A lot of programmers get very good at advocating for their preferred way, but that doesn’t mean it’s the One True Path. Going head-to-head with people telling me I was Wrong, and trying to figure out if they were right, was one of the more stressful aspects of my early career.

If you’re coding in a team with other people, someone will almost certainly take issue with something that you’re doing. Sometimes they’ll be absolutely correct, and it’s always worth investigating to see whether you are, in fact, Doing It Wrong. But sometimes they will be full of shit, or re-enacting an ancient and meaningless dispute where it would be best to just follow a style guide and forget about it.

On the other hand, if you’re the kind of person who enjoys ancient but meaningless disputes (grammar nerds, I’m looking at you), you’ve come to the right place.

Someone will always tell you you’re not a real coder

HTML isn’t real coding. If you don’t use vi, you’re not really serious. Real programmers know C. Real coders don’t do Windows. Some people will never be able to learn it. You shouldn’t learn to code. You’re not a computer programmer (but I am).

“Coding” means a lot of different things to a lot of different people, and it looks different now from how it used to. And, funnily enough, the tools and packages and frameworks that make it faster and easier for newcomers or even trained developers to build things are most likely to be tarred with the “not for REAL coders” brush. (See: “Return of the Real Programmer”)

Behind all this is the fear that if “anyone” can call themselves a programmer, the title will become meaningless. But I think that this gatekeeping is destructive.

Use the tools that make it easiest to build the things you want to build. If that means your game was made in Stencyl or GameMaker rather than written from scratch, that’s fine. If your first foray into coding is HTML or Excel macros, that’s fine. Work with something you feel you can stick with.

As you get more comfortable, you’ll naturally start to find those tools limiting rather than helpful and look for more powerful ones. But most of the time, few people will ever even look at your code or even ask what you used — It’s what you make with it that counts.

Worrying about “geek cred” will slowly kill you

See above. I used to worry a lot, especially in school, about whether I was identifying myself as “not a real geek” (and therefore less worthy of inclusion in tech communities) through my clothing, my presentation, my choice of reading material and even my software customization choices. It was a terrible waste of energy and I became a lot more functional after I made the decision to let it all go.

You need to internalize this: your ability to get good at coding has nothing to do with how well you fit into the various geek subcultures. This goes double if you know deep down that you’ll never quite fit. The energy you spend proving yourself should be going into making things instead. And, if you’re an indisputable geek with cred leaking from your eye sockets, keep this in mind for when you’re evaluating someone else’s cred level. It may not mean what you think it does.

Sticking with it is more important than the method

There’s no shortage of articles about the “right” or “best” way to learn how to code, and there are lots of potential approaches. You can learn the concepts from a book or by completing interactive exercises or by debugging things that others have written. And, of course, there are lots of languages you might choose as your first to learn, with advocates for each.

A common complaint with “teach yourself to code” programs and workshops is that you’ll breeze happily through the beginner material and then hit a steep curve where things get more difficult very quickly. You know how to print some lines of text on a page but have no idea where to start working on a “real,” useful project. You might feel like you were just following directions without really understanding, and blame the learning materials.

When you get to this stage, most of the tutorials and online resources available to you are much less useful because they assume you’re already an experienced and comfortable programmer. The difficulty is further compounded by the fact that “you don’t know what you don’t know.” Even trying to figure out what to learn next is a puzzle in itself.

You’ll hit this wall no matter what “learn to code” program you follow, and the only way to get past it is to persevere. This means you keep trying new things, learning more information, and figuring out, piece by piece, how to build your project. You’re a lot more likely to find success in the end if you have a clear idea of why you’re learning to code in the first place.

If you keep putting bricks on top of each other, it might take a long time but eventually you’ll have a wall. This is where that faith I mentioned earlier comes in handy. If you believe that with time and patience you can figure the whole coding thing out, in time you almost certainly will.

 

We conclude the tale of Alvaro Videla, who learned to code, got a job as a developer, and is now facing his first week on the job in Montevideo, Uruguay. He eventually went on to get jobs at Apple and other tech companies, but this is where he got his start.

 

Article by Alvaro Videla: https://fcc.im/2zJX3gN

Read by Quincy Larson: https://twitter.com/freecodecamp

Learn to code for free at: https://www.freecodecamp.org

Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q

 

Transcript: 

The Technical Interview

The programmer who was interviewing me explained how things would go, that I was going to walk right into their offices, get my own desk, and program at one of their computers, with everybody else just doing their jobs, since “that’s how it’s going to be if you join us.” I thought that was pretty cool already. And just like he said, once I got into the office, everybody said hello and continued doing their jobs. Even though I wasn’t close to getting the job, I was already starting to feel like a part of something.

The test consisted of building a website to list books for an imaginary library. It seemed simple enough: connect to a database, fetch a list of books, and display them on a webpage, with the buttons for the usual actions for adding books, deleting them, and updating their information. “I can do that,” I thought.

While I was focusing on the test, behind me were programmers who were splitting their time between working on their tasks and playing with tennis balls in a very particular way: they were throwing them at each other, with a lot of force, up to the point where one shot hit the reset button of one of the computers and one guy lost what he was doing on his editor. “That’s a strange way to work, but it’s kinda cool,” I thought. I had expected a more formal working environment, but was pleasantly surprised at how relaxed the environment was.

Meanwhile, halfway through my implementation, I got stuck. I couldn’t get my code to print the list of books, and nothing was showing up on the screen. “How do I get out of this one?” I wondered. I tried to debug it by adding print statements here and there, but that didn’t work, and I had no idea what was going on. The clock was ticking away, and I was starting to get really desperate. “Come on,” I told myself. “I can’t miss this opportunity because of this problem. What do I do? Should I ask for help? What if this disqualifies me instantly?”

I thought about it some more. “I guess they help each other during work,” I reasoned. “OK, whatever, I’m going to ask for help.” I called the interviewer over and talked him through my problem, trying to explain everything I had tried so far, so he wouldn’t think I was cheating him into giving me an answer. Lucky for me, he also had no idea what was going on, so he told me it was fine and that I could leave it as it was.

Unfortunately, I had used too much time on this debugging session so I didn’t have enough time to complete the second part of the test. Later on, I would value this lesson, since I saw that asking for help earlier would have saved a lot of time later — time that in this particular case was critical for me. And in the future, it could be critical for the company I would end up working for.

I didn’t want to ask for extra time to try to solve the next problem, since I thought that wasn’t fair. I wanted to play by the rules, because I felt it was the right thing to do. As we’ll see later, I think that decision paid off.

In the meantime, I had the second problem in front of me and I had to do something about it. I skimmed through it and saw that it was about parsing URLs out of some log files, so I gathered some courage. I put my most convincing face and told the guy that while I understood my time was up, the solution was a matter of just “splitting these lines by these characters, and then going with the URL splitting by using this and that character.” The guy nodded, and told me that indeed that was the solution. Then he said that the interview was over, and he asked me if I had any questions about the company or if there was something I wanted to add.

Later on, I would value this lesson, since I saw that asking for help earlier would have saved a lot of time later “Well, now that you ask, yes,” I began. “I’ve been building this mapping application that I want to show you…” This was my opportunity to shine. I typed the website URL on the computer in front of us and started to pray to every god out there for it to load without problems. “Please, just this one time,” I thought. And as every element from the website finished loading, my anxiety decreased and my excitement increased. The creation I was most proud of was there, right in front of my eyes, and more importantly, in front of the eyes of the person who would decide if I had a job or not.

I went through every feature of the app, explaining with passion the goal of the app, which features it had, and which features it lacked but that I knew I had to implement to have a clear business case.

After a demo, he seemed impressed by Aleph Maps and gave me kudos for it, which made me happy I’d had the chance to run the demo for him and gone ahead with it. This showed me that all the demos I had run for various members of my family and for my friends had been worthwhile, since when it mattered, I was able to show that I could not only build things on my own, but also that I was good at explaining things.

By then it was around 6 p.m. — time for them to call it a day, and for me to get back home. As we were leaving the building together, I asked the man who conducted my tests if he was attending university, because perhaps he knew my friend who had told me about this job opportunity. “Oh yeah, I know your friend, why didn’t you mention him before?” he asked. I didn’t answer, but the fact was that I didn’t want to bring it up and use it to my advantage during the interview. But in any case, it didn’t hurt afterward. He showed me how to get public transport back to the bus terminal and then we parted ways.

Once on my own, I couldn’t believe I was done with the interview. Everything I had prepared for in the last two months had passed in what felt like the blink of an eye. All the stressing out about the little details — some that mattered, some that didn’t — was gone. Now it was me and Montevideo, and the streets crowded with people going back to their homes, and the cars, and the night falling over the city. I’d done it.

Once I had processed all of it, the worst part came. It was time to take the bus and head home to wait for an answer, and waiting is something I’m really bad at. But that’s what it became. Waiting while staring at the ceiling of our room, wondering with my wife how our lives would change if I got the job. Waiting while looking at my books without knowing if I should have kept reading them or not. Waiting while making sure my phone had enough battery power so there would be no missed phone calls. Waiting, until at some point the wait was over, my phone rang, and again it was that number from Montevideo.

“When can you start?” asked the voice on the other end. I was in. Yes, me. They wanted me: the guy who barely knew how to program, but let’s not worry about that now. “They want me,” I told myself, letting it sink in. “I’m in.” The whole gamble had paid off. Finally, after all those years of having jobs that paid nothing, working just because that’s what people do, even if having jobs meant forgetting about our dreams — finally, life was starting to turn around and smile on us, and from one day to the next, we could see a life that was worth living.

I asked for one week to move to Montevideo, so they told me February 26 would be my starting date. “You will be working in PHP and JavaScript. You’re going to earn 15,000 pesos (500 USD) a month.” FIFTEEN THOUSAND PESOS! That was three times what my wife was making! “We are going to be rich!” I thought. I was going to be able to buy as much Coca-Cola as I wanted! We could probably even manage to save $100 per month and buy a house someday. We couldn’t believe what was happening to us.

Finally, life was starting to turn around and smile on us, and from one day to the next, we could see a life that was worth living I spent that week prepping in JavaScript and trying to find a place to stay in Montevideo. A friend hooked me up with his apartment, since he was going to move out after Easter. The rent was good for us, so we decided that in about a month my wife would move to Montevideo and join us. The “apartment” was just one room, plus a kitchen and a small bathroom, and you could only fit two beds and a dining table in there. For a short while, it would be three of us living in that room, but honestly, that didn’t matter to us. I would be starting a new and exciting job, and we would have a place to live. Mission accomplished.

First Week at Work

My first day at work began with a nice twist: the person who conducted the interview was also my new manager. He brought me to office kitchen, we sat down at the table, and he started explaining what the company was doing, what the business model was, and so on. He then proceeded to lay down on a piece of paper depicting what the backend architecture was like, how things worked, what the server was doing, where the database was located, and many other details. I have to be honest: it was hard to follow. I recall hearing the term “production” a couple of times too. “This is our production setup,” “Here’s the production database,” and so on. I had no idea what this production thing he kept talking about was! Later, I learned that production referred to all the infrastructure, including code, that was facing clients and producing income for the company.

We went through a couple of questions and answers here and there, and then came to what was, for me, the most significant part of that day. He looked at me and told me, honest and straight to the point: “We know that you’re not a good programmer, that you are just starting at this, and that you have no experience, so before you’re even able to commit one line of code to our codebase, we need you to study this book,” he said as he handed me a copy of PHP Objects, Patterns, and Practice by Matt Zandstra. “You have to know it by next week.” As straightforward it was, this was some of the most solid, sincere, and helpful feedback I’ve ever received as a programmer. To this day, I thank him for being forthright with me. During my career, I’ve learned how difficult it is to come by a manager who will give you this kind of feedback — feedback that’s useful for understanding your own shortcomings, but at the same time puts you on the right track in order to overcome them.

Then he told me: “We know you are inexperienced, but during the interview you showed yourself as a person with a great attitude. That’s why we hired you.” I was speechless. I wondered what I’d done to deserve such an opportunity. Even more, I knew I had to prove I was worth it, so I set myself a goal of mastering the design patterns book as quickly as possible. First, I couldn’t disappoint my new boss who had taken a chance on me, and second, I finally had an opportunity in the big leagues, at the job I’d worked so hard for. It was time to shine.

“We know you are inexperienced, but during the interview you showed yourself as a person with a great attitude. That’s why we hired you.” Fired After One Week on the Job

During my first week, I studied that book like my life depended on it, because in a way, it did. I tried to learn as many of those design patterns as possible, practicing every example, and I tried to absorb as much knowledge as possible. By the end of the week, I wanted my manager to come to me and tell me, “Now you’re ready to start programming with us.” But as with every tale, this story needed a twist.

That Thursday, some people from the company came and called me to another room to deliver some news: the company was conducting layoffs, and I was among the people being let go. “Nothing personal,” they said. “Business isn’t going too well, and we need to downsize, so we’re letting go of people who just joined the company. We hope you understand.” That day, I was one of around 50 employees who lost their jobs.

I’m not sure I can accurately describe what I felt at that moment. “Why does life has to be like this?” I wondered, feeling somewhat discouraged and helpless. “What do I do now?” I asked to use the phone and called my wife. “Please don’t worry, but I have some bad news…” I began. I tried hard not to lose my composure, but meanwhile, the whole world was coming apart below my feet. All around me were employees coming in from other rooms and bidding farewell to all the people who were just fired, which only made me feel worse. Even so, I tried to convince myself that I shouldn’t despair. I had gotten this far, so it was simply a matter of applying to another job somewhere else.

While I was saying goodbye to my short-lived colleagues, one of them tipped me off about some companies I should apply for, so I took note. From an internet cafe, I sent out job applications to the companies my brand new former colleague gave me, and when I was done, I headed back home.

I tried to convince myself that I shouldn’t despair. I had gotten this far, so it was simply a matter of applying to another job somewhere else. “What a depressing day,” I thought. I entered the apartment and laid down on the bed, which for the record, was just a mattress on the floor. I remember the sky was gray, a perfect match for how I was feeling. I tried to nap, but my mind was lost, staring at the ceiling of that empty apartment and thinking about this new turn of events. “What if I hadn’t been fired?” “What did I do wrong?” I knew I had done nothing wrong. It was just bad luck, but it was hard to accept it.

Suddenly my phone rang.

“Is this Alvaro Videla? I’m calling from Intersys. We received your application and we want to have an interview with you. Is next Monday OK for you?”

“OF COURSE THAT’S FINE WITH ME,” I thought, but instead I said, “Yes, that sounds great, I’ll be there.” As I hung up and placed my phone on the floor, I was in shock, unable to believe what had just happened. Montevideo was a city full of surprises.

The next day I went down the street and asked the barber if he would give me a free haircut, since I had a job interview lined up but I had no money left. I still hadn’t received my salary from the week of work, so I needed a favor in exchange for being paid back the following week. Luckily, he was really happy to help me. I still remember his warm smile; he felt proud he was helping a neighbor get a job. While I was getting the haircut, he shared his story. I learned that in the early 2000s, he and his crew were the winners of some world hairdresser championship! I had no idea there were hairdresser championships. Don’t worry, I couldn’t believe him either back then. Either way, getting a haircut with a “world champion” was cool, but also meant that the service was expensive — $10 to be exact. It doesn’t seem like much, but keep in mind that in my hometown I could get a haircut for less than $2, and $10 could buy me at least five burgers and a soda. That said, it was quite an investment for my next job interview. I couldn’t complain though: a total stranger was doing me a favor when I needed it the most, and that raised my spirits.

The next week came and I had my interview, which went great. The company I was just fired from was Live Interactive, after all, which happened to be well known in Montevideo due to being one of the biggest internet companies in the country. This meant that programmers coming from there were well regarded. Needless to say, I got the job. The salary wasn’t that great, but our plan of moving to the capital was still intact. Not bad for my first 10 days in Montevideo.

Conclusion

All in all, my plan had worked, and all my preparation and study paid off. I got my first job interview as a programmer and then passed it. I was hired and fired in the space of one week, but I didn’t give up and went on to secure a second job interview, landing a new position in my second week in Montevideo.

But in order for this to happen, the first and most important step was being honest with myself. This allowed me to assess my skills to see what I was good at doing and where I had to improve.

Being self aware helped me when I embarked upon the task of creating a program from scratch, because I was realistic about what I could do, but at the same time it forced me to do something about the areas where I was lacking. Additionally, dividing the project into actionable tasks helped me make progress and follow my idea through to completion.

But it wasn’t just about skills; I also had to believe in myself, and that self confidence helped me whenever I faced a challenge that seemed like an insurmountable mountain.

Meanwhile, humility always kept me in check, reminding me that what I had just climbed was but a little peak from among the many I had yet to climb.

Finally, my family and friends offered help and support, and whenever I felt defeated, they kept me focused and reminded me why I was on my journey and what the destination was. In the end, because I persisted, I had become hirable, and now it was time to become an actual programmer.

We continue the story of Alvaro Videla, as travels to Montevideo, Uruguay for his first developer job interview. 

In this episode, Quincy tells the story of Alvaro Videla, who was living in poverty in Uruguay when he decided he wanted to learn to code. He had limited access to books and the internet. But he eventually got a job at Apple and other tech companies.

 

Article by Alvaro Videla: https://fcc.im/2AMqmfM

Read by Quincy Larson: https://twitter.com/ossia

Learn to code for free at: https://www.freecodecamp.org

Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q

 

Transcript:

Getting the Job

During December 2006 and January 2007, I worked hard to get my maps application up and running. While building it, I wanted to learn as many programming notions as possible, trying to cram all the knowledge that would get me ready for the job interview into my head.

Out of all the concepts I could learn, I identified the main ones that I thought would be relevant for getting the job. This narrowing of focus is a very important step toward achieving goals, since we don’t want to be all over the place, trying to grasp a bit of every subject but then failing to reach deepness on any of them.

For my situation, I understood that I had to learn about object-oriented programming, since that was one of the most important programming techniques in use. On the technological side, I had identified PHP as the key programming language that would land me a job, while learning Flash programming would be the skill that would differentiate me from other candidates.

How did I know that? It was a bit of hunch informed by what I was seeing mentioned on the web, along with what the computer magazines were writing about.

Even back then, before I had the job, I knew it was very important to learn to understand and analyze the market I wanted to break into, and finding the right websites and publications is a very important step toward this. This is because these resources often have information that points to the ideas, trends, and technologies that we should focus on.

Once my app was done and I felt I was ready for the interview, it was time to build my resume. However, I had no idea what should go on a tech resume and what should be left out. I listed things like MS Word and MS Excel as some of my skills, together with Adobe Illustrator and some InDesign. Why not, right?

Wrong. Just thinking about that first resume makes me blush. If nothing else, what was clear about it was the message it was signaling: this person is a complete noob.

The problem is that as someone trying to break into a new field and start a career, it was difficult to have something to write down on my resume that made me look competent. I had no idea what to include, so I listed everything.

Today, if someone presented themselves for a backend developer position listing MS Word as a skill, I’m quite sure that person would be rejected straight away. Even worse, I think I would be the one rejecting a resume like that. But of course, hindsight is 20/20.

Once my resume was complete and I got a cell phone number I could be reached at, I applied for the position of PHP programmer at Live Interactive. You’d better believe I read and reread every input box on that online form as I went over a mental checklist. “Did I spell my name correctly? Did I type the right phone number? Let’s double check the email. I don’t want to miss this opportunity because I wrote the wrong address.” I was all nerves, but at some point, I had to hit that send button. Click. Done. Exhalation. “I’ve done it. I’ve applied for my first job.”

Once my app was done and I felt I was ready for the interview, it was time to build my resume. However, I had no idea what should go on a tech resume and what should be left out.

After I submitted my application, I lingered at the internet cafe, browsing the web for random stuff. To my surprise, about half an hour later, my cellphone started to ring.

“I don’t know this number,” I thought. The area code told me it was from Montevideo, but it was so quick, it couldn’t be them. Or could it?

It took me a couple of seconds to understand that, yes, in fact, they were calling me! Can you imagine that? I honestly didn’t know what to do. “Should I take the call?” I wondered. “I’m probably not ready for this!” I quickly tried to get ahold of myself and walked outside to answer.

“Hi, we’re calling from Live Interactive about your job application. Is this Alvaro Videla?” said the voice on the other end.

Do you see what happened right there? I couldn’t believe it! I was being contacted by the company where I had just applied for a job.

“Yes, it’s me,” I replied.

The caller turned out to be the HR manager getting in touch, trying to set up an interview with me. She asked me when would it be a good time for me, so I told her that I needed a week, since “I have to arrange things here.” This wasn’t necessarily the case, as I could’ve just boarded the next bus and traveled there straightaway, but I wanted to prepare — to be 100 percent ready for it and not botch my only opportunity.

I hung up at the end of that phone call having secured a job interview. Now it was time to get myself together and prepare for that interview. I had no doubt this was my once-in-a-lifetime opportunity and I couldn’t waste it. But first, I had to share my excitement with my mother and my wife: I needed to talk about what had happened with someone to help process my emotions.

On one hand, all my hard work was starting to pay off, which felt great. But on the other hand, life had allowed me to see a tiny glimpse of a better future. Making that future a reality now rested entirely on my shoulders, but it was too much of a responsibility for me to handle alone.

I spent the entire next week preparing for the interview, from reading and rereading the books I had, to trying to guess what kind of clothes I should wear for the interview. I had never worked as a programmer, and as such, I had no idea how the programmer culture worked and what kind of behavior would be expected from me. I didn’t have anyone to ask about this either, so at some point I decided to stop worrying too much about the appearance side and tried to focus on the technical aspect of the process, hoping my skills would speak for themselves.

I had no doubt this was my once-in-a-lifetime opportunity and I couldn’t waste it, but first, I had to share my excitement with my mother and my wife: I needed to talk about what had happened with someone to help process my emotions.

Unexpected obstacles

The time passed quickly, and before I knew it, I was sitting on a two-hour-long bus trip, heading to Montevideo. I had the PHP Bible in my backpack and enough money to buy a burger and pay for the ticket from the bus terminal to the company’s offices in downtown Montevideo. I didn’t want to arrive late, so I was around the area an hour in advance, trying my best to fight off a nervous breakdown.

I had to find something to kill time and occupy my worried mind, so I walked to a nearby square, found a bench, and sat down to keep studying. I couldn’t believe that all my struggles over the previous months would be decided in about an hour. “Did I prepare the best I could? That time I didn’t want to study that part of the book so I could go outside, was it worth it?” I wondered. Then I came to my senses. “Stop it,” I told myself. “It’s time to focus on the book in front of me right now, since there’s no reason for worrying about could haves.”

Soon, it was time to head up for the interview. If this was a Tarantino film, my character would probably be called Mr. Blue: dark blue jeans, blue shirt, and dark blue hoodie.

I got to the reception area and was welcomed by the HR manager, who I’d spoken to on the phone the week before. She asked me to sit and wait and offered me a glass of water. I took the offer and immediately started doubting myself. “Is this the right thing to do?” I wondered. “Am I being polite or impolite?” Anxiety was taking over.

Meanwhile, people were walking around, going from one office to another. “Are any of them my interviewer?” I asked myself, studying each person who walked by. One man walked up to the HR manager and started talking. “Ah, it must be him,” I thought. But it wasn’t.

After more of this wondering, the HR manager called my name and took me into a big conference room. She handed me a pile of paper and told me this was the first part of the interview: a psychological test with more than 100 behavioral and situational questions. What. Is. This? Nowhere in the PHP Bible did it mention that people needed to pass psychological tests to become a programmer! But I tried the best I could, second guessing the intention of every question. Of course, I had no idea if the answers I was choosing were correct, but I hoped they would bring me one step closer to getting the job I wanted.

Once I was done, I returned the papers with my answers and then was asked to take a seat again and wait for the next stage. Soon the HR manager introduced me to someone who was going to conduct the programming interview. “Now or never,” I thought. “Now or never.” At that moment, I felt that all the pressure was on me, that I couldn’t let down my wife, my mom, my family. “If I don’t get this job, let it be known that it wasn’t because I got blocked mid interview, and didn’t know what to do,” I thought. “If I don’t pass the next stage, it’d better be because they didn’t want me, and not because I lacked the knowledge or preparation.”

 

In this episode, Quincy tells the story of Alvaro Videla, who was living in poverty in Uruguay when he decided he wanted to learn to code. He had limited access to books and the internet. But he eventually got a job at Apple and other tech companies.

 

Article by Alvaro Videla: https://fcc.im/2fRSzwM

Read by Quincy Larson: https://twitter.com/ossia

Learn to code for free at: https://www.freecodecamp.org

Music: "Sounds of Wonder" by Vangough: https://fcc.im/2yQOq0q

Transcript:

At the end of 2006, I arrived at a crossroads in my life. My hopes of becoming a secondary school linguistics teacher had vanished in an instant, as several factors had come together and made it impossible for me to continue with my studies.

Back in my hometown of Durazno, Uruguay, my wife was working long hours for a meager $160 (USD) a month. Yes, that’s $1,920 a year. We had sacrificed our time together so I could become a teacher and get a better job because we were dreaming of a better future.

The problem with dreams is they tend to vanish when you wake up, and life’s alarm clock had just gone off.

Because my career trajectory had suddenly strayed off course, I moved back to my hometown to figure out my next steps. Needless to say, I was depressed at the way things were, and our living situation only made things worse. It was good to be back with my wife, but the reasons for it were stressful.

Additionally, we were sharing a house with my wife’s aunt, so our privacy was restricted to our bedroom, and we always felt like we were overstaying our welcome.

As a way to bring in extra income, we tried to sell homemade pasta on the streets. I would go door-to-door collecting orders for the weekend. “Hello, do you want to order ravioli to eat this Sunday?” I’d ask person after person. “Yes, they’re homemade. Just give us a time and we’ll deliver them.”

Then, after people ordered them, we spent our entire weekends making 2,000 ravioli only to end up with 500 pesos in our pockets, which comes about $20, not counting expenses.

The whole situation was disheartening, and it made us feel hopeless. My wife would work hard all week, then come home only to spend her weekends helping me prepare the ravioli. She couldn’t even have one day of the weekend for herself. She begged me to stop selling ravioli, even if that meant we would end up with less money to pay our bills. Eventually I agreed, but it meant I had to try to find a job — and finding a job wasn’t so easy in our rural hometown. Anxiety and desperation were starting to set in.

One night, I was talking with a friend who was studying computer engineering at the university in Montevideo. He told me about the various job opportunities one could find in the capital city, with salaries that were the stuff of dreams for someone living in the countryside. “There’s this big company in Montevideo, Live Interactive,” he told me. “They’re always looking for programmers; maybe you could try to get a job there. They pay really well.”

The salary he mentioned was around three times what we were making at the time, and I couldn’t help but imagine all the things we could do with that much money. We wouldn’t need to worry anymore about putting food on the table. We could finally pay for our own internet connection, get proper clothes and shoes, and even have our own washing machine!

Not only that, but I already had experience with computers. I always liked working with them, mostly because they appealed to my knack for problem solving. Programming reminded me of having to crack a code or find the solution to a difficult puzzle — but in addition to being challenging, it was fun. What’s more is that I saw programming as a career with a lot of potential for growth.

But there was one small problem: to work as a computer programmer, one usually needs to know how to program computers. Me? I could install Linux on my own, but that was probably the extent of it.

How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? How do you learn to program without internet access at home, without mentors to connect with, and without access to programming books? That was my problem back in 2006, and this is the story of how I tackled it.

The Early Days

I’ve been dabbling with computers since I was a teenager — most of the time when visiting a friend who had a PC. While we often used the computer to play games, I wasn’t interested in playing that much. Why? Back when I started secondary school, a friend’s father let us use his ZX Spectrum computer. He had good stack of cassettes with plenty of games for it, and of course, we could play all we wanted, but one day he showed me something that blew my mind: people could make their own games by programming the computer!

He showed me some tricks in BASIC, like how you could generate random numbers using the RAND function. I was amazed. At that point, I realized computers were more than a glorified Nintendo with a keyboard: you could actually tell them to do things for you — cool things, like drawing lines using trigonometric functions and then painting them by applying random colors! You could even make music with them by passing different frequencies to BEEP. In fact, once I brought the Spectrum to my house and spent an entire afternoon playing different kinds of beep sounds on my TV — I’m sure my mom loved it.

How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? Later on, during my teenage years, I continued spending time with friends who had their own computers, and naturally we played games on them. Meanwhile, with my more tech-savvy friends, I learned a few operating system tricks — mostly MS-DOS.

Every once in awhile, we would try some BASIC programming by copying, character by character, the code snippets that appeared in old computer magazines. To us, they seemed like magic spells or technological incantations. One thing we really liked was trying to edit the text messages a game would show for different situations. We thought we were such hackers!

By the early 2000s, I managed to convince my grandfather to buy me a computer: a Pentium MMX with 32MB of RAM! What a machine! I installed Linux on it for the first time, using a SUSE CD that came for free with an Argentinean computer magazine. I spent quite a lot of time on that computer: trying different Linux distributions, getting familiarized with the command line, and so on, but never really doing any programming.

When I look back to those days, I can’t understand why I wasn’t learning C programming — or any kind of programming for that matter. A friend even offered me the bible of C programming by Kernighan and Ritchie, so not having access to a manual wasn’t an excuse. But for some reason, after reading a few examples, it didn’t spark any interest in me, as I didn’t understand how what it covered would be useful for me. In any case, playing with Linux was the only thing I was doing with computers back then.

From that point on, I had several minor jobs, played in a rock ’n’ roll band, and tried to become a linguistics teacher, all while getting married and moving all over the country together with my wife.

Fast forward to November 2006 and I found myself in need of somehow becoming hirable by a software company. I had to become a credible computer programmer.

Time for Some Goals

If I wanted to get hired, the first thing to do was evaluate my skillset as a programmer. I had to be honest with myself so I could know where to focus my efforts.

At the time, I knew a bit of ActionScript for Flash MX and the very basics of PHP programming. Earlier that year, I had started learning those technologies as a hobby. I’d also started a pet project to learn programming, thinking maybe it could become a secondary source of income.

I came up with the idea of making a digital map of my hometown where you could drop pins that would point the user to the location of businesses, shops, and interesting locations. I would then charge those businesses money in exchange for appearing in my online map application.

Of course I know what you’re thinking. “That’s just Google Maps,” you say. Yes, but back in 2006, the only thing Google Maps knew about my hometown was that it was crossed by a big national highway. Given that, my map seemed like a good idea. Also, I figured this project would be the perfect way to showcase my skills to a prospective employer. I had a clear goal of what I wanted to build; I just had to get down to work and make it happen.

So at the end of 2006, I set myself a deadline: come February 2007, I had to have a working concept of the map application. This had to include a Flash frontend, served by a PHP backend, using MySQL for data persistence. The technologies I’ve just mentioned might not seem too relevant today, but the point here is that I had to nail down every detail of my plan so I would know which problems to tackle first, since time was ticking: every day that went by was another day where my wife was overloaded, working overtime to get food on our table.

Additionally, to even have a shot at getting a programming job, I had to show potential employers that I could program in those particular technologies, because that was part of the job description. Naturally, I had nothing related to these skills on my resume, so I had to build up my knowledge from scratch, and my app would serve as the showcase of my programming expertise.

The plan was to land an interview at the company my friend had mentioned before, and hopefully, with the combination of my skills and my app, I would end up getting a job there. Even then, I knew the importance of setting clear goals for yourself in order to achieve what you want.

Learning project: a Map Application

The map application I created was called Aleph Maps — a reference to Jorge Luis Borges’ 1949 story, “El Aleph,” about a place in the universe where everything — past, present, and future — is contained. Not ambitious at all, right? And to bring the idea into existence, I would have to learn how to program web apps.

Having no internet at home is a real challenge for a future web developer. When I started, ADSL broadband adoption was almost nonexistent, limited only to businesses and maybe wealthy households. For the average family, connecting to the internet meant dialing in on a modem connection and paying high prices for a slow internet experience. I couldn’t afford that, which meant I had to go and bother friends every time I needed to access some online tutorial that explained how to program in PHP.

So even though I had a computer and the will to learn, I still didn’t have easy or regular access to the information on how to do it. But I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions.

Meanwhile, due to the lack of internet access around town, cyber cafes started popping up in the city, charging around half a dollar for one hour of surfing. This struck me as a better solution than constantly bothering my friends. But this also meant finding an extra 50 cents and a couple of floppy disks in order to get to a cyber cafe, find the information I wanted, copy it onto one of those diskettes, and get it home onto my computer. More often than not, data got corrupted in the process of extracting it from the floppy disks.

Imagine how angry and frustrated I was: I had made a trip to a cyber cafe and wasted 50 cents for nothing. Half a dollar! This might not sound like much, but at that time where we lived, you could buy a burger or a bottle of beer for a dollar. For us, it was a lot of money: it meant our daily bottle of milk or a loaf of bread.

During those days, my routine consisted of trying to solve problem A to get to point B. Sometimes the tasks were rather easy and I felt like I was making quick progress. Other days, it felt like I was going nowhere. For example, say I had to implement a feature like “insert new data into the database.” This meant writing down all the obstacles I had to solve to achieve that — from how to write an SQL INSERT statement to how to execute it using PHP — and then integrating everything into the app.

Each of these tasks was an item on my daily “shopping list” for when I went to the internet cafe. I would take a couple of floppy disks with me, and then I would google for blog posts, tutorials, and guides that would help me solve the items on my list. Once that was complete, it was time to save them on my diskettes and head home, all the while hoping the data had successfully saved and would be easily accessed on my computer.

Because of the uncertainty involved, the bicycle trip back would be fueled by the worst anxiety ever. “What if the data isn’t there at all?” I wondered. “What if the bike shakes too much and the data gets corrupted? I really don’t have another dollar to spare until tomorrow, so this better work when I get home.”

I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Suffice to say, this wasn’t practical at all. Once I was back home, I’d use the information I’d brought back to help me accomplish the task in progress, but once it was complete, I lacked the knowledge to perform the next step. This means I was left sitting at home, thinking about a problem, and waiting until the next day, when I could squeeze another 50 cents out of our budget to go to the cafe and repeat this routine. Though at the time it seemed like my only option, eventually I had to admit to myself that it was time for a new strategy. I needed something that contained most of the information on how to write a web application with PHP and Flash MX, with guides explaining how to perform the most trivial of tasks, all in one single place. Not the internet, but books!

It seems like such a no-brainer, but for someone in my situation, the kinds of books I needed weren’t necessarily in reach. The problem is that when you’re part of a marginalized sector of society, accessing books isn’t so easy. The closest thing to a programming book you could find at the public library would be some outdated manual on how to repair a computer — maybe some dusty MS-DOS guide, or perhaps a BASIC or Delphi book if you got lucky — but not much more.

Well, at least one could buy books, right? Not really.

In most towns in Uruguay’s countryside, technical books are usually absent from the bookstore shelves, and my town was no exception. Add to the problem the fact that most of the tech books — particularly those talking about cutting-edge technology — are written in English, and you can just forget about the local bookstore. In the end, this left me with only one option: Amazon.

But it wasn’t that easy either. To buy books on Amazon, you need a little piece of plastic called a credit card, but to get access to a credit card, you need a good credit history — which for most people is not a problem. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan.

For us, it worked like this: if we wanted to buy something more expensive than our monthly income, we either saved month after month until we got enough money to buy what we wanted, or we asked some family member to buy the product for us and worked to pay them back later.

And even if we’d had the option of buying books on Amazon, we hadn’t factored in the fact that shipping alone from the United States to Uruguay was nearly the cost of the book, not to mention it would take a month for it to arrive.

In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan Sometimes the solution to these kinds of problems is closer to home than we think. Eventually, we ended up resorting to asking for help from family. My wife has an aunt who had been living in the US for quite a while, so we figured it was worth a shot to ask and see if she would buy me a couple of programming books. So on one of my internet excursions, I wrote an email to her explaining my situation, hit send, and basically crossed my fingers and prayed to every deity out there that she would help us. After a couple of days, I had a new email in my inbox. It was her answer, straight to the point: “Tell me which books you need and I’ll order them from Amazon.” After doing some research, I ended up asking for the Flash MX Bible and the PHP 5 and MySQL Bible.

Those two books proved incredibly helpful in the weeks to come. They were both so thorough that I was able to make steady progress without needing to constantly visit the internet cafe in search of missing information. I could finally make headway on understanding what I needed to know to build my maps application. And finally, with access to the information I needed, it was time to sit down in front of my computer and get to work.

 

At the end of 2006, I arrived at a crossroads in my life. My hopes of becoming a secondary school linguistics teacher had vanished in an instant, as several factors had come together and made it impossible for me to continue with my studies.

Back in my hometown of Durazno, Uruguay, my wife was working long hours for a meager $160 (USD) a month. Yes, that’s $1,920 a year. We had sacrificed our time together so I could become a teacher and get a better job because we were dreaming of a better future.

The problem with dreams is they tend to vanish when you wake up, and life’s alarm clock had just gone off.

Because my career trajectory had suddenly strayed off course, I moved back to my hometown to figure out my next steps. Needless to say, I was depressed at the way things were, and our living situation only made things worse. It was good to be back with my wife, but the reasons for it were stressful.

Additionally, we were sharing a house with my wife’s aunt, so our privacy was restricted to our bedroom, and we always felt like we were overstaying our welcome.

As a way to bring in extra income, we tried to sell homemade pasta on the streets. I would go door-to-door collecting orders for the weekend. “Hello, do you want to order ravioli to eat this Sunday?” I’d ask person after person. “Yes, they’re homemade. Just give us a time and we’ll deliver them.”

Then, after people ordered them, we spent our entire weekends making 2,000 ravioli only to end up with 500 pesos in our pockets, which comes about $20, not counting expenses.

The whole situation was disheartening, and it made us feel hopeless. My wife would work hard all week, then come home only to spend her weekends helping me prepare the ravioli. She couldn’t even have one day of the weekend for herself. She begged me to stop selling ravioli, even if that meant we would end up with less money to pay our bills. Eventually I agreed, but it meant I had to try to find a job — and finding a job wasn’t so easy in our rural hometown. Anxiety and desperation were starting to set in.

One night, I was talking with a friend who was studying computer engineering at the university in Montevideo. He told me about the various job opportunities one could find in the capital city, with salaries that were the stuff of dreams for someone living in the countryside. “There’s this big company in Montevideo, Live Interactive,” he told me. “They’re always looking for programmers; maybe you could try to get a job there. They pay really well.”

The salary he mentioned was around three times what we were making at the time, and I couldn’t help but imagine all the things we could do with that much money. We wouldn’t need to worry anymore about putting food on the table. We could finally pay for our own internet connection, get proper clothes and shoes, and even have our own washing machine!

Not only that, but I already had experience with computers. I always liked working with them, mostly because they appealed to my knack for problem solving. Programming reminded me of having to crack a code or find the solution to a difficult puzzle — but in addition to being challenging, it was fun. What’s more is that I saw programming as a career with a lot of potential for growth.

But there was one small problem: to work as a computer programmer, one usually needs to know how to program computers. Me? I could install Linux on my own, but that was probably the extent of it.

How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? How do you learn to program without internet access at home, without mentors to connect with, and without access to programming books? That was my problem back in 2006, and this is the story of how I tackled it.

The Early Days

I’ve been dabbling with computers since I was a teenager — most of the time when visiting a friend who had a PC. While we often used the computer to play games, I wasn’t interested in playing that much. Why? Back when I started secondary school, a friend’s father let us use his ZX Spectrum computer. He had good stack of cassettes with plenty of games for it, and of course, we could play all we wanted, but one day he showed me something that blew my mind: people could make their own games by programming the computer!

He showed me some tricks in BASIC, like how you could generate random numbers using the RAND function. I was amazed. At that point, I realized computers were more than a glorified Nintendo with a keyboard: you could actually tell them to do things for you — cool things, like drawing lines using trigonometric functions and then painting them by applying random colors! You could even make music with them by passing different frequencies to BEEP. In fact, once I brought the Spectrum to my house and spent an entire afternoon playing different kinds of beep sounds on my TV — I’m sure my mom loved it.

How do you land a job as a computer programmer when you have almost no programming experience and you lack a university degree to prove your knowledge? Later on, during my teenage years, I continued spending time with friends who had their own computers, and naturally we played games on them. Meanwhile, with my more tech-savvy friends, I learned a few operating system tricks — mostly MS-DOS.

Every once in awhile, we would try some BASIC programming by copying, character by character, the code snippets that appeared in old computer magazines. To us, they seemed like magic spells or technological incantations. One thing we really liked was trying to edit the text messages a game would show for different situations. We thought we were such hackers!

By the early 2000s, I managed to convince my grandfather to buy me a computer: a Pentium MMX with 32MB of RAM! What a machine! I installed Linux on it for the first time, using a SUSE CD that came for free with an Argentinean computer magazine. I spent quite a lot of time on that computer: trying different Linux distributions, getting familiarized with the command line, and so on, but never really doing any programming.

When I look back to those days, I can’t understand why I wasn’t learning C programming — or any kind of programming for that matter. A friend even offered me the bible of C programming by Kernighan and Ritchie, so not having access to a manual wasn’t an excuse. But for some reason, after reading a few examples, it didn’t spark any interest in me, as I didn’t understand how what it covered would be useful for me. In any case, playing with Linux was the only thing I was doing with computers back then.

From that point on, I had several minor jobs, played in a rock ’n’ roll band, and tried to become a linguistics teacher, all while getting married and moving all over the country together with my wife.

Fast forward to November 2006 and I found myself in need of somehow becoming hirable by a software company. I had to become a credible computer programmer.

Time for Some Goals

If I wanted to get hired, the first thing to do was evaluate my skillset as a programmer. I had to be honest with myself so I could know where to focus my efforts.

At the time, I knew a bit of ActionScript for Flash MX and the very basics of PHP programming. Earlier that year, I had started learning those technologies as a hobby. I’d also started a pet project to learn programming, thinking maybe it could become a secondary source of income.

I came up with the idea of making a digital map of my hometown where you could drop pins that would point the user to the location of businesses, shops, and interesting locations. I would then charge those businesses money in exchange for appearing in my online map application.

Of course I know what you’re thinking. “That’s just Google Maps,” you say. Yes, but back in 2006, the only thing Google Maps knew about my hometown was that it was crossed by a big national highway. Given that, my map seemed like a good idea. Also, I figured this project would be the perfect way to showcase my skills to a prospective employer. I had a clear goal of what I wanted to build; I just had to get down to work and make it happen.

So at the end of 2006, I set myself a deadline: come February 2007, I had to have a working concept of the map application. This had to include a Flash frontend, served by a PHP backend, using MySQL for data persistence. The technologies I’ve just mentioned might not seem too relevant today, but the point here is that I had to nail down every detail of my plan so I would know which problems to tackle first, since time was ticking: every day that went by was another day where my wife was overloaded, working overtime to get food on our table.

Additionally, to even have a shot at getting a programming job, I had to show potential employers that I could program in those particular technologies, because that was part of the job description. Naturally, I had nothing related to these skills on my resume, so I had to build up my knowledge from scratch, and my app would serve as the showcase of my programming expertise.

The plan was to land an interview at the company my friend had mentioned before, and hopefully, with the combination of my skills and my app, I would end up getting a job there. Even then, I knew the importance of setting clear goals for yourself in order to achieve what you want.

Learning project: a Map Application

The map application I created was called Aleph Maps — a reference to Jorge Luis Borges’ 1949 story, “El Aleph,” about a place in the universe where everything — past, present, and future — is contained. Not ambitious at all, right? And to bring the idea into existence, I would have to learn how to program web apps.

Having no internet at home is a real challenge for a future web developer. When I started, ADSL broadband adoption was almost nonexistent, limited only to businesses and maybe wealthy households. For the average family, connecting to the internet meant dialing in on a modem connection and paying high prices for a slow internet experience. I couldn’t afford that, which meant I had to go and bother friends every time I needed to access some online tutorial that explained how to program in PHP.

So even though I had a computer and the will to learn, I still didn’t have easy or regular access to the information on how to do it. But I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions.

Meanwhile, due to the lack of internet access around town, cyber cafes started popping up in the city, charging around half a dollar for one hour of surfing. This struck me as a better solution than constantly bothering my friends. But this also meant finding an extra 50 cents and a couple of floppy disks in order to get to a cyber cafe, find the information I wanted, copy it onto one of those diskettes, and get it home onto my computer. More often than not, data got corrupted in the process of extracting it from the floppy disks.

Imagine how angry and frustrated I was: I had made a trip to a cyber cafe and wasted 50 cents for nothing. Half a dollar! This might not sound like much, but at that time where we lived, you could buy a burger or a bottle of beer for a dollar. For us, it was a lot of money: it meant our daily bottle of milk or a loaf of bread.

During those days, my routine consisted of trying to solve problem A to get to point B. Sometimes the tasks were rather easy and I felt like I was making quick progress. Other days, it felt like I was going nowhere. For example, say I had to implement a feature like “insert new data into the database.” This meant writing down all the obstacles I had to solve to achieve that — from how to write an SQL INSERT statement to how to execute it using PHP — and then integrating everything into the app.

Each of these tasks was an item on my daily “shopping list” for when I went to the internet cafe. I would take a couple of floppy disks with me, and then I would google for blog posts, tutorials, and guides that would help me solve the items on my list. Once that was complete, it was time to save them on my diskettes and head home, all the while hoping the data had successfully saved and would be easily accessed on my computer.

Because of the uncertainty involved, the bicycle trip back would be fueled by the worst anxiety ever. “What if the data isn’t there at all?” I wondered. “What if the bike shakes too much and the data gets corrupted? I really don’t have another dollar to spare until tomorrow, so this better work when I get home.”

I was determined to get that job, and I knew that even these setbacks wouldn’t deter me from learning PHP. When you don’t have time to waste, you don’t have time to feel desperate; instead, you have to focus on finding solutions. Suffice to say, this wasn’t practical at all. Once I was back home, I’d use the information I’d brought back to help me accomplish the task in progress, but once it was complete, I lacked the knowledge to perform the next step. This means I was left sitting at home, thinking about a problem, and waiting until the next day, when I could squeeze another 50 cents out of our budget to go to the cafe and repeat this routine. Though at the time it seemed like my only option, eventually I had to admit to myself that it was time for a new strategy. I needed something that contained most of the information on how to write a web application with PHP and Flash MX, with guides explaining how to perform the most trivial of tasks, all in one single place. Not the internet, but books!

It seems like such a no-brainer, but for someone in my situation, the kinds of books I needed weren’t necessarily in reach. The problem is that when you’re part of a marginalized sector of society, accessing books isn’t so easy. The closest thing to a programming book you could find at the public library would be some outdated manual on how to repair a computer — maybe some dusty MS-DOS guide, or perhaps a BASIC or Delphi book if you got lucky — but not much more.

Well, at least one could buy books, right? Not really.

In most towns in Uruguay’s countryside, technical books are usually absent from the bookstore shelves, and my town was no exception. Add to the problem the fact that most of the tech books — particularly those talking about cutting-edge technology — are written in English, and you can just forget about the local bookstore. In the end, this left me with only one option: Amazon.

But it wasn’t that easy either. To buy books on Amazon, you need a little piece of plastic called a credit card, but to get access to a credit card, you need a good credit history — which for most people is not a problem. In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan.

For us, it worked like this: if we wanted to buy something more expensive than our monthly income, we either saved month after month until we got enough money to buy what we wanted, or we asked some family member to buy the product for us and worked to pay them back later.

And even if we’d had the option of buying books on Amazon, we hadn’t factored in the fact that shipping alone from the United States to Uruguay was nearly the cost of the book, not to mention it would take a month for it to arrive.

In my case, though, I was living in a completely different world: everything we bought was paid for in cash. We didn’t have the money or the economical certainty to enter into a credit plan Sometimes the solution to these kinds of problems is closer to home than we think. Eventually, we ended up resorting to asking for help from family. My wife has an aunt who had been living in the US for quite a while, so we figured it was worth a shot to ask and see if she would buy me a couple of programming books. So on one of my internet excursions, I wrote an email to her explaining my situation, hit send, and basically crossed my fingers and prayed to every deity out there that she would help us. After a couple of days, I had a new email in my inbox. It was her answer, straight to the point: “Tell me which books you need and I’ll order them from Amazon.” After doing some research, I ended up asking for the Flash MX Bible and the PHP 5 and MySQL Bible.

Those two books proved incredibly helpful in the weeks to come. They were both so thorough that I was able to make steady progress without needing to constantly visit the internet cafe in search of missing information. I could finally make headway on understanding what I needed to know to build my maps application. And finally, with access to the information I needed, it was time to sit down in front of my computer and get to work.