Some Answers to Students' Frequently Asked Questions

A doctoral thesis is traditionally a record of a student's first foray into original, independent research, and, indeed, unlike a Bachelor's or Master's thesis, a doctoral thesis must demonstrate both originality and independence in order for the student to graduate. (Of couse, the thesis must also be correct.) Originality simply means that the main results in the thesis haven't been done before, and independence here means that it's the student's work (and, in particular, not the advisor's work, nor the work of some postdoc or other student who's always hanging around). It represents, on the one hand, the end of a student's formal education in their chosen field, and, on the other, the beginning of their career as a researcher.  The exact composition of a doctoral thesis can vary widely, from the solution of several smaller, loosely-related problems, to a long exposition of the solution to a single larger problem. There are usually also several expository chapters included to give the background and context for the problem that one might not include in a research paper. 

It's sometimes tempting for a student entering a Ph.D program to think of their future doctoral thesis as a kind of magnum opus. Please, don't do this. It's true that a doctoral thesis is a magnificent thing, being a record of the student's first independent encounters with the unknown, and it represents a great amount of academic work and emotional toil. However, while the thesis may be - and should be - the best piece of academic work the student has produced up until that point in their academic life, if the student stays in research, their thesis will almost certainly (and hopefully) not be the best document they ever write, as they will continue to improve and do many varied and wonderful things in their future as a researcher. A Ph.D thesis is a student's first opus, and the emphasis is on doing something - anything - new, ideally in the time allotted by the student's scholarship.

There are different opinions on this, but in my view, Bachelor's and Master's theses in mathematics are the result of a student's independent (but guided) exploration of one or more advanced topics in the literature, and the requirement to graduate is that the thesis should be demonstrate conceptual and technical mastery of the student's chosen topic. Unlike with the Ph.D thesis, no original results are necessary, although some may be included if any are found. Sometimes a student does manage to produce some original results in their MS thesis, often in the form of working out some interesting new examples or computations of some mathematical phenomenon, but it's in no way negative if there isn't enough original work in a BS or MS thesis to result in a research publication. In my opinion, the emphasis at this stage is more on learning to read the literature independently and developing a clear understanding of some results which are difficult, but already known, than it is on producing original research. That said, I like to motivate the projects I propose for Bachelor's and Master's theses with an open question or two, as this can help orient the BS or MS thesis toward further graduate study, and sometimes Bachelor's and Master's students do produce some original results. Still, originality is not the primary aim, and good BS and MS theses are publishable as expository articles even when they don't contain original research, particularly in journals like the Graduate Journal of Mathematics, which were created specifically for that purpose. Writing a thesis that is a good exposition of results scattered in different parts of the literature is a very worthy goal, and, when it is achieved, it's an admirable accomplishment.

I also like much of the advice in these pages by Tom Leinster, so I'll end by including them here.

https://www.maths.ed.ac.uk/~tl/docs/project_tips.pdf

https://www.maths.ed.ac.uk/~tl/tips.pdf

In the good old days, junior faculty were often hired directly after completing their Ph.D, and postdoctoral positions were a rarity. Now, it has unfortunately become customary for an aspiring professor to pass through at least one, and often more, 1-3 year research-oriented positions (typically in different parts of the world) which act as a kind of academic purgatory, in which the postdoc tries to write as many papers as possible in order to prepare for applying to faculty positions. There are many different kinds of postdoctoral positions, and the differences between them usually involve how much teaching is required, the source of funding, and, related to the funding source, how open the possible research topics are. Funding may come from the university or department, a government or private agency, or a specific grant managed by a particular professor, and the way to apply to the position will differ in each case. The best ones - at least from the point of view of research - are positions which allow but don't require teaching, which leave the choice of research topic completely open to the postdoc, and where there are several other, more senior, researchers working at the institution in a similar field. There are other postdoc positions where a certain amount of teaching is obligatory, and others still where the funding comes from a particular grant which may require that (at least some of) the research be done in a specific area, sometimes on a specific problem. There are also positions with the title "Visiting Assistant Professor" or "(name) Assistant Professor", which are usually functionally equivalent to postdocs, although they often include a teaching requirement, and the named positions may be slightly more prestigious, but both of these things depend on the university and the specific position.

Sometimes, postdoctoral researchers are referred to as "postdoctoral students" or "postdoctoral trainees", but this is a mistake. Postdocs are not students or trainees. They completed their training in their Ph.D. and are now professional, if junior, scientists, and they should be treated accordingly.

