Emily Hunt is a soon-to-be PhD student at Heidelberg University in Germany, where she will begin a quest to find open clusters in data from the Gaia satellite. In her spare time, she is a sound engineer for both theatre and live music performances. A recent Twitter thread of hers on microphone technique garnered a solar mass of interest in this oft-untaught skill — so here’s a blog post of knowledge covering everything a sound tech could ever hope for a speaker to know!

Public speaking is an essential skill in academia. Whether at a conference or while giving a lecture, public speaking is an unavoidable (and sometimes dreaded) part of a career in science. There are an endless number of things to learn about how to be a better presenter: Who do I look at? How much should I put on my slides? How can I keep within time limits? Yet one crucial topic is often overlooked: Microphones, and how to use them.

This short post will give you a crash course in microphone technique — making your presentations clearer and more audible. Anyone can read your latest paper or pick up a textbook, but your talks are unique from your written work in your delivery and explanations. The speaking part of public speaking is your opportunity to have your work truly heard — so it’s an awful shame if what you have to say is hard to hear.

Don’t think you need a microphone? Around 5% of people have disabling hearing loss and many more have mild hearing loss, and they’ll appreciate the added volume and clarity, regardless of how loudly you can project your voice and especially in larger venues. To help audience members with hearing loss, some venues are fitted with hearing loops that transmit sound to hearing aids electromagnetically. The hearing loop will only be able to help those with hearing loss if you use a microphone! Additionally, more and more events accommodate remote participation or are recorded, and those participants can’t hear unless a microphone is used.

To help you become more comfortable with the idea of using a microphone, let’s start by going over the different types of microphones, and finish with some general tips.

The hardest microphones to use are handheld

The most difficult microphone type for the uninitiated are handhelds. Conquer these and the rest will be a breeze! They look a bit like the image below, and may or may not be wireless. Handheld microphones are common at smaller events or panel discussions. It’s important to hold them confidently and correctly — too far away and it won’t pick up your voice well, and may cause feedback.

Handheld microphone

A typical design of a handheld wireless microphone. [picture: Sennheiser]

Ideally, you should hold the microphone about 5 cm (2 in) away and point it directly at your mouth. It’s tempting to hold it farther away, but try to keep it close by. Having it too close is comparatively much less of an issue than it being too far away.

Also — unless you’re at a conference about hip-hop — don’t cup that mic! It messes with the tone of your voice and could make the microphone more prone to feeding back.

How to hold a mic

A diagram showing correct microphone technique. [picture: Emily Hunt]

If it helps, you can imagine that the microphone is a flashlight and that you want it to light up your smile. Point it at your mouth, keep it close by, and don’t get burnt by cupping the bulb with your hand! It can feel quite odd to hold it correctly: it should feel more horizontal than you think it needs to be and closer to your mouth than you think it should be. Strive to overcome this discomfort and consider karaoke as an excellent time to practice!

Sometimes, handheld microphones are on stands. Remember to adjust the stand before you start speaking to follow the 5-cm (2-in) rule. Take the microphone with you if you decide to walk around — even wireless mics aren’t THAT wireless.

Next up: lectern microphones

Okay! Hard part over. Lectern microphones (a foam blob on the end of a long, bendy stalk) are comparatively easier — they simply need to be adjusted to point at your mouth. To help them out, project your voice naturally as you would if you weren’t in front of a microphone.

Gooseneck mic

A typical lectern/gooseneck microphone. [picture: Sennheiser]

Lectern microphones are quite sensitive, so ignore the 5-cm (2-in) rule from above. In fact, talking into them that close up will probably cause them to sound distorted. Generally, any microphone not designed to be held in your hand doesn’t need to be as close to your mouth as a handheld one. Stand at the lectern and project naturally! They can be a pain because you have to keep talking with your head facing forward to get picked up, but try using presenter notes and callouts on your slides to avoid the need to look back at your slides while talking.

Microphones that move with you: lapels and headsets

Especially common at conference venues are lapel mics: a small microphone that connects to a wireless pack. The microphone itself clips onto clothing about 10 cm (4 in) away from your chin, and doesn’t need to be worried about once set up! Ideally, a sound tech will be on hand to help.

Lapel mic

