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