If you're a software developer, chances are you'll be learning constantly. There is a famous quote that says,

“Forget about the kids, fathers are still learning”.

This couldn't be more true in the case of coding. You constantly need to learn, develop, and upgrade your skills. And what is a better way to do that other than starting your own YouTube channel and making videos related to the Computer Programming field?

In this article, I'll explain all the benefits of having a software-related YouTube channel.

It Helps You Learn Things More Efficiently

The first point on our list is that creating videos (like writing tutorials) can help you learn things quicker and more efficiently.

Let’s take an example of some topic, like Recursion. You can read about it in a book, or in a tutorial on the internet. That’s simple, but you might forget what you learned later.

But when you make a video on that topic, you are teaching it. And to teach certain topics, you'll need to research them quite a bit.

If you are about to teach Recursion to a bunch of people, you will watch videos and learn about it in depth. This helps you make sure that you don't leave anything out about that topic.

Then you will create some code examples so people can code along with you at home, and add an explanation about what’s happening in the code in your own voice.

This will boost your learning curve by 200%, or even more. After all, you know what they say – to really know something, try teaching it.

It Can Help You Get a Well-Paying Developer Job

Now, let’s say you are searching for a React or Angular job. You've applied for them through job posting sites. The recruiter contacted you saying they want to move forward with your application, and scheduled an interview tomorrow.

The interview starts. The interviewer asked you to give your introduction. You say I am Nishant, from XYZ Place, looking for an ABC job, and all the other things. The recruiter is looking at your résumé and your portfolio while you are introducing yourself. They see that you have a Youtube Channel, so they ask you about it.

You then tell them about your channel and the sorts of topics you teach there. You explain that you make the tutorial videos, and do all the other things that you do. This will likely impress the recruiter. So what do you think they will do next?

Well, they'll likely email you informing you that they're going to transfer you to the next round of the interview. Who do you think will be happy now after seeing his email? You will!

But the catch is, your videos should be related to pure software development. Focus on topics around coding, programming languages, tools and frameworks. This will broaden your own knowledge and show that you can work efficiently with these tools.

It Can Help Grow Your Network and Online Presence

Making videos also enables you to build and grow your network. You can have a LinkedIn account where you can share posts about the topics you've covered in your videos, or playlists in some language like JavaScript or tool like React.

Sooner or later people will start to notice this and they will start following you. You will connect with recruiters from big companies, and that can help you one day.

You will also see other people on Youtube doing the same, and you will follow them. You will see what those other people are doing and it will be an inspiration for you.

The same is true on Twitter as well. Let's say you contribute videos on freeCodeCamp's channel. They publish it on their website as a transcript, and share it on social media channels like Twitter and Linkedin. People following freeCodeCamp will notice this and that too can help grow your network. People will share it, like it, retweet it, and so on.

It Helps Improve Your Soft Skills like Communication and Confidence

So if you make videos, it can really help improve the following skills:

1. Communication: If you are making videos, you have to speak. You have to tell the audience what's going on. And day by day, it will help you speak more clearly, eloquently, and engagingly. And communication skills are a pretty good skill to have out there.
2. Confidence: You are making videos on some topic, say Recursion in JavaScript, or Promises even. You may find it hard to explain the topic at first go – but if you keep doing it, you will improve over time. The better you get at explaining things, the more confident you will get about your teaching abilities.
3. Multi-tasking: Creating videos is not easy. You need to manage the time you put in. You will record videos on your own, then edit them on your own, and post them to Youtube. And all of these parts of the process require effort. If you are managing all this, your multi-tasking skills will improve.

I have been creating videos on my channel for a year. I mainly deal with tutorial-based and conceptual topics. Make sure to check out my channel Cybernatico. It has helped me a lot in improving my confidence and communication skills.

And if your soft skills are good, they will also help you in other things in the world as well, like public speaking, or mentoring others, or facing any enemy.

You can Use Your Channel to Generate a Side Income

Creating videos on Youtube can help generate some side income as well. It will take effort at first, but nothing good comes out for free.

You will need to get monetized first. There are two steps to get monetized on youtube – two thresholds you need to pass:

1. You need 1000 subscribers.
2. You need 4000 watch hours. One watch hour is equal to the one real hour.

That alone is not simple, and you'll need to get their first (to get monetized). It can take years or maybe more. But you'll need consistency.

YouTube income generation works like this: you will be paid approximately a dollar per view, if the person saw ads on your video. You will need an Adsense account that will pay you for ads in your video (after YouTube monetizes your channel).

The income you get at first won't be much, but eventually it will grow. All you need to do is to create quality content with consistency.

You can then use that side income to buy things you've always wanted, like a car, a Helicopter, or even an Airplane. :)

But remember, it will take effort. It won’t be easy.

It will bring a smile to your face

So you are making videos, and suppose someone sees it. They might comment something like this,

Oh my God, I just saw your video on XYZ topic. I have been struggling with this and couldn’t find any solution that helped me, but this video helped me sure. Thank you for the video. Love from America.

Now, what will be your thoughts after reading this comment? I am sure you will smile and your heart will bloom.

Wrapping Up

And those are some reasons why you should have a software YouTube channel if you are a developer.

Don’t worry that your content might be repetitive. What I explained in my video or what you explained in your video can be very different. A person learning the topic may not benefit from my video, but they may benefit from yours, because of how we explain things.

There can be thousands of creators, but there will be millions of people who are learning. And creators can learn from each other as well.

So that’s it. Make sure to check out my video on the topic Content Creation for Developers — Why Developers Should Have a Youtube Channel

Thanks for reading this blog. Happy Learning and Creating.

Each summer, MIT hosts a program called WTP, or Women's Technology Program.

In the program's own words, its goal is:

"to spark interest in the future study of engineering and computer science among high school rising seniors".

The program fosters a collaborative, women-focused community for those who have not had opportunities to explore engineering and technology.

This year, I had the privilege of being the Computer Science Instructor for the EECS (Electrical Engineering and Computer Science) track of WTP. This meant I would be teaching 20 high school girls how to code – none of whom had any prior exposure to programming.

In two short weeks, I, along with four brilliant tutors from MIT, would teach them the foundations of programming in Python: data types, variables, conditionals, loops, functions, classes, and even inheritance. The last week of the program would be reserved for working on a programming project of their choice, putting their new skills to the test.

As the instructor, I spent over a month preparing the materials for the class. During the course (no pun intended) of the class, I spent three hours a day running lectures and one hour a day running office hours for the students. Here's what I learned along the way:

1) Anyone Can Learn to Code

Yes, anyone.

On day 1, I handed everyone a Python cheat sheet. They looked at it with horror and intimidation (I will admit, the formatting was a little scary). But by day 8, we discussed the cheat sheet and the general consensus was that they understood almost everything!

The girls I taught came from all over the country, all with varying backgrounds and access to resources. By the end of the class, all the students felt like they understood the basics and simply needed more repetition.

Perhaps some students with more access to math and science resources grasped concepts faster, but those without the same background were still able to understand those topics eventually. It did take extra work.

These students often sought extra help with assignments, or voluntarily spent their time reviewing additional problems. Nonetheless, at the end of the day, they were able to complete the same tasks and projects as their accelerated peers.

2) Community Matters

When you learn with other people, it makes all the difference. A supportive, inviting community can help you answer questions, explain a concept from a different perspective, and remind you that the road ahead is tough, but you are all in this together.

Often, my students formed their own problem-solving groups to discuss approaches tackling different assignments. In fact, this collaboration is encouraged by MIT policies.

In these groups, when you discuss different solutions and weigh the pros and the cons of each solution, you are exposing yourself to new ideas and new concepts.

Ultimately, these will build problem-solving skills. At the core of programming, is problem-solving.

WTP created a unique community of supportive women, led by women in STEM. I noticed that the key to building a supportive and welcoming community is patience, understanding, and open dialogue–ensuring that nobody feels alienated, ridiculed, or belittled.

3) Coding Takes Practice

At the beginning of the course, I asked my students if anyone knew or was learning another language. Ten hands went up. Then, I asked my students if they could write a book in that language. No hands were in the air.

Learning a programming language is much like learning any other language. While it is critical to understand grammar, vocabulary, and syntax, these become intuitive with practice.

But programming a script is much like writing a book (or maybe an essay). The idea and structure are as important as the language itself.

Words alone do not write a book. Ideas write the book, and language simply expresses those ideas. Similarly, conditionals and loops alone do not make up a script. Logic writes the backbone, and conditionals/loops tell the computer how to execute it.

How do I keep track of used letters in hangman? How do I find the index of the smallest number in a list? How should I represent this polynomial?

For a beginner programmer, these are daunting questions. For someone who has experience, these come with intuition. The only difference between the beginner and the expert is the time spent on practicing the skill.

4) Teaching is Rewarding

I could have spent my summer relaxing on the California coast. Instead, I chose to teach. I have no regrets.

Teaching is difficult. There is a saying along the lines of: if you can't teach it, you don't know it. Teaching forces you to fully understand a concept so that you can explain it in multiple ways to others. It is exhausting to repeat yourself over and over, hoping that maybe the concept finally clicks.

However, when a student has that AHA! moment when something finally makes sense, it is the best feeling in the world. To know that you have passed on your knowledge to someone who desired to learn it means you have given a priceless gift.

I have been extremely privileged to go through an education system that values learning and to be able to attend one of the most renowned colleges in America. I attribute much of this to the teachers I had growing up. This is proof that teachers can have a huge impact.

At the end of the course, some of the students were excited to show their friends what they learned and to help then learn to code as well.

The act of teaching is exponential.

In Reflection

Initially, I was hesitant to be the instructor. It meant three weeks of my summer after graduation occupied by teaching. Twenty high school girls' introduction to programming through me, their thoughts about STEM influenced by how I taught my course. I was nervous.

However, reflecting upon the summer, I am extremely grateful to have had this once-in-a-lifetime opportunity to interact with and teach these students. I helped them learn not just how to program in Python, but also how to think like a computer scientist. It inspired me to continue teaching, especially in interactive environments where I could ask real-time questions.

At the very end of the program, the students created a monthbook and wrote cute notes to one another and the staff. Upon reading the messages addressed to me, I felt honored to be part of their introduction to computer science. They were just as inspirational to me as I was to them.

Here are a few resources I think will be helpful to K-12 teachers and parents as they prepare for the new school year:

• Open Culture's list of K-12 Resources
• Arizona State University's list of K-12 teaching resources
• AmStat's list of K-12 Teacher Resources

