text:
Should I share my horrible software?
After I had published my paper, some people asked me to share the software that I developed. At first, I was very happy that my paper attracted some attention, and I was happy to share not only the binary but also the source code, case studies etc. But looking at my software, I feel very embarrassed.
My software is just horrible: the source code is just a mess, containing several of my unsuccessful attempts; I have never used design patterns, so duplicate code is everywhere; for simplicity and quick implementation, I often prefer recursions to loops etc etc.
I'm always under pressure to produce new results, and cleaning those code would cost me significant effort.
My question is if sharing this horrible software will give people a very negative impression of me? Would it do harm to my career if the people I share are prospect collaborators, employers, as they work in the same field.

I'm not sure how much i really can help you, but i have seen this video which based on your problem it might encourage you a little. https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&uact=8&ved=0CCsQtwIwAg&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3D0SARbwvhupQ&ei=k2rBVKP8J8P1OPbMgagL&usg=AFQjCNEIXszWW5AeYeh5TglmX2_yHFD7WA&bvm=bv.83829542,d.ZWU Sorry i couldn't help you more, i just wanted to show you this video which i thought was relevant.

Sounds like academic software.

Related: How to share computer code and Best-practice models for “research” code? and the classic: Why do many talented scientists write horrible software?

Dirty secret: most academic software is horrible.  Even the stuff coming out of the Computer Science department.

You could release it under the CRAP license: http://matt.might.net/articles/crapl/

Research generally involves trying a thousand things that doesn't work. If you manage to write code that works in the first few tries, you're probably not doing research but just implementing.

This paper on SIAM journal is a fascinating read and makes a very compelling argument.

Another point to consider: What if some of your conclusions are based on false data originating from a bug in your software? Readers should be able to check for that.

Posting your code in a public place such as GitHub gives you a chance to show how you have incrementally improved your software. Significantly improving the software without changing the results generated from the software is not an easy task and therefore is a skill that is highly valued. You might find posting some of the code to the code review site https://codereview.stackexchange.com/ to be of help here.

@qsphan Just out of curiosity, what's your paper about?

To add to the conversation: http://www.phdcomics.com/comics/archive.php?comicid=1692

@mankoff: Please don't. That license is abysmal. Releasing it under 3-Clause BSD with a big sticker on it warning about the quality would be a much better option.

a lot of non-academic software is a mess too, cf. recent bash bugs...

Even if the code is truly awful - which I doubt - it is still battle tested and debugged which is much, MUCH more valuable than using the latest design patterns etc.  Be sure to add detailed instructions on the underlying platform (Ubuntu 12.04, OS X 10.7 with XCode with libX version Y etc) as there might be subtle differences giving problems, as well as full instructions on how to compile and link your programs.  You probably already automated somewhat when writing it - just jot it down so others can see.

Nothing wrong with recursion unless the programming language doesn't support optimizing it

@Philipp: What worries me more is a situation in which the paper is correct, but the code has a nasty bug in it. In that case, fixing the bug would change the correctness of the answer but not (say) its performance characteristics... so if you release the code, then you risk embarrassing yourself even when your results might not be invalidated. (I've found these kinds of bugs in my own code before.)

It doesn't matter if it is academic or not. http://blog.codinghorror.com/version-1-sucks-but-ship-it-anyway/

@Mark: Most software is horrible, full stop. Not limited to academic, and not a secret really. ;-)

Just to add to this, even scientific software that is used every single day in major applications gets messy and horrible - the code used by the Met Office is still in Fortran and has bits left in all over the place from several decades ago...

@djechlin While occasionally true, "The source of your pressure is your bad coding" is not always generalizable. Unless there was something about my Python skills that was driving the latest Ebola epidemic?

@djechlin Nah, I think it's likely more to do with the people still dying...

@djechlin I'm just noting that the idea that the source of pressure on an academic boils down to bad coding is both profoundly presumptuous, and definitely not generalizable.

Is it possible to work with an undergrad or graduate CS student and have them 'clean up' some of the code?

Suggestion from a programmer: don't keep your unsuccessful attempts as commented out code or in unused classes. Instead, commit (semi-)working versions to source control (GIT) often. Always remove dead code that is no longer needed! If you have to go back to an earlier version, restore it from source control. It's much easier to keep on top of your code this way, because there is much less code to read. Regarding the point that your code is not using fancy design patterns etc: that might be a good thing, keep it as simple as possible, only add complexity where absolutely needed.

Yes, you should.
First, most scientific software is terrible. I'd be very surprised if yours is worse than average: the mere fact you know design patterns and the difference between recursion and loops suggests it's better.
Second, it's unlikely you'll have the incentive or motivation to make it better unless, or until, it's needed by someone else (or you in 6 months). Making it open gives you that incentive.
Potential upsides: possible new collaborators, bugfixes, extensions, publications.
Potential downsides: timesink (maintaining code or fixing problems for other people), getting scooped. I'll be clear: I don't take either of these downsides very seriously.