Giving good math talks is hard, especially for the beginner, but not (mainly) because of the mathematics. It's hard to give good math talks because, even in specialized seminars, mathematical audiences are extremely heterogeneous, and not all of them are looking to get the same thing from your talk. If you were talking to a room full of people who knew about everything in your field except for your newest results, then there would be no problem. You'd just describe your results and proofs, and everyone would understand the context and essential techniques, since they already knew the literature. Usually, however, that's not the situation in which we find ourselves, and, instead, our audiences consist of at least three groups of people, in different distributions depending on the venue: 

1. Mathematicians who are either students or who work in a different area, and who know little to nothing  about the area or the problems you're working on.

2. Mathematicians who know something about the area you're working in, but who are not experts in the particular corner in which you work, and who don't know much about the problems you're working on.

3. Mathematicians who are experts in your area, and who can be expected to know the relevant literature.

A specialized seminar or conference talk should have something for each of these groups. As a rule of thumb, I like to recommend that about a third of the talk be directed to each group. 

One specific way you might do this is the following. For the first third of your talk, address first group by explaining the motivation for your work and the definitions and other background necessary to understand your theorems, only assuming math that is relatively common knowledge. At the end of the first third, state your main results. The second third of the talk should be directed to the second group, and include examples to illustrate your results, as well as less central but interesting results which you have shown. Finally, in the final third of your talk, you may address the experts and discuss the ideas of your proofs. If you organize your talk in this way, each of the three parts roughly answers one of the questions: "Why?", "What?", and "How?", in that order. 

In colloquium talks or talks for students, only the first two parts should be included, together with more background and more discussion of other work in the area, unless the ideas of the proofs are accessible to non-experts. 

Naturally, there are other ways to organize a good math talk - and sometimes your work doesn't lend itself well to the pattern I just described - but whatever you do, you have have to address the problem of the heterogeneity of the audience, and your talk should be designed so that everyone can get something out of it. 

Actually, no student has ever asked me this question explicitly, but almost all of them struggle with it - and, let's face it, as professors, we have our own version of this problem, too. I've occasionally found it useful to talk this through with students who were clearly having trouble, but I think a lot of students who aren't obviously struggling could still benefit from thinking about it more methodically - this certainly would have been true for me - so I've decided to include some thoughts on it here, even though it's not technically a FAQ.

First, once we finish our classes, we're playing the long game, so our aim in organizing our work schedule is consistency and efficiency, even more than before. Working 12-to-16-hour days trying to learn new math and prove new theorems might work for a week or two, but it's not sustainable. It's also not usually necessary. If you want to learn something new, for instance, and you read an average of ~2-3 pages per weekday in a topic that interests you, by the end of a year, you'll have read ~500-750 pages, which is usually enough to be able to start doing research in the area, particularly if it's sufficiently close to something you already know - and if it isn't, try to read 5-6 pages per weekday instead, maybe for two years if necessary. Writing a half-page per weekday will give you about ~125 pages per year, a perfectly respectable level of production. Granted, sometimes reading three pages of math or writing half a page can take several hours or more, and some days we may feel we have little new to write, but my point is that small, incremental, daily advances accumulate quickly, and we should organize our workdays around consistently making such advances. In graduate school, one has the luxury of not having too many other responsibilities (family, teaching, administration, thesis students), so if a student really develops this habit while writing their thesis, they will be well-prepared for the inevitable future in which that luxury no longer exists.

Regarding what, specifically, we should be spending our time doing, research involves all of the following kinds of individual work. Time for each should be set aside every week, and one should try to touch each of the major points (1-4 below) every day or two:

1. Work on active projects: 

   1. Writing: Formal writing of results you've established or notes on some topic of interest.

   2. Solving problems: Developing new lemmas, propositions, and thoerems for your projects.

   3. Learning new things: Reading books and papers to support ongoing research projects.

2. Learning new things you're curious about (outside active projects): Think of this as designing a course for yourself. Pick some topic or series of topics you'd like to learn about, put together a reading list, and then devote some time over the course of a few months to working through your reading list. (Quarter-long or semester-long learning projects are a nice size.) Organize it any way you like, whether with other people or on your own. 

3. Scanning new paper abstracts on the arXiv: The arXiv announcements are your daily scientific newspaper. The abstracts of the papers posted every day give you a good idea of what is being done in your area, and by whom, even if you don't manage to read as many of the articles as you might like.

4. (Mathematical) Play: This is a period reserved for completely free exploration. Rummage through the literature about any question which occurs to you, entertain yourself with problems in a book you like, learn a theorem you always wanted to know about but never took the time to learn, try out some ideas on a problem you're not actively working on, etc. Don't plan what you're going to do too much in advance, and don't set any goals for this time. If you find that you're doing that, then you've probably transitioned into one of the other kinds of tasks, which is great, but not play. For your playtime, just explore.

