Top 9 writing mistakes made by project students

325752626_69392aa6b1

Photo by athena on Flickr

A large part of any final year thesis project is the write-up, but every stage of the project will involve some form of writing. Whether you are writing a proposal, an interim report, a draft report, documentation or the final thesis, a very large part of your time will be spent composing text. These are the top ten mistakes we see from students year on year, avoid them and you can save yourself a lot of time (and earn a lot of marks)...

1. Unsubstantiated claims

As a general rule, any statement of fact or opinion about your work, or your topic of study should be substantiated in some way. You don't have to worry about the bleeding obvious, we know that 1+1=2 (unless your work is in the "foundations" of mathematics or philosophy, in which case 1+1 may well be undefined), but anything less obvious should be backed up by solid evidence. That evidence can be a reference to literature, an argument you make in your writing, the results of your own experiments, or any other suitably rigorous evidence.

Avoid so-called sweeping statements that are effectively impossible to substantiate "all Object Oriented programs couple algorithms and data". Do they? All of them? "Testing improves the performance of students". Really? These sorts of claims are poor academic practice and suggest that you have been a little sloppy in your thinking about your work, and of course that's not the impression you want to give.

2. Dangling pronouns and other references

This seems to be an almost universal problem with student writing. Consider the following paragraph:

In his 1953 paper, Henry Gordon Rice proved that for any non-trivial property of a partial function there is no general decision method to determine an algorithm that computes a partial function with that property. It has far reaching consequences for compilers, static analysis and other fields in practical computing.

What does the "It" in the second sentence refer to? Rice's theorem, his paper, or something else? It isn't clear from the text, although we can guess that the author meant to discuss the theorem. Better though, to be clear about the meaning in the first place. Every pronoun ("I", "he", "she", "it", "that", "who", etc.) should clearly refer to exactly one noun. The first sentence gets this right, it is clear that "his" refers to the noun "Henry Gordon Rice" and not any other noun in that sentence. So, we could improve the paragraph above by re-writing it:

In his 1953 paper, Henry Gordon Rice proved that for any non-trivial property of a partial function there is no general decision method to determine an algorithm that computes a partial function with that property. Rice's theorem has far reaching consequences for compilers, static analysis and other fields in practical computing.

3. Using a secondary source rather than a primary one

It's much easier to read the popular press, blogs and other "informal" media than research papers. Very few marks will be awarded for this, though. In a final year project you need to show that you can perform a small academic study, so marks will be available for reading peer-reviewed academic literature. There are two major pitfalls to avoid here. Firstly, you will occasionally come across some disreputable conference or journal which does not use peer-review. Worse, it is possible to come across "articles" on the Internet which have citations and publishing records and look, to all intents and purposes, like a genuine piece of academic writing, but have actually never been submitted to a journal or conference. This is very poor practice on the part of anyone who puts this kind of thing up on their own blog or website, but it does occasionally happen. A reputable publishing venue will have some sort of statement on their website stating how articles are reviewed (look for "Instructions to Authors"). This should say that every article is reviewed by at least two people and sent back for corrections before being published. Without this sort of peer-review any poor standard of work can be "published" without anyone checking even basic standard of good practice, such as detecting plagiarism. That said, even with peer-review, some poor practice still slips through the net.

Secondly, whatever references you cite should be primary, rather than secondary sources. A primary source is one where the author(s) reports work that s/he (they) have personally carried out. A secondary source is one where an author reports on work that someone else has completed and published elsewhere. Secondary sources include news reports, magazine articles and blog posts about research completed by others.

4. Confusing structure and use before definition

Any academic writing should generally be written for a reader who is an expert in the general field of the study, but not necessarily in the specific area of the study. If, for example, your final year project is on genetic algorithms, your work might be marked by an expert in artificial intelligence, or in computer science generally, but not necessarily by an expert in GAs. So, write with that in mind, and make sure that you don't use any specific technical terms without defining them. This is often very difficult to get right at first, especially when you have been working with your own ideas for a very long time. A good plan is to swap drafts of your work with a fellow student who is on the same degree course but working in a completely different field for their final year project. If you can both understand each others work, that's fine. If not, make changes.