Most scientific software is NOT terrible.  (I've been making a living working with & optimizing it for a couple of decades now, so I think I have an informed opinion.)  It just has rather different criteria for goodness: working, getting correct answers in practical time, being extensible to the next theory, etc, rather than conforming to the latest quasi-religious design paradigm or language trend.  And for the OP, your "horrible" software might, if cleaned up & commented a bit, be more accessible to other scientists than "good" code.

I'd just add to this that I'd suggest sharing it via Github or similar, which has a vibrant community and makes it easier for people to collaborate, fork your project and contribute to it.

No mention of the elephant in the room, reproducibility?

@jamesqf : I exaggerated for effect, but my thinking is this. Most scientific software is short proof-of-principle, throwaway code. It rarely gets released outside of a small group and is, in my experience, poorly written. Most scientific software that lasts at a reasonable scale is not terrible (I've also worked with some on a similar timescale): it can't be to produce multiple publications. But I'm thinking about "all code written by scientists" here.

@mmalmeida I agree, Github is a conduit for collaboration. The issues & milestones offer a way to track problems & enhancement requests. Before, open sourcing this code, I would also recommend taking some time to clean it or at minimum add descriptive comments to it.

@jamesqf Well, most is terrible. I would also say I have an informed opinion. How code works is not a criterium for "goodness" of code for a programmer, at least the one considered a good one. Correctness is a "must" property. Divergence rate, numerical stability, speed (excluding hardware specific optimizations) etc. are properties of the algorithm the code implements. You can have good code and bad code performing the same. Although I do admit "good" is too vague and often results in misunderstanding. I would say "code quality" is very often terrible. Even if the program works great.

@jamesqf: most scientific software I've come across was not in any kind of source control, and this sounds like another example (or why else are all failed attempts still in there).

@RemcoGerlich:  Well, there's an example of having different criteria for 'goodness'.  I've never yet found a source code control system that doesn't have an obvious major design flaw: checking files out of the system resets their timestamp to the checkout time, not last modification time.  The implementers of these systems obviously think that is a 'good' feature - I've had several user forum arguments about it - but the end result is that I don't use version control unless I'm explicitly paid to do so.

@jamesqf: don't take it personally, but that ranks pretty high on the list of dumb reasons not to use source control (besides, with "normal" VCSs it takes a script of maybe 20 lines to "fix" this "major design flaw").

@jamesqf I have never seen the file timestamp matter, at all. The only case I can even think that it affects anything is make, and when you have a clean checkout, there's no binaries to check if they need rebuilding. The benefits of source control are obvious: tracking changes (which is incredibly valuable in practice), protection against loss, easier sharing with colleagues, and enabling people to work on the same code base simultaneously. Your problem seems extremely obscure, and I would wager that those benefits alone outweigh the downsides of your particular use case

The Sage project (http://www.sagemath.org) is a living example of software of math research that is not horrible, though there are constantly design discussions and complaints about coding practice.

@jpmc26: How can the file times not matter?  Perhaps if you only work on one set of code, they aren't that important, but if you have many different codes, each with many files (typical of scientific software, in my experience), it's really useful to be able to see at a glance (by doing e.g. 'll *.[chyl]' exactly which files you worked on when.  Now I do agree that a CORRECTLY WORKING source code control system would be a great tool to have.  The problem is that the !@#$s that build them absolutely refuse to implement this really simple fix.

@jamesqf Commits (the core of most source control systems) have timestamps. In git for example, create a commit for each modification of your data files, for instance "reran simulation using new code from revision XXX". For each modification of code, make a commit that says "improved code in XXX for reason YYY". Then, instead of having a "last modification date" for your files, you get a nice list of commits, along with when they occurred, exactly what files were added/modified/deleted, and a helpful comment. There is no fix to be done, you simply don't know how to use source control properly.

Not to mention that if you really need this feature, any source control software lets you ask it when a file was last modified. In fact, most will go beyond that and tell you which commit last affected a file, giving you the context of the change in addition to the timestamp, which is way more helpful and practical than "oh, I last modified this file 26 days ago, I better look in my .txt file see what I did there... oh, wait, I forgot to write it down, oops".

@jamesqf Thomas nailed it. You look at the commit history to see what was changed, when, and how. With a diffing tool, you can even see a line by line comparison of the previous and current versions of the files (or even two previous versions). Your source control becomes the authoritative source for this information. This also makes it much easier to share the history with others, something I think would be valuable to the academic community. On something of a side note, you should usually put unrelated code bases in different repositories. This allows you to view the histories separately.

@Thomas: Sorry, but this is the same line of BS that I get from the developers: either work the way we want you to work, or get lost.  Sorry, but I have TRIED working your way, folks.  It does not work for me.

@jamesqf In that case, it'd be pretty easy to write a hook for most VCS systems to make it work the way you want. No reason not to have it both ways.

The reason the timestamps are reset is because if you get a changed file in your checkout that was changed yesterday, but you did a build this morning, most build systems would not pick up the change (because the timestamp was older than the build artifacts).  With the timestamp set to time of checkout, the builds will work.

@jamesqf Like it or not, using VCS is a pragmatic obligation.  If you don't use VCS, many potential collaborators (including almost all experienced programmers) will find it very difficult to take your project seriously.  And the impetus for those "quasi-religious" design paradigms is the pursuit of an ineffable elegance that makes the project extensible to the next theory and accessible to others.

@jamesqf There's a reason 'the developers' keep telling you that - it's because they're right. Also, yes, most scientific software is indeed pretty bad, including my own. I write code much differently when I'm writing it for a production project that I intend to actually maintain versus when I'm writing it as a proof-of-concept to run some simulations for a research paper. I've seen the same from nearly every piece of research code I've ever seen. There are a few exceptions, but they're just that: exceptions.

@jamesqf "How can the file times not matter? Perhaps if you only work on one set of code, they aren't that important, but if you have many different codes, each with many files (typical of scientific software, in my experience), it's really useful to be able to see at a glance exactly which files you worked on when." Uh... isn't that exactly the problem version control is meant to solve?

@jamesqf If using source control actively causes you problems, you probably just need to rethink your workflow a bit. If you can narrow down specific problems you're having, questions about how you can approach them differently would most likely be welcome on Programmers and StackOverflow. Give it a shot. You may be surprised at how much it improves your experience. I'll also say this: if you tried git, that system is really hard to learn. You might have an easier time getting started with SVN, which is far more intuitive and isn't as demanding on your workflow. SVN is far better than nothing.

As someone who works in software, no code is ever perfect. But don't let perfection be the enemy of “good enough”. As others have said, someone may well find your software useful. If you can take the time to clean it up a little and add some comments or a README so much the better :)

It's not just scientific software that's terribly written. I've been developing in software shops and manufacturing firms alike for ten years now, and I promise you the code isn't getting any cleaner. Anywhere. Writing beautiful code is very hard. It's like writing a book. The first draft usually sucks, but it will actually tell the story. To sell a book you have to make it beautiful. To please your stakeholders in the plants, they just need it to tell the story.

This comment thread has turned into an off-topic conversation about VCS. Please take extended discussion to [chat].

I've fooled around with GATT (a program for timetabling using genetic algorithms, the testbed for a series of PhDs in Scotland). It worked, but the code contained lots of commented out code, unused functions (from previous theses), over-general code (to accomodate different attempts) and very narrow, hard to adapt code side by side. Compound with convoluted data structures, which are sometimes kludged into non-designed uses. Cleaning that mess up would have been a huge task. But it was fine as it was for it's framework for exploration rôle.

I would clean it up a little and share it.  I've released a lot of code over the years, and also not released code for the reasons you give.
Go through it and and comment it, at whatever level you can.  Leave in "failed attempts" and comment them as such.  Say why they failed, and what you tried.  This is VERY useful info for people coming after you.
Make a README file that says you are releasing it on request in the hope it helps someone.  Say that you know the code is ugly, but you hope it's useful anyway.
Far too many people hold things back because it isn't perfect!

I can't endorse leaving in failed attempts. You should use version control instead. Including brief comments that explain why the initial attempt failed is fine, but including the actual failed code may be actively harmful.

@DavidZ On the contrary, show it. If you use version control, people can see previous variations of your work, which is far from being useless. But if like here you don't use VC, then don't remove failed attempts. Put them in another file with appropriate comments. How harmful could it be?

@coredump It can make the entire program virtually incomprehensible. I've seen this happen. If you don't use VC, start using it. The only way I could support a recommendation not to remove failed attempts is if you're forbidden from putting the code in VC for some reason which I can't imagine, and it's essential to see the previous code in order to understand what the current code does (which probably means the current code is bad too, though I admit that exceptions may exist).

@DavidZ Sorry, but "Say why they failed, and what you tried" is a good advice, IMHO. If your code is messy and/or if you are not accustomized to software engineering practices, please leave it as-is and comment as much as you can. Removing useful informations could make things virtually incomprehensible. I've seen this happen ;-).  Okay, so maybe there is a middle-ground between showing all the horrible things that were attempted and leaving useful traces. I think "I would clean it up a little" is also a good advice.

@coredump Saying what you tried in the sense of including failed code is good advice when you're asking for help, but not for writing the program itself.

I don't see how a failed code can help except for obfuscating the working code (unless errors are clear and e.g. "much simpler code, but works only for positive entries"). But what is good to make comments (e.g. "it would be tempting to use arrays, but they won't work for non-unique entries").

If the code is an implementation of a research paper, and he tried to implement it different ways, my assumption is that the solution is non-obvious.  In research, someone else might see the working code and think "I could do this better this way" which might be one of the ways the author tried first.  We do poorly in CS at sharing our failures, which leads to lost work sometimes.  That's my point.  Whether it's a good choice in_this_ case can't be known without seeing the code, but I know plenty of other profs who share this view

Sharing failed attempts is different from mixing broken code into the working code, which doesn't accomplish anything except confuse and prevent understanding.

Yes!  Especially if your paper is e.g. about a new/improved algorithm that you've implemented, or you do significant non-standard data analysis, or basically anything where reproducing your results means re-implementing your software.
Papers seldom have room to give more than an outline.  I know I've spent (= wasted) much too much time trying to implement algorithms from papers that left out critical (but not strictly relevant to the paper) details.

Very true comment about reproducibility, particularly, the second para.

@E.P: Yes.  I'm sorry, it's my dystypica cropping up again :-)

¿You think your code is messy? I have seen (and attempted to work with) code that gave me nightmares:

Five levels of if True nested, scattered at random places through the code.
Create an array of zeroes, convert it to degrees, take the cosine, and back to radians. Then, throw away the result.
On a software under heavy development, the list of "supported architectures" is so ancient (and they do say themselves) it would difficult to get your hands on one of these computer nowadays.
Features broken or modified several versions ago, still recommended in the docs.
Code that goes from using a standard format input to some format of their own. How to generate it? No one really knows, and the developers handwave a response.
Releases that don't even compile. (Did you even test it?)
GUI menus that you have to access in a specific order. Otherwise, you get a segmentation fault and have to start from the beginning.
Hard-coded paths scattered through the code. So you have to shift through several files finding and changing all the occurences of /home/someguy/absurd_project/working/ to yours.

And, my personal favourite, a certain program of thousands of lines of code, only used comments to eliminate random bits of code, except for one:

Here we punch the cards.

Still, no idea what it was doing.
And this is only leaving outside the classical good practice stuff, like one-letter variables all over the code, algorithms not specified anywhere...
If you are concerned about the quality of your code, it probably means you care enough to have made it better than the average. If you wait until the code is clean, it may never get out, and your scientific contributions will be partially lost.
In my opinion, the important things that you should care about, in order, are:

Input and output formats. Use standards when available, make it simple when not. Make using your program as a black box easy.
Commented. Brief descriptions of the functions, quick overview of the algorithm.
Legibility. Using idiomatic code, good variable names...
Structure. This is easier when you know what you want to do, that is usually not the case in research code. Only if there is interest in the community, you may consider refactoring it.

So, release your software whenever you have 1 (2 and part of 3 should come in as you are writing it).

+1 but I would also add appropriate error handling to the list of important points (all too often missing from rushed research code). In particular, take special care with any error that could affect the output silently - is that function return value the real number zero or a default-return-on-error zero? (Don't plot those!) Also, errors should be handled, but not over-handled. I've seen naïvely written "bulletproof" code that could silently recover from garbled input data and go on producing output without complaint. A crash may be frustrating, but inaccurate results can be a disaster.

Re your point #3, and someone else's comment about single-letter variable names: in scientific software, you are often more-or-less directly translating math equations to code.  If the variables in the equations are single letters, it makes perfect sense to use them as variable names in the code.  And, as I admit I should do more often, include LaTeX for the equations in a comment.  For the rest, you haven't really lived until you've tried to debug FORTRAN 66 with computed & assigned GOTOs :-)

+1 for answer from @imsotiredicantsleep. Code that silently fails is difficult to work with. If its going to generate inaccurate results, make sure that it generates a warning or throws an error instead.

You're asking whether sharing low-quality software would give a bad impression of you. I think that sharing software at all gives a good impression.

As a computer scientist, I like when colleagues make their source code available. It makes me more likely to look deeper into their work, maybe contact them, maybe cite them, because there is one more artifact to interact with (not just the paper, but also the code).
When a paper reports a result that is "proven" by source code, but the source code is not public, I'm often wondering whether the result is real. Looking at the source code (or just the availability of the source code, without ever looking at it) can convince me.

So sharing your source code, horrible or not, would always give me a good impression of you.
Now, if you want to impress even more, it would help ...
... if you react to issues or pull requests on a site like github, that is, when I see that others try to contact you and you react.
... if your code contains a readme file which relates the claims from your paper to the source code. This way, when I read the paper and want to know more, I can use the readme to jump to the appropriate place in the code. Typical phrases from such a readme could be: "The algorithm from Sec. 3.2 of the paper is in file algorithm/newversion/related/secondtry/foo.c" or "To repeat the run with the small dataset described in Sec. 2 of the paper, run "make; make second_step; foo_bar_2 datasets/christmas.dataset. This run takes about 2 days on my laptop".
You might also be interested in Matthew Might's CRAPL (Community Research and Academic Programming License), available on http://matt.might.net/articles/crapl/. It contains this term: "You agree to hold the Author free from shame, embarrassment or ridicule for any hacks, kludges or leaps of faith found within the Program". It is not clear to me whether this "license" has any legal effect, but the intent is clear: Release your ugly code, and don't think bad of the ugly code of others.

Tangentially related, I will addresses how to share the software given your concerns (not should you share the software which you already have an answer for).
Putting the failed attempts in version control effectively means that nobody will ever see them. The way I handle this is to put each attempt in a method, and each failed attempt in a separate method:
def main():
    get_foobar(x, y)

def get_foobar():
    return x**y

def get_foobar_legacy_1():
    """
    This attempt did not work for values > 100
    """
    return x + y

def get_foobar_legacy_2():
    """
    This attempt did not work on Wednesdays in September
    """
    return x - y

As per the comments below, it may be a good idea to put these methods in a separate FailedAttempts or BadIdeas class. This has the nice effect of compartmentalizing the various stages for the process as per actual need. I find that computer programmers often have a knack for when to break logic off into a method and when not to, but computer scientists often do not. This approach helps the computer scientists break off into a method when necessary.

That's not part of any best programming practice. Supposedly unused code should actually be commented out, lest some code keep calling get_foobar_legacy_43. And when it becomes clear it is broken, it should be removed if possible.
If understanding some failed attempt is worthwhile for readers of the current version (which happens), you should put it in version control and add a comment pointing to the relevant commit ID — possibly with a permalink.

@Blaisorblade: You are right, if the goal is to develop a well-functioning application then unused code should be removed, either via commenting or by relegating it to the depths of the source control software. However, that is not the goal stated by the OP. The OP needs to have his failures documented. This is the way to do that. Though I do see value in your point, and perhaps each method could be commented out with /* */ block comment syntax. Interestingly, one of the few languages that do not support block comments is Python, the language that I used for pseudo code above.

@Blaisorblade: An even better solution may be to have a separate file, class, or directory which encompasses the failed attempts, separate from the mail code of the application.

Documenting failures is not stated in the question, and I think it's a good idea in few cases (say, for interesting but failed attempts to achieve the paper's contributions). "Leaving in failures" seems to come from another answer—where people had a strong debate: http://academia.stackexchange.com/a/37373/8966.

Of course you should share the source code.
Academically speaking, a software-based result using code that is not readily available is not very valuable, as how would other people be able to verify your claims, if needed? Do you expect them to program on their own for this purpose?
Sharing binaries only is much less valuable, and often leads to nightmares for people trying to run them.

I think you should share it. First of all you should do some basic clean up. (e.g.: no earlier code which is not used anymore; no code in comment; valid way of commenting and so on) Moreover if you put some "to do" in the code others can see that you were out of time and they can see your intentions. (e.g.: todo: this should be changed to enum) I also think you should share the most important part of your algorithms. When I share a code I have never share unimportant parts. Everyone can handle reading/writing of files, communication between threads, gui and so on. But don't share unreadable code. It would make no sense. So I think the middle way is the best as many times. :-)

Cleaning up is good in principle. However, if one waits for a good time to clean up, that time may never happen. I'd suggest putting it in a version control repository on Github or Bibucket or similar right away, and cleaning it up as and when you get around to it. Anyone downloading it will mainly be looking at the HEAD, anyway.

Lots of points in favour of publishing the code have been named in the other answers, and I completely agree with them. Hence, as the basic desirability of publishing the code has been discussed, I would like to supplement this with a checklist of further points that need to be considered. Many of these issues probably appear in virtually all academic software, so even if you cannot respond "This does not apply to my project." to all of them, you should at least be able to respond "This is a concern, but we can deal with this issue by ..." before publishing your code:

Are you allowed to publish the code?

Can you guarantee you only used code fragments that you are allowed to redistribute? Or did you possibly use code from non-open sources that you may use for your own internal software, but that you are not allowed to publish? Can you guarantee all the code that you used is allowed to be published in one complete package? License compatibility is a non-trivial issue.
Can you even reliably find out? Did you outsource any parts of your coding work, or integrate unpublished code from elsewhere? For instance, did you supervise any students during their graduation theses or employ any student research assistants, whose work was based upon your research and thus their code was added to your codebase? Did any co-workers contribute code to your codebase? Did they get some of their code from students? Did all of these people involved properly pay attention to licensing issues (if at all they had the knowledge to make an educated judgement about these licensing questions)? Can it even still be determined where which parts of the code originated? Do the people who contributed each part still know? Are they even still "within contact range" for you?
Was the code developed during working time based on third-party funds? If so, do the funding contract terms allow to publish the code, or do they include any requirements that software created within the funded project must be shared exclusively with the project partners?

Do you have sufficient resources (time and otherwise) to spend the effort to clean up the code and its comments in a way that it is still meaningful, but does not provide any information that must not become public?

Do you have any comments giving away who worked on the code? Were the people who contributed code officially allowed to work on the respective research, as per their funding? (Software developers are well aware that teamwork and reuse of components are core aspects of software development. Funding agencies, unfortunately, are typically very unaware of this and assume that if developer A is funded from project X and developer B is funded from project Y, A works exclusively on X and B works exclusively on Y, and revealing that, w.l.o.g., A spent only half an hour doing something that ended up in project Y could lead to severe consequences, such as reclaiming parts of the funding.)
Does anything in the published data give away any information about the particularities of how the work was done that must not become public? This is especially important if the whole commit history in a VCS is going to become public (or, practically, means that the commit history should never be published), but may also play a role in other situations. For example: Was any work on the code done outside of the officially assigned working times (e.g. during weekends)? Do working times give away that you worked more than the legal limit of your country for working hours per day? Do working times give away that you did not adhere to legally required breaks? Do working times give away that people assigned to other projects made contributions? Do working times provide any reason to distrust any of the statements you made otherwise about your working times (e.g. in project success reports that required a detailed assignment of working times to pre-defined work packages with certain maximum allotments)? Does anything give away that you worked in situations where you should not have been working (e.g. during a project meeting)? Does anything give away that you worked in locations where you should not have worked (e.g. from home, when your contract does not allow you to do home office, e.g. for insurance-related complications)?
Is there any secret information in the code, such as passwords, user account names, or URLs that must not be publicly known (because the servers are not laid out to handle larger amounts of users beyond a small number of select people who were given the URL for the test setup personally)?

Is the code usable by anyone else?

Will the code run, or does it require extensive configuration efforts? Can you spend the effort required to explain what configuration is necessary?
Can the code be compiled? Have you used any unofficial modified or custom-built compilers that are not publicly accessible? If so, does the code add anything beyond what may already be provided as a pseudo-code algorithm in your papers?
Does the code require any external resources? Will the code only be useful if it can access servers, libraries, or datasets that you cannot publish along with the code for one reason or another? Can at least a description of these resources be provided, or are their interfaces subject to some kind of an NDA?
Does the code make any irreversible changes to systems it runs on? For example, does it automatically change any system configuration (such as overwriting the system search path)? Does it perform any low-level access to hardware components that could, in certain constellations (that you internally avoid in your test setups) cause permanent damage to any components? Can you reliably warn users of the code of such possible unwanted side-effects?

You consider funding agencies or employers sifting through commit logs to determine legal consequences. That's a clear theoretical concern. So, do you have any evidence of it ever happening?
My limited experience with funding agencies, ERC grants in particular, is in fact the opposite, even though that doesn't count.

@Blaisorblade: "So, do you have any evidence of it ever happening?" - the motivation for the funder to discover possibilities to reduce their costs seems clear, and the possible repercussions that might be enforced (paying back some of the grant money) are sufficiently severe (losing previously granted money is probably one of the few things that can get uni employees into severe trouble with uni administration) that it seems reasonable not to open up this possible attack point in the first place.

Talk to some of the professors in your computer science department. See if any of them are looking for a project where students can clean up messy code to make it more presentable.
For the students who revise the code, this can be a good learning experience. What happens when coders program with a results-first mindset – or results only mindset? They get to see that first hand. They also get to apply some of those best practices they've been learning about. And they might be motivated to do an especially good job knowing that other professionals are already interested in seeing the code.
A professor might even make this into a contest, where teams of students all take a crack at revising the software, and the best result is shared with the rest of the world.
If their refactoring efforts flop, you're no further behind than you were. If that's the case, disclaimers are a wonderful thing. Simply share the code, but add a caveat: "It isn't pretty. When I wrote this, I was trying to get my research done – I wasn't thinking it would ever go outside my computer lab. But you're welcome to take a look if you really want to."

I like this, I would have loved to had this chance when I was at Uni. Reading and understanding other people's code is a skill, and it has to be learned.

Of course. The only way you are going to get better at writing good software is to get feedback (all types). If you're afraid of feedback then you won't really get very far. The three basics to writing great software are practice, practice, and practice.
Now on as to the question of whether it would harm your career if people found out that your software writing skills aren't top notch. I think that no, on the contrary, they would respect you for your academic integrity. And would look forward to collaborating with you.

You may just push it to GitHub and try to maintain a project in case other people who are interested about your project can access your code easily and maybe they can help to improve your code.

+1 - This is the first thing that sprang to my mind. It is a safe place to store one's code, better than having it lurking on a hard disk or USB stick that will die or get lost. In addition, the code is easily maintainable as well as any code changes being tracked, and, as you say, others can collaborate and contribute (provided the right access settings are chosen).

A reason that no one has mentioned why you should share your code is that you might find someone who is interested in collaborating with you, but who is prepared to spend more time cleaning up the code and making it work on different systems, etc. than on doing the innovative development that you have done.
Lots of people find this kind of work very satisfying and if your code is genuinely useful to them they might be happy to do it. In any case, you might find that getting feedback from people who have tried to use it, but need some kind of help, is a good motivation for you to make it more maintainable/easier to use and understand.

Yes, you should. After all, the Linux kernel source code is quite a mess and that haven't prevented many professional developers from studying it and contributing patches and additions to it. Remember also that the Linux kernel is the base of the operating system that runs the fastest and most powerful supercomputers and most devices in the world.
P.D: Linus Torvalds, the guy who invented the Linux kernel have a very profitable and successful career which have not been affected negatively or harmed in any way by the fact that the Linux kernel source code is messy.

You should definitely share your code.
For sorting things, make regions of the same parts of code like make a region of a failed attempt, and explain why it failed. Also, if you develop in Visual Studio, install the “CodeMaid” extension from Extension Manager and clean your complete solution. It will remove spaces and also remove unused references making most of the things look better.
If you develop in C# then share your code with me. I can also help you with sorting things out :)

@PeterMortensen: Please add links only, if there is a reasonable chance that somebody wants to click them.

@Zuberi005 is the only person to offer an automated solution to help clean up the code, and the only person to personally offer to help to clean up the code. And someone downvoted? Shame on them!

Share it if you want to, don't share it if you don't want to.  I know this sounds snarky but I think there is too much pressure nowadays to "share everything" and people will try to make you guilty for not sharing, but really you have no obligation to share anything.

Reproducable results are one of the cornerstones of the scientific method. And that requires sharing. You comment is akin to saying "... but really, Scientists have no obligation to adhere to the scientific method."

Sure, sharing may be optional outside the scientific community, but it sure is not optional inside the scientific community.

@Contango Yeah that's a fair point if releasing the software helps to reproduce the results.

@JeffE I didn't share anything, what are you talking about?  I find your message cryptic.  If you wish to be understood, please be a bit more clear.

You shared your opinion, of course.

Put up a disclaimer that the code is provided "as is" with no promises of support, etc. And then share the code.
Case study: Turning a cloud of isolated points into a watertight surface is an extremely important practical problem, used everywhere from robotics to computer vision to processing data from 3D sensors like the Microsoft Kinect.
Poisson surface reconstruction is 7 years old and has long stopped being the state of the art for solving this problem. But everybody still uses it to this day. Why? Because the author released the code and it has since been incorporated into a bunch of popular geometry processing libraries. The paper now has over a thousand citations.

Yes.  You should release your code, probably under the CRAPL license.  The goal is to build a better future - and your lousy code will help people do that.  A caveat is that you should document how to successfully operate the code well enough for someone to have a decent chance of reproducing any published results.
And, don't worry - one bit of research code I worked on had been developed by 5 postdocs of indifferent programming ability for a series of projects over the course of about 8 years.
The list of global variables (just the names) was roughly 4 pages.
Roughly one third of them were used to set default behavior to change the functionality that functioned at a given moment. Another 20% were parallel data structures - meaning that they stored approximately the same data - and therefore functions in the code pulled from the data structures more or less at random.  Yes.  They were sometimes out of sync.  And sometimes needed to be out of sync.
There were roughly 50 undocumented versions, stored in random portions of the group's server - each of which served at least one specific purpose - and only one admin kept those specific purposes in his head.  It was more common than not to have people using the 'wrong' version for a given purpose.
The use of incredibly complex recursive procedures to, eg, write a file, was standard.  Seriously - a few thousand lines to save image results.
Oh, and the remains of a butchered attempt to solve a memory leak (actually an invisible figure) by never creating a new variable.
Oh, and the database, that lovely database.  About half of the data was unusable owing to (a) database design errors (b) data entry errors (in automatic programs).  The code to retrieve files from the database was several hundred lines of logic long...  The database itself was also kind enough to contain many copies of the same data, much with broken links between tables.  Constraints?  No.  I watched a statistician proceed from disquiet to fear to tears to quitting within a month of being entrusted with the database...
There were somewhere between 0 and 1 ways to operate the software and retrieve correct results at any given instant...
And yes, there were gotos.
Oh, and in an effort to ensure opaque and nondeterministic operation, a series of computations was performed by calling GUI buttons with associated callbacks.
Approximately 90% of any given function was, quite reliably, not relevant to the result or to debugging of the result - being composed, rather, of short-term projects inserted and then never removed.  Seriously - I wrote a feature complete version that actually worked that was 1/10th the size...  Significant fractions were copy-pasted inserted functions, many of which differed from each other.
And, no Virginia, there is no documentation.  Or descriptive variable names.
Oh, and the undocumented, buggy,  dlls and associated libraries - generated using code that no longer existed.
All written in Matlab.  In terms of Matlab coding practices, assume that copious use of eval would be the highlight of your day.
Seriously, your code isn't so bad.
That said, if you've done something actually useful, it might be career-enhancing to release a cleaned-up version so that other people will use and cite your library.  If you've just done something, then reproduction is probably as far as you'd be well-advised to go.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Should I feel bad for applying to two postdoc positions?
I'm a finishing PhD student in math. I want to stay in academia so I am applying for two things:

A year-long postdoc position
A 6 month postdoc position

I have been in contact with two professors regarding the two options and am going to send the application forms off today. But I feel bad because suppose I get job offers for both the positions, then I'll have to say no to one of them. Then they will get annoyed at me for wasting their time and will probably never want to work with me on anything again. Both are highly respected so it's doubly bad. What should I do?
Edit: the applications will be decided by a committee, not the professors concerned. Both professors are happy to work with me. I'm in the United Kingdom.

Suppose you get offers from none. Go for it, man.

An important thing to note is that they are likely interviewing multiple people for the position. They are not wasting your time by possibly choosing a different candidate in the same way you are not wasting their time by possibly choosing a different job.

@WilliamForcier Sorry I think I was unclear, please see the edit.

Indeed, do not apply for two postdoc positions — rather, apply for ten.

Maximize your chances of success. You can be sure that your target positions are likely to have more than one applicant.

Would you think they have wasted your time if they don't take you? It works both ways.

Yes, you should feel bad. But not for the reasons you think – instead, because you're depriving lots of other professors from having more applicants to choose from. Apply for every job that you have the skills to do and that you would accept an offer for.

Please say something about what part of the world you are in, or at least what part of the world these two jobs are in.  I am confused about how you could only be applying for academic jobs now (mid-March), let alone just two.

Only two? I applied to fifty (and that still probably wasn't enough).

You're finishing a PhD and you're really asking this question?!

Everyone who is hiring knows that applicants are applying for multiple positions. This covers everyone from McDonald's to Harvard. It's expected. They will get multiple applications and will only take one, so you must apply to multiple positions to have a chance of landing one. Unless you have an offer in hand which you have already accepted when you apply for another position, you haven't done anything wrong. I'm surprised you've only applied to two.

Is this true for Maths where most postdoc searches are very formal? If you approach someone individually about the possibility of a job, the informal and personal nature of it seems to make it a little different.

Even if they helped me a bit with the research proposal? I think you're right as the sensible thing to do is to apply everywhere, but still.

@StrongBad, I don't know about mathematics, but I suspect it's true regardless of the level of formality. If you are working directly with someone that you know well, it might be fruitful to be open with them about the other things you're exploring. Nothing is settled until you have an offer in hand and accept. If you work with a prof directly on a postdoc fellowship proposal, and it's not funded, what then? If the prof doesn't decide who gets in, but a committee does, then OP ought to have been working on a backup plan. The more contingent the job, the more plan Bs they need.

@Young_Student, unless the proposal is only a formality and is guaranteed to be accepted and funded, what ill you do if it's not? I would be pursuing multiple backup options until you have accepted an offer. I would be as open as you feel comfortable being with your closest possibilities about what you are doing.

@StrongBad: Yes, it's definitely true in mathematics (at least I can speak for the US).  Employers are well aware that applicants are applying many places and may get multiple offers.  If an applicant declines an offer to accept a different one, the declined department is disappointed but not annoyed; it's just business and they will make an offer to someone else.

@BillBarth I think you're right. I think I should say to them "I want to let you  know that I also applied for [blah] because I may not be offered this job (obviously). I hope you can understand etc etc. and I am grateful for your time in helping me prepare the research proposal."

I'm amazed and horrified by the idea of applying for only two postdoc positions in mathematics, one for a year and one for six months.  You should talk with your advisor and other senior mentors about this as soon as possible.  Maybe your personal situation is radically different from what I imagine (for example, I have no idea what country you are in), but it sounds like you are doing something extraordinarily risky.
For pure mathematics in the U.S., it's common to apply for fifty to a hundred postdoctoral positions.  Applying for ten is a mark of great confidence (or foolhardiness), and applying for two is almost unheard of.  Nobody would be surprised or upset to learn that you had applied for other jobs.  Instead, they would be unhappy to learn that you hadn't.  That would make them wonder whether they had somehow miscommunicated the odds of being hired, and whether they were about to play an unwilling role in damaging your career.

The applications will be decided by a committee, not the professors concerned.

This is a key factor.  It's hard to imagine that you are the only one to apply, or the only one to receive positive feedback from a potential mentor.  In fact, you might not even be the only one to receive positive feedback from this specific mentor.  (It's common to tell several people that you'd be happy to work with them if they are selected by the committee, even if the committee will choose at most one.)  In other words, by default you should assume you won't get either of these jobs.  Maybe you'll be lucky or you have an exceptionally strong application, but it's safest not to count on this in your plans.
I should note that I'm a little puzzled by two aspects of your question.  Applying at the end of March would be absurdly late in the U.S. system, and a six-month postdoc would hardly be desirable at all except in conjunction with another job (or if you graduate in December).  This suggests that you may be working in a very different system from the one I'm familiar with, in which case you should seek local advice or be very explicit about your circumstances.

+1: This is exactly what I thought, namely "I wonder where in the world the OP is to be contemplating this strategy for as long as it took to write the question."

@usεr11852: On the contrary. Positions in mathematics receive hundreds of applications; often nearly a thousand. The committees must go through applications quickly and so no matter how good a fit you are, your chances of being noticed are pretty low. To have a decent chance of being accepted anywhere under these conditions, you need to apply to dozens (or ideally hundreds, really.)

There are much more than 100 postdoc positions in pure mathematics in the U.S. each year (not all at prestigious universities, of course, but there are already 50 flagship state universities, and most have math postdocs).  It's not like postdoctoral positions in science, where it's important to find a great match with an advisor who needs your particular skills.  Instead, most of these positions are open to applicants from any area of math and require a lot of independence on the part of the postdocs.  Some fits are of course better than others, but finding fifty tolerably good fits is easy.

Thanks. I am in the UK, and the 6-month postdoc is desirable to me because it is on a very interesting topic. I agree my situation is unusual but this is because I want to stay in the UK (at least until I learn a foreign language) and there aren't many postdocs in PDEs.

When I was in my last year of PhD in math, I applied to 136 positions. Any place that approached me first asked if I was still interested before drawing out paperwork, etc., in order to see what has happened on my end of the job market. Jobs are not journal submissions and you need to take care of yourself.
In the end, I had multiple offers and when I said no to the offers and told them where I was going instead. All institutes were understanding and some even invited me to come speak instead of taking the job. A few told me to contact them when I next went on the market.
Do what is authentic. If you can see yourself taking a position at a place, then you should apply. The minute you have a job assured to you and that application would not lead to a job you'd take over your confirmed job, you should withdraw immediately. If you follow this process, then no one can be reasonably upset with you in this field.

136 positions! wow! Can I ask what was your the area of your PhD?

Algebraic Geometry. A lot of the jobs were general and I applied in N America and Europe. Oddly enough, I got and accepted the first of the 136 to which I applied.

@JustChill As far as I understand, this is not a big enough number to be a serious outlier, at least in th US (not sure what the average actually is).

@TobiasKildetoft I see. I am not familiar about how things work after PhD studies, and that is why I got surprised. Is there any average region of values for numbers when it comes to postdoc applications (at least in the US)?

@JustChill: 136 positions is a somewhat large number (it would be hard to apply to this many postdoctoral math positions in the US alone, for instance), but it is the right order of magnitude...very much unlike 2.

Hiring decisions are difficult for everybody. There's no reason to feel that if you turn someone down, you've "wasted" their time. The only reason to do so is if you would never have taken the position under any circumstances. Even then, using one position to improve your standing and options for another position is considered an acceptable strategy.
The key thing will be to make sure you treat everyone fairly and openly. So long as you do that, nobody will be too disappointed. (And if they are, they'll get over it with time.)

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
How long should a cover letter be when asked to include statements of teaching philosophy and research interests?
I am a PhD graduate applying for teaching (assistant professor) positions at smaller liberal arts colleges. I understand that generally cover letters should not exceed 1 page, especially when applying to large research universities. However, are longer letters acceptable when applying to smaller schools? Again, the job posting requests that statements of teaching philosophy and research interests be included directly in the letter. If more than 1 page is ok, how long is appropriate?

I have recently encountered similar postings, and have decided for me that I will just append research and teaching statements as appendices to the cover letter rather than writing a single, insanely long, cover.

I'm not at a LAC, but from my impression from reading a bunch of letters is that 1.5-2 pages is not uncommon.  At research universities, the people who don't care just won't even look at your cover letter, so it doesn't matter if it's 1 page or 2.  I'm not sure that I would follow @xLeitix's approach if the school asks for both separate teaching and research statements and for these to be covered in your cover letter.

For readability, it is certainly preferable to append.
If you feel your cover letter is a little skimpy, I suppose you might put something autobiographical in the cover letter, that was perhaps a little to personal for the actual statement.  For example, "my teaching philosophy was largely developed during my year as a VISTA volunteer teaching in ...."  (That's just an example -- your situation could be completely different.)
The cover letter is a good place to tie the threads together of the various portions of your application, to show yourself as a whole person, to project your personable qualities, and to get the reader interested in learning more about you.
I think you're right to keep it to one page.

You should follow the directions on the job ad. This is even more crucial at smaller schools, which often feel that applicants treat their applications as a "backup" and ignore their requests.
In my field, most cover letters are 1.5 to 2 pages. They include 1-2 paragraphs on teaching and 1-2 paragraphs on research. These will be the highlights of your statements. At a teaching-intensive school like a liberal arts college, you would discuss the teaching first. You should also have a paragraph somewhere which states why you are especially interested in their school. This paragraph should demonstrate that you understand their student body. I think you should aim for 2 pages here, given the requests.
In this case, I would not append your full statements. This is not following the directions and will irritate the readers. Perhaps you could consider mentioning in your closing paragraph that your full teaching and research statement are available on your website. If you are contacted for a first round interview (or have other communication with the hiring committee), you could also offer to send your full statements via email at that time.

authors: 大象永久伊园甸免费_大象永久伊园甸免费无跳转入口

authors: 尹甸园2023永久免费_尹甸园2023永久免费-高清完整版

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
Uncommon requests during job interview negotiations
I'm curious about how common it is to negotiate for requests/demands that are not necessarily directly related to salary, research, or teaching load during the job hiring process in academia.
Some potential examples that come to mind:

Coverage of school athletic facility fees
Parking pass / daily commute costs (e.g., bus fare)
Financial assistance for relocating for job
Specific holidays (e.g., lesser-known religious days)
Keys to restricted areas not pertinent to job (e.g., access to music rooms for the professor that used to be an active musician)
Coverage for continued learning in unrelated field (e.g., philosophy or theology courses offered elsewhere in the college).
Others...

Further, is it advantageous to even negotiate for these requests? Has anyone in the SE community had success with similar requests?

(3) is typical. I would avoid (1) and (2), unless you have unusual travel expenses. I don't know about (4). You can probably do (6) for free, although I don't know. (5) is interesting and it might be possible to negotiate, although I wouldn't push very hard.

(6) is common at every institution I've seen, though the number of semester hours paid for varies. My current university will cover up to nine (!) hours a semester, and when you do that, the fees for (1) are magically paid, though probably not intentionally so. (3) is basically standard unless you already live in the same city.

At some universities, there is no public transit and parking is very difficult.  Negotiating for a reserved parking space can be very important.

With respect to your title, "interview" and "negotiation" are separate parts of the process.

Instead of "negotiating requests" maybe think of "asking if these are available".

There are a lot of perks that come with being an employee of a university, so it may not be necessary to make a lot of the requests for the items you've listed above. For instance, many universities (where possible) subsidize public transportation or parking costs for their employees in an attempt to be environmentally friendly (and reduce the need for on-campus parking). Similarly, there may be programs in place that offer reduced or no tuition for "continuing education." And certainly relocation expenses are not unusual in job negotiations (I'd even argue those are standard for anything above a postdoc, and even for some postdocs, depending on the employer).
However, the more unusual your request—the key access to music practice rooms, for instance—the less likely I'd want to bring it up during job negotiations. It's just too unlikely to get anywhere, and you don't want to get off to a bad start in the process. That said, that doesn't mean you can't inquire about such things after you've accepted the offer.

Agreed.  Don't bring up things with a trivial monetary value such as (1) and (2).  You can work out access to a practice room later directly with the music department -- this is not a big deal.  Continuing education is generally a given -- check the school's website.  The thing to focus on in your negotiations is the relocation expenses.  (But not for a postdoc position.)  You certainly can ask about religious observance -- but this is something that it should be possible to work out pretty easily once you've been hired.  Still, it wouldn't hurt to ask.

If it's a long-long-term position, ask about family tuition benefits.  That's a biggie.  And don't forget about retirement benefits.  You won't be able to negotiate those, but definitely inform yourself about what they are with a particular employer.

There are a few things I would keep in mind.
The first is whether the person you are negotiating with is able to give you the thing you ask for. For example, the university probably has a fixed policy on whether they charge for parking or for access to the fitness centers, and those are handled by different offices not overseen by academic deans. So negotiating an individual exception to those policies will likely be quite difficult, if the chair and dean have no control over them.
The second is whether the thing you're interested in is sufficiently minor that you can likely handle it once hired. For example, getting access to a music practice room is likely to be straightforward once you are there. Similarly, if you need to be off on certain religious holidays, you can work out a way to handle that after you are hired.
Three things that are more straightforward to negotiate (although they may not always be possible to change) are salary, startup funds, and moving expenses. For those in the sciences, I am told, laboratory space and equipment are often negotiable as well.  So, for example, if you want to cover a fitness center membership, it might be easier to negotiate a small salary increase instead.

Also on the religious holidays — often there are HR policies in place and available to view online that cover that so one needn't even ask


text:
"Taking summers off" and the impact on tenure decisions
Assume there is a young tenure-track professor on a 9-month salary who is a good instructor and manages to get research published at an appropriate pace during the school year for tenure consideration. Could the professor's decision on how he/she spends his/her 3 months each summer affect his/her tenure decision? Specifically, if the professor chose to do something unrelated to teaching summer courses or doing research.
I'll propose two examples:

Spend the summers working a completely unrelated (perhaps lower-level) job just to mix things up or out of necessity or delight. Let's say as a cruise-ship tour guide or as a laborer (e.g., painter, landscaper, farmer, mechanic, etc.)
Spend the summer vacationing with family / kids.

If the individual got the work required for tenure completed during the 9-months of the school year, they could do whatever they want the other 3 months (since they are off contract) without repercussions, right?

This is an excellent question for your department chair.  In principle, it shouldn't matter, but in practice, it depends on your department's culture.

@JeffE the question has only one, rather obvious, correct answer (see my answer), so in that sense I actually don't think this is an excellent question for OP's department chair. If the chair is not entirely clueless he/she will give the obvious official answer since anything else would be exposing the university, and maybe him/her personally, to a big liability; and if he/she is entirely clueless, you shouldn't trust what they are saying anyway. So either way by asking them I don't see that you'd gain any useful information, and you may in fact get entirely wrong and misleading information.

@DanRomik: Really? I think it's perfectly plausible that a department chair could say something like "Officially, it's irrelevant.  Off the record, I have a sense that it might affect the votes of certain faculty members.  There was a previous case..."

"If the individual got the work required for tenure completed during the 9-months of the school year, they could do whatever they want the other 3 months (since they are off contract) without repercussions, right?"  This seems to me like a great example of a vacuously true statement.

@Dan Romik: I agree with the others. This is very plausible, especially at an R1 university (though you likely won't have profs at an R1 attempting to take any time away from their work :p...). I think a tenure committee would look at that pattern of work behavior and question your work ethic or dedication to being an effective tenured professor in the long run.

theforestecologist, plausible? Maybe, but this is pure speculation, and as I said in my answer, you're essentially speculating about people's thoughts about illegal discrimination, so neither I nor anyone else can give anything approaching an authoritative answer. If you feel comfortable speculating about this, go ahead; I don't. Also, part of what makes it difficult to answer is that as @NateEldredge commented, this is pretty near to being a vacuous question: the sample size, if there is even a sample, would be vanishingly small.

I deleted my answer, since based on @NateEldredge's comments it looks like a key premise I had assumed may be incorrect, which potentially undermines the validity of the entire answer. Sorry!

Could you explain why you're asking, please?  Is it that you are fantasizing about getting a tenure track job, and are hoping you can spend your summer snorkeling at the Great Barrier Reef?  That you are wondering how the heck the guy down the hall from you thinks he stands a chance of getting tenure if he spends his summer building himself a house out of straw and clay?  Something else entirely?

I second JeffE's comment.  There are some departments where nobody will even notice whether you're in town over the summer, because no one else is in their offices either, and as long as you get work done nobody will know or care exactly when you did it.  There are other departments where every closed office door will raise eyebrows, no matter how productive you are.

The 9-month contract issue is one of many thing that highlight how a research-oriented professor position is in an ambiguous middle ground between a "job" and a "hobby club".  It is easier to understand the conventions if you think of it as a little bit of both.

Something that I haven't seen any answers comment on--if you are advising graduate students, they may not want or be able to take the summer off.

I would like to know why you didn't like the new title

It was gramatically incorrect!

This is really dependent on your department culture.
Officially (at least for all the tenure systems I've participated in), tenure decisions are based on the quality, reputation, and impact of the candidate's research (and to a lesser extent, teaching and service), and their potential for future intellectual leadership and international stature.  (Woo, that's a mouthful.)  In particular, the decision is based on what the candidate has actually accomplished.
Are they publishing high-quality work in high-visibility venues?  Is their work highly regarded in the research community (as described in the letters)?  Do they have a solid track record of external funding?  Do they have a solid track record of successful graduate student advising?  Have they accumulated other indicators of respect within their research community: awards, plenary talks, invitations to program committees/editorial boards, well-placed and successful students?  Do they have other evidence of research impact: open-source software, community-standard data sets, or patents?
If this case is strong on these merits, then the day-to-day work habits of the candidate shouldn't matter, and usually don't.  In particular, the reference letters, which are by far the most important component of the case, will be written by people who are probably completely unaware that the candidate disappears to a fishing lodge in the Adirondacks every summer.  There have been multiple successful tenure cases in my department where the candidate essentially vanished every summer.
More strongly: If their research case is strong, then what assistant professors do during the months the university is not paying them is really none of the promotion committee's business.  I work in a field where a three-month vacation in the Adirondacks (with a sufficient supply of pens and paper and reliable wifi) would be amazing for my research productivity.
Nevertheless, faculty are apes; we do apey things.  Every department and every field has its own cultural norms, and assistant professors must be aware of and sensitive to those norms.  Some departments have a shared belief—which may even be correct in their field—that the research required for a successful tenure case requires being physically present and visibly productive 24 hours a day, seven days a week, 52 weeks a year.  Others won't even notice when you're in the office being productive, because they all keep their office doors closed, or they work at home, or in coffee shops, or in a shack in in the Adirondacks.  Others have a de facto list of accomplishments that are necessary, sufficient, or both. (NSF CAREER? NIH R1? Three papers in Science? H-index above 50? IEEE Fellow? Letters from five Nobel laureates?)
Whether or not tenure decisions should depend on these local expectations is utterly immaterial.  They do.  Either you meet them, or you find a job somewhere else.  And the only way to understand what these expectations are in your department is to ask directly, and to insist on regular mentorship and feedback from senior faculty.

There's a lot of people who would be more productive with their research taking that time off and coming back refreshed. It's called the "work hard, play hard" mentality. (Or if you're like me, it would be the "work hard, laze around when you're not working "mentality...)

@corsiKa: of course - it is vital not to get burned out, and many of the best researchers take plenty of personal time for family, hobbies, and vacations. But they don't tend to do that for the entire summer, which seems to be the subject of this question.

Everyone has their own opinion about the purpose or benefits of 9-month contracts (which is not to say the history of how they developed). It appears to some extent that these contracts are unique to the United States in any case.
Other answers point out the importance of knowing the local culture of your department. I want to point out a few commonly-held beliefs about the role of summer time for research-intensive faculty, which are good to know when you try to assess that culture. These are beliefs that a significant number of research active faculty will have.

A benefit of 9-month contracts is to allow you time (mostly) unencumbered by teaching and service to work on your research. Of course, you might be able to do this from a cabin in Alaska, but it is not "time away from research" strictly speaking.
For researchers who need to travel, e.g. those studying the art, history or cultures of other countries, the summer is a time to spend a few months in the country they study, going to libraries and museums to do the groundwork for research. Similarly, those who need to do field work (ecology, geology, archaeology, ...) can use the summer months to gather data.
A third benefit, in some disciplines, is to allow you to take salary from other discipline-related work during the summer, e.g. grant support in STEM fields or consulting work in business or engineering.   For example, many grant agencies will not allow a researcher to take salary from a grant while also drawing salary from the university. The 9-month contract circumvents this by not paying university salary during the summer.

So, from a certain viewpoint, the benefit of 9-month contracts is that they allow you to do more tenure-related work over the summer, not less.  It would be a mistake to think that many research-intensive universities have a standard that makes it easy for the average tenure-track faculty member to earn tenure while not using the summer in any way for research.
At these schools, the "appropriate pace" for research already assumes that faculty are working on research over the summer, which is why some other answers seem incredulous at the idea that a faculty member would be publishing at "appropriate pace" while also working as a waiter on a cruise ship all summer.
The situation can be very different in departments where research is not very important for tenure. These departments may have a local culture of doing some service over the summer (or not), but in my experience they generally do have more of a culture of taking the summer off. This is particularly noticeable in "transitioning" departments, where older faculty had fewer research expectations, and so developed a culture of "taking off" the summer, while younger faculty are required to do more research for tenure and do not have that luxury.


text:
Should the length of a research statement and a teaching statement be the same?
I am applying to a faculty position that emphasizes both research and undergraduate teaching. The application asks for a research statement and a teaching statement.I realize that both documents are usually recommended to be 1-2 pages long and that you should always err on the side of brevity.
My question is: would it be an issue if the lengths of the 2 documents are significantly different? For example, if my teaching statement is 2 pages but my research statement is only 1 page. Will a hiring committee automatically view this as the candidate being unbalanced? In other words, does disparity in length between the 2 documents outweigh the content of the documents?
Lastly, would it make a difference depending on the emphasis of the program? For example, should the research statement always be longer (or as long as) a teaching statement if the school places greater emphasis on research (and vice versa)?

I'm not sure why you think that a research statement should be 1-2 pages.  The length of a research statement depends both on the academic field and (to a lesser extent) on the type of institution one is applying to.  In my experience, when a research statement that is only 1-2 pages long is desired, the position posting will mention that explicitly, often using slightly different language ("research summary").
In my field -- mathematics -- if a length of 1-2 pages is not explicitly asked for, then 1-2 pages would be distressingly short, to the extent of jeopardizing your chances.  I would put 4-6 pages as a more reasonable range for those applying for junior faculty positions.  (More senior people can submit longer statements, but after a point people will stop reading.)
To be specific, I have been closely involved with the job search of two junior colleagues, in mathematics.  Both are interested in finding a "faculty position that emphasizes both research and undergraduate teaching."  Each of their research statements was about 4 pages plus references.  They have each done very well on the job market -- on-campus interviews from both large universities and top liberal arts colleges, and one already has a good job offer.  I would not want any student, mentee or junior colleague of mine to send out a 1-2 page research statement until they convinced me that this length was specifically wanted by the institution they're applying to.

My question is: would it be an issue if the lengths of the 2 documents are significantly different?

In my experience -- which is centered at a math department at a state research university -- research statements are generally 2-3 times longer than teaching statements.  The only teaching statement I've ever seen that was approximately the same length as a research statement was my own.  (Regular readers of this site will be shocked to learn that I can be seduced by the sound of my own written voice.  Only over long years and after reading, writing and refereeing many technical papers have I come to a halfway decent appreciation of the virtues of brevity.)

My question is: would it be an issue if the lengths of the 2 documents are significantly different? For example, if my teaching statement is 2 pages but my research statement is only 1 page.

To me, someone whose teaching statement is twice as long as their research statement is signalling in the strongest possible terms that they are more interested in teaching than research...i.e., up to the point where they may not be doing much post-PhD research at all.  But again: please check on your local academic culture.

Will a hiring committee automatically view this as the candidate being unbalanced?

Not automatically, no.

In other words, does disparity in length between the two documents outweigh the content of the documents?

No, the content is most important.  If in your one page research statement you give a clear description of very strong research, people who were expecting a much longer document will think "What a short research statement.  That's weird.  But it sounds good -- let me check the CV / publication list / candidate's webpage for more details."
Added: I'm finding some evidence online pointing to the possibility that research statements in mathematics may be longer than in many other academic fields:

This source advises that research statements in CS should be 2-3 pages.
This source suggests that research statements should be 1-2 pages.  Upon questioning, it becomes clear that the advice is scoped only for the humanities.

Anyway, you should definitely not choose the length of your research statement by what some internet academic tells you!  You should do so by (i) talking to your thesis advisor about it and (ii) comparing notes with others who are or recently were on the job market.  Getting a look at application materials of those who recently got the type of job that you want is ideal.  That's what friends are for.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Will they send my paper to the opposed referee?
All journals asked me to name opposed referees.
Will they really not send my papers to those whom I opposed?
Some journals seems intentionally send to those whom I opposed.

Some journals will ask for a list of reviewers that you would disprefer.
We all know that there are some in academia that bear grudges and this is one mechanism to make sure they don't land in your review pool. It's also a mechanism to indicate conflicts of interest (positive and negative) that might not be apparent to outsiders (a romantic relationship for example).
It saves time for everyone as the editors then don't have to wait for COI responses and reassignments.
So don't view the disprefer list as a wholly negative list. There are positive reasons to disprefer someone.
But it should be short. More than four or five names and the editor will suspect that you're trying to game the system by dispreferring all possible critics.
And to answer your question specifically: yes, an editor may send an article to someone on your disprefer list. It is - after all, your preference - and not binding in any way on the editor. They might, however, scrutinize and weigh the response of the reviewer on the disprefer list more carefully than if they hadn't been flagged.


text:
Can novel findings be submitted rather than a novel methodology?
Basically, my research was not into a particularly new methodology, but we have combined several existing methods to prove a result which has not been seen before under certain circumstances (rebalanced dataset, etc). Would this be an acceptable submission to a conference or journal, or should I go in a different direction and look for something unique?
For reference, this is in the field of machine learning / network security.

I thin the devil is in the details: it is hard to give a general answer, but it is very common to publish new applications / proofs. Have you consulted with tour supervisor?

Straight forward answer is YES. but, novel method is weighed higher than novel results.

@Greg My supervisor has okayed it; however, he's an expert in the Network Security domain and not the machine learning domain (where we want to publish).

@Novella Even so I am sure he knows more about your topic than random people from internet. Also, consider costs/risks: what do you loose if you learn a new field, put together a decent paper? In most fields you don't loose much.

The point of a methodology is to be able to produce interesting and significant results. If you've managed to apply some combination of existing methodologies to discover something interesting and new, then that discovery is likely publishable.
What is not clear, however, is whether a community of researchers who are focused on making new methodologies will be interested. Thus, you might not be able to publish in the particular machine learning community that you are interested in. Instead, I would suggest:

Look for "applications" journals, conferences, or tracks associated with the machine learning community.  Many "tool" communities have these associated: for example, in the general AI world, the core conference AAAI is always co-located with the much smaller but still high-significance IAAI applications meeting.
Embrace the application community (it sounds like network security in this case), and publish your results there. They will be less interested in the methodologies and more in what you have done with them.


text:
Is it wise to choose a better journal with lesser number of similar papers?
I need to choose between two journals for my article. Both candidates are, in principle, suitable for the topic. One of them has a (considerably) larger number of articles similar to mine but the other one is a better journal in my opinion. The first one is a journal of both research articles and educational articles. Whereas the second one is a journal of purely new research.
My article is about the re-derivation of a very well-known result using fewer axioms. Thus, it is new research but might be more appreciated by a community engaged in both research and education. So, I am confused as to which one to choose. Personally, if both the journals were ready to accept my article, then I would choose the second one (the one with only research articles) for its more serious tone and thus, for the possibility of my article getting more serious attention.
But I think I need to make a choice incorporating the chances of acceptance as well.

As it stands your question cannot be answered by us, as weighing rejection risk and journal quality strongly on the quality of your paper and the journals, both of which we do not know. (See also this meta post.) We might answer what to take into account when making such a decision, but you seem to have identified the key factors already.

@Wrzlprmft Would it be appropriate and helpful if I spell out the names of the journals and a brief crux of my article? Of course, the details of my article would matter but would this much be helpful to even some extent?

Would it be appropriate and helpful if I spell out the names of the journals and a brief crux of my article? – Not really. We cannot judge the quality of your article, and we do not want to. See the section Questions on research and publishing decisions of the linked meta post.

You could still submit to Journal 1 if Journal 2 rejects it, right?  And if so, does Journal 2 have any information about how long their initial decision to accept/reject tends to take?

@Nat Yes, that is, of course, a possible way, but it usually takes around more than 4-5 months since the submission for the journal (any of them) to accept or reject a manuscript. Due to personal academic reason, I do not want to afford the worst case of 10 months before an acceptance (or well, rejection).


text:
What are academic honors and prizes?
I am applying for a scholarship (women in graduate studies). It asks whether I have received any academic honors and prizes. I received a couple of master's awards from my supervisor's grant and a graduate scholarship. Do those count as an academic honor or not?
And in another part, it asks whether I have got funding in the past or present. I am getting some money for doing research. Is it a bad thing to include? They won't give me further funding? Having said that, the amount of money that I am getting for doing research is nominal, that is why I am applying for more funding.

Their form or website should contain the information that will explain what you should or should not include in your submission, which you should be capable of researching and deciphering - we don't have that information...

They did not mention anything about my questions. That is why I asked here.

@SolarMike You are very optimistic about these sorts of things if you think they're all crystal clear about what they want

I dont see why your graduate scholarship and masters award are not the honor or funding. I have used them in my CV for PhD applications, and plan to to include for my post-docs as well.
About funding: if you have received funding from any source, do mention it. It will not hurt your chances. In fact, it will demonstrate that you are a dependable researcher. Do mention about the project detail (if you can) and that you have successfully completed the project. When they ask about funding, it does not mean that they are not willing to give it to you. They are looking for someone who know the worth of the money he/she will get.

I received a couple of master's awards from my supervisor's grant and a graduate scholarship. Do those count as an academic honor or not?

If I understand correctly what you mean, I would argue that no. You should only list awards that are competitive (only a few students get them), are merit based (so not just given on a first-come-first-serve basis), and not automatically granted based on another achievement.
I'd imagine that you had already listed your master's degree on your CV, and mentioned your supervisor. Getting a graduate scholarship is not an 'honor' beyond the honor of being accepted to the graduate program (unless most students aren't supported); similarly, if you have a thesis advisor supporting you, you did not really compete for the award.
The same rule holds for conference travel grants. In my discipline, these are awarded at random, unless you are a best paper award recipient. If your paper was accepted to a conference then there's no point listing that you got some partial funding to go there. Again, you get that award because your paper got in + randomness, or because your paper was the best, in which case the travel grant is automatic (not an award in itself).
An award would be winning some prize (best paper, best poster, best presentation etc.); getting some competitive grant/scholarship (like a Google or Facebook fellowship); or an academic achievement (dean's list, valedictorian etc.). If you got accepted into a highly competitive program during your studies that might also qualify (say, you won an industrial internship at some company for outstanding academic performance).
My personal impression is that many students tend to inflate this part of their application. They list things that aren't honors (e.g. completing an online course certification), or very minor ones (e.g. 3rd place in a local high-school competition). This makes no sense to me. It makes it harder to distinguish the noise from the signal on student's current quality, and actually makes me generally more adversarial towards these applicants.
Good luck with your application


text:
Contact professors regarding a not registered invention idea
I have received my MSc degree and I want to apply for Ph.D. programs.
I have an idea for an invention (this idea came from my master’s thesis), but it is not completely related to my field – I will need help from people of other fields to design this application.
The idea is new and it is not registered yet.
Since I am graduated, I don’t have any access to the university.
How should I approach a professor to team with me for this work? Is it possible?
If yes could you please give me a piece of advice or sample emails?
BWY, I'd like to study in a foreign country as well, e.g., in the USA.

This should possibly be another question. Because the idea is coming from a thesis, could your advisor or that university have any claim to the idea?

I don't think so. because my supervisor couldn't help me completely. he does not have the knowledge of designing this application.

Just because your advisor "couldn't help [you]" isn't a strong enough claim in the event of a dispute over the rights to the intellectual property.

@Glen Pierce, he will be part of the project. I don't want to do it on my own. my problem is finding another professor and a student.

You can always contact professors in order to team up, however it will probably be the case that they will provide PhD students to team up with you. This is just a matter of communication and I don't think that is the real problem here.
The idea not being registered yet raises the real issue, because if you start to emailing everybody to try find a team someone may find the idea interesting and start working on it. Then comes the question is it possible to register the idea like in a patent or something? If not, is it possible to publish a paper about it on a conference, this would be a way to turn the idea public but with an authorship kept.
Another thing related to the team item is that you should first get an adviser and be accepted for a PhD program and then you should worry with the team up for the implementation, maybe even with your adviser help.

In fact, I want to continue my Ph.D. in the field that is much closer to the new field. It would be a switch actually. That is why I want to do it before starting my Ph.D. I want to take the advantage of my idea to get into the new field.

@nikki2 but you don't have the expertise to work your idea on your own right? Can you at least find a list of potential professors to approach? There is always an amount of risk. If the idea is potentially a product you could consider using it in the industry instead of as a PhD thesis.

yes, I don't have enough expertise to work my idea on my own. That is the problem. I do not know how should I learn and who should I contact.

@nikki2 you have to break your problem in parts. First you have to know which is the field that could work your idea and then try to find who are the professors that work on similar things. One strategy would be to go to your local university and find which department works with that and try to get some orientation. In this scenario, it seems more feasible to have a PhD that is part in your country part in the USA through some kind of partnership.

This is somewhat complicated, because including the professor puts it within the domain of the university, and universities claim ownership of some portion of intellectual property, especially patents.  In fact, professors often have to negotiate with the university's legal department regarding royalties from said patent.  As you have no affiliation with the university, it is unclear how that negotiation would work, but I'm not an attorney.  Of course, this all assumes your idea comes to fruition.
In the mean time, it would be in your best interest to clearly document this idea, in as specific terms as you can, and email it (to the professor when it becomes appropriate, and to yourself as well).  This is important because part of the patent process is establishing who originally formulated the idea, and the more documentation you have (with date/time stamps and your name), the better.