Quality is everything. So instead of relying on machine translation, we are doing this entire process by hand.

Dozens of native speakers are collaborating to make these free learning resources accessible to more people around the world.

Over the past two years, we've experimented with different approaches to this massive task. And I'm happy to announce that we have converged on some really efficient workflows.

The freeCodeCamp Localization Process

For each language, our goal is to:

1. Translate the most popular English tutorials into each world language, then publish them on the corresponding publication. For example, the Chinese publication now boasts more than 800 tutorials.
2. Then once we've made progress with that, we'll shift gears to focus on translating the core freeCodeCamp curriculum. For example, the entire curriculum is now available in Portuguese. (You can switch languages from the menu button.)
3. Finally, we will launch YouTube channels for each of these languages. The Spanish YouTube channel has been a big success, and already has more than 100,000 subscribers.

We have already made significant progress with the following world languages:

• Arabic
• Bengali
• Chinese
• German
• Hindi
• Italian
• Japanese
• Korean
• Portuguese
• Spanish
• Swahili
• Turkish
• Ukrainian
• Urdu

And we eventually hope to support dozens of other languages as well.

How to Translate freeCodeCamp

If you are interested in contributing, here's how you can get involved.

Step 1: Fill out this Google form.

Step 2: Join the freeCodeCamp Official Discord, visit the "start-here" room, and follow the instructions there.

Note that Discord has a couple of verification steps you will need to complete.

If you see a message at the bottom of Discord that says "You must complete a few more steps before you can talk", click the "Complete" button, then read and agree to our community rules to finish the onboarding process.

Alternatively, if you just created your Discord account, you might need to wait up to 5 minutes to send messages. (This is an anti-spam counter-measure.)

You will get an email from a Language Lead within a few days

We have Language Leads for each world language. Depending on which language you want to contribute to, you will receive an email from one of them to learn a bit more about you and your goals.

They may give you access to the freeCodeCamp publication, where you can start translating articles.

We use Ghost, a powerful open source CMS, for our publication. This screenshot is our Spanish publication.

Here is a list of some of our active GitHub project boards where we have the articles we'd like to prioritize. Eventually we'll add more languages.

A list of all the GitHub project boards for languages we're actively translating News articles for.

The GitHub project board we use to coordinate our Spanish translation efforts.

Let's Make freeCodeCamp Accessible to Everyone Around the World

This is a massive undertaking, and it will take many years. But the community has already made some concrete steps toward realizing this goal.

Please join us as we make these free learning resources more accessible to people around the world. 🌏🌍🌎

Happy coding.

I’m learning how to code.

I'll get a software developer job.

Learning how to code doesn’t have to cost you money.

The words I’m, I’ll and doesn’t are called contractions.

In this article, you'll learn all about contractions – what they are, when and where you'll most likely come across them, when and when not to use them. Finally you'll see some of the most common contractions used in the English language.

Let's get started!

What are contractions?

Contractions, also known as 'short forms', are shortened words.

Specifically, a contraction is when two words are shortened in form and are put together to form one new word.

For example, you and are can be combined to create a shorter word, you’re.

When two words are combined, certain letters will disappear. You can lose just one letter or more, depending on the contraction.

When you combine those two words and the letter(s) disappear, an apostrophe (’) will take their place.