5. Claims of "proof"

At the beginning and end of your dissertation you will want to set out the aims of your work and describe the conclusions you have reached. Occasionally we see students writing sentences such as "this study proves that ...", "this thesis will prove ...", and so on. "Proof" is specifically a mathematical method, and if you have genuinely proven a theorem, by all means say so. If not, then don't use the word "prove" and be very careful about what you do claim. For example ...

  • If you have tested a piece of software and it has passed all your test cases, then you have shown that your software is free of the specific errors you have checked for. You have not shown that it is "error-free" or "works".
  • If you have performed some sort of user testing, or any other usability / accessibility testing, then you may have demonstrated that the system under study is "usable" or "accessible" as far as you have tested it. However, without a large-scale study that is as much as you can claim. Be very circumspect about reading research in the area of usability; there is much good research but also much which is over-blown. Be especially careful of authors who also run consultancy practices, make sure you cite their academic literature, and not anything that could be considered advertising. Make sure everything you cite is peer-reviewed.
  • Be very, very careful about using questionnaires. I usually tell all my students to just avoid them altogether. It is very, very hard to produce a questionnaire which holds up under academic scrutiny and you will need an amount of statistical sophistication to produce sensible results. Also, you need a very large sample-size because your questions will be circumscribed (and for other reasons). This makes questionnaires very difficult to use in short, single-person projects. If you are in any doubt, then use a "semi-structured interview" to interview test subjects and the "talk-aloud protocol" or "cognitive dimensions of notation" for usability testing. Before you start, read some papers on evaluation methods, such as Hollingsed and Novick (2007) Usability Inspection Methods after 15 Years of Research and Practice, or Hornbaek and Law (2007) Meta-Analysis of Correlations Among Usability Measures.

6. Ad-hominem remarks

We see this very rarely, but just occasionally a student will forget that they should be writing about academic research, and criticise an author directly. Examples include "$X is stupid", "it would be stupid to think that..." and so on. Don't do this, stick with the research and don't criticise the person.

7. Don't be meta

If there's one piece of advise students regularly misunderstand it's that you should be cautious and critical of the literature that you read and cite. Of course, you should be critical and cautious, but you should also be sure that you are writing about the content of the research that you are reading about, not the quality of the writing. I should probably say, this piece of advice does not hold up if you are studying literary criticism, or anything similar, but for science-based subjects, stick with the science. Don't say things like:

(Foo Bar, 2009)  is a poorly written paper. It is confused and hard to follow.

Also, don't say things like:

The problem with this paper is ....

If there's a problem with the research that the paper describes, then by all means discuss that, but not the writing.

8. Don't write a giant list

I've written a separate post on literature reviews, but one common mistake we often see here is to structure a thesis as if it is a list of points, not a single piece of prose. Do not write about the literature in your field one paper at a time, try to tell a story about how the field has developed, culminating in saying that there is clearly a gap in the research where your contribution can fit. So, avoid writing like this:

Foo Bar (2007) On the usability of Flibble widgets

Bar describes the Flibble widget, which is used for ...

instead, work your thoughts on Flibble widgets into a longer piece of writing on widgets. If you do need to break up and structure your literature review, make sure your headings are topics which group together related pieces of research.

9. Don't replace elegant paragraphs with bullet points

A very common error we see in project write ups is where the student writes a series of ‘bullet lists’ instead of connected and well supported prose. The problem with this is that bullet lists do not often demonstrate complex thinking, rather, they simply provide ‘shallow’ summaries of topics (when we need some depth!). For example:

“People use CSS for:

  • Interoperability
  • Future proofing
  • Accessibility
  • Conforming to standards”

