DEV Community: Adam

Creating your own dynamic stream overlay

Adam — Thu, 18 Jun 2020 15:53:43 +0000

Introduction

This post is for people who want a custom, dynamic overlay and know how to program.

As for why you'd want an overlay in the first place, here are common uses:

Displaying information
- Latest followers
- Commands of interest like !game or !help
- Advertising your social-media platforms
Adding pizzazz
- Fanfare for a new subscriber
- Bursts of emotes
- Playing sounds or music

Regarding the dynamic aspect—your streaming software can already render text and graphics. However, it may not allow for event-based triggers or animations. For example, I made a custom overlay that reads a file from my system, fades in a marquee with that text every so often, then fades it out when enough time has elapsed. With my streaming software, I only would have been able to render static text on the stream.

How do overlays work?

I use OBS, so I'll talk about its specifics here, but software like XSplit also supports this method.

OBS has a built-in "Browser" source that lets you show the contents of a webpage:

From there, you type in a file path or URL, and OBS will render whatever you would see if you had pointed your actual browser at the same page:

That means that you "only" have to make a webpage with your overlay's contents. If you wanted something basic enough, you could write a simple HTML file with CSS animations. However, this is where game engines really shine since they're built to handle graphics, animations, and even sounds! As long as the game engine can export to HTML, then you can use it to make overlays.

I prefer to use Phaser since it's relatively easy to learn. It's also specifically intended for WebGL games, which means you can just save your JavaScript file as you're working and click "refresh cache of current page" in OBS to see your changes (as opposed to having to export a build from your game engine).

Setting up your webpage

Phaser itself can be loaded as a single JavaScript file. There are three ways you can set up your webpage:

Single HTML file

If you put everything into a standalone HTML file and load Phaser from a CDN, you won't need a web server running anywhere. On the flip side, it also means that you can't read any files from your hard drive, including JavaScript files, so you'll need to place all of your JavaScript inside the HTML file itself.

This HTML snippet will float the word "Hello" from the bottom of the screen to the top:

<html>
<head>
  <script src="https://cdn.jsdelivr.net/npm/phaser@3.23.0/dist/phaser.js"></script>
  <style>body { margin: 0; }</style>
  <script>
    let textObject = null;
    const width = 1920;
    const height = 1080;
    const phaserGame = new Phaser.Game({
      type: Phaser.WEBGL,
      scale: {
        mode: Phaser.Scale.FIT,
        width,
        height,
      },
      transparent: true,
      scene: {
        update,
        create,
      },
    });

    function update(time, delta) {
      textObject.y -= delta / 20;
    }

    function create() {
      textObject = this.add.text(0, 0, "Hello world", {
        font: "64px Lato",
        fill: "#0000ff"
      });

      textObject.x = width / 2 - textObject.displayWidth / 2;
      textObject.y = height + textObject.displayHeight;
    }
  </script>
</head>
<body></body>
</html>

You can use this as a foundational overlay via any of these three methods that I'm outlining here by saving the contents as index.html and pointing OBS at it.

Local server

Using any web server (e.g. http-server for Node.js, Python's http.server, or even something heavier like Apache's HTTP server), you can serve a directory from your hard drive and point OBS at the resulting local URL. For example, I run Node.js's server via

http-server -p 5896 .

Then, I can point OBS at http://127.0.0.1:5896

Running a web server allows you to load files from the directory that you're serving. This means that you can separate out the JavaScript from the HTML:

<html>
<head>
  <script src="phaser_3_23_0.js"></script>
  <script src="main.js"></script>
</head>
<body></body>
</html>

This has an added benefit of fetching Phaser directly from your hard drive rather than a CDN, so it will load faster.

While this works and gives you flexibility, you'll need the web server running any time you want to stream. I solve that particular problem by creating a prestream.cmd file that I run before each stream. It sets my microphone volume, starts my chat bot, and serves my stream overlays.

Online site

OBS supports using an online URL instead of a local path. This is how services like Streamlabs work; they host a page for you to use from OBS.

I only suggest putting a server online if:

You stream from multiple computers and want the same overlay available everywhere.
You want to make a generic overlay (like how Streamlabs did) that anyone can use.
You really dislike starting a server every time you have to stream.

Taking it further

A natural next step would be to integrate features from your streaming platform directly into your overlays. For example, when someone follows the channel, you may want to spawn fireworks in your overlay. In order to accomplish this, you would need to connect to the streaming platform's API.

I want to keep this blog post brief, so I'll just outline one possible solution for this in the form of a stream-event microservice:

Make a separate server, e.g. in Node.js, that will connect to the Twitch API and detect when there are new followers.
Connect from the overlay client to this new server via a websocket.
On the server, listen for a particular API event. When one occurs, emit a message over the websocket to the overlay.
Spawn an animation in the overlay's code.

Conclusion

Making your own overlay is a great way to achieve a specific effect and stand out from template-users. If you already know a game engine or rendering library that can output to HTML, then there's practically no setup involved. Otherwise, there'll be a bit of a learning curve, so unless you require custom functionality, then it may not be worth pursuing.

If you enjoyed this post, consider taking a look through the courses that I offer.

Live-streaming yourself developing

Adam — Mon, 01 Jun 2020 05:26:17 +0000

Introduction

Have you ever thought of streaming your own development process? This post covers almost every facet of the streaming process to give you more than enough food for thought.

As for me, I've streamed more than five thousand hours of my own development on Twitch since 2015. I've had plenty of time to think about what works well and what doesn't.

Advantages of streaming

Like most things, streaming has its ups and downs. This section will only consider the advantages.

Here's what I think are the pros (in order of decreasing importance):

Accountability
Community / networking
Rapid feedback loop
Impact
Fun
Extra money

Accountability

This is the biggest reason that I started streaming back in 2015. I had just quit my job, and I was worried that I'd fall into a pattern of playing games and checking social media all day. When you have a live audience, it's much easier to avoid those traps.

In addition, most successul streamers stick to a schedule, which means that you'll form a routine around streaming. For years, I woke up at 7:40, showered, ate breakfast, and prepared for the stream. I wouldn't procrastinate or delay since people were waiting for me to start.

Community / networking

In short: your audience will become your friends and/or co-workers. This has a hidden benefit though: you won't go insane.

Streaming your work almost always implies that you're working from home. If you've never worked remotely before, then you may never have experienced what it's like to be alone for extended periods of time. It's not good. I once had a remote job where I was the only developer, and a series of bad habits led to my work time creeping into my personal time. That, combined with the lack of social contact, twisted my psyche. I've managed to avoid that insanity thanks to streaming.

One other thing regarding the community: don't be afraid or nervous about showing your code for quality reasons (you have other reasons to be worried about like leaks/security, but we'll discuss that later). For example, you may feel like you're not a "smart enough" developer or that your code isn't up to snuff. Strike those thoughts from your mind immediately and permanently. Anyone who judges you for your code quality isn't someone you want in your stream.

I think that the community as a whole is more than helpful. Make sure you're not misconstruing constructive criticism for judgment, and also be sure to set your boundaries. I've had to say to multiple people that I don't appreciate their comments for various reasons, and they'll usually improve after a warning.

Rapid feedback loop

By showing your development process to the world, you'll get feedback every step of the way. This manifests in many different ways:

You don't know about some library/framework/technique and someone recommends it. This has been a massive time-saver for me. In multiple instances, I must have been 5 seconds away from committing to a multiple-hour-long decision that was bypassed entirely thanks to taking a viewer's suggestion.
You write a bug without realizing it and you're told immediately that there's a problem.
You make a questionable design decision (e.g. "players should lose money when they fail a mission") and are convinced why it's a bad idea.

All of these cases are examples of course-corrections before you've spent weeks or months in a vacuum. Keep in mind that you'll need to be amenable to feedback in order for people to break through to you.

Impact

Some people hate the term "influencer" for what it represents, but as an English word, it's just someone who influences. By putting yourself in front of an audience, people seem to immediately assume that you know more than you do. I remember doing my first piano-playing stream and being asked which digital keyboard I'd recommend even though I'd only owned maybe two in my entire life.