The missing, original letters get replaced by the apostrophe to show the place where the missing letters should be. Those letters will not appear in the contraction (as they've been replaced by the apostrophe).

For example, take the word isn't. This contraction combines the words is and not. When those two get paired together, the letter o disappears. An apostrophe now takes its place to show where the missing letter was.

Another example is when you and will get combined to form you'll. Now two letters disappear,w and i, and the apostrophe fills that space of two missing letters.

When do you use contractions?

We use contractions every day in both speech and writing.

You'll hear them from your friends, family, and on TV. You'll see them in novels, non-fiction books, newspapers, instruction manuals, blog posts, learning material, and much more. There are a couple in this very paragraph, and I use them throughout this article.

They are informal and casual, since they give your writing a more friendly, light, accessible, and approachable tone.

Contractions can make the reader feel like you are talking directly to them and having a conversation. It helps make your writing appear uncomplicated for everyone to understand and make sense of.

Because contractions are shorter, it also means that they take up less space. Because of that, you'll often see them in advertisements where space is valuable.

In a nutshell, you can comfortably use contractions in more informal writing and on relaxed occasions.

When to avoid using contractions

It's best to avoid using contractions when you want to maintain a more serious and formal tone in your writing.

For example, skip using them in academic research papers, important business presentations, or in any situation where informal writing or speech would not make much sense.

Common contractions

Below are some of the most widely used and common contractions you'll encounter when speaking and writing in English.

Common Contractions ending in -ll

Contractions ending in -ll include the word will. The w and i letters get dropped.

Common Contractions ending in -re

Contractions ending in -re include the word are. The letter a gets dropped.

Common Contractions ending in -s

Contractions ending in -s include either the word is or has.

For example:

• He is going = He’s going
• It has gone = It’s gone.

The letter i or the letters h and a, respectively, get dropped.

What about let's ? That is a bit different. let's comes from let + us.

Common Contractions ending in -ve

Contractions ending in -ve include the word have. The letters h and a get dropped.

Common Contractions ending in -d

Contractions ending in -d include either the word had or would.

Some examples with the word had:

• I'd better go now = I had better go now
• I wish I'd never left = I wish I had never left.

Some examples with the word would:

• I'd rather not go there = I would rather not go there
• I'd like something to drink please = I would like something to drink please.

Common Contractions ending in -m

Contractions ending in -m,include the word am.

The letter a gets dropped.

Negative contractions

Negative contractions are those that end in -nt.

You achieve this by adding the word not to a verb, making it negative.

In this case,the letter o gets dropped.

A word that is a little different and an exception to what has been shown so far is won’t – it comes from will + not = won’t.

will does not turn into willn’t. In fact the word "will" does not appear in the contraction at all. Just think of it as an irregular contraction (like how we have irregular verbs).

Common mistakes with contractions

A couple of contractions commonly cause confusion and people often use them in the wrong way - you'll even see native English speakers make these mistakes.

These contractions sound exactly the same with other words, so these mistakes commonly occur in writing.

You’re and Your

You’re is a contraction, a combination of the words you and are.

For example, You’re learning how to code or You’re doing great!.

Your is a possesive pronoun, it is used to indicate that something is owned by/belongs to someone.

For example, Your cat is so cuddly! or Your cooking always tastes so good.

Your doing great makes no sense since it doesn't indicate that something belongs to someone. You’re doing great does, since it indicates action and verbs are used for that.

If you get confused and don't know which to use, read it out to yourself as you are and see if it sounds right.

Your are cat is so cuddly! doesn't make sense or sound right, for example.

It’s and Its

It’s is a contraction – a combinations of it and is or has.

For example, It’s raining outside or It’s been great for me so far, I’m really enjoying it here.

Its is a possesive pronoun. Its shows possession.

For example, Don’t judge a book by its cover or The cat is in its sleeping basket.

Similarly to the example from the previous section, if you're confused use the verbs is or has in your sentence and check to see if it makes sense to add the apostrophe/make it a contraction: Don’t judge a book by it is cover doesn't make sense, so you use the possessive "its" with no apostrophe.

It is raining outside makes sense, so you now know that you can use an apostrophe.

They’re, Their, and There

All three of these words sound the same.

They’re is a contraction. They and are were combined.

For example,They’re going away for the holiday season or They’re buying a house together.

Does the sentence sound right when you use they are? Then use they’re.

Their shows possesion.

For example,Their dog bit me last night or I don’t like their attitude.

Finally, There indicates a place, a location.

For example,I wish I was there instead or I’m never going there again.

Conclusion

And there you have it!

This article gave an overview of contractions and how to use them in both spoken and written English.

You saw some of the most common ones used and some frequent mistakes made when using them.

Thanks for reading!

Over the past few years, hundreds of volunteer contributors have worked to translate freeCodeCamp into major world languages. In February, Quincy announced that freeCodeCamp had successfully launched both Spanish and Chinese editions. And Portuguese and Italian soon followed.

During World Translation Month, we will celebrate what we have achieved collectively – and what we will accomplish for everybody around the world. Watch this one-minute announcement video:

If you are interested in participating in translating freeCodeCamp into any world language, you can visit our contributors channel and learn more.

Latest Translation Accomplishments

Today, we have successfully launched the Italian and Brazilian Portuguese curriculum. We are eager to see what is to come for these active communities.

And the Ukrainian community has really taken off in their translation efforts. They have eight certifications fully translated and two close to 100%, almost all completed within a month. It is remarkable to witness the dedication and perseverance every language community has shown.

We have multiple other communities and individuals who are translating the curriculum to their native languages. You can take a look at the current statuses of all the active translations and their progress here.

Current Translation Progress

Currently, volunteers around the world are in the process of translating freeCodeCamp's curriculum into 28 world languages.

And many of these world languages are showing significant progress, especially the French, Romanian, Japanese, and German-speaking communities. Keep up the great work!

What is the Goal of the World Translation Month Event?

freeCodeCamp's goal is to give every individual the tools to translate the curriculum into their native language. Also, we will dedicate all our efforts and time to this event to reach significant progress for every world language.

We have witnessed what a handful of contributors can do together with a singular purpose. And we hope that World Translation Month will become a yearly event when all world languages can celebrate having access to free programming education translated by their community for their community.

Our Reward System 🥇

freeCodeCamp wants to make this a memorable event for every contributor who participates.

During the WTM event, we will give all participants a World Translation Month Badge. Also, at the end of the event, we will present special badges to the Top Translators and Top Proofreaders who have made the most contributions.

You can display these badges on your freeCodeCamp curriculum and forum profiles if you want to do so.

2021 World Translation Month badges

The freeCodeCamp Localization Roadmap

The freeCodeCamp curriculum is already available in Chinese and Spanish. And beyond this, these communities have many other resources at their disposal, thanks to the efforts of hundreds of contributors.

For example, the Chinese-speaking community has translated nearly all the certifications into Chinese. They also have close to 600 articles translated, there are 10 of freeCodeCamp's video tutorials with subtitles on Bilibili, and they've organized hundreds of meetups, hackathons, conferences, live coding events, and coding workshops in universities and high schools.

freeCodeCamp bilibili 频道

The Spanish-speaking community has the first two certifications available in Spanish, and they've translated around 250 articles. Community members have also written about 20 original articles, created 3 original full-length video tutorials, and Estefania has created 24 short videos for the Spanish YouTube channel.

The response from the Spanish-speaking community has been remarkable on YouTube and Twitter. Thanks to the fantastic job Estefania has been doing by engaging with the community with posts and short videos on YouTube, the channel now has over 12,000 followers. And freeCodeCamp's Twitter account en Español has reached 7,300 followers while continuing to grow.

YouTube Channel freeCodeCamp en Español

Twitter freeCodeCamp en Español

The Translation Blueprint

As Quincy mentioned in the World Language Translation Effort article, freeCodeCamp's "...long-term goal is for each of these language communities to come into its own."

And we'll take the same steps as we took with the thriving Spanish-speaking and Chinese-speaking communities with other language communities around the world.

The plan is to launch a localized publication, YouTube Channel, sub-forum, and Twitter account for these language communities, each with their own contributors and staff.

Thank You to All the Translators, Contributors, and Proofreaders!

I want to finish up by thanking the proofreaders and translators who have dedicated hours upon hours to translating and proofreading.

Active Translators

Active Proofreaders

Also, thank you to all the proofreaders and participants in the World Translation Month video:

• Andrea Ros - Italian Proofreader
• Daniel Rosa - Portuguese-BR Proofreader
• Stephan Düsterhöft and Michael Franz - German Proofreaders
• Sidemt (Yoko) - Japanese Proofreader
• Adina Solomon - Romanian Proofreader
• Khalid - Arabic Proofreader
• Juan Carrillo - Spanish Proofreader
• S1ng S1ng，Alan Luo，Zhicheng Chen，Nicholas Zhan，Miya Liu - Translators/Proofreaders

If you are interested in participating in translating freeCodeCamp's curriculum into any world language, you can visit our contributors channel and learn more.

The title is really pretentious, isn’t? Yeah, it is. Although I’ve been working with PHP for years, how could I state what are the best practices and tools for the job? I couldn’t, but I’m going to do so.

I’m seeing a real change in the way developers are doing their job with PHP, not only is the language drastically changing to become more mature and robust with new versions and improvements, but the entire ecosystem around it is changing.

New tools, libraries, frameworks and articles are being created, patterns are being defined to make code more elegant and easy to understand. Several people are thinking about ways to make the work (and your life as a developer) more productive, clean and fun.

I’m not an early adopter of new trends, actually, I only adopt a new tool when I’m sure there is a community behind it and I really think it will improve my work. What I always do is try to write my code following the best practices.

Because of that, It took me time to start using things like Composer and PHPUnit. About a year ago, more or less, I’ve opened my heart to all those shiny new things.

PSR came first, then Composer, PHPUnit, Travis-ci and several other libraries and amazing tools. I’m even using an IDE now (Vim FTW, but PHPStorm with XDebug integration is a must for a sane workflow)!

What is modern?

_By [http://creativecommons.org/licenses/by/2.0](https://www.flickr.com/photos/karen_roe/" rel="noopener" target="_blank" title="Go to Karen Roe's photostream">Karen Roe (Flickr) [CC BY 2.0 (<a href="http://creativecommons.org/licenses/by/2.0" rel="noopener" target="blank" title="))]

There are tons of articles around the web about how awful PHP is, how your life would be terrible if you had to work with PHP code, how the language is ugly and whatever else you could think of!

If you are going to work with legacy code, maybe your life will not be that good, but if you have the opportunity to work on a new project and are able to use all the new tools, you’re going to see this new PHP I’m gonna talk about.

I have several problems working with PHP on a daily basis, but one cannot close their eyes to the changes taking place in the language, community and the ecosystem. There is a long road ahead, but things are getting mature in the land of PHP.

I started creating an SDK for an internal API in the company I work for, just as a pet project, and decided to follow best practices. Most of them I was already doing, but I’ve made few changes in the way I do some things. Those changes and what I learned in the last year are the subject of this article and what I call Modern PHP.

Let’s start with the workflow

_TRIO FABRIKKER — [https://nos.twnsnd.co](https://nos.twnsnd.co" rel="noopener" target="blank" title=")

As I said, I’m a newcomer to this IDE-thing, but it was love at first sight. PHPStorm is a great-great piece of software. It is my first and only IDE. It was my fist try and I don’t even needed to try any other.

The integration with XDebug is perfect, PHP namespace resolution, composer integration, git integration, auto-complete, code generating, code refactoring. I could keep going on and on.

I don’t think you must use an IDE, actually, this point is completely personal. You should use whatever suits your needs - Vim, Atom, Emacs, Bracket, NetBeans, PHPStorm, Eclipse, whatever. Two important points here are productivity and ergonomics. Your IDE/text editor must be there to help you.

However, for me, a great point is debugger integration. To write code for big projects (actually for the small ones too) you have to use a decent debugger. Let’s forget those var_dumps and print_rs. You need to poke those variables at runtime, analyze stack traces, set breakpoints. These things are essential and make development and refactoring easier.

I don’t even know if there are other options here, XDebug has everything you need. Do you have a few minutes? If you haven’t done this yet, take a moment to setup XDebug and integrate it into your IDE or text editor. Start debugging your code using the right tools.

The other tool I want to bring your attention to is GitHub. Another entire article could be written about how good Git and GitHub are and why you must start keeping your code under a versioning system. But I wanna show you another reason.

The focus here is integration.

There are several tools which integrate with GitHub and you should start using them. Those tools can generate metrics, run tests, run jobs for you during a continuous integration process and do all sorts of things in your workflow. Integration is a good reason for you to start using GitHub, all the others are subject for another moment.

Dependency management

_INSTITUTO PASTEUR. LISBOA, PORTUGAL — [https://nos.twnsnd.co](https://nos.twnsnd.co" rel="noopener" target="blank" title=")

Another point in this modern PHP ecosystem is dependency management, and Composer is the tool for the job.

Composer is 5 years old, but it seems to me that massive adoption took place a couple of years ago. Maybe because I’m not an early adopter or maybe because PHP developers are reluctant to change.

This tool provides a front end to Packagist, which is a PHP package repository consisting of PHP libraries, projects and tools, whose source code is stored in Github (or other places like BitBucket).

All the libraries I’m talking about in this article, and maybe one of those pet projects of yours, can be added to your project with a simple

$ composer require package_vendor/package_name

If you don’t know the vendor of a package, you can search for a package to find and install the right one.

$ composer search package_name

Composer would be a great tool if it just did this work, manage dependencies, but it does a lot more. Take a time to install Composer and read the documentation.

Command line interface done right

I really like to try ideas quickly using CLI interfaces. For me, one of the greatest REPL tools is the IPython. It helps you autocomplete your code, let you easily define functions, ease the access to the documentation and several other amazing features. The downside for us, the tool is for Python, not PHP.

In the PHP world we have something called “interactive mode” which can be accessed by terminal, just typing

$ php -aInteractive mode enabled

php >

At this point, you are in the interactive mode and can start testing something. It works, but the tool is just too unintuitive. I’ve tried it several times but, since I knew what IPython was able to do, I could not keep using it.

To our luck, there is a cool new CLI (command line interface) on the block and its name is Psysh. Psysh is an amazing tool, full of interesting features and can be installed globally or per project using composer.

The nicest Psysh feature for me is inline documentation. Accessing the doc for a PHP function without heading over to Php.net is great. The downside is that you need to do few things before it is fully functional.

After installing it, type the following commands (I’m using Debian here, this may not work for everyone) in order to get it working properly

$ apt-get install php7.1-sqlite3$ mkdir /usr/local/share/psysh$ wget http://psysh.org/manual/en/php_manual.sqlite -o /usr/local/share/psysh/php_manual.sqlite

The first command is not mandatory and if you have the Sqlite already installed you can skip this step. The second command creates the directory to store the documentation and the third line downloads and save the doc into the previously created directory. Remember, all these commands must run as root.

Now you have this

_Screenshot of psysh doc in action, showing information about jsondecode

Head to Psysh and learn more about this awesome tool.

You should start testing

This a mantra I’m saying to myself every day. Like lots of people, I don’t test my code as much as TDD suggests. I’m getting into testing now and have been doing so for the past half a year, and there is a long road ahead.

I decided to learn about tests when working with a complex legacy project. The code was so fragile and rigid that anytime we added some code it broke something. New feature? Implement and break something! Fixing a bug? Create another one.

That was a big problem, which I discussed in another article, and made me start giving tests a chance.

The first tool I was presented was PHPUnit. As stated in the official site

PHPUnit is a programmer-oriented testing framework for PHP.
It is an instance of the xUnit architecture for unit testing frameworks.

So, PHPUnit is a framework for helping you create tests for your projects, unitary tests. It gives you several functions to test the outcome of your code and generate a nice output with the result from those tests.

Since I started thinking about tests, reading and talking to people about it, I’ve discovered another great tool, which complements the work you’ve put in those unitary tests, it is calle Behat, which is a BDD framework for PHP.

BDD (Behavior-Driven Development) is a development process which came from TDD (Test-Driven Development). Those acronyms are not important now, what is important is that you can specify your tests using a more natural language, a language that non-technical folks can understand.

This language is called Gherkin and is used to describe the expected behavior being tested. A test description, using Gherkin, looks like this

Behind those lines there is PHP code that is called whenever there is a match between a line and a regex pattern specified in the PhpDoc of the method. This code implements those steps and what a real user would do, using your SDK, application or web system.

The workflow with Behat is so smooth. After everything properly configured, you start writing all possible scenarios for testing a feature. The first time you run Behat, it gives you all the method templates you should add to your PHP Context class in order to implement each step in a scenario.

After that, you start writing the actual code for each step and keep repeating this cycle.

• Implement PHP code for a step
• Run tests
• If everything is fine, write PHP code for another step
• If something is broken, fix it

After half an hour of configuring and reading documentation, you are prepared to use Behat, you’ll see that in the end it is all PHP code and you already know how to program with it.

Continuous Integration

Continuous integration (CI) is a process - a way to do something, and this thing, for us software engineers, is creating software.

In plain English, it is the act of incorporating small chunks of code constantly (maybe several times a day) into your code base. Code which has been tested and did not break anything. CI helps you automate the building, testing and deployment of your applications.

With a few clicks you can integrate your GitHub project with Travis CI and every push to your repository will run those tests you created with PHPUnit and Behat, telling you whether the the last feature you’ve implemented is ready, or not, to be merged. Besides that, you can use Travis CI to deploy your code to production and staging.

Having a nice pipeline of work with a well defined process is great and Travis CI can help you with this job. Follow this nice Getting started and discover how interesting it is to think about the process of software development, not just the code itself.

Adhere to PSR-1 and PSR-2

If you don’t know what PSR is, you should. Actually, PSR stands for PHP Standard Recommendations and is proposed by PHP-FIG (PHP Framework Interop Group), a consortium formed by members from the biggest PHP projects, frameworks and CMSs, which are thinking about the future of the language, ecosystem and discussing standards to be followed.

For a long time, PHP had no coding style. I’m not that old, but every time I looked into someone’s project or library, it was following a different style. Sometimes the bracket was left in one position, sometimes it was put in the next line, different approaches were used to deal with long lines and every other combination of style and preference you could think of. It was a mess.

PHP-FIG does many other jobs, but by proposing a single unity of code, they are saying “Let’s stop worrying about code style, let’s everyone follow a standard and start thinking about creating great software”. Now, whenever you take a look at someone’s code you just worry about understanding how it works, not blaming the format, the structure.

There are, until the end of this article, 9 accepted PSRs proposing common solutions for common problems. But if you don’t know anything about those standards, start with the PSR-1 and PSR-2.

These standards propose the modern PHP coding style. Make sure you read them before start using them. Don’t think you’ll remember all of them when coding, it is a process, but to make you sure, there are tools to help you with it.

PHP CodeSniffer is a tool you can find on Packagist that you can install with Composer. I don’t think the repository name was the best choice, because it ships two different tools, phpcs and phpcbf.

Phpcs is the code sniffer, it will scan your entire code, looking for parts that are not following the configured coding standard.

You can use several coding standards with phpcs and you can even create your own. At the end of the code scan, phpcs shows you a list of the pieces of code not following the standard. It is great.

Now, how to change everything which is wrong? You could open every file, change the code, run phpcs again, see the error not being shown, and repeat the process. It’ll be extra boring.

To solve this problem, PHP CodeSniffer came with another tool, called phpcbf, or PHP Code Beautifier. You run phpcbf, following the same rule set and, voilá, it fixes everything for you, or it tries to do its best without breaking your code.

Try to create the habit of running phpcs and phpcbf before pushing any changes in your code to the repository, this will ensure that all of your code adhere to the standards and if someone likes your tool/project and wants to contribute, they will have no problem reading it.

Frameworks

I’m not going to dedicate too much time discussing frameworks. There are several good ones out there, each one with its ups and downs. Personally, I prefer not to use those big frameworks, with everything inside. I like the idea that you must use just what you need.

If you need a HTTP client, use Guzzle. If you need a template engine, use Twig. If you need a router, find a good component which suits your needs and use it. Glue these components together and create your application.

Symfony is doing a great job towards this concept. You can use the entire framework for a project, or you can just take whatever you want and use it. Simple as that.

However, whenever I need a framework to write an application, I chose one of the so called microframeworks. They are really small, offer just the basics and are easy to customize and easier to make them follow your project structure.

My microframework of choice is Slimframework and I think you should read about it. It is simple for doing small projects, but it gets a bit more complex for bigger ones.

By the way, and this is for those who are starting with programming, I really think that before adopting a framework and dying for it, you should try to create your own. This will give you the understanding of the whole mechanism and ease the adoption of a big one.

The Modern PHP Toolset

Let’s finish this article with a list of links. To me, these components, tools and libraries represent a great deal of what Modern PHP is:

• Slimframework: a nice and cool microframework
• Symfony: a bigger framework which is filled with great and reusable components
• Guzzle: a simple and easy to use HTTP client
• PHPUnit: a framework for unitary testing
• Behat: a framework for Behavior-Driven Development
• PHPCS/CBF: code sniffer and code beautifier
• Faker: fake data generator
• Psysh: a runtime developer console (CLI) full of amazing features
• Composer: dependency management and other useful features
• Packagist: package repository
• Twig: template engine

The title was really pretentious, I know. What I really wanted to show here is that PHP is evolving and the ecosystem is evolving at the same (maybe faster) pace.

Computer programs are all around us. We interact with them every day. It looks as if software is becoming more and more important to our society. But why do we find programs so necessary to us? Why and when did we start programming? What is the essence of programming? These questions might sound trivial, but I feel that today we still don’t have a good definition of what programming is. Maybe this post can help to change that.

It is pretty hard to define programming because it is so diverse. One can program games, mobile apps, websites, compilers, simulations and much more. In this case it might be helpful to start by breaking down some misconceptions and clarifying what programming is not.

Programming is not science. Science is the art of examining the world and discovering repeatable patterns in it. The scientific method is about making a hypothesis, and then performing experiments to prove or reject it. We don’t use such a method in programming — thus it is not science. Programming is not about discovery, but creativity.

Programming is not math. Yes, there is an aspect of math to programming. Some parts of programs can be expressed as mathematical functions. Writing a Fibonacci number generator is fun, but completely useless without a real-world application. Math in programming is means to an end, not a core part of the process.

Programming is not about electronic computers. Computers are very useful, but not necessary. Programs can be understood and interpreted by human beings as well. Therefore, computers are just tools we use in programming.

So what is programming about? What is at the core of every program — big or small?

Abstractions.

What is abstraction? It is a reduced image of the world. When abstracting, we are converting reality into symbols which can be transmitted as information. The word abstraction originates from two Latin words, which are abs, meaning away from and trahere, meaning to draw. The Latin translation suggests that abstracting implies separating one from the whole.

Is the process of abstraction unique to programming? Not really. It is something that humans have been doing for quite some time now. And our most basic tools of abstraction are the map and the clock.

Archaeologists have discovered stone maps that humans made more than 14,000 years ago. This shows that map-making is fundamental to humans. It is a process of transforming territory into symbols by abstracting it. A map is a way to abstract space. It is a tool that helps us to make sense of surrounding territory so that navigating it will be easier.

A clock, on the other hand, is a way to abstract time. We find the continuous nature of time confusing, so we abstract it. Humans split time into discrete intervals: years, months, days, hours, minutes, seconds. While a map helps us navigate space, a clock helps us navigate time. The predecessor of the clock — the calendar — emerged more than 10,000 years ago.

_Giant solar calendar [Chankillo](https://en.wikipedia.org/wiki/Chankillo" rel="noopener" target="blank" title=") was built 2,300 years ago.

What about computers then? They are also tools that deal with abstractions. There are 3 fundamental parts to every computer:

1. Internal clock — a computer’s way to abstract time
2. Memory — a computer’s way to abstract space
3. Processing unit —a computer’s way to perform logical operations

These facilities give computers a way to understand space abstractions and their interactions in abstracted time. This means that programs are abstractions of spacetime, and programming is the art of creating spacetime abstractions. These abstractions help us to navigate reality, and that is why they are so important to us.

And there is one abstraction method that is very similar to programming, but is even older than maps, clocks and calendars: language.

If you look closer at our natural language, you will see that it has all the features necessary to abstract spacetime.

Let’s look at an example sentence:

Go to the garden and pick up some flowers this evening.

The garden and flowers refer to abstracted space. This evening is a way to abstract time. And adds logic to the sentence. Go to and pick up are subroutines.

We can easily transform the sentence above into JavaScript:

whenEvening.then(()=>you.goTo(garden)).then(()=>you.pickUp(flower))

This sentence can be understood by a computer that has definitions of evening, you, flowers, and the necessary subroutines defined.

The problem with natural language is that it has very broad applications. Language can be used not only to communicate information, but also to express feelings and emotions. The best examples of pure natural language programs are laws, board game rules, and instruction manuals.

_[ CC BY-NC-SA](https://en.wikipedia.org/wiki/Code_of_Hammurabi" rel="noopener" target="_blank" title="">Code of Hammurabi is one of the oldest natural language programs (photo by Richard /<a href="https://creativecommons.org/licenses/by-nc-sa/2.0/" rel="noopener" target="blank" title="))

Programming languages, on the other hand, are strict and can only create abstractions. Computers are designed to interpret these abstractions in a very specific and deterministic way.

In order to write computer programs one has to learn how to encode natural language to symbols that computer can understand. This usually requires intricate knowledge of computer architecture and the syntax of the chosen computer language. Thus if you want a computer to understand your reality abstractions, you have to learn how to code.

Computers are tools that can execute rules defined in programs with superhuman speed and precision. They empower us with the ability to construct complex, multilayered abstractions, and transform our programs into truly dynamic and interactive maps of reality.

In many ways, programming is something that all of us already know how to do. The process of reality abstraction is fundamental to human beings. Computer programming is just the most effective way of doing this.

…or The Joy and Pain of Code as Language

When I’m not coding, reading about coding, or solving coding problems, I’m a managing editor for a business technology-related educator in the Pacific Northwest. As such, I spend at least eight hours a day in that place where art and science crash headlong into each other, playing word doctor to the resulting casualties. Believe me, there are many. Fortunately, it seems I’m one of those who can cross the right brain/left brain divide without too much effort (though I confess to greatly preferring the right brain functions), so I’m comfortable hanging out in the middle space between them.

That also means that I spend at least eight hours a day thinking about language. Language and clarity. Clarity and efficiency. Efficiency and effectiveness. Effectiveness and … you get the point.

All this thinking has led me to conceive of the word “language” very broadly. For example, several years working in educational publishing taught me the linguistic qualities of mathematics — the grammar of how problems are written, the specific vocabulary used, and how many mathematical properties can actually be interpreted as simply finding synonyms for different “words.”

Getting to the point …

Some time ago, in an online forum for self-taught coders, someone asked a question about why learning the basics (which we can generally take to be HTML, CSS, and JavaScript) is so difficult; or rather, why it’s so difficult for some, but not for others. I replied that we’re basically trying to learn three foreign languages all at the same time. Not only that, but three foreign languages that use similar, but not quite the same, vocabularies. I thought it would be far stranger if it wasn’t as difficult as it is.

So what difference does that make? We already knew that we were learning languages, right? I mean, it’s right there in the name — programming languages. For the coders who don’t struggle, it doesn’t make much difference, if any at all. But for those who feel like they’re “never going to get it,” that their brains “just aren’t wired that way,” and that they’re “not cut out for coding,” it could make all the difference in the world. So the rest of this article is written for them.

_Photo by [Matylda Czarnecka](https://twitter.com/matylda" rel="noopener" target="blank" title=").

Learning to Speak All Over Again

Let’s start with a simple question — when was the last time you learned a new language? For many Americans, that was grade school, when they took a few years of Spanish, or German, or what have you. For some people, though, that would have been about the same time they learned to walk. No joke. If you weren’t forced to learn a foreign language at some point since then, the last time you learned a foreign language — before you started coding — was when you learned your native tongue.

Think about that for a minute. Most people say their first word at between 10 and 15 months. They don’t get a firm grasp on spelling and grammar until between 8 and 10 years old. Those that truly master the language usually only do so after several years of college.

You expect to master JavaScript in four months. As well as HTML5 and CSS3.

[Insert skeptical expression here]

So yeah, what you’re trying to do is hard.

(A Side Argument for the Love of Language)

I hate to be one of those guys, because I think it’s somewhat out of step with the self-taught coder ethos, but why is also very important. Why are you learning to code? Not too many people learn to speak so they can get a job. In fact, everyone starts out learning to speak because they need to communicate something and have found that language is much more effective than crying at the top of their lungs until someone figures it out.

In the same way, I often suspect that the people who struggle most with learning to code are the ones that don’t have anything they want to communicate. Their reason for learning the language is much more pragmatic. There’s nothing wrong with pragmatism. I think the world needs more of that, actually. It’s just harder to learn things if there isn’t a passion or some sort of more intrinsic motivation for the learning. That’s why I did really well at calculus, but not very well at basic algebra — I was way more enthusiastic about calculus. I didn’t need to be forced to learn its grammar and vocabulary and punctuation. I wanted to know how to answer the questions that only calculus could answer.

One Last Thing About Tools

_Photo by [Terry Madeley](http://href=”https://www.flickr.com/photos/terry/6156784804" data-flickr-embed="”true”"" rel="noopener" target="blank" title=").

As I’ve been learning, I’ve seen bazillions of questions about frameworks and libraries and text editors and just about everything related to coding that isn’t actual code. It’s the same thing I saw with photography when I was moderating an online critique group— beginners who feel too insecure to participate in conversations about the substance of a thing instead choosing to talk about tools and rules. I totally get it. The problem is that it can often be a distraction from the real matter at hand, because just like the real test of a camera is the photograph that results from the photographer using it, the real test of a framework or library or text editor is the code that the coder produces with it.

As I’ve been learning, I’ve been trying out some of the different frameworks, libraries, and tools out there. With environments like Codepen and Cloud9, it’s effortless to road test something new. The ones that I’ve taken to the most are the ones that simplify the grammar of coding rather than the ones that tend to the book itself.

I’ve come to think that one of the things that makes coding so hard is that some languages like HTML are about 75% grammar and punctuation and only 25% meaningful vocabulary. For example, here’s a line of HTML from one of my Freecodecamp projects:

And here’s the same line written in Jade:

button.Adjust.add(type=’button’)
i.fa.fa-fw.fa-arrow-circle-up

Naturally, I love the Jade version. It’s clear, concise, efficient, and effective. It makes the word doctor in me smile at its simplicity.

Things like NPM, on the other hand, drive me crazy. They’re basically just like having an editorial assistant whose only job is running around collecting your dictionaries every time you sit down to write something — even when you don’t actually need them. Sure he’s useful, but he’s a total distraction when he gets all amped up on Red Bull and starts breaking things.

There are times when the editorial assistant comes with the job and you can’t fire him because he’s the president’s nephew. So be it. You work with him as best you can and try not to shove him out a 12th-story window. But you sure as hell don’t go hiring your own if you don’t have to.

Of course, these are all the opinions of a maybe-intermediate level, self-taught code monkey whose interest in coding is much more passion project than ambitious career path, so take everything I’ve said with a healthy dose of “does that fit with my experience?”

As the Buddha said, “Rely not on theory, but on experience.”

(This essay began as a discussion in the Newbie Coder Warehouse Facebook group. If you’re a self-teaching coder, it’s an excellent resource.)

Because my opinions are the best opinions

While focusing on JavaScript to level up my web dev skills over the last several months, I’ve waged a silent war in my head over how everyone else seems to pronounce certain things.

Well, here at last is my declaration, and I will countenance no disagreement and no appeals to sensible arguments or respected authorities.

• var rhymes with bear, not bar

var bear = true, bar = false;

• tuts rhymes with boots, not butts
• JSON sounds like Jason, not Khe Sanh

Okay, let’s parse this …

• in regex/regexp, reg rhymes with leg, not ledge
• names ending in -ify are consciously and playfully improper. They do not follow normal accentuation rules (i.e., not like PERson to perSONify). Browserify is BROWSer-ify, not brow-ZER-ify. JSONify is JASon-ify, not jay-SAHN-ify
• jQuery is like, “Hey, Siri,” not “Hey, Jerry”

Hey, Jerry: get a job!

• favicon is a “fave icon” and does not sound like “have a naan” (but don’t mind if I do)
• SQL and its derivatives are cooler pronounced “sequel” rather than “ess queue el”

I know it may be difficult to break those habits, but change can happen. After decades on the wrong side of two bitter fights I finally own a Mac and pronounce gif with a soft G.

And so can you!