Advice to Incoming Freshman in Computer Science
Brian Brooks <email@example.com>
Most of this advice is extremely general and you’ve probably already read or heard it, but you probably never truly experienced why it’s good advice. In fact, if you’re a freshman I’d bet good money that you probably haven’t truly achieved these experiences. Hell, I even know a slew of undergrads who still don’t grok it… and $40k (maybe even a M.S.) later they probably still wont… So take from this what you will. Actually, I wrote this for myself since I’ve already hinted at why it’s useless to you.
1. Learn a text editor, and stick to it!
One of the most important tools for a programmer is the text editor. Programs consist of code that later becomes interpreted or compiled and executed. The closer your editor allows you to focus on pure semantics of a program while coding, the more powerful, expressive, and productive of a programmer you will be. Think of notepad, IDEs, refactoring tools, cscope, etc as separate tools (hammer, screw driver, saw, etc) that are usually damn good at getting their job done. Now think of Emacs or Vim; these are collections of tools made out of Legos. If you need a new tool, you can easily make one on the fly. Brushing the topic of metaprogramming, but to stay focused, it’s all about productivity. The same analogy can be applied to programming languages when you compare imperative languages such as C++ and Java to functional languages like Lisp or Haskell; different rant. You’d be surprised at what I can concoct using just a BASH shell and emacs, all while you wait for Eclipse to finish loading.
Tip #1: Try coding with your eyes closed. If you’re working in a strongly typed language or a systems language on a project that already has the framework in place, try editing with your eyes closed. I know it sounds nuts, but the best way to learn new macros or key strokes is by repetition. You have to constantly be working to improve your editing skills. Visualization is key. You can buy the “best” tennis equipment and take lessons from John McEnroe for years upon years and not improve by much; you have to be constantly conscious of what you’re doing and how you’re practicing. There’s only a certain amount of truth to “practice makes perfect.”
Tip #2: Learn LaTeX. It is the de facto standard for formatting papers. Not only learn LaTeX, but its history and algorithms. This is how I got hooked onto studying Knuth’s material.
2. Learn C.
The “enlightening” version: C is one of the oldest systems languages. Everyone has heard of the cliche that you can shoot yourself in the foot with C. It has a weak type system, capable of producing challenging to read code. Be able to understand pointers and memory management like the back of your hand. You’re simply better off knowing it.
Actually, it’s pretty tough to rationalize why someone should learn C. Maybe the best explanation is to tell someone to read about Godel, Church, and Turing; and that’ll reveal why they should even learn anything about mathematics, logic, language, and computing.
Tip #1: Learn code organization, style, guidelines, and API design. You might think “oh these don’t matter” because you’re just an undergrad and this homework assignment doesn’t mean much, or nobody will ever read your code, or presentation has nothing to do with the “truth” of the program. After a long time, you’ll probably experience that these thoughts are a waste of your time, they usually stem from excuses, and at the end of the day you’re just bullshitting yourself. Autograph your work with excellence and you’ll eventually discover what’s up.
3. Here’s why premature optimization really is the root of all evil.
Actually, I have no clue why Knuth originally claimed this, but I have a damn good motivation for claiming this myself. The reason is that if you’re focused on optimizations (the HOW-TO), you’re not focused on the product / design (the WHAT). Pure optimizations focus on making a system faster, use less resources, etc… said optimizations don’t change what the system does and the goals that the system is suppose to achieve. When you originally design systems, you should be focused on the goals the system achieves. Or else… why design and put effort into the system?
Most of the time it takes experience to define ‘premature.’ Sometimes it’s easy (or just defined by business); ex: marketing says the most important focus is making a product faster instead of introducing new features. Great. Though, these days it seems that everybody wishes that we could be the badass, dick swaggerin’ motha fuckin baller programmers that we wish we were. We turn into speed and resource junkies that prey on chances to swoop in and save the day by ‘optimizing’ inefficient systems.
Just keep in mind, there’s no point in implementing a cache for your database if your code contains a slew of O(n^2), or worse, algorithms. You follow that? Some people don’t.
4. Know the difference between software engineering and computer science.
This is the huge mistake that students make when they choose to study computer science. Computer science != programming. Computer science != software engineering. Programming, software engineering, products, solutions are all practical side-effects of computer science.
Chances are, the reason why you chose to study computer science will have nothing to do with whether you dropped out of computer science or got a PhD in it. For me, the reason why I chose computer science is that I was really into gaming in high school; more specifically, game engines and what I would refer to now as rasterization, computational geometry, etc… After three years of wandering down the CS path I’ve fallen in love with language design and implementation. I grew to appreciate not only “computer science,” but “computer engineering”; I still don’t care about “electrical engineering,” but now have great reasoning for why. I’ve chosen to minor in computer engineering because I need to know about computer hardware (how a CPU is designed, busses, caching, memory hierarchy, ALU design, ISAs, etc…) in order to be good at language implementation. At least this is what I currently believe. In the same respect, I have acquired a greater respect and love for mathematics. So… you don’t have to restrict your passion and ideas to “computer science” or “computer engineering” or “yourfieldhere” because it’s probably dangerous for your mental health.
Also, don’t be surprised when you discover or have to tell people that engineering != computers. I can’t tell you how many Civil, Environmental, Chemical, Astro, Bio, Mechanical engineers I know that are useless when it comes to computers; almost worse than my grandmother.
5. Don’t blow off your non-CS/ECE/EE classes!
Why? Why do you have to do well in classes unrelated to what you’re going to do the rest of your life? Why couldn’t you grow up in India; bred, born, and raised to write code? I’ve made my share of academic mistakes–to the point where it will probably jeopardize acceptance into a good graduate school. You’ll probably have to take some classes that you already covered in high school; easy ‘A’, right? WRONG–at least for people like me. Sure, I knew the material. I have yet to come across extremely challenging material that I can’t wrap my head around, so what’s the excuse for sub-par performance in courses? Lack of interest combined with poor time management? There’s no way to fight the fact that some material is down right boring, can be presented in a slow and obvious manner, but you have to find a way to stay motivated and relate it to what you’re doing. That’s why I wrote Black Hole Quantum Computers and The Rationalism of Agile Software Development.
I still haven’t quite figured this one out, but the more accepting I am of this and the better I get at it, the better I feel. Or maybe it’s just the light of the good old american cliche of being “well rounded” that’s finally shining through. Regardless, do what do you do best. And do it all the time. You’re your own worst enemy.
6. Always be humble.
You’re in a field that is so abstract yet so concrete. So many opportunities to make yourself look like a dumbass. And there’s nothing wrong with that. There is with ignorance, though. So have your suspicions, but that doesn’t make you hot shit… not even close. Neither am I. Neither is your classmate who’s been incubated by Google since he was 11.
I don’t care if you scored a 800 on the math section of the SAT; you probably will never achieve the impact that Godel had. I don’t care if your team won the Cluster Challenge; Intel provided your processors and your advisors made it happen. I don’t care that you graduated with a 4.0 GPA from a prestigious school; you probably hate your job. I don’t care that you created an iPhone application and grossed over $20k; you’re probably not happy.
Also keep in mind most of the best traits of working well in a team (listening, scheduling, observing, providing quality feedback, etc…) stem from the ideology of humbleness. Lastly, on the intuitive flip-side, being humble doesn’t mean being passive. Sometimes, there’s no other option than to grow a pair of balls and speak up!
7. Understand the difference between stereotypes and cultures.
I would like to say that there is a correlation between social deficiencies and those who chose engineering, specifically computer related studies. You know the stereotype: video games, geeks, socially awkward conversations, late nights, stimulants, math, rubik’s cubes, etc… But most young people fail to distinguish the stereotype of nerds, dorks, and geeks and the culture of computing. I think this is one of the biggest factors for why more students aren’t choosing Computer Science, Computer Engineering, Electrical Engineering, Mathematics, etc… But you’ll have to consult a sociologist about this one. The only thing I have left to say about this topic is that it makes me fucking sick.