• We know how to write a History essay or an English research paper, but don’t have any clue when it comes to writing a functional specification document or a technical design document.
• We can accurately measure the run time complexity of an algorithm but cannot reliably say how long we will need to write a piece of code.
• We can make sense of an assembly dump, but cannot parse a piece of code written by someone else and proceed to rewrite it.
• We learn how how to code the hard way with Vim and Emacs, but never bother to learn to use all the features of Eclipse.
• We can do miracles while coding alone, but have no clue how to commit, checkout, branch, tag, and merge using a revision control software for a team project.
• We excel at writing thousands of lines of code, but have difficulty compiling, linking, and creating executables.
• We enjoy the challenge of a good debugging session, but hate to write unit tests and regression tests.

As I slowly approach to the end of my second year of work at GE, I can sense how much I have changed as a programmer since I left CMU. In this article I want to put down my “lessons learnt” on paper. Chances are that in a few years I won’t even remember what it felt like to go to college. So before I forget I want to pass on the experience that no text book could ever teach me. Rather than a write a wordy reflective essay, I will just list some of the common pitfalls that you should avoid as a newly hired programmer.

Resist the urge to rewrite code

This is probably the hardest one. So it deserves some special attention. You will come across a lot of crappy code in your work life. There’s seldom any documentation. So your only option will be to read through code. And the more you read, the more you will feel the code has no structure, things are not done in a proper way, there’s a lot of repetition etc.. Well guess what? It might be crappy code, but it’s well tested crappy code. A lot of the obscure code-blocks are undocumented patches to bugs people found after months of testing. If you are new to the company, you will have absolutely no clue about all the bizarre edge cases of a program. Chances are when you rewrite a piece of code, you will produce a clean but buggy application. If you are unsure whether to rewrite or not, ask yourself these questions:

1. Will cleaning up the code reduce development time in the future?
2. Will it make testing easier?
3. Will it make deployment less time consuming?
4. Does #1, #2, #3 take more time the time it will take you to rewrite the code?

If the answer to all four of these questions are “yes”, try to see if your coworkers think the same too.

Not being satisfied by anything other than your work

This is also a hard one. If you are a hard-working and productive programmer, you will get a lot of responsibility on your shoulder. There’s nothing wrong with that. But don’t go overboard. Typically there will be others in your company who can also code. You may not think that they are as skillful as you. But practically speaking, given enough time they can also get the job done. So don’t lose your sleep trying to be a one man army. Be a team player. Learn to delegate. Document your code, so that others can fill in when you go on a well deserved vacation.

Get over the need for speed

Yes, changing that data structure to a tree will make lookups O(logn). But it will only reduce runtime from 10 minutes to 9.5. It’s usually very hard to give a find out the big O complexity of real life programs. So don’t jump at the first chance you get to apply your algorithm skills. Profile your code thoroughly. Get an understanding of what the real bottlenecks are and whether they are under your control. And even then, you should only optimize if your users are complaining about it.

Reluctance to test your code

Admit it. We all hate testing. We hated in college. We got mad at professors who graded your test cases. And we still hate it at work. The only difference is, now the code may affect the lives of hundreds or even thousands of people. So get over it. If you feel testing is a waste of time. Write test scripts. Write modular code. Write unit tests as you code. Get your co-workers to test your code. The more testing you pile up till the end, the more repulsive it will get. And then procrastination will take over and you will end up shipping buggy code.

Those were the main pitfalls I could think of. Maybe someday I will write a part 2 for this post with all the small tips and tricks I picked up over the years. Anyhow, if you manage to start your career avoiding these pitfalls, you should have a bright future ahead.

Freshmen often ask me what CS courses do we take in CMU. Sophomores and Juniors want to know which CS electives would help them in their senior thesis. Seniors want to know which courses are useful to get a job. To answer everybody’s questions I have a prepared a list of CS courses I have taken in CMU, a short description of each, and a rating indicating it’s real life value. Note that some of these courses may not be offered any more and the content of some might have changed.

Introduction to Programming (10/10)

Taught me object-oriented programming. Taught me Java, the language I use at work the most.

Intermediate Programming (10/10)

More Java, and lots and lots of data-structures: Trees, Hashes, Linked Lists. Once you get a grasp of programming this course will give you a toolbox to solve real world problems.

