Computer Science at many liberal arts colleges (including my alma mater) can be very theoretical. This is fantastic, in many ways — languages will change, platforms will go out of style, but if you know the theory, you’ll be fine no matter what direction the profession takes. There are, however, certain things that this type of education neglects, and should be addressed by enterprising students looking to get a good job.
Working with Git
This really should go under a larger heading of ‘working in a team,’ but ‘learn git’ is a bit more practical for a someone to do on their own.
What is git? Git is a program that makes it easier to maintain different versions of code. This is important because in a team, there may be any number of people working on the same codebase. Each person will have their own version of the code, and their changes to the code are tracked by git. This makes merging your code with their code easier. Coming into a job knowing how to do this is a huge plus, and something that gets major points when I’m looking for developers at that level.
However, git comes with it’s own set of problems. It’s finicky, complicated, and magical (in the sense that you may often find yourself typing arcane commands in the hopes of fixing your problem). Use with care. Luckily, there are tons of resources for learning about git. Learn it. Love it. Use it for every project you do.
Tracking Your Projects
This has several advantages.
First, it gives you a record of what you’ve done. When you’re in a rut, looking back at the things you’ve accomplished can be a huge confidence booster, and spur you to slog through whatever task you’re avoiding.
Second, it helps you manage your time better. Seeing what you can do in a day/week/month helps you better estimate how long a project will take you, which is a valuable skill for everything from programming to homework to busy work. I track all of the tasks I give myself, whether they be building a new screen layout in Xcode or taking out the trash. This helps me create accomplishable daily to-do lists — which goes a long way for my state of mind.
Third, it can really help solve problems in the future. If you’re tracking your project, you can see what issues you ran into, and how you solved them. This has saved me more times than I can count.
Finally, as your number of projects balloons and time passes, you’ll have valuable documentation whereby you can reorient yourself within the project, and quickly get back up to speed.
There are several options for managing your projects. Personally, I use Trello, because it’s free with good UX, but I’ve used JIRA and Target Process in professional environments.
Using TDD
TDD (Test Driven Development) is an incredibly powerful way to write code. TDD means starting out by writing a test your code has to pass, and only then writing the code.
Why is this so important? One, it makes you think clearly about how to write your code. What are you trying to accomplish? What does this piece of code need to do? What methods should be employed to complete the task?
Second, because writing tests aren’t the fun part, you think about how to make the tests as precise and focused as possible — namely, by testing only one thing at a time. In turn, this keeps your classes and methods from doing to much; if one class has ten responsibilities, you have to write a super long set of tests, and who wants to do that?
This is all completely neglecting the obvious point that once your tests pass, you know you’ve completed the task. This is especially beneficial when you need to come back to it and change something; just run the tests again, and as long as they still pass, anything that relies on your code will still work.
There are just so many ways TDD will improve your code. I could go on and on, but lucky for me, other people already have.
Valuing Readability over Cleverness
Writing good code is often the same as writing maintainable code. In some ways, this is very straightforward. It can mean “don’t be lazy,” in that naming a variable ‘var1’ is much worse than than naming it ‘bottomLeftSidebarMarginWidth.’ Name your variables logically and clearly, even if it means a lot of typing. When you revisit the code in a year, you’ll thank yourself.
Don’t try to be too clever, unless you have a good reason for it. ‘Clever’ code is a pain to read. Often it sneaks up on you, and you end up sitting there asking, what is this person doing? This can lead to hours of diagramming, debugging, and running through examples. You should aim to never have someone ask, what does this code do? It should be as obvious as you can make it, unless performance or business requirements demand otherwise, and maybe not even then.
AGILE
AGILE is a very powerful way of getting things done. The concept seems simple enough: it amounts to doing one thing at a time. By building one thing at a time, you get something done quickly, and front load risk so that problems can be tackled as soon as possible. Compare that to working on many different features at once — it’s hard to say when the job is finished.
Frankly though, and this is why it’s last on my list, fitting into an AGILE workplace is not hard. Look up the AGILE tenants on Wikipedia, read something like AGILE Flash Cards, and you’ll be more than fine. If you expect to lead a team, well that’s different, you should know a lot about AGILE, but mostly, AGILE just a series of fairly reasonable steps to building something in an iterative and robust fashion. Regardless, though, you should know the term, and what it means.
schrock { block } 