In this example – what does ‘interoperability’ mean?  Why does CSS provide ‘future proofing’?  Is CSS the only way to enable accessibility?  There is SO MUCH TO SAY on these subjects!  The bullet list destroys your chance to demonstrate your research and ideas.

Tagged academic_writing dissertation thesis writing

How to write a literature review for your final year thesis project



A long time ago I wrote an article on how to pass your final year thesis project, which several students found helpful. In the same vein, this post deals with a particular aspect of the final year project: the literature review.

Every year I supervise projects I find students tend to ask the same questions about their literature review. Most common are:

  • How many papers should I read?
  • How long should the literature review be?
  • Should I read books, articles, or ...?
  • Is it OK to reference websites such as Wikipedia?
  • Who will read my literature review and what can I assume about their knowledge of the area?
  • When should I start the literature review and when should it be finished?


These questions crop up frequently and will be familiar to any readers who are starting their own project. However, when you fully understand the purpose of the literature and how to go about writing one, you begin to realise that these questions are actually not that important. This post is designed to help students make that transition, from not yet understanding what the literature review is for, to having a thorough understanding of its purpose and a clear idea of how to write it up.

The meaning of a final year project

A lot of students starting off their projects talk about writing a "report" at the end of their "project" and doing some "research" as part of their literature review. This is where the subtleties of the English language tend to cause a lot of confusion. "Research" can have many different meanings, and to complete a really successful final year project the first thing to do it to understand fully what is expected of you in an academic context. Even if your final year at University is the last experience you have of academic work, remember that your work will be marked according to academic criteria, and academia has quite different aims to industry.

So, to be clear: research, in an academic context, means adding something new to the body of knowledge that humans have gathered in your area of interest. Your project as a whole will be a piece of research because you will be creating something new that has not been created before. What that is exactly will depend on the field you are studying. It might be a new perspective on a piece of literature, a new proof of a theorem, a new application of a particular technology, or something else. Since you are still an undergraduate it is likely (although not necessary) that your work will be a small step forward. It is unlikely that you will produce something completely ground breaking, so don't be intimidated by fact that your work has to be novel. That said, it may be that you produce an excellent piece of work and your supervisor may want to turn that into a technical report or conference paper with you, which would be great for your CV (or resume).

A thesis is a statement of belief that is central to your research. Your dissertation will be a piece of writing that defends your thesis, based on your research. So, for example, if your thesis is regular, online tests help University students to learn new material then you will need to implement some sort of online tests for new material, design and run an experiment to test your thesis, and write it up in your dissertation. Equally, if your thesis is water causes cancer in mice then you will need to plan and run an experiment to determine whether or not this is true and write it up. Notice that you may disprove your thesis in your work. It may be that online tests do not help students learn, or that water doesn't cause cancer in mice. This is absolutely fine, so long as your experiments give a clear answer to the question and you can show that your experiments were performed fairly it doesn't matter whether your thesis turns out to be incorrect or correct (in so far as you have tested it). It may also be that your evaluation is inconclusive, which is also acceptable, so long as your experimental method is good and you can say exactly what further work is necessary to produce a definite result, you will be fine.

Alternatively, you might phrase your thesis as a research question. In which case, instead of having a thesis such as water causes cancer in mice you would ask the question does water cause cancer in mice and your dissertation would describe your efforts to answer that question.

The shape of your dissertation and where the literature fits in

