Rules for the Unborn Programmer
Print “Hello World,” and then…?
(Author note and shameless plug: This article sort of blew up. Proof of my somewhat grizzled programmerly-ness can be found through my landing page CV. I also have this start up thing called GameWisp that I’m working on.)
It’s back to school time again.
My campus is waking from its summer slumber. The air is rife with early twenty-something hopefulness and positivity, optimism abounds, Things Are Going To Be Great. It’s all a bit too much for this jaded, perpetual graduate student.
Some of these optimistic teens are undoubtedly freshman Computer Science majors. How excited they must be at the prospect of being the next Zuckerberg, Jobs, or Hopper. I know I was. I was 19 when I first really started to program and, by God, my bits were going to change the world! Sadly, there can only be one Zuckerberg, and folks trained in computer programming will likely spend their day, well…programming computers, as opposed to running enormously successfully software companies.
There’s magic and wonder in making a computer do things, but programming is so much a job, a vocation, a thing-you-do-to-pay-the-bills. And it’s the space in between the magic, somewhere after dreaming the Next Big Thing but well before actually shipping it, that the true notion of programming arises: making a computer do awesome stuff is a lot of work! Not as much as it used to be, sure, but before a project is done, sleeves are rolled up, brows are mopped, and more than one creatively heinous epithet is uttered.
There’s a lot to be learned in the space between ideas and finished projects. We call that space software development.
With this thought in mind, I set out to assemble a list of all the things I wish I had known about programming before I was neck deep in data structures and algorithms; firmly seated in that space between bar napkin and compiled executable, the place where the work gets done.
With that, I present the rules, the lessons I’ve learned that I hope will guide nascent programmers to binary nirvana. The Rules for the Unborn Programmer, accumulated from years of slogging through the doldrums between idea inception and execution.
- Embrace Source Control.
I will be shocked if, at some point in your college curriculum, a professor teaches you how to use source control. It’s just one of those practical things that’s usually “outside the scope of the class.”
Tools like Git (especially Git!) and SVN are de facto methods of sanity protection used by programmers when it comes to collaborating. Learn source control, and learn it early. If you have a group project in a class, be that jerk that insists the team use GitHub, and not DropBox, to collaborate. The team will thank you for it later.
For bonus points, why not administrate your own Linux server that hosts Git repos of your work and others’? Many a life lesson will be learned.
- Always collaborate
Computer science professors, especially in the early courses, are pretty fanatical about you not working with others. You’re expected to complete your assignments on your own as you sit alone in your room in the dark, listening to depressing music, drinking cheap bourbon, and wondering why you made such poor life decisions. This approach in no way mirrors the real world.
Programmers work together. Constantly. They share ideas, tips, and strategies that make programming easier. They come together for ad hoc, furious, cooperative problem solving in the form of hackathons. They make pull requests to strangers’ codebases on GitHub.
As early as you can, get involved in whatever programming scene exists around you. Go to meetups, participate in hackathons, be someone’s savior on GitHub, or join a university computer science group. It’s fun stuff and extremely valuable in the long run. Collaboration is the bread and butter that gets important programming projects done.
- No one cares about your text editor, unless that text editor is X.
I’m always kind of shocked about the things programmers will choose to be passionate about. The most shocking is perhaps the dogged fanaticism and debate centered around text editors and IDEs.
This will happen to you, Unborn Programmer. It’s about halfway through your second semester, you’re in class minding your own business, and someone behind you will extol to their nearest peer the virtues of Emacs (or Vim, or Sublime Text, or writing directly on hard drive platters using butterflies). It’ll get heated, too, because your peer knows Emacs is for losers and real programmers are only productive in Notepad.
The truth is real programmers are only productive in the best tool for the job. Don’t marry your tools, they’re there to be hacked on, sworn at, and ultimately replaced as you move on to some other job.
No tool for producing code is universal, at least in the practical sense. If I’m writing C++/Qt in Windows, I use Visual Studio. If I’m writing that same code in Linux, I’m using Qt Creator. If it’s a Rails app I’m working on, maybe I’m in Sublime Text. There is no Swiss army knife, the best tool for the job is the one that makes you,not that Emacs guy, the most productive.
- Go to class. And do well. Seriously, it isn't hard.
Some people will drop out of your CS program, and/or college, and/or move on to other things. Peace be with them; college isn't for everyone and that’s a-okay.
There is a different type of college no-show that really sets my teeth on edge, though. Here’s a polarizing opinion: you know that C- average student in your Algorithms class that never shows up because he’s too busy working on his own projects? Forget that guy.
I don’t care if you learned BubbleSort before it was introduced in class, no lecture is beneath you. Especially when you’re paying for it.
As a college student your job is to go to college. Not performing your job because you’d rather frolic through the glorious fields of “personal projects” just shows that you lack discipline to do the things that you find unpleasant or boring. There seems to be a collective crush on the programmer that was too cool for school, the one that just didn’t need any help. A vast majority of burgeoning programmers cannot pull this off. And the last thing I want to do is collaborate with this type of person. Go to class, do your work, and use that personal project to supplement, not supplant, your coursework.
Moreso than many other science fields, the things you learn in your coursework can be directly applicable to your future programming gigs. Once your mechanical engineering buddy graduates, he will probably never have to figure out, on paper, how many Newtons of downward force Timmy needs to exert on his lawnmower to get the grass mowed. However, the problems and ideas you encounter in class can, and will, be used nearly verbatim in a professional setting later on.
The mapping between classroom learning and real-world implementation is 1-to-1. Polymorphism will be on the exam and you can fully expect to see it again later, years down the road, when you can’t even remember the professor that taught it to you.
- Learn ideas, not languages.
When you encounter it for the first time you may really hate Lisp. You may think C++ is too problematic. Prolog may be so obscure as to be viewed as a waste of your time. The truth is, the power of a language isn't in its syntax, its popularity, or even its intended domain. The power of a language is in its ideas.
Lisp might suck (to you), but you know what’s awesome? Functional programming. And nothing demonstrates functional programming quite like Lisp. It even carries over into other languages in ways that you may never even expect. This cross-over of ideas happens all the time in programming languages. New languages don’t necessarily make our lives easier as developers, the ideas those languages support do.
Yes, the syntax of a language can go a long way toward making those concepts understandable, usable, and powerful. Popular languages typically have more robust communities around them, making the language itself more useful. I get it. However, I would still argue that a programmer will utilize the idea of inheritance long after he/she will need C++. So, stick with ideas. Ten years from now you likely won’t be using the same languages in the workplace that you used in your college classes, anyways.
- Be cool to one another.
Some programmers out there can have more than their fair share of negative character traits. Arrogance, perhaps? A sense of technical entitlement? Brogrammer?
You will see these traits in your peers. Part of it is our fault, as an industry, for propagating terms like “rock star hacker” and “bit slinging, bug wrangling, super-coding cowboy”. Programming is hard, requires extensive brainpower, provides quick gratification, and might be cool now. These factors serve as ego bait, and in some programmers, the ego comes out in spades. Don’t be this person. Learn while you’re young to skip the rockstar ego and just be nice to each other.
- Love this stuff.
You may love programming now, but burnout is a real bitch in this profession. Understand that if you dislike doing an assignment in your Programming Languages class, you’re probably going to really hate crunching through a litany of bug fixes after a QA engineer or tester gets a hold of your last code commit.
Programmers program. In course work, on pet projects, at their jobs. All the time. It’s what we think about and do, which is why I’m baffled when computer science students lament having to work on programming assignments. Passion goes a long way in this profession. So if you find three or so semesters into a Computer Science program that you aren't feeling it, you may want to look for greener pastures.
- Making software is not just writing code.
So much of software development exists outside of the physical act of writing code. So much so that at least one great book has been written about it
Much harder than writing code is solving the problem, building a design around that solution, communicating that solution to others, and turning that solution into an implementation. This is software development.
When learning to be a programmer, always think about the bigger picture. If you have to write FizzBuzz, consider how different the solution would be if it had to be distributed across a server farm, if it had to be completely fault tolerant, or if it was organized as high quality, enterprise software. Turning these simple assignments into bigger problems will force you to consider bigger solutions; solutions that will more adequately mirror the kind of things you may be working on in your career. Don’t actually code these solutions up, though, time is money, friends.
- Always be uncomfortable.
I associate being uncomfortable with being outside of my element. If I’m outside of my element, I’m probably learning something. This is crucial to being a good programmer.
If you stand still, you die in this profession. Always push yourself, always be a little uneasy in your work. Learn to accept impostor syndrome. There’s power in feeling like you’re never good enough.
Understand that if you’re not a little scared to show your work to others, you’re probably not learning anything.
I’ve been a C++ programmer for nearly a decade. I still suck at it. I’ll always suck at it. I just suck a little less each day. And it’s this attitude that keeps me learning and always trying to improve.
- Learn from your mistakes. Please learn from your mistakes.
This rule goes hand-in-hand with the last one. If you’re learning, you will make mistakes. Actually, you will make them regardless. Some mistakes will be insignificant, others may be catastrophic. These things happen.
The principle of Don’t Repeat Yourself (DRY) is strong in the programming community, and the concept is doubly important for screw ups. Learn from your failures, scrutinize them, take away the important points, and move on.
Odds are whatever pitfall got you this time will rear its ugly head in the future. Your mistakes are fire-breathing dragons. The first one will burn you, but if you fail gracefully, the next time you’ll remember to bring a shield along.
- Finally, try to have a little fun.
Seriously, writing code is a hell of a drug. There’s a lot of enjoyment to be had by changing patterns of lights in a little box. So, enjoy yourself, tackle challenging projects, and attempt to extract all the self-fulfillment from this profession that you can. With a little hard work, you’ll be a Semicolon-Savvy RegEx Samurai in no time.