This impact can be nice for a couple of reasons. For one, you can use it to market products (e.g. affiliate marketing to earn more money). The nicer reason is that it gives you insight into what you're doing well beyond what your co-workers or boss might notice. For example, I've been told that I have good organizational and note-taking skills. Knowing that others value such skills would allow me to share it with future teams or even students.

Likewise, you may discover that a skill you have is uncommon. Maybe you can explain difficult concepts clearly or come up with algorithms quickly. Knowing your strengths lets you play to them!

Fun

You never know quite what you're going to get when you start streaming. Will someone else drop by with a huge audience? Will you make a breakthrough and get to celebrate with your viewers? Will you just have a relaxed development day where people are riffing on each other's jokes?

It's nice to spend moments like that with others. It also makes the occasional absurdities of development easier to bear.

Extra money

I've purposely listed this last. Developers, at least in the US, make great salaries. The money that you earn while streaming will likely come nowhere near your salary, but it's still something! If you've already got a comfortable job, then you can at least feel less guilty when you treat yourself to your favorite restaurant or buy a new gadget.

Disadvantages of streaming

Before we look at the cons, I want you to consider that many of them vary based on the size of your audience:

If you have no viewers whatsoever, then streaming your development process isn't all that different from not streaming at all.
At 100 viewers, you'll be able to keep up with chat and respond reasonably well.
At 1000 viewers, you'll need to drastically cut down your interactions if you want to get anything done.

Again, here's a list in order of decreasing importance:

Productivity hit
Leaks
Energy cost
Security, compliance, and theft
The rat race
Internet trolls

Productivity hit

Developing is hard enough on its own, but once you add people's random thoughts into the mix, you'll find yourself context-switching constantly. Imagine this comic ratcheted up by X, where X is the size of your audience. You will lose track and forget things. And yet interactivity is the nature of the platform! If you're not going to interact with people while streaming, then it stands to reason that you could have just recorded yourself programming offline.

There are some mitigations for this:

Write down what you're working on so that you always have that text to anchor you. Alternatively, you can literally replay the last 2-3 minutes to figure out what you were thinking about (this is sort of like having source control for your thoughts!).
Ignore chat while tackling particularly difficult problems.

Leaks

Whether it's personal (like your address) or technical (like passwords), given enough time, you're going to leak something. Here are just a few unexpected ways in which I leaked data:

I was testing an HTML input and Chrome tried autocompleting the whole form with my name, address, email, etc.
Ansible has a verbose flag (-v), then it has a very verbose flag (-vvvv) that prints everything to the console, including the passwords that you're using. I didn't even realize it was doing that for weeks.
I pasted a password from my password manager into my terminal when it wasn't masking input.
Many sites and programs assume that you're the only one at your computer screen, so they'll display your data ("you are logged in as personal@example.com"). Twitter is especially egregious; they pop up a dialog every once in a while asking "IS XXX-YYY-ZZZZ STILL YOUR PHONE NUMBER?"
Searching for seemingly innocuous things (e.g. "grocery store") will typically show a map of exactly where you live.
...and many more!

Mitigations:

Don't ever point out that you leaked something. Most people aren't actively watching every little thing that you're doing, so they won't know to screenshot what they're seeing. Depending on the severity, consider ending the stream and deleting the VOD.
If the leak is technical, fix it as soon as possible. When I leaked my passwords, I wrote a note on exactly which sites and configuration files I had to modify in order to more quickly recover later (if it ever happened again).
Use multiple scenes in your streaming software and have a special one for when you're about to show sensitive data. Alternatively, use multiple monitors.
Look into extensions for your editor (like Cloak for VSCode) that can hide secrets automatically.
Honestly, just get more comfortable with people knowing relatively common things about you like your full name or the general area where you live.

Energy cost

I'm introverted, and it can take a lot of energy to stream. You have to be "on" the whole time, handle issues with grace, and change contexts like a champion. That's all on top of your normal development, which is already a mentally draining process.

Mitigations:

Time - your streaming stamina will improve over time.
Breaks - whether it's a 5-minute break every so often or a proper "streaming vacation", make sure you have work-life balance. Don't be afraid to end streams early if you feel that it's too difficult to continue.

