Unsolicited Random Advice on Having a Successful IT Career

Whenever I am teaching a class with a substantial percentage of graduating seniors, I usually close my last lecture with some advice for my students who are heading into industry to pursue their professional careers. This time, I’ve decided to publish this information as a blog post.

The following advice should be taken with a grain of salt. It just collects some random tidbits of information I’ve accumulated over the years. Nevertheless, this advice is genuine, as I truly wish someone had shared this information with me when I was starting my professional career.

• 0.) Exercise regularly. As your body gets older, it takes an increasing amount of maintenance to keep in shape. Do not neglect physical exercise under any circumstances. Note: Switching from college life to office work, when you’ll be spending 8+ hours sitting in front of a computer, must be balanced with targeted, regular exercise. Buy a decent gym membership before you start work and then set a regular exercise routine.

• 1.) Time moves at a constant rate, but our perception of it does not. Plan accordingly. Humans are horrible at long-term planning, as our perception of time changes continuously as we age. We perceive the length of any given time period (a day, a month, a year, a decade, etc.) proportionally to our age. Therefore, planning based on our past experiences is foolhardy. 
• As a specific example, assume that you are 20 years old and you wish to set some goals to accomplish (e.g., get a graduate degree, get married, buy a house, start a company, etc.) by the time you are 30. You ask yourself: how much time do I have? A common strategy is to look back at how long it took you to get to your current age from the time you were 10 years old, and it seems like an eternity! However, perception-wise, it takes much less time to get from 20 to 30 than from 10 to 20. Furthermore, when it comes to time planning, perception is reality. Therefore, a safe estimate is to half the time when planning based on your past experiences. For example, plan that it’ll take you as long to get from 20 to 30 as it took for you to get from 15 to 20.

• 2.) The best time to take risks is now! If you want to pursue something in life that requires taking risks, do it while you are young. Take risks while you are young and the consequences of failure have a limited ripple effect. If you always wanted to start a company, do it now. The allure of receiving a stable paycheck can become hard to escape.

• 3.) There are people who ask questions, and there are people who answer them. Be the one whom people ask for help, and not the other way around: that’s how you earn respect and gain value as a technical professional. If something does not make sense, try to figure it out first on your own before approaching your co-workers for help.
• Become “the go to” person in your organization, someone who can answer technical questions and make things work. Get a thorough understanding of the system you are developing or maintaining. Don’t be afraid to look “under the hood.”

• 4.) Software is in the service of business; not the other way around. IT is a tool that helps businesses increase their competitive advantage. Therefore, IT professionals with strong domain expertise are invaluable. Extend your expertise beyond the purely technical realm to learn about the domain at hand. Try to understand how your customers use the technology you are creating to benefit their business practices. For example, if you are building financial systems, learn about finance as much as possible. 

• 5.) Do not become too comfortable. If you have become too comfortable, you stopped learning. Stopping learning in a fast-moving industry like IT is suicidal for your career. Once you feel that you are becoming the most knowledgeable, experienced person in your organization, it may be time to move.

• 6.) Your professional reputation is your most valuable asset. The higher you move up the professional career ladder, the bigger is the role of your reputation. Professional references may play an increasingly decisive role in obtaining senior positions. Integrity is key. Make it a habit of doing your best possible work all the time and treating people right.

• 7.) Keep in touch. I’d like to hear from you. I’d like to know if what you have learned in this course turned useful. Have I missed something important? Was I right on?
• In addition, I’m available for advice, recommendation letters, consulting, etc. If you become very rich and successful and find that my teaching had positive influence on you, do not forget to establish a chaired professorship and give it to me!

Attendance Policy Considered Harmful

A recent e-mail exchange between an NYU professor and a student has been making rounds around the Internet. During the first class meeting of the semester, a student walked into a classroom an hour late; the professor would not let the student into the classroom; the student got upset and expressed her frustration via an e-mail to the professor; the professor’s anonymized reply, made public, became an internet sensation. How so? Using very harsh language, the professor explained why the student was wrong and also gave some advice about how the student should behave in the future. What I found most surprising about the reaction to this story is how almost everyone is siding with the professor, complimenting him for having the guts to tell it like it is.