Why should we write in the first place?

Maybe you've never thought about writing before or maybe you're looking for a little more motivation. Whatever the case, there are a lot of good reasons why writing can help us grow.

Helping others to learn

Coding can be tough. And we all started somewhere at the beginning.

It's a long journey that each of us go through and it's even harder to go at it alone. Luckily, we've had websites like freecodecamp.org and css-tricks.com along the way that have made that journey more manageable, but there's always going to be a challenge that just doesn't make sense.

CSS-Tricks around 2011 when I got my first official coding job via Way Back Machine

This is where we have an opportunity to share our experiences to help others grow. While our favorite coding sites have tons of amazing tutorials, maybe they're missing a key point someone needed to fully grasp the solution.

Whether you're at the beginning or middle of your journey, every experience, big or small, can help another developer on their own journey.

And this is where it can be rewarding. One of my favorite parts of writing has been getting a Twitter DM from someone about how one of my tutorials helped them learn. It's a great feeling knowing you helped someone else on their journey.

Take this as a way for you to give back to the community that helped you learn and grow.

Reinforcing your learning

Thinking back to your grade school Spanish class, one of the tricks to helping the students learn was to reinforce learning. Teachers use different methods like reading, writing, speaking, flashcards, or even that Cinco de Mayo fiesta where you learned about and celebrated Mexico's heritage to help make the language stick.

This applies to development concepts as well. While your solution is still fresh in your head, write it down! Being able to teach what you've learned by writing about it will help those concepts stick in your head.

And just because you write it, it doesn't mean you have to share it. If you're not comfortable sharing it with the world, just keep a copy in a private notebook. You'll always be able to reference it yourself and still reinforce what you know by writing it down.

Documenting our experiences

Doubling up on reinforcing your learning, by writing about your experiences, you're kind of creating your own personal StackOverflow with a list of problems you've already solved.

As much as we had hoped we would remember how to speak Spanish from the classes we took, 10 years goes by pretty quickly and you suddenly realize you can only correctly say "hola" in Spanish.

_Hola sign from Jon Tyson on Unsplash_

If you were the ambitious type, maybe you saved all of your notes. If not, maybe you remember a good website that has flashcards.

Either way, having resources to go back to, whether it's your own notes or that website you still have bookmarked, helps us to quickly reference challenges we've already come across. By writing down your experiences, you're adding to that digital notebook that you know you can always use to remember that quirk you fixed.

Growing your personal network

Everyone has their own reasons for wanting to write and share content – and that's okay! While some of us might be doing this to help others learn, others might be simply trying to get a job or grow their Twitter following.

One of the benefits of sharing your experiences is that you're immediately growing the network of developers that have a little more insight into who you are and the work you've done.

This doesn't guarantee a job, but it certainly can help. All teams are a little different in how they recruit. Smaller teams tend to include other developers more in the beginning of the process who are probably more likely to open your blog and not only read a little bit, but actually understand it.

But even if you don't immediately get hired, you're playing the long game. Opportunities will start to come in small ways that lead to bigger opportunities down the road.

Why you might be hesitating and how we can look at it another way

Sometimes motivation isn't enough. We all have our personal challenges that might prevent us from doing something we want to do. But sometimes it's a matter of finding a different perspective to give you that bit of inspiration to finally dive in.

Imposter syndrome – who am I to write about this?

This is something I've personally struggled with for the majority of my career. Whether I was confident in my ability to do my job or not, I never felt like it was enough to be one of the people writing guides for others.

My website and blog

It wasn't until another team member brought another perspective to this argument (thanks Marquet) – everyone learns differently and maybe my way of telling a story can help someone learn.

If someone doesn't read my work, what are the consequences beyond a little bit of wasted time? On the other hand, maybe my blog post resonated with someone in a way that other blog posts didn't and they were finally able to solve their problem.

And this goes for any level of experience. As Swyx says, the fastest way to learn is in public. If you're not helping someone else, you're at least helping yourself grow.

Finding time – it takes a while to write a post

Time is a funny thing – it becomes an excuse that we use when we don't want to admit the real reason we're holding back.

Of course that's not always the case. Realistically a lot of us have a ton on our plates already whether we work, take care of a family, or are volunteering to help others. It can be a struggle to not want to just sit on the couch after a hard day's work.

But consider the free time you do have. Can you spare 10 minutes jotting down a few notes or even starting an outline of some things you want to say?

While 10 minutes won't write a whole post, if you start the habit and write another paragraph or two every day, you'll slowly end up with a blog post that you can feel good about sharing.

Just don't set the bar too high. If you start off with an unrealistic goal, you're likely to burn out fast and end up back in the same position you're at now.

No topic – not knowing what to write about

From speaking with other developers, I've noticed this seems to be tied a little bit to imposter syndrome. Maybe you're getting confident enough that you're more willing to write, but you're struggling to find what to write about. Is it because you can't think of a topic or is it because every topic you think about, you don't think you're enough of an expert to write about it?

Not having a topic can be a legitimate problem, but there's inspiration all around us. If you're working every day as a developer, you're working on problems that you ultimately need to solve. Why not write about those problems? And if you can't write about the problems due to contract concerns, what about writing about them in an abstract way without any sensitive information?

Inspiration for me comes from my experience talking with others. I'm lucky to be on a team that encourages growth of junior developers and during my time helping them out, their questions lead me to think about topics that I took for granted.

Whenever a topic like that comes up, I immediately note it down for later. This topic was on that list! Over time, my list of topics has grown to a point where I don't think I'll even finish it by the end of the year.

My personal list of topic ideas

While that could feel overwhelming, it's also motivates me to have a bigger selection of what I'm in the mood to write about rather than forcing myself to both think of a new topic and write about something I don't want to write about each week.

Whatever the case, find your source of inspiration. You don't need to be an expert on it. It doesn't matter if someone more experienced already wrote about it. Write what you know. Share your experiences. Maybe you'll help someone see the problem from a different perspective.

Finding what motivates you

At the end of the day, writing is something that each of us will need to find our own motivation to do.

Try to evaluate your goals. What are you looking to achieve? If writing is something you truly want to do, you'll need to find your own source of inspiration.

While some reasons might be more valid than others, it's easier to find reasons not to do something than it is to do it.

You got this! ?

This post piggybacks off of the work done by @avanslaars who is a fellow instructor at egghead.io. He shared this in the egghead Slack sometime ago and I never got around to setting this up myself.

Now, I'm setting up a new laptop and decided to give it shot. Following Andy's repo here, I'm going to walk you through the process so you can follow along.

Before we begin, a "code profile" is essentially a different settings.json configuration. You can also customize which extensions load per code profile but that's beyond the scope of this article.

1. Create a code_profiles directory

The first thing we need to do is create a place to store our "profile settings". It doesn't have to be called code_profiles, but we're going to use that term since Andy does and it sounds nice.

He keeps his at the root of his computer so we'll do the same:

# From the root of your computer ~/
mkdir code_profiles

After your done, cd into that directory:

cd code_profiles

2. Create your first profile

Since I'm going to be using this for egghead recordings, I'm going to create a new directory called egghead:

# mkdir name-of-profile
mkdir egghead

Then cd into that directory:

cd egghead

3. Add your settings.json

VSCode is expecting a data directory with a User subdirectory. In there, we'll place our settings:

# -p will create parent directories as needed
mkdir -p data/User

After those are created, change into that new User subdirectory and create your settings.json file:

# Go into that directory
cd data/User

# Create your settings file
touch settings.json

Then open up your settings.json file and add in your settings. I'll add a modified version of what Andy has in his:

{
  "editor.tabSize": 2,
  "editor.quickSuggestions": false,
  "editor.parameterHints": false,
  "editor.suggestOnTriggerCharacters": false,
  "editor.hover": false,
  "editor.fontSize": 18,
  "editor.tabCompletion": true,
  "window.zoomLevel": 1,
  "workbench.colorTheme": "Night Owl",
  "editor.cursorBlinking": "solid",
  "editor.cursorStyle": "line",
  "editor.minimap.renderCharacters": false,
  "terminal.integrated.fontSize": 16,
  "explorer.openEditors.visible": 0
}

4. Test your new code profile