The sub-points in 1 above often overlap a bit in practice, but I find it useful to think of them separately and to make sure I'm doing at least a little of each every week. Also, while there isn't any strict method of doing research, I find that play often exposes an interest or a question that I want to spend more time learning about, and once I do that, it evolves into some specific open questions for a project, which I then solve some of, maybe with some other people, which is then written up in a paper. So, even if the other points seem like they're more important because they give more concrete, measurable advances week by week, don't discount the importance of play. Also, there will be times when nothing seems to be going quite right, and this regular playtime can help rekindle your curiousity and remind you why you got into this business in the first place. The bad periods do pass eventually.

How best to balance each of these things in your week will vary with time, and figuring out the right balance at any given moment requires some trial and error. People also have a tendency to over-schedule themselves when they start consciously planning their time. Remember that you're aiming for a work schedule which is sustainable over the long term, with minor variations. Be realistic and reasonable, and concentrate on learning to work efficiently (see the next paragraph) instead of trying to work lots and lots and lots of hours. 

About efficiency: Modern life is replete with potential distractions, and even before the internet age people found many ways to work inefficiently. If you watch closely, you'll find that, even though filled with the best intentions, many of us lie to ourselves (and others) about how much we really work. Sure, we might sit at our desk for 10 hours a day, but between social media and email and other things, there's a very real danger that less than half of that is really used well, particularly when trying to do solitary, creative work. To avoid this pitfall, and to get the most out of the time we have as mathematicians, it's essential to learn to focus. How do we do that? The best advice I know of is something borrowed from Zen: When you recognize that you're not focusing on what you meant to do at any given moment, gently guide yourself to re-focusing on the intended task. Don't beat yourself up about being distracted, just recognize that you're distracted and return to being focused. If you feel sleepy, stand up for a moment and shake yourself out, maybe get some water or something, and then come back to what you were doing. This is a lot harder than it sounds, but you get better at it with practice.

Finally, at the risk of overstepping my role as a professor, I'm also going to suggest a few non-mathematical activities which I believe positively influence one's mathematics - and energy levels, and life in general - over time, if sometimes in ways that are hard to identify. That said, these are inevitably the things that are the most difficult to do consistently, since we have to squeeze them in between research time and any other responsibilities we might have. Take what appeals to you and do what you can.

1. Read. Especially read well-written, long-form, non-mathematical writing (novels, short stories, plays, history, epic poems, etc), and in different languages. One of the main weaknesses of mathematics students that I've observed is that even very good ones often don't write very well, and the best way to improve one's writing is to read voraciously. Also, I think reading in a foreign language forces you to attend to the way a language is used more than reading in your native language, and I believe that this also helps one's writing, although reading in any language will help. Naturally, if your native language is not English, then reading more in English will help you improve your facility with the scientific lingua franca as well.

2. Exercise. I think this is self-explanatory, but in case it isn't: Exercise, and particularly aerobic exercise, has been shown to help preserve cognitive function as one ages, in addition to reducing the risk of many chronic and debilitating diseases that you definitely don't want. If you're a student, you might not be thinking too much about this now, but you'll thank me in fifteen or twenty years if you take this advice to heart.

3. Learn to cook, and to enjoy cooking. We all have to eat, and unless we're rich or live in a house where someone else cooks for us, most of the time we're going to have to cook for ourselves. If we want to eat well, we have to learn to cook well. It's best to learn to enjoy the whole process, too, particularly since we can't escape it. Also, cooking for other people is a very nice way to socialize. 

Of course, if you do live with someone who cooks for you regularly, it may be less critical (for the moment) that you learn to cook yourself, but I guarantee that whoever this saint-chef is that you live with, they'll be very appreciative if you do learn to cook well and if you cook for them from time to time, too.

4. If you grew up doing dance, art, or music, make time to continue, even if it's sporadic and inconsistent. If this applies to you, you'll already have your own reasons for why.

