Last weekend, I played my first professional gig as a clarinetist after a 15-year long hiatus. The gig was professional because someone actually paid me to play the clarinet. Having made my living as a freelance musician in NYC for almost a decade, I was quite surprised about how refreshing it felt once again to be in demand as a musician, when others hire your exclusively for your clarinet playing skills.
This experience got me thinking about the issues of jobs and compensation. In the 15-years that passed since I left NYC to get a Ph.D. in Computer Science, I made a living working at a whole variety of jobs. I held a full-time Software Development position at a large company, survived on meager Graduate Assistant wages in graduate school, provided expert consulting services in a lawsuit, etc. Finally, now my main job is as a faculty member at a major research university. All these jobs ranged widely in terms of their expectations and compensation. As a university professor, my job is so multifaceted that I often find it hard to figure out how my salary compensates me for the whole slew of activities I engage in during a typical workday: teaching, mentoring, writing, outreach, reviewing…
Hence, there was something very refreshing to be hired specifically to play the clarinet. Upon earning tenure a couple of years ago, I started practicing the clarinet again on a regular basis. My professional music degrees and a huge prior investment in mastering my instrument enabled me to get back in shape rather expeditiously. As a result, I was able to participate in several performances with musicians of various levels of professional preparation. And yet, it was only now that I got to play a professional gig. Even though my engagement comprised of a short piece played with a choir, it was very satisfying to execute it without a hitch despite having had only one rehearsal.
The ability to play a musical instrument professionally comes from a rigorous preparation routine, decades of studying with brilliant teachers, regularly confining yourself to the isolation of practice rooms, auditioning, concertizing, analyzing, improving, etc. I surmise that this is the reason why I have found playing a professional music gig again so fulfilling. Making music at the level when people are willing to pay you for that validates the enormous investment of time and passion required to master your instrument. I welcome this validation very much and keep looking forward to other professional playing opportunities!
The mobile computing landscape is characterized by extreme heterogeneity. According to Facebook, the mobile version of their application is accessed from more than 2,500 varieties of mobile devices. Modern smartphones and tablets differ in terms of their respective hardware setups (e.g., screens, sensors, processors, memories, batteries, etc.), platforms (e.g., Android, iOS), versions, etc. Furthermore, mobile devices access the Web via mobile networks with dissimilar characteristics such as latency, bandwidth, and packet loss rates (e.g., 3G, 4G, Wi-Fi, etc.). It is the confluence of these differences that causes the heterogeneity challenge in mobile computing.
Addressing the heterogeneity challenge entails engineering mobile applications that can be used seamlessly on any device. As is commonly the case, addressing a challenge of this magnitude requires satisfying several constraints, only a subset of which can be satisfied at the same time. Specifically, the engineering process is subject to the following constraints: (1) maximize utility: provide the required functionality in as user-friendly fashion as possible; this is commonly achieved by supporting a native look-and-feel on every platform and properly leveraging a given device’s hardware capacities (e.g., screen resolution, touch interface, sensors, etc.); (2) minimize energy consumption: as the energy demands of mobile applications continue to outstrip the battery capacities of modern devices, mobile applications should be engineered with energy efficiency in mind; (3) minimize software development and maintenance costs: software development is costly and software maintenance is even more so.
The software maintenance and evolution constraint is particularly hard to satisfy in mobile computing. Mobile applications designed yesterday will have to run on mobile devices to be designed tomorrow. Mobile devices are evolving rapidly, with each new device featuring new hardware capabilities. Mobile software must keep up with the device evolution to provide quality user experience while keeping the energy consumption in check. Perfective maintenance, which codifies a set of activities aimed at optimizing applications for different objectives, is particularly hard hit by the heterogeneity challenge.
When planning their next mobile application, enterprises have no choice but to carefully select which two of the three constraints (utility, energy efficiency, development costs) they want to satisfy and plan their software development processes accordingly.
Computer Science is an odd discipline in many respects. I find quite puzzling the relationship between the perceived value of technical experience and age. I have observed this relationship as shown in the following graph.
At certain career points, a computing professional is likely to find his or her experience grossly overestimated or underestimated.
1.) When starting college (age 18), the perceived value of experience is vastly overestimated.
A common misperception is that incoming freshmen must have been introduced to computing (coding in particular) to successfully major in Computer Science. Somehow having reached the ripe age of 18 is considered as too old to start learning the discipline from scratch. Having never studied computing as part of their K-12 curriculum is commonly deemed to put students at a severe disadvantage, if not preclude them from succeeding in the CS major altogether.
2.) When graduating college (age 21-22), the perceived value of experience is mildly underestimated. In essence, if you have a degree in CS and can solve programming puzzles, which commonly have little to do with your future day-to-day job responsibilities, companies are eager to hire you. Having had industry internships, which provide invaluable practical experience, is a positive but not decisive factor in getting the first position after college.
3.) For young professionals (age 22-30-35), the perceived value of their experience is similar to how professional experience is perceived in other areas. Until 30, the perceived value of experience grows more steeply, and it continues to grow until the professional reaches his or her mid-thirties.
4.) From age 35 on, the perceived value of technical experience starts to plummet precipitously. IT is commonly considered an up or out field—either you switch into management or you leave the field altogether.
5.) In middle age (45+), the perceived value of technical experience reaches the negative territory. One’s experience is held against them. Software development is unabashedly rife with age discrimination. “This is a young man’s game.” “Technology is evolving so rapidly with new languages and tools introduced every year. For older IT professionals, it is just too hard to learn these new technologies. Their minds were molded by different technical realities.”
Because these experience perception patterns reflect industry-wide trends, computing educators have a limited but vitally important role in properly preparing students for successful long-term careers in computing. To that end, I propose three concrete action items.
1.) Actively dispel the myth that to successfully study CS in college, a student must have some prior coding experience.
The vast overestimation of the value of having some computing experience before starting to study CS in college is particularly harmful. While a student may benefit from being introduced to computing earlier on, the freshman year in college is definitely not too late to start learning the discipline. Having participated in multiple orientation sessions for incoming freshmen, I continue to be taken aback when approached with a question: “I find computers very interesting, but I do not know how to code. Do you think it would still be possible for me to major in CS?” I usually reply that the student has been fortunate to have the opportunity to learn the foundations of the discipline properly, without having to unlearn any bad habits.
To bring the point home, I usually draw parallels to other disciplines to highlight the ridiculousness of so grossly overestimating the value of prior exposure to coding. How do the following questions sound to you? “I am fascinated by Architecture. However, having never participated in construction projects in high school, I am not sure whether it would be possible for me to major in Architecture.” “I am excited about Airspace Engineering, but having not built any flying machines in high school, can I still major in this discipline?” If this does not help, I then talk about my own journey into computing, which I started at 24 without any prior exposure to computing even as an end user.
2.) Encourage students to take internships.
Industrial internships are an essential component of computing education. It is well-known that internships provide an excellent avenue for students to complement the theoretical knowledge acquired in the classroom with practical technologies and tools. Another important advantage of industry internships is exposing students to the day-to-day realities of the IT workspace. Usually students love these realities, coming back to school reinvigorated and happy with their career choice. Nevertheless, other students often realize that working in IT is not for them. Some of them decide to go to grad school and pursue a research career thereafter, while others may decide to switch majors altogether. Getting this real world exposure early on is invaluable.
3.) Convey the importance of properly developing non-technical (soft) skills.
To smoothly move into management when they hit mid-age, students must have well-developed non-technical skills. Whenever giving career advice to CS students, I always stress the importance of developing strong communication skills, both oral and written. In addition, I often encourage students to take non-CS classes as a means of broadening their intellectual horizons and expanding their toolset of practical skills. A business minor may be a wise investment for CS students who see moving into management at a later point of their careers.
“What classes do you recommend I should take next semester?” I have been asked this question too many times, usually by graduate students who are just starting their studies. Because my take on this issue is a bit unusual, I have decided to express my thoughts on this matter as a blog post.
Taking a graduate class is first an opportunity to learn about the professor’s research and second to learn about the actual subject matter. When it comes to graduate classes, with some minor exceptions, professors teach those classes they want to teach. This situation is in contrast with teaching undergraduate classes—some undergraduate classes need to be covered, and faculty are often assigned to teach them out of necessity. In a research university, professors are researchers who occasionally teach, and research is what occupies most of their time and efforts. When teaching a graduate course, professors will always try to use it as an avenue for introducing their research to the students. If you are not interested in the professor’s research, do not take his class.
When shopping around for graduate classes, one should pay more attention to the instructor’s recent publications and research grants than to the actual course curriculum. This advice is motivated by the following observations. Few graduate courses have a required textbook, so the majority of reading assignments usually come from research papers. Course instructors decide what these papers should be, and their research interests heavily bias the selection of reading assignments. Course projects in graduate classes are also commonly open ended, and used as an opportunity for professors to try out new research ideas. Oftentimes, even the course’s title may not accurately express its content. For example, an HPC researcher teaching a graduate networking course is likely to focus on the networking topics relevant to HPC. A student not interested in HPC may feel disappointed.
Overall, taking a graduate course is a great opportunity to try out the instructor as a potential thesis or dissertation advisor or a committee member. By taking a graduate class, one learns not just about the instructor’s research interests but also about her research style and personality. What kind of open-ended questions does the instructor pose to students? What kind of feedback does she provide? How much attention does she pay to the quality of written or oral presentations? All these questions can guide the decisions of whether it may be worth your while to get involved in the instructor’s research or invite them to serve on your committee.
There are some exceptions of course. Some professors may not be active in research, while others may decide to follow a state-of-the-practice curriculum. The easiest way to identify such courses is to see if there is a required textbook. No research focused graduate class will have a required textbook. A graduate class may have a bunch of recommended textbooks to consult for the background information, but most of the reading will come from research papers. Finally, if not sure, just ask the professor how they plan to teach the class.
Finally, what about the prerequisites? You really like the instructor’s research, but you feel you have not had sufficient background in that area. In most classes, this limitation should not be an issue. If you genuinely like a research area, you should be able to get up to speed fairly quickly. Besides, quoting Einstein “Imagination is more important than knowledge,” particularly when talking about research related issues. If the majority of your grade comes from a term research project, your ingenuity in coming up with new ideas will be more important than almost any background knowledge you may lack. Grades matter little in graduate school anyway. Always remember that in graduate school, “A” means average; “B” mean bad; and “C” means catastrophic.
It is with great sadness that I have learned about the untimely passing of Mary Jean Harrold last Thursday. Remaining true to herself—never disclosing the difficulties she always overcame so stoically—Mary Jean kept her illness private, with only a limited circle of people being even aware of her condition. Consequently, the news of her passing came to me as a complete shock. As a member of my Ph.D. committee and academic colleague, Mary Jean had a hugely positive influence on me as a researcher and person. To convey what a truly remarkable individual she was, I would like to offer the following series of vignettes of my interactions with Mary Jean.
My first encounter with Mary Jean occurred during my first semester in the Ph.D. program at Georgia Tech. She just joined the university and was moving her lab there. I came to grad school having been frustrated with the practices of industrial software development that I had witnessed at my job. However, I could not find an advisor who shared my research interests. After listening to her presentation to the first year graduate students, I was impressed not only with her enthusiasm for her research, but also with the unabashed pride she displayed for the accomplishments of her grad students. I knew right away that I wanted to join her research group.
Being supervised by Mary Jean was an amazing experience. She held two hour-long meetings a week with each of her advisees. With that kind of unprecedented support, I quickly got up to speed in my project, which was sponsored by Boeing and involved building a static analyzer for avionics code written in Ada. By the end of the semester, I acquired a deep appreciation for program analysis and testing. At the same time, I managed to realize that my research interests lied more in building systems than in analyzing them. However, due to the excellent guidance I received from Mary Jean, I delivered on all of the project’s goals, and later a research engineer was able to pick up where I left off, so that all the research goals set off by the sponsor were met. Based on my own experiences as a faculty, I can say that this was a remarkable win-win outcome: I actively learned about a new-for-me research area, and the industrial sponsor got their deliverable. Under any other advisor, the results of working on a project only for a semester would have to be completely written off. When I informed Mary Jean that I wanted to focus on distributed systems for my Ph.D. work, she was very supportive and we retained a cordial professional relationship for the rest of my studies and beyond.
For most of my Ph.D., I was working across the hall from Mary Jean’s lab. She felt that it was highly important to have dedicated space for a lab, so that graduate students could form a community fostering a sense of collaboration and camaraderie. It had not been a day when I would not stop by her lab to talk to her students, forming lasting friendships with several of them. Mary Jean’s office was close by and she’d often stop by the lab to talk to her students.
Once, collaborating with another student, I was trying to meet a tight deadline and ended up pulling an all-nighter. As a smoker, my collaborator needed to step outside for a cigarette about every other hour. I would come outside with him, so that we could continue our research discussion. I clearly remember seeing Mary Jean leave the building late in the evening around 10:30 or 11pm. Then, we saw her coming back to work around 5am. “I find you guys in the same place where I left you yesterday—have you been standing here all night?”–Mary Jean greeted us in the morning. For us, pulling in an all-nighter was an uncommon occurrence; as soon as we reached our goals, we went home and crashed for the rest of the day. For Mary Jean, leaving the office late at night and starting her work day at 5am was her regular work style, something that she did day in and day out.
When I applied for faculty positions, I naturally asked Mary Jean to serve as a reference for my applications and to write me a recommendation letter. I clearly remember how in early December, I sent out my faculty job applications and e-mailed all my recommendation letter writers where they should submit their recommendations. I left the office around midnight and headed home. When I woke up the next morning, I saw an e-mail from one of the universities, informing me that Mary Jean Harrold submitted a recommendation letter on my behalf at 6:15am. Later I asked Mary Jean how she could have written and submitted a recommendation letter so fast. She told me: “Look, this recommendation letter will be very important for your career and procrastination on my part can hurt you. As soon as I got to work at 5am, I saw your e-mail. So I just wrote the letter and sent it out.” This incident left a profound impression on me—this incredible display of professionalism and compassion. Influenced by this experience, I always give the recommendation letters I have to write the highest priority.
When I accepted a faculty position at Virginia Tech, Mary Jean invited me to celebrate this accomplishment with her research group. She was sincerely happy for my success, and treated me as if I were her own student. We went out to lunch to a fairly remote restaurant driving in two separate cars, with Mary Jean driving one of them. During the lunch, we argued about what was the shortest route to get back to the Georgia Tech campus. It was decided that on the way back we would compete on who would get back first. However, in the spirit of a true research experiment we committed to not breaking any traffic laws. Sitting in the car driven by Mary Jean was quite an experience, as she took this competition with the utmost seriousness and was really eager to win. To her disappointment, both cars got back to campus approximately at the same time.
The last time I saw Mary Jean in person was during a very difficult period in my life. I just went through my mid-tenure review, and the results were mixed. I had strong publications and teaching records, but my lack of success in obtaining federal research funding could seriously compromise my chances of getting tenure. I was seriously considering quitting my faculty job and going back to work in industry. Back in Atlanta for a meeting with an industrial collaborator, I asked Mary Jean for an appointment. I needed her advice. Mary Jean gladly agreed to meet with me. I felt very dispirited and confused, and I was very honest with her. “I wrote seven NSF proposals in a row, and all of them got rejected. I am not sure if I can make it.” What Mary Jean asked me next was striking in its wisdom: “It makes no difference whether you think you can make it or not. Is making it what you would like?” Would I have liked to succeed as an academic researcher? Of course! Going back to making a living by writing computer code would have felt like a huge defeat. This simple question helped me to completely refocus my thinking and ultimately persevere in my quest for academic success.
My last e-mail exchange with Mary Jean occurred when I was just promoted to the rank of Associate Professor with tenure. Upon receiving a congratulatory e-mail from Mary Jean, I replied by thanking her and also expressing frustration at how difficult my tenure track experience had been: “It was quite a rocky journey–I feel fortunate that things have worked out in the end.” Mary Jean was ever so gracious in her reply: “It may have been rocky at first but you figured it out!”
I wish I had a chance to thank Mary Jean in person for all the great influence she has had on me. She has made a lasting impact on her research community and on all the people who were fortunate to have had a chance to interact with her. I hope that these personal vignettes I have shared will help others understand what a remarkable individual she was and help preserve her memory.
As the new school year is starting up, fresh faculty members just embarking on their tenure track careers are being inundated with sagely advice from their senior colleagues. The reason I have decided to contribute to this already excessive body of recommendations, implorations, admonitions, etc. is the last month’s guest blog entry of Scientific American, whose core idea is to treat your tenure track appointment as a 7-year guaranteed job and not to worry about the future outcome of your tenure case. Since almost no real-world job provides comparable job security, tenure-track faculty have the unique opportunity to focus on achieving happiness, which for the author entails maintaining the right work-life balance. What I found surprising is that many of my tenured colleagues exasperatedly stated that they wished they had read this piece of advice before starting their tenure track appointment. Although I have enjoyed reading this blog entry, encountering it seven years ago, when I was just starting my journey toward tenure, would not have made any difference in my tenure-track experience, which was soul-crushingly hard and stressful, but ultimately successful.
First, let us have a look at why being on the tenure track is so stressful. It is definitely not because people are terrified of not getting tenure (i.e., getting fired) and not being able to find alternate respectable employment. Undoubtedly, in Computer Science, a 40-year old (give or take), Ph.D.-level, jaded ex-academic would have many fewer career options than a starry eyed, fresh holder of an undergraduate degree. As an area rife with age discrimination, we have a continuous shortage of 20-something IT professionals, ready to single-mindedly devote their lives to their jobs. Nevertheless, career options are plentiful even for middle-aged Ph.D.-level computer scientists, and these options are typically much more remunerative than even a typical tenured faculty position.
In my estimation, the causes of stress come from two main realities. First, graduate school is an amazingly poor preparation for a faculty job. Second, academic research is a highly communal enterprise, and the success or failure of a particular member of that community affects either directly or indirectly a number of other members.
Even though professors are routinely accused of creating their own clones when training graduate students, nothing can be further from the truth. Graduate students are trained to exclusively focus on their dissertation research with everything else treated as a distraction. A fresh out of grad school Assistant Professor may have never juggled more than one research project, presented a technical topic without the benefit of a thorough preparation, acted in a supervisory position, or contributed to a funding proposal. The structure of graduate training almost deliberately neglects the development of the ability to multitask and context switch effectively.
Here is an example of a conversation a faculty may have with a senior graduate student. “Would you have 30 minutes to meet with a distinguished researcher visiting the department next Friday?” “Oh, no, I wish I could discuss my research with her, but have a paper submission deadline on Friday.” Typically, the faculty replies as: “I see—good luck with the paper.” A more appropriate (and beneficial to the graduate student) reply would be: “So freaking what?! Taking 30 minutes away from working on the paper would make any difference?! I also have a paper deadline on that day, and a committee meeting, and a class to teach, and a Skype call with colleagues. That’s the nature of academic work! Learn to multi-task and context switch effectively now before you start your faculty appointment!”
Freshly minted Assistant Professors, trained to focus on a single research problem, are suddenly asked to supervise their students working on multiple, independent projects, teach courses, serve on committees, provide service to the department, etc. Having not been properly prepared for this modus operandi, almost anyone gets stressed out. Furthermore, the ability to multi-task and context switch effectively may take years to properly develop. Thus, this cause of stress is unavoidable.
The second serious cause of stress on the tenure track is that research is not an individualistic enterprise. Multiple individuals have invested their time, efforts, and professional reputation in the success of every single junior faculty member. Reputation is the most valuable academic currency. Academics rely on recommendation letters when making hiring decisions, as it is virtually impossible to ascertain a faculty candidate’s potential for success. Academics do trust each other’s recommendations. If someone enthusiastically recommends a person for a faculty position and the person fails to live up to the recommendation, the recommender’s reputation would suffer. The subsequent recommendation letters from that person would have less weight and would be taken less seriously. Also, junior faculty do supervise graduate students. The research career trajectory of a graduate student is, to a large degree, determined by how successful his or her advisor is. The desire not to let your professional colleagues down is what is keeping a junior faculty up at night.
In that light, I cannot imagine how I could have been able to treat my tenure-track appointment as a postdoc. For me to do so would be similar to saying “I have achieved everything I have on my own, and I do not owe anyone anything. If I fail, it is my own business, and if people who invested in me or entrusted their professional careers in me suffer as a result, I do not care.” That’s why being on the tenure track will always be stressful for anyone, and I have serious doubts that the original blog post’s author’s tenure track experience was as stress-free as claimed. I wish all the Assistant Professors embarking on their tenure-track careers best of luck!
Any compendium of advice for budding researchers is never complete without admonitions about the importance of developing good communication skills. However, communication skills are defined almost exclusively as the ability to write technical manuscripts and give formal oral presentations. Although these skills are critically important (don’t even contemplate applying for an academic job having not gained some mastery in them), there is another set of communication skills that are not any less important but are commonly overlooked. I am talking about the ability to manage the expectations of your research peers and superiors as well as keeping them properly informed about your progress or lack thereof.
The modern research enterprise is a fundamentally collaborative process of discovering new knowledge and sharing this knowledge with your research community. Few researchers work by themselves. Even a researcher who publishes all of her papers as single author has organizational superiors (e.g., dept. head, manager), whose jobs are affected by her progress. A graduate student working on his own research under the guidance of an advisor has the responsibility to inform the advisor about his successes, setbacks, and changes of directions in a timely fashion. Doing so properly requires strong communication skills that graduate students must take time and effort to properly develop. What I am going to say next may sound blasphemous, but an otherwise competent researcher working in a team (e.g., in an industrial research lab) may be forgiven poor formal written or oral presentation skills. Other team members can take the lead on writing research papers or giving presentations. However, not properly communicating with your research team about your personal research progress can be truly disastrous.
Let us consider a hypothetical example of a graduate student working on a project that involves applying an AI algorithm to a software engineering problem. The statement “The AI algorithm we picked does not quite work” from a graduate student to her advisor would have vastly different implications depending on how long in advance of the planned publication deadline it is uttered: (a) two months—normal research process; “let’s find and try another one”, (b) one month—worrisome; “can we make this deadline?” (c) two weeks—frustrating; “forget about making a strong submission now!” (d) one week—exasperating; “why are you telling me this now, when I have wasted all this valuable time working on this manuscript?!” (e) days—catastrophic and maddening; “…!!!”
Nevertheless, I often witness graduate students struggling with developing this important aspect of communication skills. I believe that some cultural norms and common misunderstandings may prevent the effective development of such communication skills. Let us examine them in turn.
- Lack of Appreciation for Negative Results
Some graduate students take an engineering approach to research tasks: something to be successfully executed to completion. Especially for someone who had a career in industry, not performing an assigned task on time successfully often signals incompetence or lack of work ethics. By contrast, doing research entails continuously trying out new ideas to test them out for their promise. In that light, knowing that an idea does not work is often as valuable, if not even more so, than knowing that it works. Hence, negative results should be reported and discussed in a timely fashion.
- Not Feeling Comfortable to Ask for Help
Some students have a false sense of pride in handling all the research challenges by themselves. They see asking for help as a sign of weakness and incompetence. As a result, they often postpone getting the required help until they get dangerously close to the publication deadline. This creates unnecessary stress for everyone and often leads to failure.Nobody was born knowing how to conduct great research. So it is perfectly OK not to excel at each aspect of this demanding cognitive activity. Asking for help in a timely manner makes planning easier. The planning is required for the advisor to be able to plan how best to help the student. This help may entail allocating more of the advisor’s time to the project, a brainstorming session, an inclusion of additional students, or targeting a publication venue with a later deadline. With enough time, all these options are possible.
- Poor Articulation in Describing One’s Progress
Often graduate students fail to properly articulate the progress they are making in their research. Instead of precisely identifying which aspects of the project are going well and which ones are problematic, they report their progress using generalities. Here is a list exemplifying inappropriate answers to the question “How is your project going?”: “It is going fine.” ; “No specific results yet, but I am working on it.” ;“I am writing the paper.”A competent researcher should be able to articulate her progress using concrete terms and specify not only the successes but also the hurdles to be addressed. For example: “I am having a really hard time finding a convincing motivating example—the ones in the literature do not seem very applicable.” “I have finished the implementation of the system. For some reason, I am not seeing the expected performance advantages. I am checking my implementation for bugs, and if my implementation is correct, we may need to tone down our performance efficiency claims.” “My paper draft is almost completed with the exception for the experiments section. For some reason, I find it hard to clearly explain our experimental setup.” “When summarizing the system design, I find it hard morphing the text from my prior papers to avoid self-plagiarism. I may need your help with this part.”
I know that some research teams hold regular meetings, in which each team member reports on their progress and difficulties encountered. Some academic research teams even have successfully adopted Scrum, an approach used for managing Agile software development teams. However, I find the practice of regularly reporting progress in a rigid format contradictory for my vision of the research enterprise, even though these practices may work exceptionally well for other research groups. I see research as a fundamentally creative enterprise, with researchers being more akin to artists than engineers, with individual researchers having a strong ownership of their work. In my view, properly developing the neglected aspect of communication skills discussed in this post can help ensure timely research progress without jeopardizing the spirit of free discovery and exploration that I value so much.