FROM THE ARCHIVES OF PRAGPUB MAGAZINE JUNE 2016
Tips for Young Programmers
…of All Ages
By Antonio Cangiano
In 2015, Antonio interviewed over 100 candidates, all impressive young people, for a certain large computer company. Here’s what he wanted to tell all of them.
I’ve long wanted to put together a series of tips for young programmers, and I finally decided to do it.
My advice is aimed at aspiring programmers, students, and programmers who are just starting out. It’s more about experience than age: if you are 60 and only now getting started with programming, you fit my definition of “young.”
If it’s all right with you, I’m going to skip the part where I motivate you by telling you why learning to code is a great idea and akin to acquiring a super power. I’m just going to assume that you’re interested and highly motivated to become a programmer. If you’re not, find your “why” first. The why is more important than the how and you’re going to need both in order to succeed.
Although I’m numbering them for reference, these tips are presented in a more or less random fashion, and each can pretty much stand alone.
Tip #1: Specialize in Something
Last year I interviewed over 100 candidates for IBM. Most were students from elite universities and all of them were impressive young people. We ended up hiring a couple dozen of them, mostly as interns.
Their university education had opened them up to a wide variety of topics in computer science. The logic behind such an approach is sound. Syllabuses are intentionally designed to prepare students to think like a computer scientist, and to expose them to as much computer science as they can cram into four years.
The idea is to show students what’s out there so that they can then decide what interests them so that they might pursue further specialization academically or on the job.
The downside of this approach is that unless you do independent work in your spare time, you might graduate with very little code under your belt.
More importantly, you’ll simply be a bundle of potential. You could specialize in anything you want to. You could become a good programmer, but you haven’t likely reached that point in either case yet.
There are certainly companies willing to hire you on the basis of that potential. I mean, if you graduate from an Ivy League school, with top grades, naturally there will be big companies who are interested in you.
To widen your job prospectives, however, I suggest that you specialize on your own.
The market will pay you for the value you bring to it. This is true whether you are an employee, freelancer, or opt to launch your own startup.
This is why I fully respected, appreciated, and even hired candidates with plenty of potential and not much experience. My favorite candidates, though, remained those who independently developed a keen interest in a particular area of the information technology world, and learned as much as they could in parallel to their more formal studies.
This tip could very be easily phrased as, “Be useful at something.” If I hire you to do something, it really helps if, on top of having the potential, you also have a measure of experience and expertise in that something, that will aid us in developing your skills further.
To date, there are still students around the world who graduate and come to the market with very little knowledge regarding things such as the command line, any editor that isn’t an IDE, who have no idea what Git is, and whose memories of subjects (e.g., web development) they touched upon a couple of years back are often hazy at best.
Whether you’re a student or not, my first tip is, therefore, to become useful at the creation of a particular type of product.
Here are some examples of “stacks” you can specialize in:
• Learn how to develop Android apps
• Learn how to develop iOS apps
• Learn how to develop web applications with Rails
• Learn how to do data science with Python (or R)
• Learn how to hack hardware
No matter what you choose, try to become experienced enough so that you have an essential understanding of the lingo, best practices, and challenges of that particular type of development.
Once you’ve determined the type of software you want to build, it becomes much easier to focus your efforts toward what needs to be learned, what books should be read, and what code you need to write.
Want to become a web app developer? Learn HTML, CSS, JavaScript, Ruby, and the Ruby on Rails web framework, for example. Then start creating projects by first following along with tutorials, then on your own.
Want to become an Android developer? Learn Java, then how Android apps are built (you’ll have to become well acquainted with Android Studio and the SDK).
Speaking of Android, I’m particularly reminded of one of the best performing students from my LEADing to Africa summer internship in San Francisco.
My L2A summer interns
Not only had he a comparable foundation in computer science to that of other students I’ve interviewed, but he had also taken the time to independently learn enough Android to be “useful” (or dangerous, depending on who you ask :)) on that front.
You could ask him to create a fairly complex Android app, and he’d know how to approach it and make it happen in a reasonable timeframe. That’s adding value to the market.
Be like that student. Be a mile wide, and an inch deep, but specialize enough in something to be useful.
Tip #2: Learn Revision Control
A surprising number of people in our profession are not familiar with revision control software.
In the world of computer software engineering, revision control is any kind of practice that tracks and provides control over changes to source code. Software developers sometimes use revision control software to maintain documentation and configuration files as well as source code.
— Wikipedia
Over the past ten years, the growing prominence of Open Source software has helped to make several best practices far more established, but it’s still all too common to encounter developers who are not familiar with revision/version control software such as Git, Mercurial, or Apache Subversion (SVN).
Understandably, this lack of knowledge is much more noticeable among young developers and students.
Let me be absolutely clear about this: there is no software development today without revision control. Anything non-trivial will require that you use revision control, whether developing in a large team, a startup, or even on your own.
If you’re an aspiring developer, your career in our field will be enhanced by studying Git. Why Git specifically? It provides several advantages over SVN (mostly due to its distributed nature), and it’s more popular than the also excellent Mercurial.
Ten years ago I would have recommended that you learn SVN. Things change, and it’s possible that in another ten years, Git will no longer be the reigning king in this arena.
I’m operating, however, under the reasonable assumption that you want to work today or in the near future. If so, learn Git. The principles of how revision control software works remain the same, even if a different solution were to show up on the market at a later date.
Bear in mind that you don’t need to become an expert in what is a fairly complex system. Just master the basics, so that you’re competent enough to resolve most common situations and collaborate with fellow developers in your team.
Learn how to create a repository, clone it, pull, add, delete, commit, push, create and merge branches, diff files, revert changes, and so on. Basic stuff you’ll do day in and day out when changing code.
It won’t take you more than a couple of weeks of practice to really nail the fundamentals.
Another couple of related suggestions:
Add Git to your resume. While interviewers will probably just assume that you know Git, placing this skill on your resume, especially if you’re a student or inexperienced developer, will clear up any doubts they may have.
You’ll need a place to host your Git repositories. Sign up with GitHub (and if you want a private repository for free, Bitbucket. Even if you’re not at a point where you can commit code to your repository, you can still practice Git by changing and pushing text files to it. If you have a GitHub profile that you use to contribute to Open Source, make sure that it is listed on your resume, too.
To learn the basics of Git, I recommend that you use these two resources:
1. tryGit
2. This tutorial by Michael Hartl
They should get you well on your way to Git productivity.
Tip #3: Master an Editor
As a developer, you’ll spend a lot of your time writing code. Less than you’d think, but still thousands of hours.
It pays dividends to master your code editor. A powerful editor, properly used, will provide a myriad of benefits.
The following incomplete list will give you an idea of some of the ways in which an editor can serve you:
• Speed up the process of writing code by autocompleting parts of the code you write.
• Highlight and indent your code for readability.
• Simplify the process of refactoring code (e.g., consistently change the name of a variable across your program).
• Point out obvious typos.
• Easily find code within your project (e.g., through finders or through the ability to jump to definitions).
• En mass manipulation of text and code, without having to manually perform changes line by line (e.g., replacing strings, commenting out large sections of code, etc.).
• Execute code directly without having to step out of the current window.
• Folding your code, so that you can focus on the current method or class, and ignore the rest of your code base.
• Visually identify files that have changes from your Git repo.
Honestly, this isn’t even scratching the surface. Just take my word for it, being well acquainted with your editor of choice will eliminate a world of frustration from your coding experience.
GitHub’s Atom editor
A natural follow-up question would be, “Which programming editor should I use?” Ask ten programmers and you’ll get at least five different answers. It’s a highly personal choice and people get religious about their editor-of-choice.
I’m going to share my opinion and you can then find out for yourself what works best for you.
I would classify most editors into five categories:
1. Shell-based text editors. These are historic text editors that include such offerings as Vi/Vim and Emacs. They are extremely powerful and customizable but come at the expense of a high learning curve.
2. WYSIWYG text editors. Examples of this type of text editor are Notepad++, Atom, and Sublime Text. Much less of a learning curve than something like Vim, but still quite powerful.
3. Integrated Development Environments (IDE) that are specific to a particular development stack. Some will argue that these are not code editors, but they certainly include one, among a whole host of other features, often including a way to visually design your application. Examples of IDEs are Android Studio, Xcode (for iOS and Mac OS X apps), and Visual Studio (for .NET applications).
4. Niche-specific editors. For example, Coda [U8] for front-end web design.
5. Cloud editors that enable you to develop directly from your browser. One example of this sort of editor and development environment is Cloud9.
Any editor will do (well, don’t use Microsoft Word), but the choice will be very dependent on the kind of development you intend to do.
For example, if you plan to develop for the web:
• Learn the basics of Vim or Emacs for when you are remotely shelled into a Linux/BSD server.
• Master Atom or Sublime Text for your main development. Conversely, if you plan to develop mobile apps:
• Learn the basics of Atom or Sublime Text for incidental file editing.
• Master your app platform IDE (e.g., Android Studio, Xcode, Xamarin).
In general, I would recommend that you learn the basics of Vim so that you can quickly change files when connected to a remote server via the shell.
Vim or one of its variants is almost always installed on Linux/Unix servers already or can be easily installed if you have admin rights.
If you love it enough to master it, you might even want to stick with it as your main code editor. Many developers do.
Regardless of what you choose or do, spend the time to become proficient in the tool you decide to use to edit your code (including reading a book on the subject if your editor or IDE is quite advanced).
Tip #4: Get Familiar with the Command Line
Back in my day, and I’m not that old, programmers were a subset of people who were “really good with computers.” It would be hard to find a programmer who didn’t know how to use the operating system of their choosing far beyond end-user level.
These days things are a little different. Now we’re encouraging everyone to code and become a programmer, so a lot of newcomers no longer have many a sleepless night fighting with, say, SUSE CDs, under their belts.
As a result, you run into people who can be somewhat competent within a given development environment, but who don’t know how to create a symbolic link or tail a log.
This is not said to disparage newcomers. On the contrary, it’s quite commendable how quickly many young programmers are now able to learn a whole stack of technologies in order to create applications.
It is, however, an impediment to their ability to become productive and successful programmers.
So, my advice today is to break free of that limitation by learning the command line. You don’t need to become a wizard, but you should get acquainted enough with it that you know how to use the command line to accomplish tasks that are simply not exposed in GUI interfaces.
I’m specifically talking about the Unix-based command line, such as Bash. Technically, it can be used on Windows as well, but realistically, hardcore Windows programmers might find learning the Windows PowerShell to be more useful.
Where to start? There are countless tutorials and books on the subject. I personally recommend Michael Hartl’s Learn Enough Command Line to Be Dangerous tutorial, as it’s specifically aimed at newer developers.
But Wait, There’s More!
These tips are drawn from a series of posts on my blog, ProgrammingZen. I’ll be posting more tips for young programmers there, so if you found these useful, come visit and learn more.
About the Author
Antonio Cangiano is a software developer and technical evangelist for IBM, web entrepreneur, and serial blogger. He is one of the main go-to people within IBM for advice on blogging, social media, and technical marketing. In addition, he is the Marketing Lead for Cognitive Class, an educational initiative which he helped to grow from zero to over 1 Million students. Combined, his technical blogs have attracted millions of page views and tens of thousands of subscribers, and currently generate a substantial side income for him. You can learn more about Antonio at antoniocangiano.com.