There are two standard ways to do this. One is by subscribing to email updates, and another is through an RSS feed using an RSS Feed reader client. Personally, I prefer using the RSS Feed. (I use QuiteRSS as my feed reader client, although there are lots of options, some local and some web based. If you choose to use RSS Feeds, you'll have to experiment to find out which client you like best on your system.)

The instructions for subscribing to arXiv emails are here: https://info.arxiv.org/help/subscribe.html

The instructions for subscribing to RSS Feeds are here: https://info.arxiv.org/help/rss.html 

For better or worse, I learned to program under very different circumstances - and, to be sure, I'm still learning - so this isn't an easy question for me to answer. Nonetheless, I'll share my current thoughts on this, as well as give some references below. These are opinions which, admittedly, are ever-evolving, but I hope that what I've written here may still be useful to the aspiring mathematical programmer.

First, if you've come to the question of how to program a computer because you actually need to write some computer programs right now, and maybe even for a project that you'd like to (or need to) finish as soon as possible, then starting with Matlab, R, Python, or Julia are the most sensible choices, and to narrow it down, I'd say choose Matlab if you mainly need to quickly test some computational ideas, R if you need to do some statistics and produce nice pictures, Python if you need a specific Python package, and Julia for everything else. (Julia is much faster than the other three, and very easy to learn, but it's a newer language and it has fewer mature libraries.) Tutorials for all of these are abundant on the internet and you should be able to do some interesting calculations in a few days' time with minimal effort. Nonetheless, I still highly recommend working through the book, Structure and Interpretation of Computer Programs, Second Edition by Abelson and Sussman in parallel with whatever other projects you're working on, in addition to learning Common Lisp and C++ over time. If you don't have access to Matlab, then Octave is said to be a good, free alternative, although I haven't tried it myself.

If your interest is really in computer programming, however, and you're willing to constitently dedicate some time to learning it over the course of a few years, then I recommend learning Common Lisp and C++, the first for its 'code is data' philosophy and as an introduction to functional programming (and because it's great fun), the second for object-oriented programming and because it's widely used, including in scientific computing, and both languages for their different approaches to metaprogramming, in addition to also being good tools with which to experiment with "data-oriented design". What about Python and Julia? They're both excellent languages, and very easy to learn, particularly once you know Common Lisp and C++. However, in my opinion, they're almost too easy to get started in, and it's not that hard to write rather complicated programs in both of them without ever needing to think much about programming style or learning some fundamental concepts, something which can lead to some bad habits which could be difficult to correct (and bugs which could be even more difficult to find). Both Common Lisp and C++ are harder to learn, but that difficulty forces you to slow down and think about design issues and programming practice in a way that (I believe) helps immensely in the long run. (That said, basic Lisp is actually extremely easy - everything is a list! - but becoming comfortable with the more interesting features of the language - that, really, everything is a list - is much more challenging.) Once you become reasonably proficient in Common Lisp and C++, you may decide that you actually want to use (or create!) some other language for your own programming projects. Excellent! By then, you'll have a solid background to build on, and learning a new computer language won't be that difficult at all. While Common Lisp and C++ are, indeed, useful in themselves (yes, even Lisp), the point of devoting time to these two specific languages at the beginning is that, in addition to being useful, I think the process of learning them - and particularly their more advanced features - will make you into a better programmer, often in ways that learning other languages doesn't.

I've listed below some books and other references which have been and continue to be useful to me, roughly ordered by complexity within each section. In addition to some of the more typical references, I've also added three which I'm reading now on "data-oriented design/programming" (not to be confused with "data-driven design/programming"), a relatively recent addition to the ways to think about organizing programs which grew out of the demands of game programming, and one worth thinking about, particularly for scientific and mathematical programming. Indeed, the thing I like about the data-oriented design books is that they present a principled alternative to object-oriented design which can work even in a language like C++, despite the fact that C++ was built around the object-oriented paradigm, and I find this refreshingly liberating. (That said, the style of the third of these books is a little silly, but it contains some interesting ideas and examples.) 

I'll finish with a few comments: First, Abelson and Sussman is excellent, and it should be at the top of your reading list, but if you haven't programmed much before, then I'd recommend reading it alongside either Stroustrup on C++ or else the Seibel and Graham books on Lisp, all of which cover the mechanics of the languages they describe more systematically. Second, although it's not really discussed at the beginning of any of these books, learn to use a debugger as soon as you can, and use it often, even when you don't (yet) see any bugs. In Lisp, too, test everything in the REPL (the Read, Eval, Print Loop) before committing it to a longer program, and take advantage of the C++ kernel in Jupyter to do the same. These two simple habits, (1) pre-emptively using the debugger to understand your code , and (2) testing your programs in bite-size pieces as you write, will help you avoid a lot of problems and write more solid code. Third, while you're programming, get used to making liberal use of the documentation on the web, particularly the Lisp hyperspec and various references on C++ and its libraries. While the books here are indispensable, there are a multitude of technical details that would difficult to cover in a book while still keeping it readable (and which would be even more difficult to remember if they were), but which are useful to look up when you're actively trying to do something. Fourth, if you don't have a project in mind, a nice way to both improve your programming chops and also learn some new algorithmic ideas is to implement algorithms in one of the data structures and algorithms books I've included below. Finally, there are a lot of books in these lists, certainly more than can be read quickly. To begin with, I'd focus on the following four, for the mechanics of programming in LISP and C++: Abelson and Sussman, Stroustrup, Seibel/Touretzky/Weitz, and Graham, and then move on to Michaelson, Fabian, and Weisfield, the latter three in order to compare the functional, data-oriented, and object-oriented programming paradigms, respectively. Also, keep a few algorithms/data structures/numerical recipes books handy for reference. Unfortunately, even that's a lot. Luckily, however, once you get through a large part of one or two of them, you'll already be well on your way to writing interesting and useful programs. For the rest, take your time - and enjoy!

