What does it mean to program?

First, let's address an important difference: programming and coding aren't the same thing. We often use both interchangeably, since the word code is a lot shorter than program, but Cratecode doesn't teach people how to code. It teaches them to program.

Coding is the act of writing code. It might take a bit of memorization, and some knowledge about the language you're using. Someone who knows how to code could take a detailed document on what to write and write a program with it, but coding is fairly simple.

Programming, on the other hand, is a problem-solving process that using coding. Essentially, programming is figuring out what to code, or being the one to write the detailed document. Programming is not simple. It involves understanding the problem at hand and learning how to approach it. It means figuring out the best solution for a problem, and applying computer science concepts to figure out what to write. Cratecode teaches you how to solve problems, not how to translate an already-solved one.

On that note, let's talk about looking stuff up and copying. In the real-world, everything's fair game so long as it helps you solve a problem and doesn't break copyright law, and that's the environment that I aim to prepare you for. That is, if you copy something and insert it into your code, make sure you're allowed to and add a comment to point to where you found it. A lot of software development is building upon problems that others have already solved, and knowing how to put them together to solve your specific issue. The two main ways you'll see this are through libraries and code segments. Libraries are basically little bundles of code that someone has made which you can download and call (think of them like little programs that your program talks to). Code segments, on the other hand, are pieces of code that you might copy, modify a little, and then put directly into your own code. This is in contrast to libraries, which sort of exist alongside your code and usually can't be modified. Because of this, I'm not going to tell you not to look stuff up or copy (of course, so long as it follows the two golden rules above). But I will urge you to:

1. Give the problem a go. Even if you don't get it, you'll learn a bit by making the attempt. After that, check out how other people have solved it (even if you solved it yourself).
2. Understand what the code does and how it works. One of the biggest reasons we copy other's code is to avoid re-inventing the wheel. We could if we really wanted to, but it would just end up being a waste of time.

And always keep in mind that, across every discipline and sub-discipline of computer science, everybody looks things up and copies/uses other's code.