A lapel mic on a blazer (left) and a person being mic’d up (right). [pictures: Shure, lensrentals.com]

Annoyingly, lapel mics tend to work best with buttoned shirts or blazers because they need something to clip onto. Women’s clothing and blouses in particular tend to end too close to the chin, making the mics harder to clip in the right place. As a best practice for lapel mics, make sure that you aren’t wearing any jewelry that could hit the mic.

Headset microphones are an alternative to lapel mics — you might have seen them in TED talks. They’re not as comfortable as lapel mics and need a sound tech to set up due to their fragility, but will generally sound better and don’t rely on your outfit choice. The end should be about two to four finger-widths away from the edge of your mouth to not sound breathy.

Headset mic

Miho Janvier giving a TED talk in 2017 about solar storms. Spot the headset mic! [picture: TED]

With both lapel and headset mics, you’ll need somewhere to put the wireless transmitter, which is about the size of a pack of cards and typically has a clip. Wearing clothes with pockets or a belt will help. Microphone manufacturer Shure has a good article on choosing between headset or lapel microphones if you want more reading on the differences between the two.

Honourable mention: These weird things from my undergrad

Something I’ve only seen at the University of Bath are lanyard mics, which clip around your neck. Surely they exist somewhere else too? Lanyard mics are useful because they don’t depend on your clothing and are extremely easy to put on (you just have to clip them round your neck).

Lanyard mic

A lanyard microphone, which clips around your neck. [picture: Revolabs]

Some general tips

Microphones are there to reinforce your voice — not to be it. Presenting quietly makes a microphone/sound tech’s life harder, as there’s less of your voice to work with (think signal to noise ratio) and more chance the mic will have to be turned up so loud that it feeds back. Projecting your voice, even when wearing a mic, is still important.

Be cautious of walking off of the stage or in front of the sound system in a venue unless you’ve been told or know that it’s okay. Mics that are in front of or closer to loudspeakers have a higher chance of feeding back. You’re safer if you stay on the stage. Oh — and if you have a microphone, always assume that it’s on. Including if you go to the toilet.

Lastly, to conference organisers: you can help your speakers out by making sure your venue has a range of different microphones available to cater to different clothing choices and body types. It can also be very helpful to arrange soundchecks before the event or during breaks for your presenters, allowing them to get acquainted with the microphone they’ll be using. This is especially true for someone who’s nervous. Hearing the sound of your voice through a microphone for the first time can be off-putting, but soundchecks let your presenters get used to it, which can help their talk to go more smoothly.

And while you’re here — about 5% of sound engineers are women. We’ve won academy awards for mixing film scores, worked on Prince’s music, and helped groups like Pearl Jam to sound their best live. So don’t assume everyone in the industry is a “sound guy” or “sound man”! Every woman in sound engineering I know has dealt with heaps of sexism, and even people’s language choices erase us. Unless you know that everyone who is sound teching on an event identifies as a man, please just ask for the “sound tech.” There’s a chance that you’ll make someone’s day. (I’ve been known to buy musicians beers for doing this. You could get one too. There are ethical and practical incentives!)

I hope that this discussion of microphone types and best practices for each is useful! Do you have any questions or insights to share? For further reading, this similar guide breaks some of the information above into ten simple tips, and the AstroBetter wiki has a lot of information on various presentation skills.


Authors: Daina Bouquin, Gus Muench, Kelle Cruz, Daniel Chivvis, Edwin Henneken

Daina (@dainabouquin) is the Head Librarian at the Center for Astrophysics, Daniel is a Digital Projects Assistant at the CfA’s Library, and Edwin is part of the ADS team at the CfA. Gus (@AAS_Publishing) works for AAS Journals as a Data Editor. Kelle Cruz (@kellecruz) is the editor-in-chief of AstroBetter. This post started as a project at the AAS233 Hack Together Day. It ended up being extremely difficult to write and took many telecons to complete!