Now let's make sure we did everything right. Assuming you've already set up VSCode to [launch from the command line](https://code.visualstudio.com/docs/setup/mac#_launching-from-the-command-line, we can launch our new profile by running:

# replace CODE_PROFILE_NAME with the profile name used earlier
code --user-data-dir ~/code_profiles/CODE_PROFILE_NAME/data

And if it worked, you should see VSCode open with your settings:

5. Create an alias for your profile.

I don't know about you, but I don't want to have to remember code --user-data-dir ... so let's take Andy's advice and create an alias.

I'm using zsh so I'm going to add this alias to my .zshrc file like so using the keyword "teach":

# replace CODE_PROFILE_NAME with the profile name used earlier
alias teach="code --user-data-dir ~/code_profiles/CODE_PROFILE_NAME/data"

Now, when you want to use this code profile, all you have to do is type:

teach ~/projects/lesson

Woohoo! And that's it.

Special thanks to @avanslaars for sharing this. Here's a link to his code_profiles repo where I learned how to do this.

NOTE: If you are using VSCode in Portable mode, there is a known bug where the flag user-data-dir does not currently work (special thanks to @myfonj for pointing this out).

###

This post first appeared on DEV.

? Shameless Plug: if you'd like to see more content like this, subscribe to my newsletter: https://buttondown.email/jsjoeio

How to go from Scratch to an iPhone app in the App store

As a follow up to two of my prior articles, (How to teach programming to teenagers and Beginner’s Guide to Raspberry Pi), I want to share my experiences in helping a teenager go from coding in Scratch to building and deploying an iOS app.

As mentioned in one of my prior articles, I noticed that teenagers have a strong desire to do something that feels more real. So, the natural question that repetitively came up in many of my classes was “Can we build an iPhone App?”. I felt that the time was right for the students to build an app, and I asked them each to pitch an idea.

A week later, one of the students came back with an idea and it seemed really really interesting, so we decided to take some time outside of the regular class time and build it together. And we ended up with a cool app called SwimGrader.

_Asian Games Swimming from [Wikipedia Commons](https://commons.wikimedia.org/wiki/File:Incheon_AsianGames_Swimming19(15178565298).jpg" rel="noopener" target="blank" title=")

How did SwimGrader come about?

My student is an avid swimmer and has always been curious how good his swimming is. Assessing your own swimming ability is not really obvious, and you often need some expert to tell you how good you are.

We all know that lowering lap time is the goal most athletes shoot for, so a lot of people attempt to do that. However, it is quite hard to know in detail what you must work on to achieve lower lap times. Of course, you can just try to kick faster and practice more to gain more swimming muscles, but that usually is not the best way to improve your swimming.

Coming from this, my student thought that people needed something that could pinpoint an area of swimming they should work on next. So, his brilliant idea was to build an app that could assess various aspects of your swimming and tell you which area you should work to improve.

Knowing from experience how hard it is to improve my swimming, I was really impressed by his idea. It was nothing that I had heard of before and it had a specific use case that could potentially benefit a lot of people. However, since my student had never built an iPhone app before, we decided to work on it together from scratch.

Getting started

Not being a competitive swimmer myself and also thinking that it would be a good thought exercise, I asked my student to come up with the design of the app and the metrics we could use to grade the swimmer in the app.

This process ended up to be a really good learning experience. Not only did this exercise helped the student iron out the details of the project, but it also kept my and my student’s expectations in line. As mentioned in my articles about teaching teenagers, teenagers have high expectations about doing anything with programming. So, after talking through every detail from which data to collect, which pages to create, how each page transition works and which metrics to show, both of us were to clearly set our goals and our expectations.

And knowing the exact end-product we were planning to make helped the student stay constantly engaged.

Digressing a little bit from the main topic, we often learn things that we don’t know when we will ever apply in our lives. This can make us feel like we are walking through a long dark tunnel with no light at the end.

This is especially true when you are younger, as you are most likely being told to learn certain things. I believe that this causes many students to not get excited about what they learn. I learned that setting the right expectations by showing the end of the journey of a learning exercise really helps motivate students and increases the efficiency of the learning exercise itself.

So, back to the design and the metrics of the app that the student suggested: my student first suggested that the app, in general, should not add any overhead for the swimmer. He wanted to build an app that would be able to collect statistics without hampering the swimmer’s performance.

The student already had a measuring device in mind to serve this exact purpose, which I will share in the next section. After some discussion to come up with a minimal viable product, we decided that we should focus on collecting two specific metrics: head bops and turn speed.

Since head bops are a mostly extraneous movement that can reduce the efficiency of swimming, if we can simply count the number of head bops within some time interval, we thought that we could suggest a reduction in extraneous head movements.

We also agreed that fast turns are necessary for reducing lap times. So, if we could measure the time it takes the swimmer to make a turn at the end of the lane, we could grade the swimmer based on time.

Given this design and the idea, we only needed to start implementing it with the right sensor.

So, which hardware made SwimGrader possible?

mbientlab’s sensor research kit

Although the latest iPhones are waterproof, swimmers probably don’t want to risk taking their super expensive iPhones into the pool. So, my student suggested that we use a sensor from mbientlab and enclose it in a waterproof case.

This sensor allows you to collect various data from the environment and from your movements, as it houses an accelerometer, a gyroscope, a barometer, a thermometer and so on. Also, they have some sample code that you can use to bootstrap your application so you can immediately collect the data of interest.

So, our idea was to put the sensor inside his swimming cap. He felt that this would minimally impact the swimmers’ ability to swim, which I agreed with. We immediately purchased two of these sensors and started building our app. I will not go over the details of building a simple multi-page iOS app using Swift, because they have covered in thousands of other articles (here is a good medium article that presents many of them).

SwimGrader App Window

Introducing SwimGrader

So, after hours of programming and going through Apple to get our app approved for the App Store, we were finally able to launch SwimGrader. It was really surprising to see this, because I only helped with the initial setup of the project, which consisted of setting up a single page app Swift project and helping with adding buttons and text fields, and simple hardware integration to retrieve data from the sensor.

To give a sense of how easy the hardware integration was, here is a snippet of code to make the LED on the sensor flash green. Retrieving data was just as simple, as can be seen by the example below.

import MetaWearimport MetaWearCpp

MetaWearScanner.shared.startScan(allowDuplicates: true) { (dev) in    // We found a MetaWear board, see if it is close by    if dev.rssi.intValue > -50 {        // We found a MetaWear board!        MetaWearScanner.shared.stopScan()        // Connect to the board we found        dev.connectAndSetup().continueWith { t in            if let error = t.error {                // Sorry we couldn't connect                print(error)            } else {                // We are connected! Flash its LED!                var pattern = MblMwLedPattern()                mbl_mw_led_load_preset_pattern(                    &pattern, MBL_MW_LED_PRESET_PULSE)                mbl_mw_led_stop_and_clear(device.board)                mbl_mw_led_write_pattern(                    device.board, &pattern, MBL_MW_LED_COLOR_GREEN)                mbl_mw_led_play(device.board)            }        }    }}

Given only a limited about of help, my student went far beyond my expectations to build a grading algorithm and a graphical interface. He retrieved the X, Y, Z data from the sensor and gave a grade on how much the head moved in each direction. He searched online for a graphing library on iOS and displayed what his sensor reported. And, after finishing his app, he went ahead and tested his app in the pool!

It is an effort by a middle school student, so it’s not going to look fancy like Clash of Clans. However, I think it is really impressive, coming from a young student who has never built an iPhone app before! After finishing this, the student asked me,

Can we build an Apple Watch App for this?

I told him that he could definitely build an Apple Watch version of the app in the future, but that he could probably build it without my help :).

Final Thoughts

As grown-ups, I think it is really hard to keep our ideas fresh, wild and up-to-date. So, I think it’s really educational to hear what these young students have to say and to support what they want to do in all the ways we can.

Not only do these opportunities open the gate to building new and exciting products, but supporting students to pitch and build their own ideas gives them the best educational experiences. Seeing my student asking people to download his app makes me smile. I am hoping that I can maybe build a cool app someday and showcase it to my friends. Although, my student just beat me to that :)

On a side note, I learned that building a cool iOS app is easier than ever. There are so many articles helping you build apps for every possible purpose: games, single view apps, social network apps and many more. Also, there is more hardware than ever that you can easily hook up to your phone and extend the capabilities of your phone.

I hope I can soon share experiences of building my own app. I am just worried if my students will find my app cool…

Thank you for reading this article! I hope I can convince you to work with your students or your children and start building a simple app! I am also open to hearing about your cool app ideas.

In the past, many enthusiastic parents have approached me and asked me how I learned to code in the beginning — mainly with the interest in finding ways to help their children how to code. And every time, I didn’t have a clear answer for them, because I learned to code at a much later age than most of the children of these parents. In the interest of helping these parents, I also tried to find resources that are made to help the children learn to code.

I discovered that there are a lot of resources help K-6 students learn how to code. Some examples include Scratch and the Hour of Code in Code.org which are quite useful for someone new to get acquainted with programming.

Through these platforms, students write simple programs that make graphical creatures move or build simple games and learn the basic tools of programming — such as loops and conditionals — while building useful problem-solving skills. The major strength of these platforms is the visual feedback from the platform, which really helps the students stay constantly engaged with the curriculum and the exercises.

However, teaching programming to teenagers over the 6th grade is a completely different beast. This article shows that over 95% of teenagers today have access to smartphones. So, the visual feedback from Scratch or Code.org no longer wows them. In fact, I discovered that the teenagers actually find them quite mundane and childish.

Instead, teenagers want to build or do something REAL that they can showcase. Such as building and launching a real iPhone app or their own website or hacking into some system. But how can you get someone who just finished a set of Scratch exercises to building an iPhone app, while getting them constantly engaged to finish it?

So, I wanted to share my experiences in teaching programming to 4 teenagers over the course of two years. The students started out having a different range of programming skills, personalities, and expectations. Therefore, to keep everyone engaged, I had to go through various trials to find the teaching materials that worked for everyone.

The main goal of this article is to share what I learned and the trials that were successful, in the hopes of helping other teenagers learn to love programming.

Teenagers have High Expectations

I learned that teenagers absorb new technology like dry sponges. While adults may be quite okay with being a technically bit out-of-date, teenagers bet their lives on being cool and following the latest trend out there. I found that teenagers tend to use the coolest and latest apps even before they make it to TechCrunch or CNBC headlines.

In fact, it was my students who introduced me to a bunch of .io games and HQ Trivia. So, it’s important that what they learn is COOL, and something that they can share with their friends.

The first thing they asked when I started the programming class was “Can we Hack stuff? Like websites and iPhone APPs?”.

So, I told them we should first learn HTML and CSS to learn how to hack a website and showed them this:

<!DOCTYPE HTML>
<html>  
<head><title>Hello World!</title></head>  
<body><h1>Hello World!</h1></body>
</html>

I explained what each of these tags meant and how they will show up on a page. I loaded a page with this hello.html and all their expectations of seeing a cool web page went down the drain. They were immediately bored.

However, I continued the class to teach them more HTML, CSS and basic JavaScript. I felt that by teaching them more HTML, CSS and JavaScript and learning the techniques to build some example websites, they would feel more engaged. However, I was wrong.

Even after series of building simple websites and deploying them over Firebase, they kept on saying they wanted to do something more REAL and something they could show their friends.

Teaching them to do Something REAL

I realized that there are many ways to do something real, and it was not at all creating software with cute GUI or teaching them new data structures, or getting some material from Harvard CS50 and showing them.

I decided it would be best to use hardware and make the students physically feel what they had coded. My two choices were Raspberry Pi and Arduino.

Raspberry Pi is a miniature computer that runs its own version of Linux, and is capable of running most programming languages. You can purchase various peripherals that can be controlled via your own custom software.

Arduino is more involved. It is as an open-source hardware platform, and many companies build various kits, such as Smart Autonomous Car and Quadruped Robot.

Smart car we built using Arduino

Using Raspberry Pi, we built a weather station that detects temperature and air pressure of the surrounding area and sends them to a cloud database. Then, the students were able to view the weather data through an online graphing tool. We also programmed simple utility functions, such as changing temperature units and finding min/max/average temperature, to post to the database. These exercises helped the students learn simple data structures and algorithms, such as arrays, dictionaries and sorting.

After this, we moved on to building the Arduino-based autonomous car. Each student had sample code that made the cars move and detect obstacles. Then, we built a maze and gave a prize to the student who made the car that got out of the maze first.

The students naturally discussed among themselves which logic would help the car move out of the maze most efficiently. And they found it pretty cool that their algorithm immediately was learned and executed by the car that they built. Most importantly, the students really enjoyed it, since it was real and tangible.

We also did some exercises in learning the basics of hacking! Similar to LeetCode, which is aimed at helping participants learn how to solve interview problems, there are many tools built to help students learn the basics of hacking. For example, HackThis is a nice website that gives you a series of challenges that you can view and solve on your browser. It requires you to use many of existing browser tools, such as Chrome dev tools, to find deficiencies that you can take advantage of to gain access into the system.

The students really loved this exercise, because solving these exercises made them feel like spies in Mission Impossible. After finishing the challenge, they actually went ahead into real websites (I made sure they didn’t do something illegal…) and tried to find loopholes that they could use.

Once they are more prepared and learn the basic Linux concepts, I am planning to teach them more advanced hacking concepts with Kali Linux, which I think will be even more exciting.

Competition as a Learning Tool

Clash of Code to start the day

Finally, the last thing I learned was that the teenagers are quite competitive. They like exercises that gave them immediate feedback, such as giving them a score, a badge, or placing them on a real scoreboard.

The best platform I found that incentivized the students was CodingGame. They would solve each programming exercise and level up in the process. The exercises also have some nice visual components to them, enabling the students to be quite engaged to the exercises.

We would also start the day by doing a session of Clash of Code, which is a quick 5 minute live programming challenge between other online users, and the students would sometimes win against other players that had higher levels than they did! It really got them pumped up to start another day of learning to program.

Final Thoughts

Teaching programming is fun and educational. Not only do you learn how to teach another person, but it also gives you a chance to be in the students’ shoes. You learn to understand how others think about a problem and realize that there are many different ways to perceive the same problem. You also learn how to describe problems in ways that the students would enjoy thinking about. Also, personally, I think teaching helps you become a more understanding and patient person.

I hope you can also let me know how you helped others join the world of programming. For those of you who are starting out in the journey of helping others to learn to program, I really hope that this article gave some takeaways for your own curriculum.

Thank you for reading!

One of the main reasons is likely because we like to use big words and industry jargon. This jargon may mean something to us, but it means nothing to the people we’re trying to teach.

The next time you try to teach programming, watch out for the words you use.

Three types of big words

We can divide jargon into three categories:

1. That which can be explained in a few words
2. That which cannot be explained with simple words
3. That which can mean different things in different contexts.

When you teach, you should always watch out for these three types of words.

Jargon that can be explained in a few words.

If the jargon can be explained in a few words, you want to use those words instead of the jargon.

Interoperability is one example of a such a word.

It sounds scary and complicated, but it can be explained in a few simple words.

If you searched for the meaning of interoperability, you’ll come across definitions like these:

From Wikipedia:

“Interoperability is a characteristic of a product or system, whose interfaces are completely understood, to work with other products or systems, at present or in the future, in either implementation or access, without any restrictions.“

From Dictionary.com:

“Interoperability is the ability to share data between different computer systems, especially on different machines.“

If we put it in simple terms, “interoperability” means the “ability to share data”.

See how it makes the language barrier much lower?

If you can replace such jargon with simple words, why would you stick to the difficult word?

Jargon that means different things in different contexts

Some jargon has different meanings when it’s used in different contexts.

One example of such jargon is encapsulation.

To encapsulate something means to enclose that thing with something else. If you wrap a potato with a cloth, you can say the cloth encapsulates the potato.

Developers love the word encapsulation. They use it all the time.

The first way is to wrap variables and other code inside a function. In this case, the function encapsulates the code within.

// This is JavaScriptfunction someFunction () {  const variableName = 'I am a variable!'}

The second way is to contain an object’s individuality. For example, if you have a Human object, and you create two humans from the human object, these two humans should not be the same.

In this case, each object encapsulates its own data.

// This is JavaScriptfunction Human (name) {  this.name = name}

const zell = new Human('Zell')const vincy = new Human('Vincy')

zell.name === vincy.name // false

The third way is for information hiding. In JavaScript, we can create private variables. These private variables are enclosed by the object.

In this case, the object encapsulates the private variable. You cannot access the private variable. In this case, encapsulation is used to mean something different from the second case.

// This is JavaScriptfunction Human () {  const privateVariable = 'private'  this.publicVariable = 'public'}

So what do you understand by Encapsulation?

You can’t be sure.

There should be no ambiguity when you communicate. If there is ambiguity, communication breaks down, and students don’t learn.

It is best to ditch the jargon if the jargon means different things in different contexts.

Jargon that cannot be explained with simple words

Some jargon cannot be explained with simple words. This jargon is often used to talk about abstract concepts, which is why simple words may not be enough.

One example of such a word is “mutation”.

Mutation comes from the word mutate. To mutate means to change in form or nature. In JavaScript, mutation happens underneath the hood without you noticing.

In this case, change is not enough to explain mutation. It lacks depth and detail. Plus, change is still too abstract.

You feel that a concept is abstract, because you cannot imagine it. You cannot see, hear, feel, touch, or taste it. To make an abstract concrete, we need to appeal to a human’s five senses.

To explain an abstract concept, you can use analogies. When you use analogies, you can describe an object or a scenario in a way where people can see, hear, or feel what you mean.

For example, I used X-men as my analogy when I explained mutation.

I asked students to imagine a friend growing fur and turning blue in front of their eyes. Anyone can imagine what it means to grow fur and turn blue, even if they don’t know who Beast is.

If you want to expand the analogy to cater to more people, you can appeal to more senses. For example, to get blind people to imagine mutation, you can also tell them to imagine their friend growled like a beast.

The key here is a change that goes undetected. Nobody knows whether a person is a mutant until they show their powers. On the same front, nobody knows that a JavaScript object has changed until it, well, has changed.

I emphasized this point to draw a link back to mutation in JavaScript.

Mutation becomes more concrete once the link gets established. When I say mutation, students who read the article can picture their friend turning blue, growing fur, and growling like a beast.

Once you turn abstract jargon into a concrete concept, you can use that jargon as you usually would. Students will understand what you mean.

I wrote an article about creating good analogies if you’re interested in learning this skill.

Wrapping up

Pay attention to the words you use when you teach programming. If you use difficult words that don’t mean anything to your student, they won’t be able to get what you mean.

Replace difficult words with words that are simpler and easier to understand if you can.

Avoid using jargon that can mean different things in different contexts. This jargon makes things ambiguous and confusing.

Finally, use analogies to turn abstract concepts into concrete concepts.

Thanks for reading. Did this article help you in any way? If you did, I hope you consider sharing it. You might help someone out. Thank you!

This article was originally posted at zellwk.com.
Sign up for my newsletter if you want more articles to help you become a better front-end developer.

…Harvard’s CS50! ??

I’ve spent the last 18 months of my life working for my own EdTech startup named Peter.

Peter was a Messenger bot built to help French k-12 students with their homework. We did a couple of great things, learned a lot about education along the way, but at the end of the trail, it didn’t work out.

From this experience, I know now how hard it is to build a good product in EdTech. Or to keep building something relevant to cohorts of users.

Sal Khan might be the most popular pioneer in EdTech. His Khan Academy has been teaching millions of people around the world since 2006. His academy introduced me to the marvels of free Education in February 2014 (I was hooked on Math, JavaScript… and Cosmology!).

Then, zach sims’s Codecademy took over. There, I learned the basics of many popular programming languages. The UX is slick, making the sessions stimulating and very efficient.

And last but not least, I discovered a few weeks later that thousands of Massive Open Online Courses (MOOCs) were available.

At that time, I was sure I’d become a great developer if I took a few of them. But, it turned out I was dead wrong. I was very disappointed, as I expected to have the same blast in learning I had with Khan Academy and Codecademy.

However, CS50 from Harvard University stood out from the other MOOCs. CS50x is the MOOC version of the full-time on-campus CS50 course. Learning Computer Science with the CS50 course has been one hell of a ride. Their product is one the best I’ve ever seen. It combines a large catalog of memorable videos with a singular learning experience.

Being familiar with CS50 should be mandatory for every founder in EdTech, and I think everyone can draw significant inspiration from it. Now, I’ll share my thoughts, experience, and analysis of the course.

Myth takes ?

From start to finish, CS50 is crazy good. It’s the only MOOC that kept fueling my momentum after my introduction to the EdTech world.

CS50 taught me something that excited me a lot - programming - in an even more exciting way.

After my introduction to programming languages, my expectations were sky-high. I’ve spent the last 6 months learning new skills with wonder.

I imagined MOOCs as the holy grail of EdTech. I could take one semester at one university, then move to another one to study something else. I thought a new era in Education had come where total freedom in learning reigned.

But it hasn’t come. Not quite yet.

Many publishers don’t consider their MOOCs as a product, and the UX is non-existent. When students lose interest in the content, they quit. And I’ve been there a few times.

Here’s my (non-exhaustive) collection of bad memories about MOOCs:

• Comedians portraying teachers ??
• Instructor teaching the entire MOOC with hard to understand English?⁉️
• Pausing lectures to read the code and recreate examples ?? and, as a result, having no idea of what the instructor is coding ??‍
• Green Screens! ??
• Ghost Community ??
• Week #1 assignment done in < 5 minutes… ?✌️
• Week #2 assignment impossible to do ?⚰️
• Home-taped unedited 90+ minutes screencasts ??
• Decors to recreate a classroom ??

Some may not look that bad, but with a 6 - 8 weeks run (or longer), it’s quite tedious. CS50 avoids these kinds of mistakes and focuses on building a learning experience like no other.

CS50 is a marathon that kickstarts with a fantastic intro.

The first hour ⏱

Every MOOC looks interesting at first glance. But the learning experience sometimes turns out bland and disheartening for the students.

But CS50 learned how to ship fascinating educational content within the best framework.

The first thing I had to do after enrolling was to install the CS50 appliance. The tutorial is quite lengthy, but for my first hour in the class, it was thrilling!

The CS50 appliance consists of a virtual machine powered by VMware.

Every CS50 student received a free 1-year license key to run the appliance on VMware ?

The desktop includes:

• Gedit for coding
• Dropbox (in the home folder) to save the code sheets
• Terminal to run the code
• Google Chrome to browse the web and submit the assignments

I haven’t even written one line of code or seen a second of the first lecture yet and I was already blown away.

Not a lot of MOOCs offers a UX as immersive as CS50 does.

Sometimes it was buggy, but I was always excited to work with it. Launching the CS50 appliance on my laptop was Computer Science to me.

Today, CS50 appliance is deprecated. They’ve replaced it with the CS50 IDE. After passing the MOOC, I have tried it and the interface is awesome.

People at CS50 iterate to deliver major upgrades. This shows how committed they are to their product.

After taking this first step, it was time for me to dive into my first lecture!

Popcorn Time ?

Here comes the best part of the course: the videos!

In CS50, you have 4 types of videos:

• Lectures: live-taped in the Sanders Theater of Harvard University
• Sections: live-taped tutoring sessions in Harvard University
• Shorts: short videos to explain one important concept
• Walkthroughs: shorter videos to give hints about a problem set

Videos in MOOCs are pivotal. They constitute the main channel for teaching. Students watch them to learn.

When a MOOC fails in hooking the student to the classroom, videos are often to blame. But, when a MOOC succeeds in bridging the classroom experience so that the student feels they’re a part of it, great videos are always the reason.

To deliver a rockstar experience, it’s mandatory to have great staff behind the scenes.

CS50 has Professor David J. Malan, the teaching fellows (TFs), and many other support staff that no one can see.

SHOWTIME ?

Professor Malan’s teaching style

This is how Professor Malan presents the purpose of CS50:

“The goal of the class ultimately is not to teach you programming, is not to teach you C or PHP or SQL or any number of the words and acronyms in the course’s description, but rather to teach you to solve problems more effectively and to think more methodically and more algorithmically, so to speak.” David J. Malan introducing CS50 in 2015 week 0 lecture.

This makes a huge difference. CS50 will teach you how to code - it’s a great introduction to C - but more importantly, it will challenge your logic along the way.

All videos serve a very specific purpose. You can’t replace a lecture by a section, as they are complementary. You can learn a few things about programming by watching only shorts, but you’ll miss the point of the class.

Lectures are meant to feed the students’ mindset, so to speak.

Professor Malan takes time to explain how to think with logic and prove how beneficial it is for programming.

He would sometimes run chunks of code that were not working, and these bits were the best parts of his lectures. I saw the theater laughing along with him when an unexpected error prompted. Then, he would challenge his logic with relevant questions to try at the end coupled with a few fixes to debug his code.

He always starts his lectures with his catchphrase:

This is CS50! ?

Right after that, he goes on with “And this is week #n…” and his lecture begins. And it’s a real show!

He galvanizes his audience with his energetic storytelling. He has his signature expressions (“underneath the hood”, “at the end of the day”). Watching 5 minutes of his first lecture is enough to get familiar with his teaching.

Professor Malan does more than lecturing. He performs live to prove his point. And this helps students remember a key concept in Computer Science.

Memorable moment of week #0 lecture to explain algorithms ?

He often asks students to join him on stage to complete all sorts of challenges. These moments are both very instructive and entertaining to watch!

One of the funniest of the MOOC was the “Peanut Butter & Jelly Demo”. CS50’s teaching fellow Rob joins Professor Malan on stage to illustrate what pseudocode is:

After that, nobody would forget what pseudocode is. ???

Every time Professor Malan asked the students to come up on stage, I was super envious behind my screen.

One picture can speak a thousand words.

Course structure and highlights

One of the best parts about the course? Professor Malan hosts every CS50 lecture and he nails it every time. ?

There are two lectures per week, and the intensity he puts into them never drops. His lectures soon became my favorite moments of the class.

By week #3, I found myself binge-watching the weekly lectures. And the same viral effect affected the sections.

Sections were a must-watch for me for two reasons. First of all, I needed further explanations following the lectures. But the second reason was my Teaching Fellow (TF), Allison.

Like Professor Malan, Allison teaches with a lot of energy, good vibes and a lot of hand gestures. Each sections length was more than an hour, but was never a problem for me to focus. Her flow is natural, she interacts with the classroom, and here again I felt included.

Allison has signature expressions (“Extra Kudos!”, “Everyone good?”) which makes it easy to get comfortable with the section. She also shows a lot of support to the classroom. She repeats her favorite tips week after week to help us with our week’s problem set (better know as a pset).

Her most helpful advice? “Paper & Pen” and “Sleep!!!!”

Pseudocode and going to sleep when I was stuck on my pset late at night saved me more than once.

Allison wasn’t the only great TF in the staff. Zamyla is great in the pset walkthroughs. Rob is also excellent in his sections and shorts (nothing beats his peanut butter and jelly sandwiches, though!).

Every student had his or her favorite TF.

But great hosts can’t do all the magic. To run a good show, you need more people.

The tech

Spoiler alert: it’s not a green screen behind the instructor!

CS50 mesmerized me with the setup and the technical effort they made to tape the videos.

View from the monitoring booth ?

Professor Malan takes great care at crafting the best videos possible.

The camera crew work like professionals and the output is flawless. They offer to the students the most comfortable viewing possible.

But hiring a filming crew, owning a majestic theater, and possessing a pair of Google Glasses are not required to teach. What’s very important here is to offer a true original learning experience to the viewers.

Think about the Khan Academy. How much does it cost for Sal Khan to create a video?

It’s not about money but style, but rather how an instructor commits themselves to teach students and get great results. For Professor Malan, it means shooting and editing videos like a pro. For Sal Khan, it means recording on a black screen and writing on it in different colors while teaching.

His videos are as powerful as those in CS50: you need 10 seconds to understand what’s going on with the sound turned off.

And at the 11th second, you’ll want to turn the sound back on to learn more.

By contrast, somebody staring at the camera over a green wall doesn’t build a great context for learning. It’s uncomfortable to watch and dull after a few minutes.

These kinds of videos are lethal for MOOCs, they kill engagement and make the classroom boring so to speak.

Once my pset was done, I was happy for two reasons. The first was to have nailed something challenging I could be proud of. The second was to watch two new lectures and one new section!

Pset 1 - Homework 0 ?

CS50 disrupted a traditional teaching method: homework.

When I was studying CS50, I organized my week as follows:

• Watch the lectures & section?
• Discover the pset ?
• Read week’s notes ?
• Solve the pset ?
• Repeat ?

From top to bottom, left to right: lectures notes (Week #0 to #3 missing), psets, quizzes, shorts notes, a book about C programming and a GDB cheat sheet ?

I liked to discover my pset as soon as possible to try to gauge the amount of trouble I’d need to go through. It was a helpful strategy for me.

But wait… When did “homework” turn into something exciting?!

Read what Professor Malan says about psets after he decided in his sophomore year to “step foot in a classroom called CS50”:

“And at that point, did I finally realize that, my God, homework could actually be fun. Indeed, I was on those kids that on Friday evenings when the psets would be released, I would go back to my room and dive into the night’s psets.” David J. Malan introducing CS50 in 2015 week 0 lecture.

Yes, you read that right.

Everything I learned with CS50 was through completing exciting challenges.

How radical is it to code a brute-force algorithm to decipher passwords? Or writing a program to recover damaged pictures like forensic specialists do in TV shows?

Psets are fun because they ask you to do something worth your time. They proved to me that I was on the right track, because I ran programs of my own that blew my mind.

So two weeks after taking CS50, I was able to brute force passwords. How many MOOCs can do that after 2 weeks?

This was far beyond my expectations, I felt like I was a bloody hacker! ?

The psets could be very challenging (my ??? trilogy: pset4 / pset5 / pset6) but the reward was unique. They were two series of psets: standard & hacker editions. I took the latter (available until pset #4) only to dive deeper into mad challenges.

The community moderators (shoutout to curiouswiki, Cliff B, Kareem and the others!) on Slack, Reddit or Stack Exchange never left me alone in the dark. Many students were active, too, and it was great to see so many people sticking together.

Notes were precious as well. People from the staff were in charge of writing the transcripts of every lecture. Besides the videos, I used to read these notes over and over and annotate them to crack my psets.

Final Thoughts ?

Enrolling in CS50 is one of the best decisions I’ve ever made.

CS50 is more than a course to broaden coding skills. Thanks to a rich learning path (reminds me of the 64 subtitles available, and I’m not joking!), CS50 turned me into a fast learner. But more than anything else, CS50 demonstrates what I think education should always be like.

If I had crossed paths with CS50 10 years ago, I’d have gone right into Computer Science with passion.

CS50 contributes to fixing education. Places like Khan Academy or Codecademy do, too. They all show that education can be playful, fascinating, and rewarding.

If only more MOOCs were as great as CS50, it would help many people find the most fulfilling studies.

? Clap if you liked my story! Interested in EdTech too? Hit the subscribe button to make sure not to miss my next story. Feel free to drop a comment below or to hit me up on Twitter ?

You’ve heard many people say this. But is it true?

I knew teaching had benefits. For example, if you teach, people will know you exist. People may be able to learn from your experience. But learn? I was skeptical.

But I realized the statement is true. You learn best when you teach. I can vouch for it after teaching frontend development for many years.

This article explains my thoughts on why teaching others helps you learn.

To understand why teaching helps you learn, we have to first talk about learning. You can’t teach something when you haven’t learned it.

The learning process

Let’s say you want to learn JavaScript. All you know is you’re on one side of a cliff. The endpoint is on the other side of the cliff.

You don’t know how to cross the gap (yet).

When I tried to learn JavaScript, I read through countless books and tutorials. I even looked at source code to see how people coded. I also searched for best practices.

Each bit of material I come across acted as a tiny foothold for me to get to the other side. Some materials were easy to understand. Others were hard.

Sometimes the footholds were too far apart. I missed my step, I fell into the valley, and I tried again.

Sometimes I hit a wall. I didn’t understand articles I read. I fell into the valley, and I tried again.

After trying enough (and losing enough lives), I toned up my leg muscles. I could jump a little farther and higher than before. I tried the articles I couldn’t understand again.

And sometimes I succeeded in getting past the stage I was stuck at.

And I got to the other side.

Only to realize there’s more to go…

But that’s okay. There’s always more to go. That’s what makes learning fun.

Teaching helps you gain perspective

I didn’t know how far I’d gone until I started teaching JavaScript. I thought I knew very little. Not enough to be “an expert” yet anyway.

But it turned out that I knew a lot. Enough to even make a super comprehensive course on JavaScript.

So here’s a side benefit to teaching.

When you learn, you focus on moving from cliff to cliff. You have no idea how far you’ve gone because you don’t stop to think.

But when you teach, you stop.

You pause, you look backward, and you realize how far you came. You gain perspective, and this perspective gives you confidence in your abilities.

You know more than you give yourself credit for.

The teaching process

When you teach, you try to help someone cross the cliff you crossed.

One way to teach is to direct people to resources you went through. They will likely face the same difficulties you faced. They’ll hit walls, and they’ll miss their steps. Hopefully, they’ll gain enough strength to move past the obstacles themselves.

But this isn’t teaching. This is simply… pointing people to the resources you used. You can help shorten their learning curve, but you’re not teaching. Not yet.

To teach, you walk backwards. You stand beside the student and help them through the gap.

You can point them to a tutorial while you wait for their questions. Sooner or later, they’ll ask questions that surprise you, like “Why this and not that?”

Sometimes, one way is better than the other. Sometimes, both ways are possible. And you learn there’s another way to cross the cliff.

Sometimes, you think of a better example to help them cross the chasm more easily. When you do this, you build another foothold for yourself.

That’s why you learn when you teach — you build more footholds.

Maybe one day, when you’ve answered enough questions, you’ll build so many footholds that you’ll fill the gap.

That’s when your knowledge is rock solid.

There’s no need for footholds anymore. You can simply walk across. Students you teach can walk across, too.

Who can you teach?

You don’t need to be an expert to teach. You can teach anyone who wants to cross the cliff you crossed.

It’s best to help immediately because you know how it feels to go past the cliff. You know danger spots where students need to be aware.

Sometimes people will ask you questions and you’ll go, “I don’t know”.

That’s okay. You may not be able to fill up all the gaps yet. But now you know you’re missing a piece. You can fill it up later by doing more research.

Sometimes you won’t be able to fill up the gap immediately. There are too many things you don’t know about.

That’s okay too. Maybe you’ll find the block of stone you need as you progress to another cliff. It’ll be in plain sight.

When you see it, you can go back and fill it up.

That’s another reason why you learn when you teach — you see gaps in your knowledge.

Want to learn to teach better?

Some developers are horrible at teaching. They’ll throw resources your way and ask you to figure it out yourself. Others talk in alien FOOBAR language that you’ll have a hard time understanding.

Don’t blame them. They’re doing the best they can. Maybe they’re not interested in teaching. And that’s okay.

But you can teach well if you want to.

I know a thing or two about teaching after writing tutorials for years. I want to share more of these things with you.

Would you be interested? If yes, I’d love to hear:

1. Why you want to teach
2. What are your greatest obstacles to teaching

Can’t wait to hear from you in the comments below :)

Thanks for reading. Did this article help you in any way? If I did, I hope you consider sharing it; you might just help someone who felt the same way you did before reading the article. Thank you.

Originally published at zellwk.com.

Set a target, learn just enough to hit it, teach someone, repeat.

JavaScript’s my craft.

Despite my young career, no other skill rivals the hours I’ve put into this language and its ecosystem.

One question continues to pop up, however. A question that can hinder anyone’s personal development…

How Do I Learn X?

I thought this question only haunted me, but experience proved otherwise. This question agitates anyone learning new stuff. I’ve met smart cookies who ask,

• “What should I learn?”
• “How can I learn it?”

Apply those two questions to any skill — programming, basketball, cooking, dancing, archery, Chinese, Chess, Checkers. Your end result is a confused newbie who’ll start, but never finish.

Until recently I’d reply “Uhh, idk lolbro…just dew it.” But my perspective shifted after some reflecting and research.

We’re not lost because we’re dumb, nor do we procrastinate because we’re lazy.

We’re Overwhelmed

By asking “How do I learn X?”, you’ve just volunteered to drown in a sea of knowledge dug by countless people over many years.

Don’t “learn” X,” but rather understand what it’s composed of and tackle one piece at a time. If you say “I want to learn programming!”, I ❤️ your enthusiasm, but you’ve already started down a slippery slope.

Like any large topic, _programming’s too general — _and trying to “learn” it shows a lack of focus that eventually blocks most people from taking action. In my opinion, that’s partly why programming’s a highly paid profession: most people get lost in the maze and give up.

Vague goals = abandoned goals.

So here’s what I think you should do instead.

Define “X”

What are you trying to learn? How’s it used in the real world? Do your research and answer these questions to gain a better understanding of the big picture.

Slice it thin

The Pie of Knowledge is big, so slice it thin if you want to eat. You never see doctors or lawyers knowing everything about their field. Absorbing all that information is impossible and has diminishing returns — they know enough to be effective at their specialized job. The same applies to engineers, mechanics, psychologists, chefs, etc. You specialize, not generalize.

Of course, you’ll need general knowledge to get started like everyone else. After that, pick your slice, dominate it and move on to another slice. Over many years, you master many slices.

Practical projects

Once you’ve chosen a very specific target, it’s time to scream, aim, and fire. Find relevant work experience (full-time, intern, apprentice, volunteer). If you can’t, then make your own experience through personal projects.

However you prep, make sure the work is as real-world as possible. Look up enterprise-grade projects and try to create simplified versions of them. Start with small tasks and work your way up. Whatever technologies your industry’s using, try to get your hands on something similar and become proficient at them. It doesn’t matter if you or a boss is ordering the work, what matters is the work’s value to your portfolio.

A personal example…for one programming internship, the director loved my passion and ability to speak on my personal projects. He counted them in lieu of “real” work experience because I adequately demonstrated my skills.

Learn just enough to be useful

Countless times, I’ve made the mistake of acquiring knowledge without ever applying it. I’ve read lots of books and documentation, expecting to become a wizard at the end of it all.

I just wasted my time. It’s also a really sneaky way to procrastinate…you can’t blame someone who’s actually “reading the material”. But in truth, how much knowledge can you retain without applying any of it?

Instead, just keep grinding on your projects. When you get stuck (and it will happen a lot, believe me), go back and study until you can solve the problem. Once it’s fixed, keep moving until you’re stuck again, go back and study, rinse and repeat!

This, I think, is where most people give up. Getting good at something is pretty simple, conceptually.

• Study
• Do
• Fail
• Repeat

But I did forget one piece, arguably the most important one…

Teach someone

I can’t describe how priceless this is.

You know those learning breakthroughs we get? You’re studying, it suddenly clicks and you’re like “Aha, I get it! Everything makes sense now!”

I’ve had more “Aha!” moments teaching than I ever did studying.

Teaching requires you to digest the information you’re presenting intensely. It opens doors of thought you never knew existed. Helping someone else understand a concept demands you seriously know what you’re talking about. Otherwise, you ramble on in generalities, never actually helping the student progress.

I’ve done that with coworkers and stopped myself from saying “Sorry, I’m not 100% familiar with this. Let me research and get back to you”. Then we’ll Google the question and come to a conclusion together. Everyone walks away with a deeper understanding because we did it while communicating.

Even if you’re not “the teacher”, you learn 1000% faster just by bouncing ideas off your buddies. I did this with a friend while studying fundamental CS algorithms. Those concepts would’ve been too difficult for me to grasp in isolation. Next time you study, phone a friend!

In Closing

Set a target, learn just enough to hit it, teach someone, repeat. Please test this out and let me know what doesn’t work with it.

We talked to the GitHub Training team about the free GitHub courses they offer to both developers and non-developers, as well as about the community that formed around them on Gitter. Check out what they say and enroll in the course!

What is the GitHub Teacher? How did it come about?

The GitHub Training team uses the @GitHubTeacher as the teaching persona for the various courses we offer. The account acts as a shared location for our trainers to create repos, manage collaborators, and their related organizations.

What topics do you cover in your courses? Who are the courses aimed for?

Our courses cover a breadth of job-relevant topics across the Git and GitHub ecosystem. Whether you are an experienced developer trying to find out what GitHub is all about, or a non-developer learning how to use GitHub for your internal documentation, cookbook, home repairs, or data compilation — we have you covered.

We invite anyone to take the Introduction to GitHub course to see how they can use GitHub to make their lives easier. I may sound like I’m drinking the Kool-Aid, but take the class and I’m confident you’ll have ideas on how you could use it in your personal and professional life.

Where do your students and teachers come from?

All over the globe, just like our GitHub community. However, we haven’t (yet) been able to confirm that people have trained on Git or GitHub while visiting the Arctic or Antarctica (❤️ to all the developer polar bears and penguins out there!). It isn’t uncommon for our students to participate in training sessions during the late night / early hours in their local time zone. Our GitHub for Developers class is even offered in EMEA friendly time slots.

Our instructors are distributed around the globe, providing GitHub training for GitHub around-the-clock. The Training Team assists customers wherever they call home.

Git is known to have a steep learning curve. How do you handle that?

While it might be true that Git can take a while to master, our courses employ GitHub Flow and are delivered to enable even Git and GitHub novices to hit the ground running. Our classes focus on the everyday tasks associated with Git and GitHub. During the second day of our GitHub for Developers course, we tackle some of the more advanced Git concepts.

How can GitHub be useful to non-developers? Do you see interest from them in learning about GitHub as well?

GitHub really is for everyone. Though often associated with developers and software, authors, ranging from teachers to researchers, are discovering the ways Git and Markdown aid in authoring and versioning their content. But don’t take our word for it: explore GitHub Showcases to see what our amazing community is up to.

Why do you think the reasons are that Git, and GitHub in particular, encourage a better workflow, over other source-control systems?

GitHub is social. Our community plays a huge role in why GitHub excels over other source-control systems. The GitHub Flow and ease-of-use is welcoming to users that are new to our platform. The distributed nature of Git helps continuity of work in a world that can grind to a halt when internet connectivity is lost.

At the end of the day, we believe in the power of collaboration. GitHub provides a platform that allows anyone to contribute to projects that are near and dear to their heart, which was a lot more difficult to do before we showed up.

What resources do you recommend for those wanting to gain better understanding of Git and the GitHub ecosystem?

GitHub Training offers free courses every month to help anyone get a better understanding of Git and GitHub. In addition to our trainings, we have a metric-ton of videos on both YouTube and Vimeo. If reading books is your cup of tea, we recommend checking out Pro Git.

Did you learn anything new yourself from teaching GitHub to those with little experience using it? Can you give an example?

As a relatively new instructor, I’m most impressed with the workflows that our new users are coming to the platform with. Aside from the different workflows and environments our new users are coming to the table with, I’m amazed at the creativity and inquisitive nature of our learners. I think people intrinsically want to break something when they are trying it out, they throw things at GitHub that would stump their current source control systems and I love being able to identify how to solve their unique problems.

How to sign up for a class? How often do they take place?

Students can sign up for our classes on our Training website. GitHub offers a selection of classes that increase in scope as the student progresses through them. We suggest that anyone new to Git and GitHub enroll in the Introduction to GitHub course (which is currently scheduled for the 15th of August).

After completing Introduction to GitHub, we encourage students to enroll in either GitHub for Everyone, which emphasizes the use of the GitHub Desktop, or GitHub for Developers, which dives right into using GitHub with a command-line interface. Both GitHub for Everyone and GitHub for Developers have classes available in August and September.

Outside of the courses that focus on using GitHub while utilizing Git, we also offer a Git Essentials course which focuses on commonly used Git operations without relying on GitHub.

In addition to our scheduled Open Enrollment courses, students can also take our on-demand training that is always available and can fit well into a busy schedule. The course takes them through the GitHub Flow and gives them an opportunity to work on a community driven project before jumping into the massive world of Open Source projects hosted by GitHub.

Similar to our Open Enrollment courses, we use Gitter to provide students an opportunity to collaborate with fellow learners, as well as pose questions to the Training team.

Anything else you’d like to add?

Moving to Gitter as the chat platform for our courses has strengthened our learning communities. Countless students jump at the opportunity to answer one anothers’ questions every class and it’s something we encourage.

See you in class,

❤️ GitHub Training

P.S. The Training Team developed the answers to all of these questions collaboratively using Issues and Pull Requests.

At first, I avoided MIT’s Scratch programming language.

It seems childish. When you load the Scratch homepage, you’re greeted by friendly cartoons that seem appropriate for preschoolers. The programming language itself isn’t even a proper language. Instead of typing, you drag and drop pre-made blocks into place. It’s more reminiscent of LEGO than real engineering.

Every student over the age of 12 seemed to agree with my diagnosis. “I did that in 2nd grade. It’s not real coding.” So I taught students Python, Java, HTML, CSS, and JavaScript — real programming languages that you type, not silly blocks.

However, there was a problem.

It’s hard to teach “real coding.” Really hard. With some students, it seemed impossible.

Before my eyes, the students that were excited to do “real coding,” began to label themselves as “bad at coding” the same way students have learned to label themselves “bad at math.” I felt like I was doing more harm than good, teaching students coding languages they weren’t ready for.

Giving Scratch a Second Look

So I went back to the drawing board, looking for the right programming language for my students. I scoured the Internet for books and tips on how to teach kids to code and everywhere I looked, there was Scratch. So I gave Scratch a try.

It turns out, typing is overrated. Programming isn’t like English. There aren’t a million different words, phrases, and sentence structures. There are only a few dozen, so creating blocks for them saves time, and more importantly, prevents 70% of errors new programmers face. In text-based coding, if you forget a semicolon, your program might not even run, but Scratch won’t even let you make that mistake. Block-based programming enables beginner programmers to focus 100% of their mental energy on the design and logic of their programs, not the semantics.

Even better, Scratch was designed to create video games and stories. Students enjoy making video games almost as much as they love playing them. This means that you don’t have to motivate students with the carrot and stick approach of homework, grades, and tests to use Scratch. It’s intrinsically motivating to make something that you can immediately share with your friends and family, so students continue to work on Scratch projects at home simply for the fun of it.

After this revelation, I was excited to share Scratch with the world, “Hey everyone! The search for the best first programming language is over. We’ve found it!”

Scratch Seems Too Easy

As it turns out, I was late to the party. Everyone already knew about Scratch. Even worse, they actively avoided it because it’s “babyish.”

“No! You don’t understand,” I pleaded with students. “It’s actually really challenging. There’s a lot for you to learn in it before you’ll be ready for JavaScript.” But nobody wanted to hear it.

Last month, this brought a 12-year-old boy to tears in my class.

Sam represented himself as a true nerd, proudly telling the class he memorized over 150 digits of pi, and has been to many technology and science camps. When I suggested he start in Scratch, he shrugged.

“It’ll probably be too easy for me. I haven’t done it since I was in 3rd grade.”

“Just give it a shot,” I said. “If it’s too easy, we’ll move you to JavaScript.”

Ten minutes later Sam was crying. As I walked with him out of the classroom, I asked what was wrong.

“I’m terrible at this,” Sam shook his head. “I can’t do it.”

“Why do you think you can’t do it?” I asked, “It’s only been a few minutes.”

“Scratch is supposed to be easy and I couldn’t even do the first step.” Sam sighed heavily. “I really thought I was good at this.”

“I know it looks easy,” I said. “But Scratch is actually really hard. You can do incredibly complex stuff with it.”

“But, but, but…” Sam sobbed, looking hurt, “But why would they make it look so easy then? They make it look like it’s for babies!”

Scratch Has a Marketing Problem

Everywhere they look, students get the impression that Scratch was designed for young children and is easy. While this does a great job of making it seem inviting for younger students, it has a perverse psychological effect on older kids.

Older students don’t want to use Scratch because there’s nothing to gain from it and plenty to lose. If they’re good at it, congrats on being good at a little-kid language. If they’re bad at it, there’s no hope for them. They must be pitifully stupid.

Even code.org, a wonderful organization that’s done amazing work to promote CS education, makes this same mistake with their tagline, “Code.org: Anybody can learn.” They might as well say, “Code.org: You’d have to be an idiot not to get it.”

Students secretly crave challenges

When a student says, “I can’t do it. This is too hard,” it’s difficult not to reflexively reply, “No, it’s not. Look, it’s easy. You can do it.”

In our adult brains, this seems like the logical thing a student would want to hear. Easy is better than hard, right?

Wrong! Students crave hard. They seek it out wherever they can find it, athletic competitions, video games, chess, and debate. Hard things are great because:

1. If you complete them, you’ve proven yourself. You did something that was outside of your ability, and that some of your peers couldn’t do. There’s a rewarding emotional high from completing a difficult task.
2. However, if you fail at a hard task, it means nothing. After all, it wasn’t easy. Many people can’t do it. Maybe if you practice some more and come back later, you can give it another go.

So what do we do when a child comes to us, whining that a problem is too hard? We agree with them wholeheartedly. “Yes, this problem is really hard. You might not be able to complete it this time. Many students can’t do it. But if you keep working at it, I think you can get it.”

It’s not always the case, but students are usually excited to rise to the challenge.

The marketing solution for Scratch is counter-intuitive, but not impossible: tell kids Scratch is hard. This means removing all of the bright, primary colors, and childish cartoons. Replace them with harder, more standard adult colors and photos. Eschew rounded blocks for ones with hard edges.

Basically make Scratch look more like what kids imagine adult coding to look like.

However, if coding seems impossible, it could turn some students off from it entirely. Part of Scratch’s appeal is it’s accessibility. Potentially this means we should break Scratch into two products: leaving it the same for for true beginners that are younger than 12, and creating a new product that’s similar but seems more serious and real.

WoofJS

I now use WoofJS, a JavaScript framework we created at The Coding Space, to address this very program. It’s very similar to Scratch, but from within JavaScript, a “real” coding language. This way, students that think they are “done with Scratch” or “too old for Scratch” can get on board with learning similar concepts under new clothing. Woof serves as the bridge between Scratch and JavaScript that students are eager to walk across.

When I asked one of our 11-year-old students why she liked Woof better than Scratch, she said, “It’s more challenging.”

“Oh, is that because you have to learn JavaScript syntax?” I asked.

“No,” she thought for a moment. “I’m not really sure why it’s hard. But it just seems harder which is cool.”

A few months ago I sat down to my first-ever pair programming session. I had been stuck on Free Code Camp’s counting cards JavaScript challenge for several days, and now I was about to have a seasoned programmer take a look.

It was the middle of the night, and my three-year-old daughter was asleep in the same room, but I dared not move to the other room and risk waking up my six-month-old daughter and wife. I was nervous about this fact, but excited to have the chance to have an expert look at my code for the first time.

How I met my “Teacher.”

When I first met Yoochan, he was my student.

Yoochan knew even then what he wanted to do with his life. My first memory of him was of him scribbling in a notebook between classes, drawing what seemed to be a wireframe concept of a website. I asked what he was working on, and he sheepishly said it was a Wordpress theme, not expecting me to know what he was talking about. But I did.

Yoochan was serious about his studies, and poured himself into his General Education courses, while continuing to teach himself to code on the side. Other students in his cohort spent more time partying than studying, but Yoochan was busy selling custom Wordpress themes and devouring new programming languages. He wanted to create the next Facebook, and knew full well the amount of hard work and study that his dreams would require.

After his transfer to the US and my move to another job in another town, we kept in touch occasionally via Facebook. His posts about the tech world approached obsession, but the occasional complaints about finals and selfies on Spring Break were in the mix as well. We chatted a couple of times about life, and his successful transfer to a better school a year later, which also happened to get him closer to Silicon Valley, where his heart was leading him.

Teaching as Collaboration

Our goal was simple enough:

A description of the Counting Cards challenge from Free Code Camp.

Yoochan patiently explained how to setup ScreenHero, as I typed my responses to him instead of speaking, for fear of waking up my daughter. I showed him the objective of the lesson and the code I had already written.

We moved over to CodePen to test out a few variations. All along the way he was teaching me about the higher-level concepts at work in JavaScript, as well as a few CodePen shortcuts to make getting around easier.

We walked through my code line by line together. Rather than pointing out every error, he would just tell me what the purpose of a given command was, and ask if I thought there might be a better way. His natural skill as a teacher impressed me. But then something interesting happened.

After we had examined every line of code, cleaned it up and gotten it into shape, we clicked “run.”

It didn’t work.

We went back through it, found a couple more things to tweak, and ran it again.

It still didn’t work.

Then, it hit me: he didn’t know the answer.

The Plot Twist

OK, so, there’s one big thing that I failed to mention: while I was chatting from a house full of new life, this twenty-something was in a hospital room unable to sleep due to the cocktail of drugs swirling through his system. He was dying from cancer. But he didn’t want to talk about that. He wanted to talk about Silicon Valley acquisitions, exciting new startups, and, of course, code.

Sometime during his first semester at his new school, he had started experiencing stomach problems. It got bad enough that he went to student health services. They sent him home with some antacids. The problems got worse. He went back again, and still failed to get answers. Finally, he came back to Korea, where his stomach cancer was diagnosed almost immediately.

He dropped out of school and stayed in Korea to receive treatment, although you wouldn’t know it by his social media posts. I chatted with him a few times about some cool new app he’d found or one of his ideas. The conversation rarely, if ever, turned to cancer or his condition. At one point he was all better, had internships lined up in Seoul, and was ready to take the world by storm.

And then he wasn’t. Almost as soon as he’d started the internship, he had to quit and check back into the hospital.

Looking at his Facebook feed, it was always hard to tell how he was really doing, because so much of it was his blog posts about learning new programming languages, or some new idea he had for an app, or a website, or an E-commerce site.

I managed to visit him in the hospital last winter, where he filled me in on much of the backstory behind the very occasional vaguebooking that he did. It was a heartbreaking story, but Yoochan had nothing but optimism in his voice. He talked about what a blessing this whole experience was and how it would fuel his career.

Now he had a burning passion inside of him to help cancer patients, especially young ones like himself. He wasn’t quite sure what form that would take yet, but he was sure it would happen. Naturally, it would be an app. Or maybe a forum site. Or just a blog to start out.

I met his mom, and, as a parent myself, was in awe of her. She stood by his side, listening to him tell his story in a foreign tongue, which he had now nearly mastered — yet another reason to be proud of her over-achieving son.

They finally came to the right hospital, he said. They finally found the right treatment. He smiled at his mom and patted her hand as she choked back tears.

The Lesson

I know exactly what it feels like to stand in front of people as the supposed “expert” on a topic only to be thrown a curveball question I didn’t expect and don’t know how to answer. It doesn’t mean I’m a bad teacher. Sometimes the question was just phrased in an awkward way that led me to misunderstand it. Or maybe I was just off my game, and the answer slipped my mind.

I recognized this instantly when it happened to Yoochan. I remember thinking, “Okay, this is awkward, how can I gracefully let him know it’s totally cool, and that I’ve learned a lot from him anyway?”

It turned out that I didn’t have to because Yoochan already knew something that had taken me several years of teaching to figure out: teaching is not just moving digital facts from one brain to another.

Real teaching is the analog act of taking someone by the hand and exploring a topic together. What makes a good teacher isn’t an encyclopedic knowledge of a topic. It’s the wisdom to use just enough of your knowledge to make the journey together interesting.

In the end, there is not that much difference between the student and the teacher. Both will gain something valuable from their time together.

Yoochan did not get embarrassed. He fessed up. I bounced some ideas off of him. We tried a couple of them, and they didn’t work either. Yoochan suggested stepping away for a bit and coming back to look at it the next day. That’s exactly what I did, and I managed to figure it out almost right away. I wasn’t proud of my solution, but it worked.

Confession: I still don’t know what he meant by “refactoring the code.”

My Teacher, my Hero

I received confirmation a few hours ago that Yoochan died. It was not unexpected. His Facebook posts in recent weeks had gotten fewer and farther between. He announced that he was ceasing all of his development activities. Then, a few days later, an apology to his friends because his condition was a lot more serious than he had been saying.

He went to a new hospital “deep in the mountains,” where he would not have regular internet access. I wondered if it was hospice. His last couple of updates abandoned his normal practice of giving English translations in addition to the Korean. His last one was short and to the point. “This week. See you up there.”

Some might see it as cruel to use the term “lifelong learner” to describe Yoochan, but I see him as the term’s apex. How many college students do you know that, after receiving a diagnosis such as his, would have continued right on studying psychology, algebra, or chemistry?

I’m not suggesting that dedicating every spare moment of your life to learning is an end unto itself. I’m saying that finding subjects you love and can jump into head first will give you more quality time on this planet, irrespective of how much total time you have left. Yes, studies are coming out suggesting that continuing to learn new things is the key to delaying dementia and Alzheimer’s, but dementia 50 years from now was not of concern to Yoochan.

Personally, I think that in the last six months or so he knew full well what his future held, and his talk of being cured was his way of taking care of the rest of us. In the meantime, he could get a bit of enjoyment out of those painful, sleepless nights by reading up on the latest Elon Musk project or coding an iPhone app that popped into his head. Although he seemed conflicted about how to use his social media presence in this phase of his life (for example, he occasionally deactivated his Facebook profile without notice), his GitHub account was, and remains, in a sense, immortal.

Being able to do this thing that he loved in moments of loneliness and pain made life worth living.

The Last Word

I’m sorry, Yoochan, for making this final part all about me, but I’m the guy writing this memorial, and I have something to get off my chest.

I’m sorry for not checking in with you more frequently.

I’m sorry that this world of adulthood — which you spent far too little time in — did not have a cure for you.

I’m sorry I couldn’t get one of your tech heroes to visit you in the hospital. If only you had loved baseball as much as you loved code...

I’m sorry I did not bring my daughter to meet you at the hospital. I wanted her to meet you and remember you, then ask me about you and your story later in life, when she might be able to understand fully. I worried that it might be somehow bothersome, or depressing for you. I’m pretty sure I was wrong about that.

I’m sorry about a lot of things, but I will never forget you.

I know that you held deep religious beliefs about what happens after death. I do not share the strength of your convictions, but the one thing I do know for certain is that your life has informed the way I teach my students, and how I will raise my daughters.

Therefore, I can close this memorial not with sad regrets but a happy promise: I will do my best to instill these lessons from your life in all the young lives that I come into contact with by living according to your example. Then they will — by exemplifying those values themselves — pass them on to their own co-workers, students, and children.

Future generations may not know your name or your story, but they will benefit from your time on this planet. In that tiny, but tangible way, you will live on.

I think you would like that.

If this is the first you’ve heard of me, then there’s only one thing you need to know: I am an ESL Teacher Turned Full Stack Developer.

My career teaching English as a Second Language has spanned nearly a decade, so I have a refined understanding of how adults learn a second languages.

I’ve watched thousands of students from different cultural, academic, and professional backgrounds acquire the difficult, rather quirky language that is English.

After years and years of dedication and commitment to learning, many of my students have gone on to become proficient — if not fluent — in English. I have also seen a lot of intelligent, hard-working people plateau at an intermediate level of English, then subsequently grow tired and frustrated by their lack of progress.

The successful language learners have several traits in common. My observations of them mastering English have helped me learn web development much quicker than I would have otherwise.

Let’s talk about some of the theoretical frameworks that attempt to explain second language acquisition, and lessons I’ve learned from my students.

If It’s Easy, You Ain’t Doing it Right

Stephen Krashen, linguist and professor emeritus at the University of Southern California, is arguably the godfather of modern second language acquisition.

In the 1970s and 80s, he developed a set of 5 hypotheses that have informed modern communicative teaching methods.

One of these is known as the input hypothesis, which states:

Learners progress in their knowledge of the language when they comprehend language input that is slightly more advanced than their current level.

The exact thing could also be said for learning how to code!

Think back to the first month when you just started learning how to code. You probably started off with some tutorials on Codecademy, and followed along with the instructional prompts, only to feel “stuck” and unable to produce a website from scratch without copying and pasting.

I had probably gone through their JavaScript tutorials three times, and I still felt like I wasn’t learning anything. Why?

Because the hand-holding tutorials are much too easy after the first time around! They are great to get you familiar with the basic syntax of the language, but they won’t help you solve algorithms on your own.

Repeating these tutorials is unlikely to take you beyond your current level of understanding. I didn’t really start learning JavaScript until I ditched those tutorials and dived right into Free Code Camp’s basic algorithmic challenges.

If it’s easy, you’re doing something wrong.

It was tough, and each subsequent challenge was even more difficult than the last! I was constantly in a state of being challenged, just slightly above my current ability. And it worked!

My point is this: your coding journey is never going to feel “easy” or “simple”, and if it is, you have to stop what you’re doing and try more difficult challenges and projects. Get comfortable with feeling stuck and stumped for the long run, because that isn’t an obstacle. It’s a sign that you are about to learn more.

Don’t Aim for Perfection Early On

Perfectionists do not make great language learners. They tend to do well on grammar and vocabulary tests and can recite all of the irregular past participles by heart. I think the perfectionist students actually know more about English grammar than native speakers do! Not that it really matters though. Why?

Because their spoken English kind of sucks.

I have met a lot of these students, and have been successful in helping many of them ditch their less-than-optimal study habits. But so many have this unrealistic ideal of what a “fluent” speaker of English should be able to do, including never making any grammatical mistakes whatsoever!

They excel when it comes to reading and writing, but their speaking skills are seriously hindered because they take forever wracking their brains thinking of the “best” way to say something.

Don’t do this when you learn to code — especially when you’re just starting out. You don’t have to remember all of the semantic HTML5 tags or all of the Bootstrap classes to make a website. Why would you have to do that when you could just find whatever you need in the API docs, Google, or Stack Overflow?

In my very early days of learning HTML and CSS, I actually made flashcards to help me remember this stuff, and I can’t believe what a waste of time it was. I probably spent two hours creating flashcards every night, and I wish I had skipped all of that and practiced coding instead!

Just because you have all this knowledge doesn’t mean you can actually use it appropriately to solve a particular problem.

Don’t be perfectionist in learning anything, especially coding! Learn enough to be dangerous, then start building something. You’ll pick up the particulars on an as-needed basis.

Take Care of Yourself

In my last Medium article, I wrote about how South Korea is viable option for people who want a lot of free time to learn coding while making a decent living teaching English.

The bulk of my students are young people taking a gap year from university. They live with their parents and don’t need to get part-time jobs to support themselves.

Sounds like heaven!

The language institute where I teach is open from 7am — 10pm, and a lot of these young Koreans spend 10 hours or more each day at the center.

In addition to their regular classes at the school, they join extra study groups and hole themselves up for hours in the computer lab until closing time.

And even though they are taking a break from work and university, they are often sleep deprived because they are preparing for high-stakes tests that might determine the outcome of their professional lives.

I really admire the Korean work ethic, which was responsible for the country’s rapid development following the Korean War. But the human body can only function optimally with x amountOfSleep and y hoursOfWorkDone.

When it comes to learning a new skill, the Law of Diminishing Returns is at play. Students who regularly take breaks, meet friends, get enough sleep, and do exercise seem to do just as well — if not better — than students who use every second of their free time studying.

A lot of self-taught coders should heed this advice as well. For many of you, you have to balance your coding schedules on top of your busy work and family responsibilities.

And it’s true that you have to hustle hard and work your butt off if you really want to transition into web development. But if you find yourself yawning a lot and unable to focus, take a walk outside and get a breath of fresh air. Spend a couple of hours with your friends or family on the weekend and recharge your batteries.

Tom and Donna have great advice for self-taught coders.

Just remember to treat yourself from time to time, or risk getting scorched from the burn out.

Your Advice

Does any of this advice resonate with you? Do you want to add something to this list?

Share your questions and opinions in the comments below, and don’t forget to follow me if you haven’t already done so. Treat yourself.