Things I Wish I Knew as a Comp Sci Student

AlexTatiyants

Rate me:

4.00/5 (2 votes)

11 Mar 2012CPOL3 min read

6.8K

Here are some things I wish I knew as a comp sci student.

I would guess that most CS students don’t know what they need to pay attention to. After all, there are millions of ideas competing for their attention and they all seem equally important. But they’re not.

When I think about my first few years as a professional developer, I often wish I knew certain things sooner than later. I wish that someone told me what was important, what I needed to pay attention to. Granted, I would’ve probably ignored the advice (because that’s what young, dumb know-it-alls do), but still.

Anyway, here are a couple of thoughts I’d like to share with up-and-coming devs.

Be Afraid of Obsolescence

Here’s an over-generalization: Learning technology in a college setting may give you a false sense of permanence.

Technology and change go together like peanut butter and jelly. Back when I graduated college, the technology landscape was a tad different from what it is today. Java was a joke, JavaScript was an even bigger joke, Ruby was only used by a handful of Japanese guys, and the .NET platform did not exist.

And it’s not just the languages or platforms that change. Technology problems change too. Back then, very few were worried about “Big Data” and “Massive Scalability”. “Mobile” meant pager and “Cloud” meant big puffy thing in the sky.

In other words, I had to learn a whole lot of new stuff after graduating and you will too. And if you don’t, you’ll be committing career suicide. Because it just doesn’t matter how cool a technology is today, it won’t last forever (take note Ruby heads).

Write Maintainable Code

Here’s another over-generalization: People in academia don’t have to live with the code they write.

This was certainly true for the majority of my professors. I remember one case in particular. One day in class, a professor wrote a very long and complicated looking for loop on the blackboard. The loop was peculiar because it didn’t have a body. All it had were the counter variable, the iteration condition, and the limit.

After having us stare at it for a while, he gleefully explained that this loop reversed a linked list. That’s right, all of the logic required to traverse and reverse a linked list was cleverly embedded in the loop condition.

Needless to say, this code was as comprehensible as it was debuggable: not at all. Yet our professor wasn’t the least bit bothered by either of those realities. On the contrary, he was proud of his cleverness.

To make things worse, this episode had a pretty negative impact on my coding style, though I didn’t realize it at the time. I kept trying to write “clever” code (no matter how obtuse), because that’s what I thought was important.

When you don’t have to live with the code you write, making it maintainable is not a big concern. On the other hand, as a working engineer, all you do is fix and enhance the same code base. Therefore, maintainability matters a lot more than pretty much everything else: performance, cleverness, etc.