I was recently asked over lunch to provide some advice for someone going through my alma mater’s computer science program. I took up the whole of lunch rambling on, and dropping in comments like, “Maybe I should just write this down,” and “I’ll put this online so you can just give it to him directly,” and so on. It’s a real problem I have. I think, “Oh that’s a simple question to answer,” and really, if ever there were a signifier that a question is anything but, it’s that exact thought. Anyway, here’s some advice.
First of all, I should note a few things about the program. My alma mater is a state school, and thus the state has some say in the way things work. However, more than that, the state has some say in the way all public universities work when it comes to certain programs to ensure that transferring between schools goes smoothly. It’s a lofty goal, but what it comes down to is a series of educational compromises that, yes, make it easier to transfer school, but rarely add anything to the program. In fact, in the efforts to keep these programs similar across schools, much is removed that might be beneficial to students (and nevermind the lack of competition). A lot of teachers have interesting courses to teach in interesting ways, and a lot of classes do better with one book than they might another, but a lot of that is stiffled. Additioanlly, much of these shared programs are not exactly set up by experts in the field so much as those who have wound up through business or politics in the position to be the type of people who would set a curriculum.
So I didn’t get my degree in CS.
This has given me a few benefits and a few setbacks, but I’ve never really felt as though I regretted to get the degree that I did (music composition) rather than computer science. In fact, a lot of the benefits I’ve run across have been directly due to my degree. And no, the correlation between math and music is not one of them, I’m sorry. Please stop telling me about that. One of the biggest has been that, after I wound up in the workforce as a programmer and made it to the point where I was helping to conduct interviews, I wound up being the one who helped hire (or not hire) candidates who had come from various different CS programs, and a few who hadn’t. The difference is readily apparent.
Although I’m going to number these bits of advice and such, none are necessarily more important than the others, so keep that in mind!
Unit of Advice Number 1
Maintain a portfolio of public work and information.
A lot of those who wound up coming out of my school’s CS program, to my eyes, had very little in the way of a portfolio of work, or even any public information about themselves, beyond just a résumé. A notable exception, though, was one of my coworkers in school who graduated with publicly visible open-source code as well as time working for private companies, with works he could point to and say were his, as well as projects of which he had been a part. The opposite of that, which I saw with relative frequency, was the sort of blank slate you would expect going into a degree rather than coming out of it. Your time in college is a chance to grow and expand your experience in ways that will help you down the line, rather than simply learning facts.
Write code. Join clubs. Get a job. Get a lot of jobs. Write more code. Do stuff. This comes up more in Number 2 below, but seriously, get out of school. My degree required that I attend a certain number of concerts per semester (15, if I remember correctly), and only a certain number of them were allowed to be department-held events. Getting out of school helps, but yeah, more on that later. The most important thing to take away from this is that you really, really need to have something to show people that you love what you do (because if you don’t love it, boy will you hate it as a job!). Set up an account at GitHub/BitBucket/whatever and keep posting to it as much as you can.
Unit of Advice Number 1 - corollary 1
Contribute to open source projects.
While we’re on the subject! Contributing to open source projects does a lot more than just show off your skills working with code. It shows three things that will be helpful to you down the line: that you can work with a project not your own, that you can work with a team, and that you can work on atomic tasks.
Working on a project, as I said above, helps to show that you are willing to accomplish something with your skills, which is great! However, as nice as it is to come up with a problem in need of solving, this is usually done by some entity other than yourself. Your business, your department, or even your team in a department is going to have some sort of task to accomplish, and it’s not necessarily going to be yours. What you gain by accomplishing your own task is solving a problem, but what you gain by workint on an existing task is project comprehension: it shows that you can read code, understand the project, and then contribute.
More than just working on a task in a larger project, there is a social aspect to working with a project that isn’t your own, as many of these projects accept contributions through a vetting process, such as a pull request or merge proposal. These are social, I promise. There’s a way to propose code, even if you’ve never met the project lead, that will make it more likely for your patch to be accepted, just as the opposite is true, and you need to be able to learn how to figure that out for each project, as each project lead will be different. Working solo is fun and can be quite fast, but working well with a good team can go far, far beyond that.
Finally, working on an atomic task is very different than working on an all inclusive task. The reason that this is important is the push for management techniques that help the team to work with each other as much as possible without getting in each other’s way. You should also know about these, of course: figure out what the various types of management are and how they work (not just Agile, not everyone follows that, of course). The practical side of it, though, is that a lot of these styles will mean that you’ll be working on a small task that is as focused as possible in order to speed you up and keep you from stepping on anyone else’s toes.
Unit of Advice Number 1 - corollary 2
Be accessible on the web.
The upshot of both of the previous two points is that you automatically wind up with resources available to friends and employers online. You’ll have your GitHub or Launchpad URL that you can point to and say, “See? I did that.” This is of the utmost importance when applying for a software development job, and I personally consider it to be one of the most useful things available when deciding whether or not to hire or even interview a candidate. LinkedIn profiles, while good for organizing information and work relationships, tell us relatively little about how you work, which is of immediate importance to us, your future coworkers.
Get yourself a webpage, teach yourself at least something of the net (if you’re not going into web dev, fine, but please at least set up a simple landing site for yourself and learn how to manage it), and collect information in one place for people to peruse. Put a blurb about yourself, a PDF of your résumé, and links to your portfolio pieces and OSS contributions there. Also, if you’re going into web dev or web design, now’s your chance to show that you know your stuff. You should already know this, but it’s worth saying. Send your résumé when applying for your job, but also send this URL, or even include a link on your résumé itself for those application processes that only allow a file.
Unit of Advice Number 2
Branch out away from school.
A lot of programs with a set curriculum will focus only on one limited set of things: one language, one processor architecture, one database style, and so on. Get away from that in your free time. If you graduate with a comprehensive knowledge of Java, MMIX, ANSI SQL, and so on, that’s all well and good, but that limits your best-fit job prospects to those that want just those skills. If you’re stuck with Java, learn some of the other languages that run on the JVM and scratch out some of your homework in those before finishing it in Java (or write some of those personal projects in them, hmm?). I’d suggest things like Groovy, Clojure, Scala and the like to get away from the Plain Old Java OO paradigm. Try out Mongo, play around with a different OS, definitely try something other than Eclipse!
The goal here isn’t necessarily to just make yourself more marketable in these languages, though it’s that as well, but to learn how to learn. Once you learn how to efficiently learn a new language, learning a new language isn’t a barrier to applying for a job outside of your list of known languages. It’s not just languages, either. Get into web dev. Or get out of web dev. Just get away from school and write code and join communities and learn. It’s pretty crazy out there.
Unit of Advice Number 3
Creativity and problem solving are more important than mechanics.
Your job is not to sit and do a task without thinking. Your job is to solve a problem. You will run across mechanical tasks like refactoring, but the majority of your work will involve creativity. You’ll have to be able to dive into a problem and pick it apart into its component pieces as well as step all the way back and take a look at where it fits within the project at large. There will be a lot of technically correct solutions, and only a few of them will be Actually Right, and your job is to pick one of those and make it work. It’s really hard to stress this enough: you are not data entry with a lot of curly braces - your job is to get your job done and to do it well, and that takes creativity as well as the rote skills you learn in school.
Unit of Advice Number 4
Get comfortable with tools.
The language used as an abstract concept at work is not your job, either. You work with computers, and so it’s good to know more about them. A very good example is VCS tools. Learn at least git and svn, but don’t be afraid to check out all the others, too. You will almost certainly use a VCS of some sort at your first job, and there’s a pretty good chance that you’ll use a different one at the next job. Learn about DVCS as well as centralized VCS, figure out feature versus release branches, be comfortable in IDEs and on the command line. Get comfortable with the fact that process is a part of work, and that process generally happens over a series of tools.
Unit of Advice Number 5
Do something else, too.
Stop working every now and then. Please. Make sure you keep a hobby that doesn’t involve computers at all, or you risk burning out. I took up cycling (until I got hit by a car - twice - at which point I took up running and reading), but there’s a ton of things out there that don’t involve sitting in front of a computer. Or if they do, they don’t involve the same means of interaction, the same ways of thinking as programming. You have to be able to get away from Things That Feel Like Work for at least part of the day, or you start to lose fun. After all, this isn’t just advice on how to get hired doing something awesome after school, so much as things that keep awesome things awesome as time goes on.
On a more practical note, look into a work time management program such as Work Rave or a pomodoro technique tool. Ergonomics are plenty important, but they only solve so many problems if you just spend 100% of your time sitting (or standing) in front of a computer. Knowing when to move, when to step away, look away, or exercise are things that can help keep work from seeming so much like a death march, and honestly, stepping away from the computer for five minutes is when a lot of those good ideas come and a lot of problems get solved.
Finally, learn how to say “enough”, “no”, and “I resign”. Be happy doing what you do, and accept that you are not some sort of all-powerful programming deity with all the time in the world on your hands to do everything, even the unpleasant things. Definitely be wiling to accept that as time goes on, you’ll be able to do less, especially as you get older. It’s not just a time thing, either: your focus will narrow as you’ll get better at what you do. Just be healthy about that.
There’s a lot that goes into working with computers right out of college, but never forget that your goal is to make awesome things. Just make sure that you get in the habit of doing just that, doing it well, and being healthy about it, and really, everything will be pretty great.