Advisors have typically lots of different things to do and to care about, and sometimes it is just hard for them to find the necessary time to provide good feedback to your inquires, emails, projects or paper drafts. Yet, it is in your interest to get the most out of your advisor! So: optimize your input, and help your advisor give you the best feedback possible :-)
The considerations below aim to help you make the most out of the collaboration you have with your advisor - indpendently of the level of your carreer - and to improve the quality of your scientific production. Another very good resource with lots of thoughts on research and teamwork I share you can find on Fabio Casati's personal website.
Should you have any feedback after reading this page, suggestions, corrections, or complaints, just drop me an email, and I will be happy to answer.
I think there are some simple attitudes toward work that, if followed, can make the difference (and people happy, including you):
Of course, it is not always possible to be interested in everything, it may happen that someone forgets the notebook, that he/she fell so in love with someone else that some work could not be done properly, or that it could not be done at all. As long as the last point is satisfied, things always work out well.
I know, I am working on IT, that is, information science and technology, and am therefore not supposed to care about this apparently non-technical aspect. However, working with students from all over the world at Bachelor, Master and PhD level, alas, their writing skills make me increasingly puzzled. That is, the absence of writing skills.
Here my point: If you are doing a PhD or Bachelor/Masters thesis, forget about your IT skills. If you are doing it, let's give those for granted. All that counts now is whether you are able to communicate your idea or not. It is a common convention that communication happens in natural language, not in HTML or Java. That language is typically English. So, you must be able to write decently in English.
More and more, I consider this point important. Sometimes, I even go as far as to say that, when interviewing a candidate for a new PhD position or an internship, it would be a good idea to tell the candidate just to sit down and write a short essay about some random topic. In English. Perhaps a topic related to the open position, but not mantatorily. The topic is not important, but the quality of the writing. It just happens so often that, when trying to give feedback to a paper draft by a student, I get distracted by language issues and forget about the actual content of the draft. Therefore, you must strive for a good and fluent English!
Three hints on how to improve your English:
I know this may seem far away from programming and research, and I admit it somehow is, but it is in your own interest that your work is also properly understood by your audience. If they don't get it, they don't buy it.
This is somehow a story in itself, but it starts from giving for granted the previous point. That is, we assume the right vocabulary is there and it is clear how to structure text. The problem now is how to write a scientific paper. Hard to say. Each paper is different, each scientific community has different conventions and styles, each topic may require own approaches, etc. Again, I don't have a solution, just some ideas of how to approach the problem that worked for me in the past (at least, I like to believe so).
The single most important rule here is: Read, read and read! Reading lots of papers (good papers!) by others doesn't tell you only about what these authors do; it also allows you to learn some domain-specific vocabulary and area-specific paper structure conventions. For instance, if you want to write a paper for conference X, go and leaf through lots of papers published by conference X in the past. Understand what the community X is interested in, where they usually place the state of the art, whether they like to see an explicit problem statement or not, how they describe the implementation, whether they like to see formal, mathematical proofs, performance tests, user studies, or whether a well-done case study may suffice, etc.
I call this meta-reading. You read a paper not to learn about what the authors have to say, but to understand how they say what they have to say. Look at how content is structured into sections, at how section titles are chosen, how text is strucured and given meaning by using numered or itemized lists and paragraphs, what the key messages of each section of the paper are, which the key message of the whole paper is, and so on. It's like movie actors who learn how to act: it's all about the form (gestures, expressions, accent), not the content (each movie is different, after all, just like papers).
Scientific papes vary very much from community to community. In psychology, for instance, there is typically a hypothesis the authors want to prove or disprove. So, they identify a test setting that allows them to gather the necessary evidence (the data) to make a statement about the thesis, they perform the test, analayze the collected data, and draw their conclusions, i.e., the accept or reject the hypothesis. To give you an idea of how these papers typically look like (and also to have some fun), read the paper by Bègue et al. (2013) demonstrating that people that think they are drunk also think they are more attractive (the paper is among the winners of the 2013 Ig Nobel Prize) or the paper by Cholakians et al. (2009) about the famous "beer goggles" effect. Both easy to read and understand and instructive.
A scientific paper in our context is typically more complex. Of course, there is some hypothesis to be proven. It's not always easy to indentify it, but it must be there somewhere in the paper, e.g., called "claims" or "contributions" or similar. But here is the complication: this hypothesis is usually not about some human behavior or natural phenomenon; it's about a technical artifact (e.g., software in the domain of computer science). The problem is that this technical artifact must first be constructed so that it can be studied, and it must be constructed in such a way that (i) the reader can understand it, (ii) he/she agrees that its construction is correct, and (iii) he/she can associate a real need/value to it. Attention, if your reader does not get these three points, the very acceptance of your hypothesis may by useless. This is the complication! Not only is there a hypothesis to be accepted/rejected, there is also a technical artifact that must be properly designed (which requires good technical and engineering knowledge) and motivated (which requires good knowledge of the state of the art). Since the claim here it typically that the technical artifact solves some problem, the problem statement assumes a key role. If you don't convince the reader that there is a problem, whatever solution you propose is useless. However, if you do convince the reader that there is a problem, he/she will be accommodating regarding the solution you propose.
In short, when writing a paper carefully think about the problem you want to solve and put all your effort into convincing the reader that the problem is real. To be precise, always clarify your goals, assumptions and requirements before starting with the explanation of your solution.
Here some useful references for those who want to deepen this aspect and improve their writing skills:
Giving a good presentation is a hard task. I think I haven't seen perfection yet in this context, and I don't think my own skills are any better than those of the average researcher. However, I think there are some simple tricks that everybody can apply to obtain decent results:
Just a nice presentation by David A. Patterson on how to have a bad career in research/academia. Have a look and enjoy!
Instead of developing new software, sometimes research or a M.Sc. thesis may survey the state of the art in a given domain. Writing a good survey is not easy and requires some methodology and care. Please find here a brief summary of my ideas on how to write a good survey. As usual, consider this document work in progress to be updated, e.g., also based on your feedback.