Security, compliance, and theft

This is similar to leaks except that you're intentionally displaying your code to the world. Doing so leads to three issues:

Security - suppose you write a bug into some server-side code that you showed while streaming. People may take note of it without telling you only to later exploit the flaw.
Compliance - did you use a library or code snippet that you weren't licensed to use? Other people can see that and alert the owners of the software that you've done so.
Theft - your code is copyrighted as soon as you type it, but that doesn't mean that someone can't steal it anyway. It's hard enough to pursue those cases when the thief is in your country, and it's almost impossible if they're in a different country.

In practice, these shouldn't have a major impact unless people have a reason to go after you, so don't make yourself a target.

The rat race

I've seen many people start out streaming saying things like "if I get 1-2 viewers, I'll be happy!" or "I'm just streaming for fun." That's probably true at first. However, we naturally like seeing progress, yet we also adapt to our current level of success, so when we hit a plateau, it's easy to start feeling dejected.

The biggest mitigation here is to answer why you want to stream before you even start, then try not to lose sight of those reasons. For me, it was just to stay accountable, and even though I was meeting that goal, I still felt the desire to keep growing my audience.

That brings us to the mitigation which actually did help me: hide your view count from yourself. There's no real reason to have it showing in the first place since you should always act like you have a captive audience even if no one's there.

Internet trolls

Ah, the flip side of the community coin. Trolls generally seek to ruin your day in order to draw attention to themselves. They'll say mean things, spam your chat, or try to get you to say something bannable on-air. The silver lining in this cloud is that for every troll you get, you'll find a hundred nice people.

Mitigations:

Don't hesitate to perform moderation actions. Is someone annoying you? Time them out. Are they still annoying you after being warned? Ban them. You're not just streaming—you're developing—and you can't do either very well if you're in a bad mood.
As much as possible, try not to give them attention.

How do I start?

Set expectations

Before doing anything else, you should envision what success looks like for you as a streamer; why do you want to do it? Your reasons are personal, but there's one that I'll specifically argue against: making it big. It's not that you shouldn't try to grow your audience or make money, but streaming development isn't a get-rich-quick scheme. In my experience, it's been a make-less-than-minimum-wage scheme even though I'm usually toward the top of the category.

Granted, I could have made more money if I'd pushed for subscribers, but it doesn't change my point: I think it's always good to set reasonable expectations and sporadically reevaluate. Go to the category you'll be streaming in and see what the numbers are like. At the time of writing this post, there are 158 Science & Technology streams on Twitch. 132 of them have fewer than 10 viewers. 121 of those have ≤5. It's likely that you'll end up in that bucket at first (and it could potentially last for a while).

Finally, be ready to conclude that streaming isn't meeting your goals. Streaming has its own overhead associated with it: setting up overlays and scenes, researching gear, rewatching your videos, etc. Streaming development adds to that overhead, e.g. the productivity hit that I mentioned. Thus, if it's not actually helping you, then that's fine! It's not like you're throwing in the towel; it was just a tool that didn't meet your needs.

Set up your stream

There are guides online for setting up your software and hardware, so I won't cover specific steps here.

The bare minimum that you need is streaming software, e.g. OBS, which I use. For hardware, given that development work is relatively drab to watch, I advise using both a microphone and a camera. With a microphone, you can think aloud to fill some of the dead space, and the camera will add some personality.

In my opinion, the only other hardware to consider getting at first is another monitor if you don't already have two; it's nice to put OBS, chat, and any private windows on it so that you don't distract from the development process while viewing those.

Don't consider investing in an expensive setup until you know that you enjoy streaming. Over the years, I've upgraded lots of my gear. The best piece of advice I have around that is to upgrade the weakest link. For me, it was my webcam; I went from a Logitech C310 to a C922x and felt like it was a huge leap in quality.

Whatever you end up with, make sure to test it out by watching your own videos. How do you sound with no typing or with music? Are you physically obscuring your code with your webcam's output? Is it hard to hear you when you turn your head?

Choose a platform

