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.

Ttechnology 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.

You may also like:

Did you love / hate / were unmoved by this post?
Then show your support / disgust / indifference by following me on Twitter!

This post got 5 comments so far. Care to add yours?

  1. Erik says:

    Great point about maintainable vs clever code in college. Both during undergrad and graduate school, I definitely encountered this phenomenon, and I think it is one of the biggest originators of the sentiment “you’re only a true programming genius if nobody can understand your code without careful study.”

    I personally would add “fail early/quick feedback” to the list of things I wish I knew as a student. I recall long nights of coding where I would work for hours without compiling, let alone testing. I would then work for a bunch more hours figuring out how to (1) get it to compile and (2) get it to work.

  2. Mark says:

    Every once in a while I wonder what I would teach if became a professor. One of my ideas is to create a large fairly crufty app and spend the semester giving the class assignments to add features, refactor, and add test coverage to someone else’s mess. Perhaps the course would be called “a day in the life”….

    • Alex Tatiyants says:

      Hi Mark, thank you very much for reading the post. I love the idea, could be very educational especially if new features are something like “now add support for mobile devices”. Another interesting angle might be to add significant non-functional requirements like “now support 10000x more users”.