People trying to cite software may be doing so in ways that do not meaningfully give credit to authors or establish pathways to access the software itself. If software is not cited properly, the authors will not fully benefit from the citation. In this post, we provide some basic citation instructions, a few examples of common use cases, and some questions you should consider when citing software. This post is not comprehensive but hopefully helpful for the most common use cases. Additionally, the landscape around software citation is evolving quickly and most of the currently available resources (e.g., Zenodo, ADS, AAS Journals) do not consistently provide citation information that is formatted in the way we recommend below. As a result, authors will often need to make some edits and do some digging in order for software to be cited as meaningfully as possible.

All of the below examples are also available in a companion overleaf document.

In text

What are you linking to?

One major distinguishing characteristic that impacts how software can be cited is whether or not the software has a resolvable identifier (e.g., DOI) or only a URL (e.g., GitHub). DOIs are minted by organizations dedicated to the long-term preservation of your code (e.g., Zenodo). Citing a software DOI helps prevent link rot and makes it clear your citation is to software rather than a paper. So, in general, when the software you want to cite has both a DOI and a URL, cite the DOI. You can also footnote the URL, but this is not necessary if you cite the DOI.

Example 1:
In this example, we show how to refer to software used to generate results presented in a paper. The version of the software used to obtain the results should be archived in Zenodo or some other DOI-minting archival repository. We are also showing how to point to the in-development software online.

The software is available on GitHub1 under a <OSI approved license> and version <semver> is archived in Zenodo (Cruz et al. 2019).

1. Eudoxus codebase: http://github.com/kelle/eudoxus