Every dissertation is slightly different, but good dissertations will all contain the same elements. I should say that the advice given in this sections is likely only relevant to science based projects. If you are working in the arts or some areas in the humanities then the expectations of you may well be very different. Still, a good dissertation in the sciences will contain roughly the elements listed below. I say "roughly" because, depending on the exact nature of your work, it may be sensible to expand some sections into two chapters rather than one, or to coalesce some elements into a single chapter. Your supervisor can give you more specific advice on this.

  • Introduction: should introduce the reader to the broad context of the research and explain why this is an interesting area to work in. So, if your thesis is something to do with mobile computing, you might say something here about why mobile phones are important, why mobile computing is an interesting and important area, and broadly what other researchers are working on. At the end of the chapter you will want to introduce your specific research question, having said why the area you are working in (and therefore your question) is important.
  • Literature review: Now you have introduced the reader (who will likely not be an expert in your exact area) to the broad research agenda in the field, and your research question, you can start writing more specifically about your own project. In this chapter you will survey the work that other researchers have done to answer your research question, or related questions. At the end of the chapter you should briefly explain how your own work builds on and differs from the work that has gone before it.
  • Method: this chapter should describe what you did to answer your research question (or to support your thesis, if you think of it that way), and how you went about it. You should describe your work in sufficient detail that another researcher could recreate your work to check your results.
  • Evaluation: here, you should evaluate what you have done, and say what answer (to your research question) you have arrived at. It may be that in your method you describe some experiments, and this section records your results and analysis of those results. This is an important section -- most students gain or lose marks in either their literature review or evaluation. Key to producing a convincing evaluation is to plan very early in the project what information you will need to write this section. More on that in another blog post.
  • Conclusions: should summarise what you have done and how you answered the research question. It may be that your work produced a very clear answer to the question, or it may be that your work points to a need for further research to clarify or confirm your answer. You should refer back to the literature review and summarise how your research differs from (hopefully improves on) the work described in the literature. Make sure you also say what research you would do if you were to continue working on your project.
  • References: a list of publications cited in the main text, in Harvard style or similar format.

It is likely that most chapters will be roughly the same size, although the introductory chapter and conclusions are usually slightly shorter than the others. Try to let the lengths of each chapter be guided by the amount of useful and important information you have to convey to the reader, don't impose artificial word limits on yourself.

Summaries and synthesis: what should go in your literature review

Poor literature reviews often take the same form -- they tend to be a (usually short) list of papers that the student has read, briefly summarised. This is not really what is expected and will not gain high marks. Another common mistake is to review literature that has been used to inform some part of the practical work of the project, rather than to review work that has answered the same or related research questions. To do better, your writing needs to not only summarise the prior art in your area, but also synthesise what is in the literature. In fact, synthesis is one of the key skills that we expect to see from final year students.

So, what is synthesis? The main idea is that you should have understood the literature you have read and, more importantly, you should show that you understand the relationships between items of literature. That means what came first in your field, how it influenced later work, how each step forward in the research improved upon what came before it, and so on. Ideally, you will present your own view of the work you are describing. This partly means that you should be critical of the literature you read, and say where the shortcomings of the work are, and how the work could be improved upon (in particular how your work will improve on the prior art). Also, you might have your own view on where your area of research is likely to go in the future.

Critiquing the work of others is something that is often new to students in their final year. One of the most frequent mistakes I see from students is to criticise the style of the papers they read, rather than the research that those papers describe. Avoid writing things like "this paper is not well written" or "this paper is hard to understand". A literature review should really be a review of the research work that has gone before you, not a literary criticism of the style that other authors adopt.

Practical matters: how to start, how to finish and how to do the bit in the middle

Reading and understanding the work of others is a lifetimes work for professional researchers, it is not something that starts and stops on particular dates, according to a Gantt chart. Your final year project will have a hand in deadline, so you need to be a little more circumscribed about how work. 