I actually don't think there's a choice here; you have to go where the audience is, which is Twitch (as opposed to Mixer, YouTube, etc.). There's a non-obvious reason why I wanted to mention this: depending on how far you progress with a streaming platform, you may eventually end up signing an exclusivity contract. I signed one when I became a Twitch partner, and it now prevents me from streaming on other services.

For now, this isn't important. In the future though, other streaming services may become more appealing for developers.

Figure out why people should watch you

There are a few primary reasons to watch someone's development stream:

Personality - are you entertaining? Nice? Positive?
Skills - are you good at your IDE? Your operating system? The language you're using?
Community - is chat friendly? Are they knowledgeable?
Project - is it interesting? Easy to jump in to? Note that most people who watch aren't glued to their screen as you type each line of code. As a result, I don't see someone's project being too important, but it will attract or repel certain viewers. For example, I had people watch me while I was creating an NES ROM, but they didn't stick around when I did web development.

Here are some general tips on how to make your stream more enjoyable for viewers:

Make sure your font is readable. You may be able to comfortably see ~70 lines on your monitor, but there's no guarantee that someone watching in 480p on their phone can read them.
Talk! If there are only a couple of people chatting, then you should probably engage them. What are they working on? What suggestions do they have for you? How long have they been coding? If you don't have an audience, then act like you have one and narrate what you're doing and why. At the very least, it'll put you in the habit of doing so when you do have an audience.
Work on your speaking skills. Cut down on verbalized hesitations ("uh", "um"), mumbling, etc.
Work on your development skills. For one, you'll be more competent, so your development itself should benefit. However, you'll also look more competent, which will go a long way with new viewers.
Set a schedule. People want to know when to expect you online.

I wouldn't worry about which part of the development process you're streaming. There's always going to be someone out there who wants to watch! I've streamed myself documenting, designing, testing, refactoring, etc.

Growth and interaction

As I've touched on, growth isn't necessarily a good thing depending on your goals. If you only want to be held accountable, then having ten active viewers is better than having ten thousand.

There's a site called SullyGnome that tracks Twitch statistics. You can check out your favorite streamer there or even an entire category's stats.

Growth can come from several sources:

The platform - either people are looking for streams in your category or the platform specifically recommended you to someone.
Networking - you bond with another streamer or community and gain viewers through them. This is why you should always host or raid another streamer at the end of your stream. Follow or join their stream/Twitter/Discord, chat in their channel, etc. Essentially, do what you'd want those streamers to do in your channel or with your community.
Promotion - most people aren't outright buying ads for their channel, but if you're comfortable with a particular community, they'll usually be okay with you posting your stream link. Follow-for-follow schemes are a waste of your time since they don't provide any lasting benefit.

Once a viewer is in your stream, it's your job to captivate them so that they want to come back. Let's say you split your time on-stream so that you're developing for about 80% of the time and interacting with chat for the other 20%. In a 5-hour stream, that would mean that you're spending an hour interacting. When you have a small audience, that hour goes a long way. You can make a real, personal connection with each individual chatter.

As you start to get tens or hundreds of viewers, you'll only be able to say "hi" to each person and maybe remember some basic, broad details about them. This tension between interaction and productivity is core to growth as a development streamer. After all, the biggest difference between a live stream and a prerecorded video is interactivity!

You'll have to discover techniques to maximize your interaction time:

Make commands

One technique that I use is to have commands for frequently asked questions, that way I'm not answering "which keyboard do you use" twenty times per day. However, when a new viewer asks that question, they don't know that it's already been asked repeatedly in the last few minutes, so they may be put-off by not getting a personal answer. This is the give and take of streaming, and you'll have to test different strategies to strike a nice balance.

Identify dead-ends

Sometimes, a conversation is destined to go nowhere. You'll have to spot patterns in these so that you don't spend too much time on them. The patterns that I've noticed repeatedly are:

Conversations that just aren't suited for live-streaming. For example, if a design discussion spans 6 hours and someone joins halfway through, you likely can't get them up-to-speed without spending 5-10 minutes on them (this is partially because very few people will read any public documents that you share). Without that context, they'll start proposing ideas that you've already discussed, but you also don't want to sound dismissive by saying not to ask questions.
People who can't contribute. Some people mean well but have no realistic way to contribute. For example, they may not even be technical, or maybe they don't know your particular stack very well.
Overly opinionated people. This seems like trolling sometimes, but it's actually just someone who has a very strong opinion on something. For example, I had someone say that I shouldn't be using Windows. I asked them why, and they said they hated it. I don't really care if people like or hate the technology that I use, but a personal distaste is not a reason for someone else to switch.

Delegate

By shifting some of the onus onto your community, you'll free yourself up for the work that doesn't scale. Encourage them to welcome new viewers and answer their questions. Elect moderators to help out with this.

Miscellaneous

Here are some random tips that didn't fit anywhere else:

Avoid variety streaming (e.g. streaming development and gaming) unless you want to brand yourself as a variety streamer from the start. If you haven't branded yourself as a variety streamer, then you'll see a tremendous dip in your audience's interest when you switch from your main activity to a secondary one.
I find it frustrating when I enter a stream and the streamer isn't even present. From my point of view, I don't know if it's a 10-second water break or a 20-minute lunch break. For that reason, I almost always put up a "BRB" screen with an estimated time of when I'll return.

(I know this is a short section for now; I'll likely add links to specific blog posts that I have planned for the future, e.g. making overlays in OBS)

Conclusion

Streaming is just a tool. If you want it to work for you, then you'll need to know your audience and capitalize on your own strengths. You should expect very slow growth unless you're already e-famous, but remember that growth isn't everything! Twitch is and likely always will be a platform primarily associated with playing games.

My own goals with Twitch have changed drastically since I started 5 years ago, so rather than link my stream again, here's something that will help us both: my Development Efficiency course! Astound your new audience with your impressive efficiency. ⚡

So you want to learn how to program?

Adam — Mon, 25 May 2020 16:42:57 +0000

Introduction

This post is for people who want to learn how to program but don't know where to start. I won't talk about the specifics of any particular language; this is more about getting you into the right mindset.

As for me, I've been programming professionally for many years, five of which were live-streamed on Twitch, so I've gotten my share of questions on the topic. The most common ones are:

Question: can anyone learn how to program?

If you can understand this blog post, then you can learn how to program.

Question: does programming involve a lot of math?

From a practical perspective, no. Programming is entirely based on logic, and while I do look at logic as being part of math, it's not the kind of math that people usually mean (e.g. calculus). Still, basic math skills and algebra will help.

For another point of view, think of a programming language like a human language—just because you know English doesn't mean that you can speak with authority on any topic! Programming is the same way; you may need to know biology in order to make medical software, music theory to code a sequencer, and math for data analysis.

Setting expectations

Without the right expectations, it's easy to get demotivated before you can build any momentum. The biggest expectation to set up-front is that you probably won't be making interesting programs for a while (at least a month or two). They'll more likely be small, console-based programs to help build the fundamentals.

Those fundamentals are typically concepts like variables, if statements, and outputting text. They are not things like adding fiery swords into games or building a social-media network. Nobody goes from writing their first program to coding World of Warcraft, and that's okay!

This is why I suggest focusing on exactly two things as you get started:

Are you learning?
Are you having fun?

If either answer is "no" for longer than a week, then you're probably going to lose focus (this post should help you find fun and effective ways to learn).

The coding landscape has changed a lot in the last 10 years or so. Coding bootcamps started popping up around 2011. They serve as a focused, immersive way of learning coding quickly, and even then, it takes 3-6 months of full-time (sometimes more than full-time) learning.

In addition, tools for programming have become much more accessible. I mentioned that you won't be adding a fiery sword to a game, but thanks to game engines and modding, you actually could add one without even writing a single line of code. However, that's sort of like saying that you can lift a car so long as you have access to a crane; the tool takes time to learn and use, but it's doing the heavy lifting for you.

Don't get me wrong—I don't say this to delegitimize game engines or the work that people do. Instead, I'm saying that if you want to learn programming, then at some point, you'll have to learn what goes into making those tools. By all means, start your programming journey with Minecraft mods or the Unity game engine.

This brings us to the last question that I get all the time:

Question: which programming language should I learn first?

Alternatively, I hear this as "is Language A better than Language B?"

This is the beauty of learning programming: it doesn't matter! Here's why:

You need to start somewhere.
You will likely learn many languages if you continue programming.
Technology changes rapidly enough where the popularity of languages will also change over time. This even leads to the death of some languages or environments (e.g. Flash), thus forcing you to move away from the specifics that you've learned.

In my opinion, the time you spend debating on which language to learn is time wasted. If you want someone to pick for you, then go with Python:

There are tons of Python resources out there, so you'll be able to find support online for any problems you run into.
It's still actively used in the professional world.
It can be set up in roughly a minute on any operating system.
It reads almost like English in some cases.

How to go about learning

In general, learning programming is no different from learning anything else. It's some combination of studying, practicing, and talking to other people (e.g. teachers and coders). Studying and practicing will help you internalize the skills and come up with questions to further your knowledge. Talking to others will prevent you from building bad habits.

More specifically, there are lots of resources out there. People ask me which ones I recommend, but unless it's a resource that I used in the last couple of years, it could be out-of-date and I wouldn't know! Instead, I suggest looking at something like this absolutely massive list of free programming books. Augment that with YouTube videos, general Internet searches, and the resources that your friends and teachers recommend, and you should be set.

At some point early on, you'll probably ask, "what project should I work on next?" It's crucial to pick the right project, because if you don't like it, you'll simply stop working on it. If that happens early enough into your programming endeavors, then you may stop learning altogether.

The sections below contain important notes on how to choose a project.

Scope

Always pick a project that is slightly beyond your current skill level. This concept is called scoping the project. An overzealous scope is the biggest killer that I've seen for personal projects. It's tempting to put in a couple of weeks of time learning the basics and then jump right into making that game or site that you've always wanted to build. It's much better to prune that idea down to just one or two systems.

For example, suppose you were interested in making your own version of Twitter. Here are some projects of various sizes that you could implement:

A "tweet typer" that counts your characters as you type and warns you when you've gone over the limit
A site where text blobs get downloaded from a server as you scroll down the page
A sign-in system
A mobile app that renders a website
A link-shortener service

I didn't spend a long time typing that list, and I didn't even cover 10% of what Twitter actually does.

If you find yourself on a project whose scope ends up being larger than you thought, then don't hesitate to cut features completely. Remember that your primary goals should be learning and having fun, so try not to add pressure to yourself by tackling a project that intimidates you.

Domain

Do you like games? Sites? Graphics? Networking? Algorithms? Utilities?

There are hundreds of domains from which to choose a project, and I can't answer for you what you'll find interesting or fun. Going back to the Twitter-clone example, suppose you didn't want to make a sign-in system, but you felt that it was too important to skip. The good news is that someone out there has already made the system for you! You can look into what they did and incorporate it into your project (although be careful about licensing; I'm not advocating for plagiarism or theft!).