\footnote{\texttt{Eudoxus} codebase: \url{http://github.com/kelle/eudoxus}.}

Example 2:
In this example, we show how to refer to the various scripts and/or data which were used to generate results and figures presented in a paper and are not under active development. The scripts should be archived in Zenodo or some other DOI-minting archival repository.

The scripts and data used to perform the analysis and generate this manuscript are available on GitHub2 and archived in Zenodo (Cruz et al. 2019).

2. Supplementary materials: http://github.com/kelle/eudoxus-supp

\footnote{Supplementary materials: \url{http://github.com/kelle/eudoxus-supp}.}

What if there is no DOI?

If the software does not have a DOI, refer to a URL that links directly to the software itself whenever possible. Citing the code itself, as opposed to the documentation or a package website, is extremely important. Be sure to note what version of the software you used, a release date if there is no version number available, or the date of the latest commit hash of the code you used (the commit hash is a 40 character string).

If you are citing software that does not have a DOI, look for citation metadata in README files and other documentation associated with the software. Ideally, the software authors will have created a distinct file to specify citation information and made that file available with their source code (e.g., CITATION.cff, CodeMeta.json).

Example 3:
In this example, we show how to refer to and cite software which has versioned releases, but does not have a DOI. The example software package also does not have an explicitly defined preferred citation. In this situation, the author of the paper must determine which URL is most appropriate to cite. The BibTeX for this entry is discussed in the following section.

Version 1.0 of Oenopides3 was used to do a portion of the analysis presented in this paper (Oenopides Project, 2014).

3. Oenopides website: https://bitbucket.org/oenopides

\footnote{\texttt{Oenopides} website: \url{http://bitbucket.com/oenopides}.}

Example 4:
In this example, we show how to refer to and cite software which does not have a DOI or versioned releases.

Aglaonice4 (accessed on 2014 December 14) was used to do a portion of the analysis.

4. Aglaonice as of 2014 December 14: http://github.com/user/aglaonice/tree/12ao345oeu678

\footnote{\texttt{Aglaonice} as of 2014 December 14: \url{http://github.com/user/project/tree/12ao345oeu678}.}

What if the preferred citation provided by the software authors does not directly link to the software itself?

If the authors want you to cite a paper, cite the paper in addition to a DOI or a URL that points directly to the version of the software you used.

Example 5:

Hypsicles was developed for <specific scope and purpose> (Muench et al. 2014). Version 1.2 of Hypsicles was used to analyze our results and is archived in Zenodo (Bouquin et al. 2019).

Software section

Fundamental software which is used by many packages can be cited in the software section of AAS Journals. The BibTeX entries for these packages are provided on the wiki: Software.bib.

Example 1:

Software: MOOG (Sneden et al. 2012), LMFIT (Newville et al. 2014), PyRAF (Science Software Branch at STScI 2012), Astropy (Astropy Collaboration et al. 2013, 2018), SciPy (Jones et al. 2001), Pandas (McKinney 2010), Matplotlib (Hunter 2007).

\software{LMFIT \citep{lmfit}, PyRAF \citep{pyraf}, Astropy \citep{astropy:2013, astropy:2018}, SciPy \citep{Scipy}, Pandas \citep{Pandas}, Matplotlib \citep{matplotlib}, Numpy \citep{numpy}}

References section

The references section of a paper serves as a list of formal citations that point to all of the in-text citations used throughout that paper. This means that, although footnotes and acknowledgments may be useful, they are not captured as formal citations in a paper. Simply put, if something isn’t included in the references section, it’s not a citation.

Software citations are similar to other citation types such as books, journals, etc. However, when adding them to references sections, some software-specific information is needed. This includes the Author(s) or Creator(s) of the code in addition to the software package name. The software version (e.g., v.01) and its release date are also important pieces of information to include in the citation. Note that in the case of open source projects, where the Author(s) or Creator(s) are unknown or difficult to determine, using “[Package Name] Project” is entirely appropriate. Similarly, using “[Company Name]” suffices for commercial projects (e.g., “[Knightware]” for the Deep-Sky Planner package).

A unique identifier for a package, such as its DOI, bibcode, or arXiv ID, is one of the most important parts of software citations included in references sections. A URL to the project’s website or digital repository (e.g., GitHub or GitLab) may also be used as an identifier (refer to Example 3 and 4 above).

A @software BibTeX entry type exists, but it is not yet widely adopted. We therefore recommend that unless otherwise specified by your publisher, use the @misc entry type for software.

Example 1:
In this example, we show an entry for software with DOI published by Zenodo. In particular, we’ve added the version, publisher, and keyword fields. “Astronomy software (1855)” is the formal UAT concept that should be entered into the keyword field.

Cruz et al. 2014, “Eudoxus”, v1.0, Zenodo, doi.10.5281/zenodo.12345

author = {Cruz, Kelle and Bouquin, Daina and Muench, August and Chivvis, Daniel and Henneken, Edwin},
title = {Eudoxus},
month = apr,
year = 2019,
doi = {10.5281/zenodo.12345},
url = {https://doi.org/10.5281/zenodo.12345},
version = {v1.0},
publisher = {Zenodo},
keywords = {Astronomy software (1855)}


\bibitem[Cruz et al.(2019)]{eudoxus_key} Cruz, K.\ 2019, “Eudoxus”, v1.0, Zenodo, doi:10.5281/zenodo.12345

Example 2:
In this example, we show an entry for software with no DOI and no version release. The date corresponds to date of code used and the URL corresponds to that hash.

Aglaonice Project 2014, “Aglaonice”, http://github.com/user/aglaonice/tree/12ao345oeu678

author = {{Aglaonice Project}},
title = {Aglaonice},
urldate = {2014-12-01},
url = {http://github.com/user/aglaonice/tree/12ao345oeu678},
keywords = {Astronomy software (1855)}


\bibitem[Aglaonice Project(2014)]{aglaonice_key} Aglaonice Project\ 2014, “Aglaonice”, GitHub, \url{http://github.com/user/aglaonice/tree/12ao345oeu678}

Full paper examples

The papers below can be used as examples for you to follow when structuring your software citations so that ADS can capture them.

Full Paper Example 1:
This JGRA paper has a mix of proper software citations using Zenodo DOIs and software URLs in references:

Burrell, A. G. et al. 2018. “Snakes on a Spaceship—An Overview of Python in Heliophysics.” Journal of Geophysical Research (Space Physics) 123(12): 10,384. https://ui.adsabs.harvard.edu/#abs/2018JGRA..12310384B/abstract

Full Paper Example 2:
This ApJ paper is a nice example of how to mention software at the end of the paper and include Zenodo DOIs in your references:

Berger, Travis A., Andrew W. Howard, and Ann Merchant Boesgaard. 2018. “Identifying Young Kepler Planet Host Stars from Keck-HIRES Spectra of Lithium.” The Astrophysical Journal 855(2): 115. https://ui.adsabs.harvard.edu/#abs/2018ApJ…855..115B/abstract


The ADS can now capture citations to your software when your software is properly cited using Zenodo DOIs. This functionality results from a project funded by the Alfred P. Sloan Foundation called Asclepias. Software citations cannot be captured though unless the community adopts and normalizes standard practices like those outlined in this post.

Still have questions? Please use the comment section below or tweet at @astrobetter or one of the authors and we’ll try to help out the best we can!


A recent discussion on Twitter spawned some suggestions for the best iPad apps for taking notes and using an iPad as an integral part of your workflow. We wanted to point people towards some of the suggestions other scientists had.

GoodNotes received several recommendations, particularly for making hand-written notes. If you are interested in using graph paper for your note-taking but find the native GoodNotes graph templates too thick, Dr. Robert McNees provided a number of templates you can use. He made these using LaTeX and pgf/TikZ, and you can find the code to make your own on his GitHub page.

In addition, Evernote, along with the Evernote app for hand-writing, Penultimate, came highly-recommended.

Dr. Julianna Dacalnton suggested several apps for augmenting the use of an iPad:

Other apps worth checking out include:

What are your favorite note-taking apps for tablets? Leave a comment below if you have any additional suggestions or tips!

{ 1 comment }

Publishing a scholarly journal article, particularly if it is the first time you are doing it, can feel overwhelming. In order to demystify the process, the American Astronomical Society has recently released a set of videos on YouTube to guide you through the process of publishing in the AAS Journals. These ~5-minute videos provide insight into and tips about how to make your publishing experience as smooth as possible.

The AAS plans to release more videos in the coming weeks, so subscribe to the AAS YouTube channel to stay up to date! We’ve also linked video series in the AstroBetter Wiki under Technical Communication: Reading, Writing, Reviewing for your future reference.


Guide to Organizing Inclusive Scientific Meetings

by Joanna Bridge April 24, 2019

Conferences can be an invigorating experience for many astronomers, giving people a chance to share research, make new contacts in the field, and socialize with colleagues. For many, however, meetings end up being stressful and anxiety-inducing, particularly for people in marginalized groups. 500 Women Scientists recently published a guide on how to organize inclusive scientific […]


Read more →

Celebrating AstroBetter’s 10th Anniversary

by Joanna Bridge April 11, 2019

Today, AstroBetter is celebrating its 10th anniversary! During the last ten years, we have had many important discussions on the blog, covering issues of policy, computing, productivity, career path, and more. We’ve had some difficult discussions about the work commitment required of astronomers, diversity, racism, and equity. The advent of the AstroBetter Wiki has provided […]


Read more →

Apply to attend the ComSciCon workshop at the AAS meeting this summer

by Joanna Bridge March 29, 2019

The 234th American Astronomical Society Conference will take place June 9-13, 2019 in St. Louis, MO. The ComSciCon (Communicating Science Conference) workshop series is partnering with AAS to bring a science communication training workshop for graduate students who are interested in bettering their science communication skills, held on June 9 and June 13. According to […]


Read more →

Kids these days and their publications lists [Cross-post]

by Guest February 25, 2019

Growing up by the mountains of Northern Greece, Hercules (aka Iraklis) Konstantopoulos developed a fascination with the night sky and all its intrigue. After a career as a researcher in astrophysics that spanned ten years and four continents, he became drawn to addressing a greater variety of data-related problems. Data science ensued with work on […]


Read more →

exo.MAST: A New Tool for Navigating Exoplanet Data

by Guest February 4, 2019

Susan Mullally is a Senior Archive Scientist for the MAST at STScI. She is an astronomer who likes working with time series data and improving the reliability of exoplanet catalogs. The Mikulski Archive for Space Telescopes (MAST) at STScI introduces a new way to explore the archive’s exoplanet data: exo.MAST. For confirmed planets and planet […]

{ 1 comment }

Read more →

Information for Astronomers Regarding the Partial US Government Shutdown

by Joanna Bridge January 24, 2019

The partial shutdown of the United States government is have far-reaching affects on US-based astronomers. The American Astronomical Soceity (AAS) sent an action alert to its members today. “Many federal agencies, including NSF, NASA, and Smithsonian, have been shut down to all but essential operations for 33 days and counting… Hundreds of AAS members are […]


Read more →