Welcome back! This is another post aimed at total beginners. It’s a follow up to last week’s post.
We ended last week with a simple set up so that we can make and run computer programs on our own computers. This week, we’re going to talk about two other important concepts to getting started: IDEs and version control.
Do I want an IDE?
An IDE is an integrated development environment. But what are we integrating?
An IDE integrates a toolchain. A toolchain is the series of programs that takes your code from the text files you wrote to instructions that the computer can execute. The advantage of an IDE is that the toolchain is set up for you in one step. Instead of using makefiles or something to organize your build process, you just have a button that says “run.”
Many developers use IDEs because they provide a fast and simple setup, even for languages that might have a more complicated toolcahin. On the other hand, some developers avoid IDEs because they make a lot of decisions for you. For me, the choice of whether to use an IDE depends a lot on the language and on the project. I do use an IDE at work. (I use Visual Studio at work. If you’re writing in a .NET language on Windows, you should certainly use Visual Studio; the languages and the tools are built together, and really complement each other well.)
If you’re a beginner, and there is a good, free IDE for your language, I recommend two things: First, install that IDE, because it will lower your barrier to getting started. Second, learn what the IDE is doing so that you’ll be able to go without it or troubleshoot it later.
Version Control All the Things
In this section of the tutorial, you should first install Git on your computer, if you don’t have it already. I also recommend you go through the try Git tutorial, and create an account on GitHub. For the rest of this post, I’m going to assume you’ve done those things. If they give you any trouble, leave a comment and I’ll update this post with further instructions here.
And now, a sad story about not using source control:
One morning I was sitting at a coffee shop before work. I was running a little late, but I was determined to finish a coding exercise from a Coursera course before work that day. I didn’t have an editor I was in love with for that language (R, in this case), so I was jumping back and forth between Notepad++ and Visual Studio Code, depending on what I was trying to do. (Mixing editors mid-flight was a mistake.) I got something finally right, pressed CTRL+S, pressed ALT+TAB, and there was this dialog box. “File has changed on disk. Reload?” and I made the wrong choice. Boom. About two hours of code accidentally deleted because I was in a hurry and using two text editors.
Fortunately, the story is not that sad. I lost 2 hours work on a personal project. It’s not like I lost 2 weeks of work on my boss’s projects. Still, I was frustrated, and now even more behind.
So here’s the moral of my short sad story: always use source control. Always. Always. Somewhere on his blog, Joel Spolsky wrote that all non-trivial projects need source control. I’m going to add that all trivial projects need source control too.
Typing ‘git init’ in your new directory is free, gives you good practice for your future job, and gives you the ability to track different changes and versions. Plus, if you’re going to mess up source control, you might as well get it out of your system while it’s your own homework and not your company’s source code.
How I Start a New Project:
- Make a new directory for it, with a name I can remember. (I keep all my projects at D:\Projects\<projectname> because then I don’t need to look for them.)
- If I’m using an IDE, tell the IDE to create a new project there; otherwise, start writing a source file and save it there.
- Create a new file called “.gitignore” in that directory.
- I get a premade “.gitignore” template and paste it into my new .gitignore file. If I’m using Visual Studio, for example, I’ll use a .gitignore template for Visual Studio.
- I type ‘git init’. This creates a new repository.
- Every time I make a change I like, I commit it at least to the local repository.
- If this project is even slightly longlived or complex, I’ll put it on GitHub. (Note: free git repositories are public, so make sure there aren’t things like passwords or API keys in your public git repo.)
- I start actually writing lots of code.
Now that you can track changes to your source code, and can get it to execute locally, and can back it up to a remote source code repository, you’re in business.
In a future post (soon, I think) I’ll talk about choosing an easy starter project, since that’s something a lot of people ask about at programming meetups.
Till next week, happy learning!