Ideally, you should be reading some literature in your field very early on in your project, to help you choose a good topic and write an initial research proposal. I would suggest that you consider this to be the starting point for your literature review and keep on reading and adding to your writing all the way through your project until you hand in your final dissertation. To do this, I suggest you do two things. Firstly, keep a careful log of what you read in a format you find easy to work with. This might be a a log book on paper, or it might be a file on your computer, whatever works best for you. Each entry should include the title of the work you have read and enough information about the authors and so on that you can find the publication again. You should then summarise the work in the paper, including the research question answered by the work, the nature of the answer and the methodology of the research (i.e. what the authors actually did). This will give you a couple of advantages -- you won't forget anything you read because you have a record of it, your literature review can be written from your notes and if you are asked any awkward questions in a viva you can refer back to your log. Secondly, as soon as you feel you have read enough to understand the broad context of the literature, start writing it up formally as your second dissertation chapter. This should really be within two or three months of your starting date. Then, as the project progresses and you read more, you can integrate your new reading into your already drafted chapter. This might seem like a lot of effort early on, but when you come to write up your work, you will be incredibly grateful that your most time consuming chapter has already been written, when it was fresh in your mind, leaving you free to write up the later sections of your work.

An example of good writing

Now you know what a literature review is for, how it fits into your dissertation and how to go about writing your own, it would probably be useful to see an example of (part of) an example review. The paragraphs below give such an example and the text [in italics] is some commentary to explain how each part of the writing contributes towards the start of a good thesis chapter. When you read this, don't worry too much about the subject matter, just try to concentrate on the style of writing and the structure of the text. 

The area of pervasive, or ubiquitous, computing was founded by Wieser (1991) [ referenced] who predicted that computers would one day be integrated into everyday objects and interact with people seamlessly. Although few such products are available today Weiser’s work has led to the creation of a number of research areas, including ambient intelligence (Eli and Epstein 1998), smart dust (Khan et al, 1999) and the Internet of Things (Brickley et al, 2001). [Sets the historical context of the area and defines related areas.]

An early application of pervasive computing was the active badge location system, described by Want et al (1992), in which users and objects were tagged with an "active" badge which could locate and identify them. This system was based on ultrasound locationing, whereas later systems might use RFID technology to achieve the same effect. [describes how the field has changed over time] Uses of the active badge system included routing phone calls, email alerts and so on to the physical location of the receiver. [contextualises the fundamental research]
 
...

 

Tagged academic_writing dissertation literature literature_review thesis writing

How to pass your final year thesis project

I've been thinking for a while that it would be good to distill some of the advice that colleagues and I give to students doing final year thesis project, so here it is -- enjoy!

Think of yourself as an academic.

Whatever you want to do when you leave University, your work will be written for academics and marked by them. A thesis project is like a small research project and to get the best marks available you should run your project with that in mind. So, you need to perform a thorough literature survey, follow a sound methodology, critically analyse your results and so on.

Have a hypothesis (or a thesis statement or a research question).

A lot of students approach their projects by saying "I want to do this", like "I want to invent a Foo, written in VB". This is not the best way to get good marks. Your project needs to have some sort of clear purpose and in the academic world it's best to state that purpose as a hypothesis, thesis statement or research question. These three are really just different ways of stating the same thing and which you choose is just a matter of taste. So, if your project is a study on the ratio of smokers which develop cancer (e.g. "I want to do some statistical analysis on smoking") then you might phrase that in one of these ways:

  • Smoking is correlated with cancer -- hypothesis
  • Smoking is correlated with cancer -- thesis statement
  • Is smoking correlated with cancer? -- research question

Or, perhaps you want to design a new GUI widget to replace list boxes:

  • Users will find WidgetFoo easier to use than ListBoxes -- hypothesis
  • Users will find WidgetFoo easier to use than ListBoxes -- thesis statement
  • Is WidgetFoo easier to use than a ListBox? -- research question

Part of the point of phrasing your work like this is that it should change the way you think about the work. You now have a very clear goal to reach -- to prove your hypothesis / thesis statement or to answer your research question. Everything you do in your project should now be directed towards this one goal.

Also, you have reduced your risk of failure. What if WidgetFoo turns out to be rubbish? Well, then you have still answered the research question or disproved the hypothesis -- you've got a result. In your write-up you can probably say a lot about why WidgetFoo wasn't as good as you thought, how you achieved your results and how other researchers can use your work to invent even better widgets.