If you didn't want to go that route, then just take a shortcut to where you feel like you'll learn and have fun. When I didn't want to code sign-in systems, I just made buttons that said "Adam1" and "Adam2". Clicking them would act like I'd signed in, but I didn't need to make name/password inputs or even send that information to a server.

Design

Programming and product design are filled with microdecisions:

How should the site look as you shrink the browser?
Will users understand what I'm trying to convey here?
Is this game more fun without this system?

You can't ever completely remove decision-making from the equation, but you can drastically cut it down by reinventing the wheel. For example, if you wanted to learn game programming by making your own game, you just made two tasks for yourself: designing a game and learning how to develop that game. If you instead recreate an existing game like Tetris or Pong, then you can focus solely on the code (obviously don't actually claim other people's work as your own or try to sell it).

I've done this before where I wanted to learn a new language or framework without having to come up with my own unique project, and it's so refreshing to bypass all of those decisions that would typically nag at me.

What to learn

I talked about how to learn by making use of all available resources and picking the right project, but here's what you should learn regardless of which language you start with.

Self-sufficiency

Programming has a lot to do with self-sufficiency. If you've ever fixed someone else's computer problem by Googling the issue, then you know how powerful this can be. A good programmer doesn't memorize everything; they just know how to solve problems as they arise. For new programmers, StackOverflow will be a great resource. You'll find anything from basic questions like "what does 'syntax error' mean?" to more advanced ones like "how do I integrate these two systems?"

