So you want to learn about programming (part 2)

Feb 2, 2017

Part 2: Tooling around

Wooden toolbox

At some point before deciding that you want to be really good at programming, either you’ve started some classes or one of your friends recommended a specific programming language that is beginner friendly, such as Python or Java. If so, either you’re editing your code in something like Notepad (much like a modern day caveman would) or you’re using an Integrated Development Environment like IntelliJ or Eclipse, which sounds really fancy but it turns out that it’s just Notepad on steroids.

Experienced programmers take time to learn how to use tools like IDEs to make their jobs and lives easier. There are other types of tools, and it’s up to you to stay up to date with what industry pros use to write code as fast as possible.

Code writing tools

Despite being somewhat of detour from yesterday’s topic, I have a very strong opinion about telling beginners about developer tools as soon as possible. This is because your absence of knowledge1 leads you to believe that writing code is bothersome, when in fact developers are the laziest creatures to have roamed this planet. We write code to automate boring stuff and then pack it as a plugin for an IDE. How many times have you wanted to rename a variable you’ve used several times in one or multiple files? How about creating a class with just a few fields and their correspondent getter and setter methods? You’ll be happy to learn that, thanks to our legendary laziness, we’ve automated these kinds of actions that even if not so common, are just boring to perform.

Therein lies the perks about getting to know your programming environment: performing actions that would have you tearing out your eyeballs with minimal effort. Don’t get me wrong — I’m not suggesting going through the entire documentation of the software that you’re using, since odds privilege the chance of you quitting programming altogether and head out to work in a farm rather than being able to finish it and become some sort of IDE wizard. The sweet spot is to always be very suspicious about repetitive tasks like the ones I’ve mentioned, and for each occasion you’d want to Google if your IDE has got you covered.

For the remaining sections of this post I’m going to assume that you’re using an IDE. If you’re not by any chance, please do consider it! 🙂

Code storage tools

Beginners with OCD or with a very organized workflow will tend to keep their code very neatly organized in a folder somewhere, with projects separated either by language, college course and/or date. You win 10 internet points if you have your current setup like that, but be aware of 2 significant limitations of this approach:

  1. If you are working on a cool project you’d like to present one day in your CV, no one is going to see it if it’s tidily stored in your laptop.
  2. You can’t usually scale to work with multiple partners on the same project without having to manually merge different versions and files that you’d share in some very primitive and naive way.

Now before you start complaining, I can hear you loud and clear from here:

“That doesn’t make sense. I can have my code repositories stored in a Dropbox folder, and that makes it possible to work with as many people as I want. And I could just send a .zip file with all of my projects to someone who’d like to see them.” — Some noob (probably me at some point)

There’s a gazillion reasons why this doesn’t work, and I’d take forever to list them. Let’s first approach the multi-user setup and why Dropbox is definitely not how you want to be working in a group:

  • You cannot have multiple parallel versions.
  • There’s a lot of suffering awaiting those who dare to try this with partners that run any different software stacks. Even using the same IDE with different versions and/or OSes can cause you a world of suffering. In short, you’re going to see your IDE crash constantly.

The zip file approach is also a really half assed one too. You’d email ALL of your 150 projects to an interviewer if you’re just applying for a web development position? Would you cherry pick between them and zip only the relevant projects?

I hope that these arguments are enough to sway even the most stubborn of you away from working like primitive chimps. Onto the more interesting part: how pros do it.

Every sane programmer uses some sort of code repository service, be it self-hosted, organisational, or a paid one.

GitHub, Bitbucket, GitLab, SourceForge, …

Pick the first. No, seriously! Pick GitHub. I’ve become somewhat of a GitHub fanboy, not for how amazing they are when compared to the competition (spoiler: they aren’t, most services have very good offers), but because they partnered with big industry names to provide freebies to students, in order to unlock your full potential. They are also the most popular option, having managed to rack up an incredible customer base, with names like Apple, Google, Facebook, IBM, Intel, Mozilla, Apache, etc…

This is what code repositories provide: - They host your code for you, which basically means that if your laptop gets stollen or if it faces a fiery death, you won’t lose a byte (provided you actually send code to the repository!) - They manage concurrent versions, support rollback to previous versions, which tends to save lives when you break stuff that was working shortly before handout deadlines. - If you want, they can be public.

If you think about it, it solves all our problems from before, since it allows you to work with teams of any size, and you can have public and private repositories. All you need to do when you send your CV is send the link to your GitHub profile, and anybody will be able to see your public projects, without hassles.

Remember to claim your pack of freebies if you have an email associated with a college! (works outside of the US, I’m from Portugal)

As much as I’d like to keep babbling, there just wouldn’t be enough space for me to teach you how to use GitHub and repositories. Just remember that programmers are lazy, any decent IDE supports one-click pushing to remote repositories, and for the more curious among you, complete the hello-world assignment from GitHub themselves.

How to find other tools

There are too many tools out there and listing any would make me look biased; I’m gonna leave it to you to search for tools that are relevant for what you’re working on. Maintaining a keen sense of curiosity and open-mindness about using new tools will ultimately enable you to be at your peak performance.

The best way to find out about the best tools for any job is to participate in online communities such as Stack Overflow or Google Developer Groups. Go out of your way to bother other developers (especially more experienced ones) and ask them what they use. If you’re using something different, tell them and discuss the differences. Most times you’ll learn new things from how developers work, so it’s paramount to be an active participant of communities related to your area of work. If you’re a student and you deal mostly with Java, why not sign up for a Java community or meet-up nearby? It’s guaranteed you’ll learn boatloads of new and exciting things.


Take the red pill, and be wary when you need to do repetitive tasks. Look for better and quicker ways to do them through your IDE. Use GitHub because it’s awesome and go get your student pack. Talk to other programmers (colleagues, teachers, people from online communities) to see what tools they use and if you should be using them. Your mastery of a specific IDE is independent from your mastery of programming languages, so don’t be shy to learn all the ins and outs of the tools you use the most.

  1. I use euphemisms sometimes. [return]