Produce something useful to others.

So, you've got a hypothesis to answer. Great. But your teachers will still want to be convinced that the hypothesis you've chosen is worth six months of your time and lots of hours of their time. How do you know if your work is useful? Firstly, make sure you've read the relevant literature. Use Google, go to the library, talk to potential users. There should be a group of people in the world who have a clear reason to be interested in what you're doing. That might be a section of the research community, a user group, a company, whoever -- but there must be someone who wants your hypothesis validated or disproved. You should convince whoever's marking your thesis that this group of people exists by explaining in your thesis what the current literature says about the area you are working in and how your work contributes to this area.

Do something (a bit) novel.

You're not expected to win a Nobel Prize on the back of your undergraduate work. However, there's no point in doing something that everyone has done a million times before. The worst example of this in Computer Science is a project which is basically "I'm going to write a website with a database". Usually the website is for a friend or relative and the database keeps track of users. There's nothing wrong with that if there's some real novelty in it (e.g. you've just invented a new sort of database and this is a demonstrator for it). But often this is something that most first years could complete for a coursework (so, it isn't stretching you) there are simple, free tools that can do the job for you (it's not novel) and the user is bogus (noone's interested in it). Choose wisely!
 
Have clear success / failure criteria.

This should be taken care of when you write your hypothesis (or thesis statement or research question). However, it's important to know what will constitute a "successful" project for you. What results do you want to end up with? Once you know that, you can choose the appropriate methods to use in your work (e.g. will you be running a focus group? Writing a questionnaire? Writing some programs -- and testing them somehow?). You can also think about reducing the risks in your project. What if you don't finish part of your work on time? Is there some catch-up time in your schedule? What if early tests go badly? Is there time to repeat them?

Don't change the world.

Don't choose a project which is just far too big. If you're going to invent a new computer, writing an OS from scratch and a windowing environment for it is not a one-person, six-month, part-time job. Keep it small and give yourself some scope for extending the project if it goes better than you thought.

Even if you've chosen something small with a clear hypothesis, once you've written out a project schedule it will still feel like far too much to do. You will feel overwhelmed. The trick to reducing your fear early on (and making sure you work to schedule) is to break down your work into small tasks. Each task should have it's own goal and deliverables with it's own success criteria and a deadline. So, if your hypothesis is "WidgetFoo is easier to use than ListBoxes", your sub-goals might be:

  • Produce a literature survey on list widgets.
  • Write comprehensive unit tests for WidgetFoo in the Gtk widget set.
  • Implement a WidgetFoo in the Gtk widget set.
  • Debug (goal is to pass all unit tests).
  • Devise usability experiments (deliverable: methodology document).
  • Write application software for testing in the experiments.
  • Perform experiments.
  • Analyse data.
  • Write-up thesis.

Note that these tasks are dependent on one another. WidgetFoo cannot be written before you know how to test it. The experiments cannot be run until you have designed them and decided how to analyse the data they will produce.

Your new list will make life a lot easier, but you will probably still feel that it's too much to handle. To feel better about your work and motivate yourself, it's a good idea to take each of your sub-goals and write out the next physical action you need to perform to carry out that task. So, for the literature survey the next action might be "Google for 'list widget'". For the unit testing your next action might be "Find documentation about the UnitFoo testing framework". And so on. Most people find action lists much more motivating than task lists. Scroll down to see more stuff on productivity and where to keep your lists!

Choose a project that will maintain your interest.

Six months is a long time. If you choose a boring project (maybe you think it'll be "easy") then you'll quickly lose interest, get bored, stop working and possibly fail. In some ways, it's good to choose a project with a lot of scope (so you can change direction a bit and still address your hypothesis) in an active area of research (so there's lots of work to build on). On the other hand, some people would find that sort of project unfocused and confusing.