I've written that you should use other people as resources, and now I mention that you should be self-sufficient. Which is it? Programming is full of "small" problems that can expand to fill your whole day, and you'll frequently find that you save yourself hours by just asking someone early on. In the end, it's a judgment call of when to involve other people. For quick, factual questions like "can I make a website with JavaScript?", I think you should almost exclusively be searching the Internet. For more involved programming problems like "why isn't my code working how I want it to?", you sometimes need to sink your teeth into the problem to understand your own thought processes before asking for help.

Debugging

Everybody writes bugs. We all strive to write them infrequently and to find and recover from them quickly. Experience will help you with the former, and debugging will help you with the latter.

Most modern languages have an easy way to debug them (e.g. PyCharm for Python, browsers for JavaScript). The two most significant aspects to learn are how to place breakpoints and how to inspect variables. With breakpoints, you'll be able to stop your program at a specific line of code, that way execution is frozen in time. Then, you can inspect variables to see if your assumptions hold true. I still find myself saying, "this can't be happening because I turned this flag on" only to debug and see that the flag is really off.

You haven't fixed a bug until you've fully understood it. The reason why this is so important is because when you come across a bug, you immediately make a bunch of assumptions. Suppose that the bug is a missing image on your site, and your initial hunch is "the image file doesn't exist." You look in the folder that should contain the image and you see it there. Then you think, "maybe one of my libraries got updated and that's having trouble rendering the image." You investigate that and make some changes, and in the process, the bug is solved, but you don't know why.

If you stop there, it's possible that the bug still exists but that you don't realize it. In this particular example, let's say that the bug was caused by trying to access the file on a Tuesday for some reason. You're clearly going to encounter this bug again, but you'll assume you dealt with it. That's why it's so important to understand the root cause of a bug.

Whenever you find [and eventually fix] a bug, you should ask yourself these questions:

Where else might this bug exist in my code?
How will I prevent myself from hitting this bug in the future?
What techniques/knowledge did I learn that could help me find any bug faster in the future? For example, maybe you learned that logging is helpful or that you tend to make typos in filenames.

Miscellaneous

Learn more interactively
- Take notes to reinforce concepts.
- Test out programs for yourself so that you're not just assuming how they work.
- Don't be afraid to look through code that you don't own. Open-source software is everywhere nowadays, so if you're using an open-source library and you have a problem, then dig in!
Recognize your accomplishments. Impostor Syndrome runs rampant amongst programmers. You will know more one week into programming than you did when you began, and you'll know much more after another month or year. It all happens so gradually that it's easy to focus on people more experienced than you and wonder why you're not there yet, but getting there only happens with time and effort.
Start NOW. You just read this blog post, so you were motivated enough to do that (and good job, by the way!). Carry that momentum over to python.org or any number of other sites and go write your first program! It's completely free and you'll open up a whole new world for yourself.

Why should you learn programming?

I'm putting this section at the end because you had your own reasons for even arriving at this blog, so this section is just to bolster those reasons:

Technology is everywhere. I went to the store before writing this blog post and saw a barbecue grill with Wi-Fi built-in. I can't believe I'm typing this sentence, but... some amount of programming had to be done to make that grill work. You never know what possibilities might arise in your own lifetime where programming may help.
It's full of problem-solving, which can be deeply satisfying. There's nothing quite like spending hours investigating a pesky bug only to find out its true cause and then share the results with your co-workers, customers, or annoyed significant other.
There's so much to explore! You'll go from "software is a mystery" to "how would I have implemented that?" sooner than you think. That opens up doors for you. You may write an application that your friends love, automate parts of your house, or just tinker around with something technical and fun. I combined several of my own interests by learning how to type with a piano keyboard. Who knows what you'll end up doing?

Conclusion

The biggest takeaway from all of this is that you should start learning! Don't create barriers for yourself by debating which language to choose.

I've got more specific resources for you to check out eventually at my site where I sell courses.