Good luck!

General Computer Programming

• Abelson and Sussman, Structure and Interpretation of Computer Programs, 2nd edition (also introduces Scheme, a Lisp dialect)

Functional Programming

• Michaelson, An Introduction to Functional Programming Through Lambda Calculus

• Okasaki, Purely Functional Data Structures

Data-Oriented Design

• Fabian, Data-Oriented Design: Software Engineering for Limited Resources and Short Schedules

• Nystrom, Game Programming Patterns

• Sharvit, Data-Oriented Programming

Object-Oriented Design

• Weisfield, The Object-Oriented Thought Process, 5th Edition

• Gamma, Helm, Johnson, and Vlissides, Design Patters: Elements of Reusable Object-Oriented Software

Lisp Books and References

• Seibel, Practical Common Lisp, https://gigamonkeys.com/book/ (also on Springerlink) + Touretzky, Common Lisp, Chapters 3, 6, 7, 11, 12 + Weitz, Common Lisp Recipes, Chapters 2,5,6,7

• Graham, On Lisp: Advanced Techniques for Common Lisp, http://www.paulgraham.com/onlisptext.html

• Hoyte, Let Over Lambda

• Domkin, Algorithms in Lisp (on SpringerLink)

• Kiczales et al. The Art of the Metaobject Protocol

• Weitz, Common Lisp Recipes (on Springerlink)

• Norvig and Pitman, Tutorial on Good Lisp Programming Style, https://norvig.com/luv-slides.ps

• Didier Verna, How to make Lisp go faster than C, http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pdf

• Quiennec, Lisp in Small Pieces

• Norvig, Paradigms of Artificial Intelligence Programming, Case Studies in Common Lisp, 6th Edition, https://github.com/norvig/paip-lisp/releases/download/v1.3/PAIP-6th-ed-with-toc.pdf

Useful Lisp Websites

• The Common Lisp Hyperspec, http://www.lispworks.com/documentation/HyperSpec/Front/index.htm

• Lisp-Stat, A Statistics Package for Lisp https://lisp-stat.dev/ 

• The Common Lisp Cookbook, https://lispcookbook.github.io/cl-cookbook/

• Lisp-lang.org, https://lisp-lang.org/

• CLiki, https://www.cliki.net/

• SBCL User Manual, https://www.sbcl.org/manual/sbcl.pdf

C++ Books

• Stroustrup, Programming Principles and Practice Using C++ (Long, but a good introduction to C++ programming if you've only read Abelson and Sussman, or nothing at all)

• Gottschling, Discovering Modern C++, 2nd edition (Faster to read than Stroustrup if you've programmed before, although some topics in Stroustrup aren't covered as thoroughly, or at all. If you decide to read Stroustrup, you can skip this one.)

• Williams, C++ Concurrency in Action, 2nd edition

• Kushnir, Safe C++

• Grimm, C++ Core Guidelines Explained

• Scott Meyers, Effective Modern C++ (also all of his other C++ books)

• Vandevoorde, Josuttis, and Gregor, C++ Templates, The Complete Guide, 2nd edition

• Ellis and Stroustrup, The Annotated C++ Reference Manual

Useful C++ Websites

• C++ Core Guidelines, https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

• C++ Language Documentation from Microsoft https://learn.microsoft.com/en-us/cpp/cpp/?view=msvc-170

• C++ Standard Library Documentation https://devdocs.io/cpp/

• C++ Documentation https://en.cppreference.com/w/

• C++ Info and Documentation https://cplusplus.com/

Data Structures, Algorithms, and Numerical Recipes Books

• Press et al. Numerical Recipes: The Art of Scientific Computing, Third Edition

• Knuth, The Art of Computer Programming, Vols. 1-4

• Cormen et al. Introduction to Algorithms, Fourth Edition

• Sedgewick and Wayne, Algorithms, Fourth Edition

• Domkin, Programming Algorithms in Lisp (on Springerlink)