Most importantly, I now have a proven track record of being able to

successfully work as part of an interdisciplinary team, demonstrating

that I am capable of applying specialized training toward solving larger

scientific goals in many disciplines. This quality, I’ve been told, ranks

high in the eyes of many people in hiring committees in both industry

and academia.

What follows are several key lessons drawn from my experience.

These are insights that would have been useful to know before start-

ing to ensure that I focused my efforts in the appropriate places. While

geared toward those working in an interdisciplinary team, many are

applicable to the success of any PhD student.

debug something. When I told them, “It won’t take that long,” they fully

expected that it wouldn’t take that long, which caused me some trouble.

Once a funding agency, colleague, or potential collaborator sees

even the smallest glimpse of a semi-working prototype, the scope and

importance of a project will often explode. Several times I found

myself devoting far more time and effort under far more pressure than

I had originally anticipated. So, be sure that you have enough time to

commit to your existing set of tasks (most importantly graduating!)

before you agree to take on anything new.

Keep Track of Tasks and Time

Like most research assistants, I spent most of my time working my

advisors’ projects. To make these interactions as smooth as possible, I

outlined and documented exactly what tasks I was responsible for,

deadlines for those tasks, and specific deliverables prior to getting

involved in the project. Because my non-CS colleagues were often

blissfully unaware of the underlying implementation complexity of a

project, they often underestimated the work required. Spelling out the

specific technical tasks ahead of time allowed me to extend the finish

line or cut all but the essential tasks from the work scope as well as

have a record of what I was responsible for doing.

In addition, I found it very useful to

keep a log of how much time I was spend-

ing on each task and sub-task such that I

could truthfully report my progress and

explain why I was ahead of, or behind,

schedule. When I did find myself behind

schedule, I learned that it was better to tell

my advisors immediately, as they were able

to re-prioritize and eliminate tasks. Most

importantly, I found that waiting until near

the deadline to have these conversations never worked out well.

Know Your Roles and Responsibilities

As the “computer person” in the eyes of many on my interdisciplinary

team, I’ve had to play hand-holder, “programming wizard,” and

naysayer to people with widely varying understandings of and expo-

sures to CS. When my training allowed me to see potential logical and

computational pitfalls in all aspects of study, design, and implementa-

tion, it was my responsibility to let people know. It then also became

my responsibility to propose creative solutions using what I learned in

my coursework, industry, and research experience.

Being a member of a team means that

you will have to do your fair share of in-

troducing your colleagues to relevant CS

techniques and principles. Although it’s

not your responsibility to provide them an

undergraduate education in the subject,

you must tread carefully, thoughtfully, pa-

tiently, and respectfully. Draw clear lines as

to what you can and cannot be expected to

do or explain.

❝I now know a great deal more
about potential funding sources
and collaborators than I would
have otherwise, having written
grant proposals to institutes
interested in things other
than CS….❞

Stay Focused

I implore you—at all times remember what your number one priority is while in school: completing your coursework and thesis, and getting out of school. This means stop programming right now. I mean it.

Closing down the IDE and opening up the word processing program was one of the hardest parts for me. As engineers, we often pride ourselves on the beauty of the perfect implementation. However, my colleagues from other departments typically had no idea what was under the hood, nor did they care as long as it worked. It took real effort to wean myself away from immediately fixing every minor bug that anyone ever reported or adding that last bell and whistle. In order to achieve goal number one, quick and dirty are the two words to live by.

Be Prepared to Say No

Don’t be afraid to decline a request to get involved in a project. Your advisors and colleagues have succeeded in their careers by effectively managing their schedules. They will completely understand if you explain that you simply don’t have the time to devote to a new project right now. Make sure that your priorities are focused in the right place.

For me, it took a while to get comfortable turning people down. Early on, I would enthusiastically agree to “help out” on every “small job” which “shouldn’t take me that long.” Feature creep nearly always occurred, and I came to realize that non-CS people often do not appreciate the amount of time and effort it takes to design, implement, test, and

Be Aware of the Expectations

I’ve found people in other disciplines often have very different expectations as to the scale and scope of the output at the end of a project. In CS, we often research and write papers showing a proof of concept of some new approach or technique that incrementally advances the state of the art. Many times, this gave me the luxury of working on small datasets without worrying about the exceptional cases. My colleagues from other disciplines, however, were oftentimes expecting production-scale systems to work equally well on tested and untested data at scales I was not anticipating.

Fixing one or two exceptional cases or scaling a system can be challenging. I found that speaking up ahead of time to set acceptable levels of performance prevented uncomfortable situations later on when the timeframe for the project was coming to an end and certain cases or workloads were not being handled perfectly. If and when you are asked if something is possible or how long it will take, don’t promise the world, and don’t hesitate to let your advisors know that something is just not possible given the time available.

Get Involved

My experience has given me the opportunity to learn about many new journal outlets, funding sources, conferences, and academic and professional organizations. Many of these were above my head and not