Concepts of Mathematics (4/10)

This course gives you a gentle introduction to the world of discrete mathematics and proofs. For some, this is the first real challenging course in CS. It’s not at all useful in real life, however, it does prepare you for upcoming disasters in discrete maths.

Data Structures & Algorithms (7/10)

Even more Java. At this point, it starts to get repetitive. Her you learn about exotic data structures which you will most likely never use in real life. The only reason this course gets a 6 is because of the various graph algorithms you will prove to be a useful addition to your toolbox.

Great Theoretical Ideas of Computer Science (10/10)

Rating this course is tricky. It doesn’t teach you something that you can directly use in real life. But GTI helps build character. It separates the curious CS enthusiast from the ones who are worthy of a CS degree. This course helps you build the stamina to solve difficult mathematical problems and write formal proofs to justify your solution.

Programming in C in Unix (10/10)

I am one of the lucky few who doesn’t work in a Microsoft dominated company. Our entire software architecture is Unix-based. Whatever Perl and shell scripting I learned in this class, I use it every day. On the other hand, programming in C made me a better man and prepared me to face Fortran which I often face at work.

Fundamental Principles of Programming (5/10)

Better known to CS students as “ML”, this course attempts to bend your mind by teaching you functional programming. It’s really fun, if you get it, otherwise you’ll feel that ML is just a twisted language. Not much real world application today. However, functional languages are coming back in fashion. So doesn’t hurt to have a taste of it in college.

Web Application Development (7/10)

This is one of those light-weight courses that doesn’t add to your workload, but gives you a lot to learn. You are introduced to the wonderful world of Ruby on Rails, the bread and butter of IS students. Regardless of whether you like developing web apps or not, writing code in Ruby will be a breeze of fresh air after Java, C and ML.

Introduction to Computer Systems (9/10)

This is the first serious CS course in CMU where you really get your hands dirty. You get down to the assembly level and learn the basics of compilers, computer architecture and memory management. For sure, you won’t need much of this directly in real life. But the realization that “there is no magic inside the box” will help you understand performance bottlenecks of even the most complex systems.

Algorithm Design & Analysis (6/10)

This is the grand-daddy of all discrete math courses. While it’s not as mind-bending as its pre-requisite GTI, it’s still teaches you some useful stuff. Understanding how to determine the time and memory complexity of algorithms will help you design better applications. In a company where a lot of applications build on your work, demonstrating a sound knowledge of algorithm design will raise a lot of eyebrows

Algebraic Structures (0/10)

Really abstract mathematics. Simply pointless.

Formal Languages & Automata (3/10)

This is a course I really enjoyed, even though there is a lot of talk about abstract computational devices. Here you get to learn about regular languages, context free grammars, Turing machines etc. Nothing terribly practical, but very insightful nonetheless.

Foundation of Programming Languages (0/10)

More ML, but this time with a focus on formal analysis of programming languages. You get to write your own toy programming language every week. Sounds fun but terribly dry and useless.

Technical Communication for Computer Scientists (0/10)

This course has the potential to be a useful course. There is a variety of technical documents that a CS professional need to author on a regular basis, (e.g. Technical Design Document, Functional Specifications, Technical Requirements Document, Programmer’s Guide etc.) This course teaches none of them. I will write more about this point in a future article. CMU really needs to improve the content and instructors of this course.

Software Engineering (2/10)

Another course that had the potential to be very useful. But I guess there is no way to make students without industry experience appreciate the impact of good architecture and design. If I could go back to CMU and take any course, it would be this one. Any how, software engineering skills is what helps you climb up the corporate ladder and takes you from a code monkey to a software architect.

Computer Networks (8/10)

Another heavy duty programming course in C. A lot of new material. You learn networking from its dirty low levels of sending individual bits, error correction, collision detection & avoidance, routing, queuing, Ipv4, Ipv6, TCP/IP, and even some application level network protocols. The programming assignments are pretty demanding. You get to read the technical specification of the IRC protocol and build your own IRC server. You even get to write your bit-torrent client in the last assignment. The networking stuff isn’t that useful to me as a programmer. However, as a distributed systems programmer, the code from the assignments are a useful reference for me.