The Undergraduate's Guide to Becoming a Professional Developer

Having achieved the first steps toward success in my career, I sometimes find myself giving advice to college students. This post distills the most essential advice so that kids can get off my lawn more expediently.

The fundamental issue is that the skills needed to get and succeed at a software development internship or job are somewhat different than the skills that most computer science classes teach. In some cases, classes teach exactly the opposite of what you need for a job. In my opinion, the job skills are substantially easier than the class skills and you can pick them up quickly.

I got my first programming job at 18 years old, before many of my friends who were much better computer science students than I was, because I understood these skills. Because people told me about them. Like I'm telling you.

Other People's Code

Most classroom assignments are analogous to something called "green-field projects:" when you build something starting from scratch. The professor says, "Here is this wonderful blank file, go ahead and implement mergesort in Java." Or, the boss says, "Hey, we need a mobile app, go write one."

In most workplaces green-field projects are rare, especially for interns and new developers. It is incredibly rare that you would work on one by yourself. Instead, you spend most of your time building on other people's code.

In school, they go a step further and say you have to write your own code. You can't just use your language's standard library sorting function because that wouldn't teach you anything, you have to write it yourself. In the so-called real world, writing your own code is hard and takes a long time and results in way more code to maintain so you generally don't do it. You use other people's code whenever you can.

Two great sources of other people's code are libraries and frameworks. I use these things all of the time. There are external libraries and frameworks maintained by third parties, and internal libraries that your company maintains itself.

Another great source of other people's code is, without loss of generality, Stack Overflow. Sometimes these snippets can be difficult to place in context or use without documentation, but solving a problem yourself is slower than using someone else's solution. In school, using someone else's code is cheating. In the workplace, as long as the code you're using is appropriately licensed, using someone else's code is how you get your job done.

Glue Code

When you have two chunks of other people's code, whether from libraries or stack overflow or frameworks or APIs or the stuff last year's intern wrote, usually they don't play nice out of the box. So you have to write something called "glue code" to stick them together.

Usually, you have to take output from one system and re-format it to make it valid input for another system. These programs bridge the interstitial space between the bricks you build your software with; a digital mortar.

Development Environment

For your first 2 days (if you're lucky) or 2 weeks (or more if you are particularly unlucky or work for a very enterprisey company), any time not spent in onboarding meetings be mostly devoted to setting up your development environment. A development environment must provide three pairs of things:

A way to write your code, and a way to read other people's code in context.
A way to run your code, and a way to see how it interacts with other people's code.
A way to save versions your code, and a way to reconcile changes you make with changes other people make.

You know your development environment is set up when you can run whatever programs you're going to be working on locally and they work the same as they do live.

The final key piece of your development environment is version control. Without knowing your job, I can say your version control will probably be Git via GitHub or maybe GitLab. Learning how to use Git confidently is among the highest returns on investment an aspiring developer can get on a single afternoon spent learning.

Projects

A natural question is, "Hey Philip, this all sounds great, but how do I develop these skills and then communicate them to potential employers."

Projects, mostly.

Make a GitHub with your real name or a professional alias. A personal website is cool but not strictly necessary. Demonstrate that you have these skills by putting your projects on GitHub. Final projects from class can be a good fit if publishing the code after is allowed. Hackathons are good for this. So is just making stuff with your friends. You don't need a bunch of projects. You don't need huge projects. But 3-5 projects that go beyond basic tutorials and show that you can glue together other people's code in a development environment are proof to a potential employer that you have these skills.

There are plenty of other skills that go into being a professional developer. But if you can make these job skills part of your repertoire you'll have a much smoother time getting and excelling in your first job.