When you plan your project, think hard about what motivates you. Is it reaching towards a really interesting goal, or the fear of failing really badly? Either way (or both) you need to keep that motivation in mind whenever you're working. So, choose something interesting to do, give yourself at least a little scope for changing the details of the project over the year and keep in mind why you want to succeed (or not fail!).

Don't be too dependent on clients.

If you have a client to work for, especially one from industry, be careful about how you plan your project. If you are expecting resources from your client what will you do if they don't turn up on time? If you want the client to test your work, what do you do if they get a major order in when you're ready to test and noone has the time to help you out? What if the client goes out of business? What if you have to sign a non-disclosure agreement -- can the University still mark your work?

Having a "real" industrial client can be a big bonus. For one thing it's very easy to say that someone is really interested in what you're doing for the project. However, you need to make sure that if the client pulls out or doesn't cooperate you'll still have a viable project. Plan well and you won't have any problems.
 
Understand that research is not reading and a thesis is not a report.

Most undergraduates (at least in Computer Science) seem to be pretty confused about what research really is. It certainly isn'tabout using Google or reading in the library. Research means adding something new to the body of knowledge on a particular subject. This is why it's so important to know what work has already been done (so you know your work is novel), to have a clear hypothesis (so you know what new understanding you're adding) and to write up your work well (so other researchers can use it).

Also, understand the place of your thesis. You are not writing a report which tells people what you did. You are writing a thesiswhich tells people about the research you have done. This can be structured in whatever sensible way you prefer, but it needs to have the following parts:

  • An introduction. What's your hypothesis? Why is your work interesting? What are your trying to achieve?
  • A literature survey. What have other people done? What new knowledge will your work add? What is the current state of the art missing and how are you going to address that?
  • Your methodology. How did you go about validating / disproving your hypothesis? Why is your method sound? Why should anyone trust your results?
  • Your results. What did you do? How?
  • Your analysis of your results. What do your results mean? Why are they interesting? Did you validate your hypothesis or disprove it?
  • Conclusions. What did your work contribute and how could it be continued by others?


Eat well, sleep well, get some exercise and take a day off every week.

Basically, look after yourself. To work productively you need to be in good physical and mental condition. If you feel ill or your not coping well with life, slow down a bit and take a break. Don't eat junk food all the time or you'll feel sleepy and miserable. Cut down on caffeine and alcohol or you'll get stressed and sleep badly. Sleep a sensible number of hours every night -- consistency is important. Get some exercise because you need endorphins to keep you happy and some oxygen getting to your brain. Omega-3 and the sorts of minerals that aren't found in hot dogs will keep your brain working sensibly.

Most of all, take a whole day off University work every single week. It doesn't matter what you do with that day (have fun, earn money, write a novel, whatever) but working every day will limit your creativity massively. Most very creative (and productive) people find that their best ideas come after a day off. This gives your mind a chance to consolidate all the material you have learned, synthesise it and solve some of the problems you've been considering. In fact, to revise for an exam or solve an interesting problem, it's a good idea to spend a few days working really hard at reading everything you need to know and taking notes, then take a day off directly before the exam or the day before you're going to write the solution to your problem. This will give you the best chance to properly understand everything you're working and be creative about it.

Be productive but don't spend time on productivity.

You need to organise yourself well, which is a difficult problem in itself. However, if you spend even five per cent of your time on productivity management (e.g. using Microsoft Project!) then that is far, far too much and a massive waste of your most important resource -- your time.

Good productivity strategies are effortless, effective and fun to use -- and take almost no time at all. I can recommend David Allen's Getting Things Done strategy and RememberTheMilk for managing lists of action items.

One thing you can do to really give yourself a head-start in the workplace is to estimate how much time it'll take you to do every single task in your project. You'll start out finding that your estimates are stupidly far out, but as your project progresses you'll get better and better at correctly estimating your tasks. Joel Spolsky has a nice essay on how to do this simply, which you can use with RememberTheMilk

 

Tagged dissertation hypothesis novelty productivity research_question thesis
​