Yesterday, I was asked a question on my Tumblr about the differences between writing code in an academic setting, and writing code professionally. Full disclosure, I sort of baited this question to be asked; it’s a topic that I feel pretty strongly about, and I know that a lot of the people who still follow me on Tumblr are CS students.
I’ve been writing code, professionally, for over two years. I’ve been doing it non-professionally for a lot longer. But I’m also still a student, still completing the research portion of my CS degree, and so I wanted to spill what was in my brain before I lost my frame of reference, my perspective.
Anyway, I’m reproducing it here, in full form. Not to get all Merlin Mann on you. But I think these are good things to know, and I also think that they apply to more than just programming; these are things that are helpful to understand about life, as long as you reframe it to the context of the tools and skills required for whatever it is you do on a daily basis.
The first thing you have to get used to is the idea that the code you’re writing is suddenly important. I can’t speak for anyone else, but this fucking terrified me to the point that it impacted (and sometimes still does impact) my productivity. Getting a C on a project is one thing. Over-torquing the motor on a million dollar robot or crashing a UAV in to the ground is a whole new ball game.
But the thing is, those are things that have to happen. Failure is good. You can’t learn without failure. But our educational system and culture isn’t set up to support that. I’m always a little scared every time I hit the commit button to check in code. Meanwhile, my friend Jesper from the Netherlands is constantly frying wires and writing code that kills the robots and just sort of… breaking things. Not coincidentally, he’s much more known for his ability to solve problems and fix other people’s broken things than he is known as being a breaker, because his fearlessness has been his greatest education. It’s very, very difficult to separate your code from your own personal identity, because programming is — at some level — a craft as well as a discipline. It is a creative endeavor with a tangible product, so often critique and even failure will get transposed as personal criticisms or personal failures. Learning to separate your code from your persona and accepting when you fuck up could be the most important skill you develop in your career.
Speaking of committing. If your university offers Software Engineering electives, take them, even if it means loading up on extra courses. Having to learn proper architecture and design, version control, collaboration and planning techniques, etc. was a bit of a hurdle for me too, as I took an entirely theoretical and algorithmic track through the CS program, specializing in embedded programming and AI. I’ve had to learn all of these things myself, and it wasn’t hard, but it was one more thing to have to learn.
But out of all of that, maybe the most important thing to realize is that by the time you graduate and start looking for a job, there’s a pretty good chance that you are going to be, or at least feel like you are, woefully underprepared for whatever job that you take; nobody feels it necessary to tell you this when you’re in school. Being a good programmer is one thing, but as soon as you begin to write code that does something useful, then you get in to dealing with domain-specific knowledge. Which you probably won’t have. On top of that, we’ve had the advent of this little thing called the Internet in between the 1970’s and today. You mentioned in one of your posts that you have an upcoming weed-out exam that requires you to have what I would consider to be a monumental knowledge of the Java language since you have to solve a problem with no resources or look-up capability. All of our code at the robot lab is written in Java, and there are people there who have been writing Java code for over a decade. And every day we are all still continuously referring to the documentation on the Java website. The notion that a “good” developer needs to have an encyclopedic knowledge of a language and its syntax went out the window with easy access to learning and resources. This doesn’t bear out well in education, but it definitely does in the industry. The one exception I can think of in my educational career was my Operating Systems teacher, wherein if you only gained one thing from his class it was the ability to read man pages.
Even if your entire four year degree is taught all in one programming language, you will leave that institution knowing a fraction of what there is to know about that language. Computer Science degrees are not language courses; languages are simply tools that are used to solve problems in the field of computation. Dijkstra himself once said “Computer Science is no more about computers than astronomy is about telescopes.” To become fixated on “knowing a language” instead of knowing how to solve problems is a dangerous game.
That’s not to say that holding on to this sort of knowledge about languages isn’t still a good thing; it should be something that good developers should strive towards, and my knowledge of Java has grown substantially over the past few years. But even I’m not confident that I could pass the test you’re about to take, and I’m not exactly a shitty programmer by any stretch of the imagination. The realistic need for this has been mostly obviated by the awesome array of tools we have before us; IDE’s like Eclipse that provide completion assistance and code suggestions and symbol look-ups; searchable API documentation in the form of digital media; becoming a proficient wielder of tools and a proficient problem solver should be the true goal of any computer scientist. And programming languages are just tools, in the same way that your development environment is also a tool. The ability to fluently solve a problem using a specific programming language should come about organically and as a result of familiarization, almost osmotically. It shouldn’t be the result of the consumption and retention of a bunch of printed words.
Rote memorization takes up space in your brain that is much better served being filled up with real knowledge and solid thinking skills. There is no shame in using Google as your own personal secondary brain; it doesn’t mean that you’re any less “smart” than the programmers of yesteryear, it simply means that you’re a different breed of programmer.
At the end of the day, Computer Science is a fundamentally different field than Software Engineering. Many people go in to Computer Science with the expectation that they will exit with the skills of a Software Engineer, and this could not be further from the truth. I’ve had to learn how to manage my expectations, and my fears, and in turn realize that no matter how good I get that there will always be something more for me to learn from someone else that’s much smarter than me.
It’s all about tools.