By contrast, I disagree and find the entire incident quite bizarre, as it goes against both of my core teaching principles: (1) treat students as adults, and (2) don’t take yourself too seriously. In line with these principles, I have no attendance policy in my classes. During the first lecture, I usually say something as follows: “I certainly hope that you will find my lectures interesting and worth your time. However, if you have something more important to do with your time than to attend my lectures, please feel free to do so–I won’t get upset and it will not affect your grade in any way.” I have no attendance policy because I respect my students’ right to decide how they want to learn (or not to learn) in my classes. They are free to attend my lectures in full or in part,  or only read the textbook,  or only talk to me in person during my office hours, or engage in any combination of these activities. Besides, there could be things going on in their lives that are more important than attending lectures. For example, they can be preparing for a job interview with the company of their dreams or creating a proof-of-concept for their brilliant startup idea.

However, the issue at hand with the NYU incident seems to be not missing the lecture but rather walking in late.  It does not bother me a bit when students walk into my classroom late. Let’s take an extreme case of a student coming in 10 minutes before the end of the lecture. My thinking will go as follows: “Wow, this student was obviously doing something very important that did not allow him to come to my lecture on time. However, he finds my lecture so interesting and important that he found it worth his while to attend the very last 10 minutes of it. I must be doing something right!” Besides, who knows–perhaps some of the insights I share in the last 10 minutes may prove to be valuable for the latecomer. So in my view, coming in just for the last 10 minutes is better than not coming at all.

But what about distracting other students by walking in late? Gimme a break! We live in a distracted world, in which we need to switch our attention to various matters continuously. In fact, the ability not to let distractions derail your work progress is one of the most valuable skills for a modern professional. I have worked in industry, and I do not remember having a sterile working environment, in which I could focus on the tasks at hand without any distractions. Working in a cubicle, I had to learn to maintain my focus in the presence of extraneous conversations in the neighboring cubicles, colleagues passing by, phone calls, etc. Why should the modern classroom be so drastically different from the modern workplace? Of course, common sense still applies: I do take exception to students talking loudly to each other during the lectures.

Notice how in the absence of an attendance policy, the NYU incident would never have transpired. I understand that it was an MBA class, and the professor may have good reasons to run his classroom the way he does. However, as a computer science professor, I choose not to have an attendance policy that explicitly disallows absences and lateness. I believe that my students are better off as a result.

Curbing the Unnecessary Scholarship (an annual April 1 e-mail)

Dear Colleagues:

The Taulbee Survey Report ranks CS departments based on the amount of their external funding: “The U.S. CS data indicate that the higher the ranking, the more external funding is received by the department (both in total and per capita).”
(Source: http://cra.org/uploads/documents/resources/taulbee/CRA_Taulbee_2009-2010_Results.pdf). And yet, as the recently submitted Faculty Activity Reports (FARs) indicate, some of you are spending only between 60% and 90% of your time on “research activities,” defined as bringing in external funding to the department. If we are truly serious about increasing the rank and prestige of our department, we should be spending a 100% of our time on such research activities. Two obstacles stand in the way of realizing this vision: teaching and scholarship. Fortunately, recent advancements in massive open online courses (MOOCs) have great potential to significantly alleviate the first obstacle if not to remove it altogether. Effective handling of the scholarship obstacle, however, will require some creative problem solving. To that end, a new committee has been established: Curbing the Unnecessary Scholarship or The CUrSe Committee for short. How do we know what scholarship is unnecessary? We will use the following intuitive definition: a scholarship activity is necessary if it prepares preliminary results for a successful funding proposal; it is unnecessary otherwise.

Conference publishing is particularly harmful. Publishing at conferences wastes faculty and graduate student time, while traveling to conferences incurs high administrative overhead, draining staff time and resources (and is bad for the environment). Besides, allocating budget for conference travel makes your funding proposals less competitive. All other factors being equal, which proposal has a better chance of being funded: the one that asks for $5K in domestic and international travel or the one that asks for $500 to travel to DC to discuss your next proposal with an NSF program director? It is simply unjustifiable to be wasting your and your graduate students’ time to go through several rejection cycles to have your papers accepted to conferences with ridiculous acceptance rates (e.g., CHI, ICSE, KDD, IPDPS, SC, etc.). Conference publishing is a dangerous addiction and should be treated accordingly. Therefore, the first recommendation of the CUrSE committee is that we go cold turkey on conference publishing for a period of one year. Then, the committee will assess the expected positive impact of this initiative and may recommend occasional recreational conference publishing on a case-by-case basis.

Journal publishing should be curbed as well. Too much time and effort is spent on preparing journal manuscripts and addressing comments from the reviewers. To address this inefficiency, the CUrSE Committee is tasked with compiling a list of journals that do not impose the unnecessary burden of the review process on the authors. The committee needs to identify those journals that fully embrace the value of inclusiveness and welcome all submissions irrespective of their topic, content, or fit.

The journal writing process itself can be streamlined as well. A couple of years ago, SCIGen, a promising technology emerged from MIT that makes it possible to automatically synthesize scientific manuscripts (Source: http://pdos.csail.mit.edu/scigen/). At the time, SCIGen received some negative press due to its technical imperfections stemming naturally from the breakthrough nature of this technology. Only because an innovative technology does not pan out as intended right away, it does not mean it would not mature over time to become ready for practical application. Therefore, the CUrSe Committee will explore whether it is the right time for us to invest time and efforts in mastering SCIGen.

Once all the unnecessary scholarship is properly curbed, we will be able to dedicate all our time and efforts to increasing the amount of research funding in the department. What about graduate students? One point needs to be made perfectly clear: the value of a graduate degree is positively correlated with the rankings of the department awarding the degree. Therefore, our graduate students should be even more interested in and dedicated to increasing our rankings than we are. To help our graduate students really increase the value of their future degrees, we must immediately stop counting publications as a criteria for graduation. Instead of saying “OK, this student deserves a Ph.D., as he has published N papers,” we should be saying “OK, this student is ready to graduate, as he has contributed preliminary results for N successful funding proposals.” When a graduate student asks you “When can I expect to graduate?”, you should have profound answers prepared; for example: “When your thinking reaches the right depth.” If students ask you what devices will be used to gauge the depth of their thinking, just look thoughtfully off into the distance and utter Yoda-like: “You won’t miss it when you get there.”

Please, let me know by EOB today, if you feel prepared and motivated to join the CUrSe Committee. We need a lot of talent, energy, and passion to eliminate the scourge of unnecessary scholarship, thereby fulfilling our raison d’etre of increasing our department’s rankings!

Back to the USSR by Way of Twitter

“A guy told a joke to his friend. Someone standing nearby overhead the joke. The joke-teller was fired from his job.” If someone asked me to describe the circumstances under which this scenario could have transpired, I would not have to think twice. You see, I was born in the Union of Soviet Socialist Republics (U.S.S.R.) and I have heard plenty of stories like that from my family. It usually went as follows. Someone told a political joke to his friend. A KGB informer was eavesdropping nearby. The informer alerted his KGB handlers, and the joke-teller’s state-owned employer was ordered to let him go. Most likely, this story happened after Stalin and before Gorbachev. If the story happened during Stalin, the joke-teller would be sent to a Siberian GULAG camp for a period of at least 5 years, probably along with the guy to whom he told the joke (for not ratting on the joke-teller to the KGB). If the scenario took place during Gorbachev, nothing would have probably happened, as by then the soviet repression apparatus had started to collapse.

The fact that a scenario with the same cause and effect transpired in the 21^st century America is mind boggling and terrifying. Enter the Adria Richards Twittergate: “At a technology conference, a guy tells a dirty joke to his friend. A fellow attendee overhears the joke, gets offended, and in response, twits the picture of the joke-teller to her followers on Twitter. Scared of the potential of negative publicity, the joke-teller’s employer fires him.” Of course the nuances of these two scenarios are quite different: a political joke vs. a dirty joke, a KGB informer vs. a public person with a large Twitter following, the Soviet repression apparatus vs. the corporate PR machine. However, the cause and effect in both scenarios are terrifyingly identical: tell a joke to a friend => get fired from your job.

I am not going to comment on the appropriateness of telling dirty jokes where they can offend bystanders, on the propriety of twitting surreptitiously taken pictures, or on firing people based on hearsay; others have written about these issues in excess. What I would like to comment on is the terrifying similarity of the two Systems, with respect to sharing the same cause and effect for similar scenarios. It is amazing how a combination of modern social networking tools (i.e., Twitter) and the corporate PR machine has effectively replaced the role of the secret police in a totalitarian society. In fact, not every part of the scenarios was strictly worse in the USSR: the KGB would have certainly investigated the infraction; the joke-teller would be summoned to report to the local KGB headquarters, where he’d be able to tell his part of the story. “I was drunk as a fish and cannot remember anything” could have even served as an acceptable defense for first offense.

We live in a democratic country. That is, even though the USA is a republic, I would like to believe that the system in place is more or less representative of the collective wishes of its electorate. As a society, do we want to live in a country where a person can lose his job because he has told a dirty joke to his friend? Back in the USSR, parents taught their children to never share unapproved political opinions with anyone outside of close family. It is not that political jokes were not plentiful, but they were shared in the company of close friends. Here is one: Brezhnev asks Carter: “Do you collect political jokes about yourself?” Carter: “Of course, I’ve got two notebooks! What about you?” Brezhnev: “Of course, I’ve got two prison camps!” We are not yet imprisoning people for telling offensive jokes, but it is all a matter of nuance. Once a society accepts a given cause and effect as acceptable, it is a slippery slope from there.

Senior Recital for Computer Science Majors?

Last weekend, I attended a senior clarinet recital given by a student at the Department of Music. As a former professional clarinetist, I continue to have a deep and unabated interest in this instrument and in classical music in general, even though I switched careers into computing more than 20 years ago. Having spent my youth practicing clarinet obsessively, I am always intrigued to see how young clarinetists today fare against what I and my colleagues used to be at the same age. I won’t disclose my opinion on this topic, as this is not the point of this blog post at all.

Listening to this recital as a CS professor, I was struck by how authentic this academic exercise was. The recital was not just realistic but real with all the required attributes: a concert hall, an accompanist, a diverse audience, a concert dress, program notes, etc. This recital did not differ in any noticeable way from the recitals of famed instrumentalists I’ve attended in places such as the Weill Recital Hall in NYC.

The student giving the recital had to deal with all the stress and unpredictability of playing a solo recital in front of a live audience. Some of this required dealing with purely technical issues, such as not forgetting to tune the instrument after a couple of pieces. (Wind instruments tend to get sharp after they are played for a while, so on a clarinet a barrel has to be pulled out to stay in tune with the piano.) Other factors were less predictable. For example, some members of the audience suddenly started clapping after each part of a three part concerto rather than waiting until the piece’s end, even though this goes against the concert etiquette. These kinds of unexpected interruptions cannot derail the performance. The recitalist had to handle all these issues completely independently without any help from anyone. The student’s clarinet instructor was in the audience, but only as a passive listener. Overall, I find senior recitals an excellent avenue for music students to demonstrate their proficiency in their chosen field of study.

This experience got me thinking that in the CS curriculum we never quite expose our students to a situation when they have to perform independently to show the level of mastery of their discipline they have achieved in their studies. This is true that our students get summer internships when they apply their CS knowledge and skills in real world environments, but for that they have to leave campus. Besides, internships are not required to get a degree in CS. Even in our capstone classes, in which it is recommended that students accomplish a project for an external client, professors are always present ready to step in to help students deal with any issues that may arise.

I am curious how we can create an experience for CS majors similar to the senior recital. For example, this would require a capstone project in which faculty take a seriously hands off approach, so that student teams take full responsibility for the project, and an external client’s level of satisfaction serves as the only criteria for success. The most ironic part is that nowadays the probability of a music major becoming a solo concert musician (musicians who give solo recitals as their primary occupation) is minuscule. There is probably only half a dozen of solo clarinetists in the world. While the majority of CS majors go into productive careers in IT. Perhaps we do just fine without any senior recitals.

On doing a Ph.D. revisited

My recent post has generated quite a lot of traffic to my blog and a good number of comments, expressed both publicly and privately. In that post, I expressed my take that if the purpose of Ph.D. training is to prepare individuals for unforgiving careers in research, the strategy of breaking down Ph.D. trainees and building them back up stronger, more determined and thick skinned seems like a reasonable one. The purpose of this follow-up blog is to reply to some of the common themes I have seen in the comments.

• Research is fun, so your argument is baseless. At first, I was wondering if I should even merit such a facetious comment with an answer. However, since this issue keeps coming up, I may as well address it. I agree with Einstein, who said that ”Science is a wonderful thing if one does not have to earn one’s living at it.” I do not find the word “fun” appropriate for describing the essence of a professional research career. However, I agree with Philip Guo in that research is fulfilling, despite all the frustrations of dealing with the research enterprise.
• Isn’t the research enterprise itself due for a major revamping? As an admirer of the Hegelian philosophy, I subscribe to its central notion that only a crisis can precipitate a major change. What would a crisis in academic research in Computer Science look like? It would take nothing short of CS faculty leaving academia in droves for jobs in industry. It is just not happening. The few occasions when it does happen (see references 1 and 2) receive that much attention only because they are so exceptional.
• I am in denial about the need to improve the specific problems with the current Ph.D. production system (e.g., low pay, lack of structure, advisor advisee relationship, poor graduation rates). All of these issues are real, but they won’t change unless precipitated by a crisis. U.S. grad schools keep receiving hundreds and hundreds of Ph.D. applications, most of them from oversees. Faculty searches for the Assistant Professor positions receive hundreds of applications from newly minted Ph.D.s, a good portion of whom are well-qualified for the advertised positions. Let’s look at the specific problems mentioned, one at a time.
  • Wouldn’t it be nice to pay graduate students better? Of course, but the issues of compensations are determined by the market (i.e., supply and demand). Until there are enough applicants willing to compete for the meager Ph.D. stipends, the compensation will not increase. There are some positives here as well. From my personal experience, six and half years of making a typical Ph.D. student wage, which amounted to about the minimum wage when divided by the number of hours put in,  has instilled in me the virtue of frugality probably for the rest of my life.
  • Shouldn’t Ph.D. training be more structured? I am afraid it is impossible when you need to produce a substantial body of new knowledge for a dissertation by engaging in research. There are no well-structured milestones students can set for themselves and meet with any degree of predictability.
  • Don’t Ph.D. advisors have too much power over their advisees? You can always switch advisors if things don’t work out. Choose carefully, but remember that your relationship is not that of indentured servitude.
  • Isn’t it a shame that every other person never finishes their Ph.D. studies? It is probably not a good use of scarce research funding, but when one engages in a long process with hard-to-foresee outcomes, this dropout rate is almost inevitable.
• The Ph.D. training process should encourage more communal support, primarily from fellow students. No argument here. However, it does not contradict anything I have said about not changing the way Ph.D. training is conducted. Even if the process remains long and rigorous, Ph.D. students should get as much support as they can from whatever resources available to them. In that light, universities should encourage informal groups whose aim is to support Ph.D. students in their difficult journeys.
• Well, is there anything you would change in the way Ph.D. training is currently conducted?! In fact, I have done something to that end in my own department. In the last couple of years, I have taught a course that introduces graduate students to research in CS. Because knowledge is power, I strongly believe in informing Ph.D. students about what will be expected from them early on. In one of the first assignments in my class, I ask students to learn about their advisors’ expectations for them. In other words, students get a clear statement from their advisors as to what they will be expected to accomplish (e.g., external publications, research artifacts built and evaluated, etc.) to be granted their degree. Thus far, I received very positive feedback both from my students and their advisors regarding this and other aspects of my course.

More on Maintenance

I keep finding more parallels between software maintenance and academic maintenance. Back in my days as a software developer, I vividly remember that the more senior and experienced developers were, the more their jobs were concerned with maintenance. In fact, the head of our programming team was devoting almost all of his time to fixing bugs. He was the most senior developer, who was most intimately familiar with our main product. He always had the largest number of bug reports in his work queue. These were pretty nasty bugs–showstoppers–which stood on the way of shipping the product to the customer. Despite performing an utterly important service for the company (i.e., keeping the product afloat), I remember my team lead being one of the most bitter people I’ve ever encountered. Fixing mostly other people’s mess must not be that fulfilling, even though the activity is vital for the very survival of the product and company. Not wanting to be eventually put in a position like that was one of the primary reasons why I decided to go back to school to get my Ph.D. and seek a career in research rather than in industry.

I am noticing that a faculty’s seniority level is almost directly proportional to the amount of academic maintenance they perform. The amount of service I perform has increased significantly since I got tenure. The faculty with administrative responsibilities mostly focus on academic maintenance rather than research. Department head is the ultimate example of a faculty focusing solely on maintaining the research enterprise of the department. I wonder, however, if focusing on academic maintenance too much can make faculty bitter, similarly to how it tends to work in software development. Too much non-research commitments is indeed stated as a key reason by those who have left academia.

It seems that maintenance, while essential, makes people engaged in it unhappy. There are notable exceptions, however. One of my former bosses claimed that he enjoyed fixing bugs more than he did writing original code. I am sure there are faculty who find departmental service as fulfilling as their research activities. Perhaps some of the techniques used to facilitate software maintenance can be applied to academic maintenance. Appropriate architecture, thoughtful design, solid implementation–all are known to streamline the maintenance process. A well-structured academic department with well-engineered work processes indeed reduces and simplifies the maintenance of the research enterprise as well. I wonder what other software maintenance state of the art can be applied here.