So you want to learn about programming pt.2

Part 2: Tooling around

So you want to learn about programming pt.2

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 knowledge 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.