Our online courses (all are free and have no ads):

Other useful resources

fast.ai in the news:

Is GitHub Copilot a blessing, or a curse?


GitHub Copilot is a new service from GitHub and OpenAI, described as “Your AI pair programmer”. It is a plugin to Visual Studio Code which auto-generates code for you based on the contents of the current file, and your current cursor location.

It really feels quite magical to use. For example, here I’ve typed the name and docstring of a function which should “Write text to file fname”:

The grey body of the function has been entirely written for me by Copilot! I just hit Tab on my keyboard, and the suggestion gets accepted and inserted into my code.

This is certainly not the first “AI powered” program synthesis tool. GitHub’s Natural Language Semantic Code Search in 2018 demonstrated finding code examples using plain English descriptions. Tabnine has provided “AI powered” code completion for a few years now. Where Copilot differs is that it can generate entire multi-line functions and even documentation and tests, based on the full context of a file of code.

This is particularly exciting for us at fast.ai because it holds the promise that it may lower the barrier to coding, which would greatly help us in our mission. Therefore, I was particularly keen to dive into Copilot. However, as we’ll see, I’m not yet convinced that Copilot is actually a blessing. It may even turn out to be a curse.

Copilot is powered by a deep neural network language model called Codex, which was trained on public code repositories on GitHub. This is of particular interest to me, since in back in 2017 I was the first person to demonstrate that a general purpose language model can be fine-tuned to get state of the art results on a wide range of NLP problems. I developed and showed that as part of a fast.ai lesson. Sebastian Ruder and I then fleshed out the approach and wrote a paper, which was published in 2018 by the Association for Computational Linguistics (ACL). OpenAI’s Alec Radford told me that this paper inspired him to create GPT, which Codex is based on. Here’s the moment from that lesson where I showed for the first time that language model fine tuning gives a state of the art result in classifying IMDB sentiment:

A language model is trained to guess missing words in a piece of text. The traditional “ngram” approach used in previous years can not do a good job of this, since context is required to guess correctly. For instance, consider how you would go about filling in the missing words in each of these examples:

Knowing that in one case “hot day” is correct, but in another that “hot dog” is correct, requires reading and (to some extent) understanding the whole sentence. The Codex language model learns to guess missing symbols in programming code, so it has to learn a lot about the structure and meaning of computer code. As we’ll discuss later, language models do have some significant limitations that are fundamentally due to how they’re created.

The fact that Copilot is trained on publicly available code, under a variety of licenses, has led to many discussions about the ethical and legal implications. Since this has been widely discussed I won’t go into it further here, other than to point out one clear legal issue for users of Copilot discussed by IP lawyer Kate Downing, which is that in some cases using Copilot’s suggestions may be a breach of license (or require relicensing your own work under a GPL-compatible license):

The more complex and lengthy the suggestion, the more likely it has some sort of copyrightable expression.


Before we dive into Copilot more deeply, let’s walk-through some more examples of using it in practice.

In order to know whether that auto-generated write_text function actually works, we need a test. Let’s get Copilot to write that too! In this case, I just typed in the name of my test function, and Copilot filled in the docstring for me:

After accepting that suggestion, Copilot got a bit confused and suggested a meaningless function containing many lines of near duplicate code:

No problem – Copilot can show us other suggested options, by hitting Ctrl-Enter. The first listed actually looks pretty reasonable (except for an odd extra tab character in the first line):

Here Copilot assumes there’s a function available called read_text, which doesn’t actually exist. But it’s easy enough for us to ask Copilot to write and test that for us too.

I also asked Copilot to create a function for me that would “Tar and optionally compress directory dir to dest in bz2, xz, or gzip format”, which resulted in:

def tar_dir(dir, dest):
    "Tar and optionally compress directory `dir` to `dest` in bz2, xz, or gzip format"
    if dest.endswith('.bz2'):
        with tarfile.open(dest,'w:bz2') as f: f.add(dir, arcname=os.path.basename(dir))
    elif dest.endswith('.xz'):
        with tarfile.open(dest,'w:xz') as f: f.add(dir, arcname=os.path.basename(dir))
    elif dest.endswith('.gz'):
        with tarfile.open(dest,'w:gz') as f: f.add(dir, arcname=os.path.basename(dir))
    else: raise ValueError('bad dest: {}'.format(dest))

I also had Copilot create a test using the same basic approach as above, and it wrote:

with TemporaryDirectory() as tmp:
    assert os.path.exists('out.tar.bz2')
    with tarfile.open('out.tar.bz2') as f:
        assert f.getnames()==['a.txt','b.txt']

That test doesn’t actually pass, since getnames in the last line includes the parent directory, but it’s an easy enough fix from there. Copilot even cleverly decided to use the write_text function I created earlier, which is something I wasn’t expecting.

You can even use Copilot to write prose. I’m writing this blog post in vscode right now, and just clicked the “enable Copilot” button. After I typed the previous sentence, here’s what Copilot recommended as a completion:

I can now write my blog post in a single line of text, and Copilot will generate the rest of the post for me

Clearly Copilot has a rather inflated understanding of its own prose generation capabilities!

Code problems

The code Copilot writes is not very good code. For instance, consider the tar_dir function above. There’s a lot of duplicate code there, which means more code to maintain in the future, and more code for a reader to understand. In addition, the docstring said “optionally compress”, but the generated code always compresses. We could fix these issues by writing it this way instead:

def tar_dir(dir, dest):
    "Tar and optionally compress directory `dir` to `dest` in bz2, xz, or gzip format"
    suf = ':' + Path(dest).suffix[1:]
    if suf==':tar': suf=''
    with tarfile.open(dest,f'w{suf}') as f: f.add(dir, arcname=dir)

A bigger problem is that both write_text and tar_dir shouldn’t have been written at all, since the functionality for both is already provided by Python’s standard library (as pathlib’s write_text and shutil’s make_archive). The standard library versions are also better, with pathlib’s write_text doing additional error checking and supporting text encoding and error handling, and make_archive supporting zip files and any other archive format you register.

Why Copilot writes bad code

According to OpenAI’s paper, Codex only gives the correct answer 29% of the time. And, as we’ve seen, the code it writes is generally poorly refactored and fails to take full advantage of existing solutions (even when they’re in Python’s standard library).

Copilot has read GitHub’s entire public code archive, consisting of tens of millions of repositories, including code from many of the world’s best programmers. Given this, why does Copilot write such crappy code?

The reason is because of how language models work. They show how, on average, most people write. They don’t have any sense of what’s correct or what’s good. Most code on GitHub is (by software standards) pretty old, and (by definition) written by average programmers. Copilot spits out it’s best guess as to what those programmers might write if they were writing the same file that you are. OpenAI discuss this in their Codex paper:

As with other large language models trained on a next-token prediction objective, Codex will generate code that is as similar as possible to its training distribution. One consequence of this is that such models may do things that are unhelpful for the user

One important way that Copilot is worse than those average programmers is that it doesn’t even try to compile the code or check that it works or consider whether it actually does what the docs say it should do. Also, Codex was not trained on code created in the last year or two, so it’s entirely missing recent versions, libraries, and language features. For instance, prompting it to create fastai code results only in proposals that use the v1 API, rather than v2, which was released around a year ago.

Complaining about the quality of the code written by Copilot feels a bit like coming across a talking dog, and complaining about its diction. The fact that it’s talking at all is impressive enough!

Let’s be clear: The fact that Copilot (and Codex) writes reasonable-looking code is an amazing achievement. From a machine learning and language synthesis research point of view, it’s a big step forward.

But we also need to be clear that reasonable-looking code that doesn’t work, doesn’t check edge cases, and uses obsolete methods, and is verbose and creates technical debt, can be a big problem.

The problems with auto-generated code

Code creation tools have been around nearly as long as code has been around. And they’ve been controversial throughout their history.

Most time coding is not taken up in writing code, but with designing, debugging, and maintaining code. When code is automatically generated, it’s easy to end up with a lot more of it. That’s not necessarily a problem, if all you have to do to maintain or debug it is to modify the source which the code is auto-generated from, such as when using code template tools. Even then, things can get confusing when debugging, since the debugger and stack traces will generally point at the verbose generated code, not at the templated source.

With Copilot, we don’t have any of these upsides. We nearly always have to modify the code that’s created, and if we want to change how it works, we can’t just go back and change the prompt. We have to debug the generated code directly.

As a rule of thumb, less code means less to maintain and understand. Copilot’s code is verbose, and it’s so easy to generate lots of it that you’re likely to end up with a lot of code!

Python has rich dynamic and meta-programming features that greatly reduce the need for code generation. I’ve heard a number of programmers say that they like that Copilot writes a lot of boilerplate for you. However, I almost never write any boilerplate anyway – any time in the past I found myself needing boilerplate, I used dynamic Python to refactor the boilerplate out so I didn’t need to write it or generate it any more. For instance, in ghapi I used dynamic Python to create a complete interface to GitHub’s entire API in a package that weighs in at just 40kB (by comparison, an equivalent packages in Go contains over 100,000 lines of code, most of it auto-generated).

A very instructive example is what happened when I prompted Copilot with:

def finetune(folder, model):
    """fine tune pytorch model using images from folder and report results on validation set"""

With a very small amount of additional typing, it generated these 89 lines of code nearly entirely automatically! In one sense, that’s really impressive. It does indeed basically do what was requested – finetune a PyTorch model.

However, it finetunes the model badly. This model will train slowly, and result in poor accuracy. Fine tuning a model correctly requires considering things like handling batchnorm layer statistics, finetuning the head of the model before the body, picking a learning rate correctly, using an appropriate annealing schedule, and so forth. Also, we probably want to use mixed precision training on any CUDA GPU created in the last few years, and are likely to want to add better augmentation methods such as MixUp. Fixing the code to add these would require many hundreds of lines more code, and a lot of expertise in deep learning, or the use of a higher level API such as fastai, which can finetune a PyTorch model in 4 lines of code, resulting in something with higher accuracy, faster, and that’s more extensible.)

I’m not really sure what would be best for Copilot to do in this situation. I don’t think what it’s doing now is actually useful in practice, although it’s an impressive-looking demonstration.

Parsing Python with a regular expression

I asked the fast.ai community for examples of times where Copilot had been helpful in writing code for them. One person told me they found it invaluable when they were writing a regex to extract comments from a string containing python code (since they wanted to map each parameter name in a function to its comment). I decided to try this for myself. Here’s the prompt for Copilot:

code_str = """def connect(
    host:str, # host to connect to
    port:int=80, # port to connect to
    ssl:bool=True, # whether to use SSL
) -> socket.socket: # the connected socket
# regex to extract comments from strings looking like code_str

Here’s the generated code:

comment_re = re.compile(r'^\s*#.*$', re.MULTILINE)

This code doesn’t work, since the ^ character is incorrectly binding the match to the start of the line. It’s also not actually capturing the comment since it’s missing any capturing groups. (The second suggestion from Copilot correctly removes the ^ character, but still doesn’t include the capturing group.)

These are minor issues, however, compared to the big problem with this code, which is that a regex can’t actually parse Python comments correctly. For instance, this would fail, since the # in tag_prefix:str="#" would be incorrectly parsed as the start of a comment:

code_str = """def find_tags(
    input_str:str,     # the string to search for tags
    tag_prefix:str="#" # prefix marking the start of a tag
) -> List[str]:        # list of all tags found

It turns out that it’s not possible to correctly parse Python code using regular expressions. But Copilot did what we asked: in the prompt comment we explicitly asked for a regex, and that’s what Copilot gave us. The community member who provided this example did exactly that when they wrote their code, since they assumed that a regex was the correct way to solve this problem. (Although even when I tried removing “regex to” from the prompt Copilot still prompted to use a regex solution.) The issue in this case isn’t really that Copilot is doing something wrong, it’s that what it’s designed to do might not be what’s in the best interest of the programer.

GitHub markets Copilot as a “pair programmer”. But I’m not sure this really captures what it’s doing. A good pair programmer is someone who helps you question your assumptions, identify hidden problems, and see the bigger picture. Copilot doesn’t do any of those things – quite the opposite, it blindly assumes that your assumptions are appropriate and focuses entirely on churning out code based on the immediate context of where your text cursor is right now.

Cognitive Bias and AI Pair Programming

An AI pair programmer needs to work well with humans. And visa versa. However humans have two cognitive biases in particular that makes this difficult: automation bias and anchoring bias. Thanks to this pair of human foibles, we will all have a tendency to over-rely on Copilot’s proposals, even if we explicitly try not to do so.

Wikipedia describes automation bias as:

the propensity for humans to favor suggestions from automated decision-making systems and to ignore contradictory information made without automation, even if it is correct

Automation bias is already recognized as a significant problem in healthcare, where computer decision support systems are used widely. There are also many examples in the judicial and policing communities, such as the city official in California who incorrectly described an IBM Watson tool used for predictive policing: “With machine learning, with automation, there’s a 99% success, so that robot is—will be—99% accurate in telling us what is going to happen next”, leading the city mayor to say “Well, why aren’t we mounting .50-calibers [out there]?” (He claimed he was he was “being facetious.”) This kind of inflated belief about the capabilities of AI can also impact users of Copilot, especially programmers who are not confident of their own capabilities.

The Decision Lab describes anchoring bias as:

a cognitive bias that causes us to rely too heavily on the first piece of information we are given about a topic.

Anchoring bias has been very widely documented and is taught at many business schools as a useful tool, such as in negotiation and pricing.

When we’re typing into vscode, Copilot jumps in and suggests code completions entirely automatically and without any interaction on our part. That often means that before we’ve really had a chance to think about where we’re heading, Copilot has already plotted a path for us. Not only is this then the “first piece of information” we’re getting, but it’s also an example of “suggestions from automated decision making systems” – we’re getting a double-hit of cognitive biases to overcome! And it’s not just happening once, but every time we write just a few more words in our text editor.

Unfortunately, one of the things we know about cognitive biases is that just being aware of them isn’t enough to avoid being fooled by them. So this isn’t something GitHub can fix just through careful presentation of Copilot suggestions and user education.

Stack Overflow, Google, and API Usage Examples

Generally if a programmer doesn’t know how to do something, and isn’t using Copilot, they’ll Google it. For instance, the coder we discussed earlier who wanted to find parameters and comments in a string containing code might search for something like: “python extract parameter list from code regex”. The second result to this search is a Stack Overflow post with an accepted answer that correctly said it can’t be done with Python regular expressions. Instead, the answer suggested using a parser such as pyparsing. I then tried searching for “pyparsing python comments” and found that this module solves our exact problem.

I also tried searching for “extract comments from python file”, which gave a first result showing how to solve the problem using the Python standard library’s tokenize module. In this case, the requester introduced their problem by saying “I’m trying to write a program to extract comments in code that user enters. I tried to use regex, but found it difficult to write.*” Sounds familiar!

This took me a couple of minutes longer that finding a prompt for Copilot that gave an answer, but it resulted in me learning far more about the problem and the possible space of solutions. The Stack Overflow discussions helped me understand the challenges of dealing with quoted strings in Python, and also explained the limitations of Python’s regular expression engine.

In this case, I felt like the Copilot approach would be worse for both experienced and beginner programmers. Experienced programmers would need to spend time studying the various options proposed, recognize that they don’t correctly solve the problem, and then would have to search online for solutions anyway. Beginner programmers would likely feel like they’ve solved the problem, wouldn’t actually learn what they need to understand about limitations and capabilities of regular expressions, and would end up with broken code without even realizing it.

In addition to CoPilot, Microsoft, the owners of GitHub, have created a different but related product called “API Usage Examples”. Here’s an example taken directly from their web-site:

This tool looks for examples online of people using the API or library that you’re working with, and will provide examples of real code showing how it’s used, along with links to the source of the example. This is an interesting approach that’s somewhere between Stack Overflow (but misses the valuable discussions) and Copilot (but doesn’t provide proposals customized to your particular code context). The crucial extra piece here is that it links to the source. That means that the coder can actually see the full context of how other people are using that feature. The best ways to get better at coding are to read code and to write code. Helping coders find relevant code to read looks to be an excellent approach to both solving people’s problems whilst also helping them improve their skills.

Whether Microsoft’s API Usage Examples feature turns out the be great will really depend on their ability to rank code by quality, and show the best examples of usage. According to the product manager (on Twitter) this is something they’re currently working on.


I still don’t know the answer to the question in the title of this post, “Is GitHub Copilot a blessing, or a curse?” It could be a blessing to some, and a curse to others. For those for whom it’s a curse, they may not find that out for years, because the curse would be that they’re learning less, learning slower, increasing technical debt, and introducing subtle bugs – are all things that you might well not notice, particularly for newer developers.

Copilot might be more useful for languages that are high on boilerplate, and have limited meta-programming functionality, such as Go. (A lot of people today use templated code generation with Go for this reason.) Another area that it may be particularly suited to is experienced programmers working in unfamiliar languages, since it can help get the basic syntax right and point to library functions and common idioms.

The thing to remember is that Copilot is an early preview of a very new technology that’s going to get better and better. There will be many competitors popping up in the coming months and years, and GitHub will no doubt release new and better versions of their own tool.

To see real improvements in program synthesis, we’ll need to go beyond just language models, to a more holistic solution that incorporates best practices around human-computer interaction, software engineering, testing, and many other disciplines. Currently, Copilot feels like a product designed and implemented by machine learning researchers, rather than a complete solution incorporating all needed domain expertise. I’m sure that will change.

fastchan, a new conda mini-distribution

Summary: today we’re announcing fastchan, a new conda mini-distribution with a focus on the PyTorch ecosystem. Using fastchan, installation and updates of libraries such as PyTorch and RAPIDS is faster, easier, and more reliable.

This detailed blog post by the brilliant Aman Arora of Weights and Biases provides a great overview of what fastchan is for, how it relates to other parts of the ecosystem, and how it makes life easier in practice.

What you need to know

If you use Anaconda, you can now install Python software like fastai, RAPIDS, timm, OpenCV, and Hugging Face Transformers with a single unified command: conda install -c fastchan. The same approach can also be used to upgrade any software you’ve installed from fastchan. Software on fastchan has been tested to install successfully on Mac, Linux, and Windows, on all recent versions of Python. A full list of available packages is available here.

We’ve been testing fastchan for the last few months, and have switched the official installation source for fastai to use fastchan. According to Anaconda, it’s already nearly as popular as the PyTorch channel itself!

Anaconda download statistics for PyTorch
Anaconda download statistics for PyTorch


conda is one of my favorite pieces of software. It allows me to install a huge range of software, such as Rust, GCC, CUDA Toolkit, Python, graphviz, and thousands more, without even requiring root access. It installs executables, C libraries, Python modules, and just about anything else you can think of. It also handles installing any needed dependencies automatically.

If you’ve used a Linux package manager like apt (Ubuntu) or yum (Fedora) then that will sound pretty familiar – conda is, basically, just another package manager. But rather than being used to install system packages that are used as part of the operating system, it’s used for installing your own personal software. That means that you can’t accidentally break your OS if you use conda.

It also can create separate self-contained environments with totally isolated software installations. That means I can create a quick throwaway environment to test some new software, without breaking my base environment, or even keep separate environments for different projects, which might require (for instance) different versions of Python or libraries.

Some people conflate conda with pip and virtualenv. However, these are just used for managing python packages. They can not manage executables, C libraries, and so forth.

conda installs software from channels, which are repositories of installation packages. The most widely used channels are defaults, which is used automatically by Anaconda, the most popular conda system installer, and conda-forge, a community repository to which thousands of developers have contributed conda packages.

Many organizations maintain their own channels, such as fastai, nvidia, and pytorch.

The distribution problem

You have likely heard the term distribution, as used in the Linux world. Distributions such as Ubuntu and Fedora provide scheduled releases of sets of software packages which have been tested to work correctly together. They also provide repositories where new versions of software are made available, after testing the software to ensure it works correctly as part of that distribution.

Anaconda and the defaults channel are also a distribution. On a regular basis, Anaconda release a new version of their main installer, along with a set of packages that have been tested to work correctly together. Furthermore, they continue to test new versions of packages between software releases, adding them to the defaults channel when they are ready.

Many of the packages in the defaults channel are sourced from conda-forge. conda-forge is not a distribution itself, but a repository for any user to upload “recipes” to build software, and to make available the results of those builds. Anaconda takes a subset of these packages, along with software they package themselves, and software packaged by other partners, does additional integration testing of the combination of these packages, and then makes them available in their distribution.

This system works very well in many situations. Those needing cutting-edge versions of software or packages not available in the defaults channel can install them directly from conda-forge, and those needing the convenience and confidence of a distribution can just install software from defaults.

However, many Python libraries are not in the defaults or conda-forge channels, or are not available in any channel at all. Furthermore, conda-forge is now so large (thanks to its great success!) that I’ve had to wait over two days for conda to figure out the dependencies when trying to install software that uses conda-forge. (There is a much faster conda replacement called mamba, but it is not yet feature complete, and can not currently install PyTorch correctly.)

Libraries which use the GPU are a particular issue, since conda-forge does not yet have facilities for building and testing GPU-enabled software. Furthermore, GPU libraries are particularly difficult to package correctly, needing to work with many combinations of versions of CUDA, cudnn, Python, and OS. There is a large ecosystem of software that depends on PyTorch, and the PyTorch team has set up a large number of integration tests that are run before each release. PyTorch also has its own custom framework for building the software, resulting in packages that automatically identifies the correct installer for each user.

These issues result in complex commands to install packages in this ecosystem, such as this command that’s currently required for installing NVIDIA’s powerful RAPIDS software:

conda create -n rapids-21.06 -c rapidsai -c nvidia -c conda-forge \
    rapids-blazing=21.06 python=3.7 cudatoolkit=11.0

As Aman Arora eloquently explains, running this command creates a new environment that doesn’t include any of the other software that we’ve previously installed, and provides no mechanism for keeping the software up to date. Adding other packages to the environment becomes complex, since version mismatches are very common when combining multiple channels in this way.

I wanted to create packages that depend on RAPIDS, but there’s no real way to make it easy for users to install and update such a package.

I hear a lot of developers telling data scientists that they should create new docker or conda environments for every separate project, and that that’s the correct way to avoid these problems. However, that’s like telling people to install a new operating system for each application they want to use. Imagine if you couldn’t run Chrome and vscode at the same time, but had to switch to a new environment for each! We need to be able to install all the software and libraries we need to do our work, in the same place, at the same time. We need to be able to use them together, and maintain them.

The solution: a new distribution

To avoid these problems we created a new channel and distribution called fastchan. fastchan contains all the dependencies needed to install fastai, PyTorch, RAPIDS, and much more. We use the official PyTorch build of PyTorch, the official NVIDIA build of RAPIDS and CUDA Toolkit, and so forth. The developers of these packages have spent considerable time packaging their software in a way that works best, so we think it’s best to use their work, instead of starting from scratch.

For libraries and dependencies that are only available on conda-forge, we copy those into the fastchan channel. We use a little-known, but very useful, Anaconda command called copy that copies packages across channels.

fastchan uses conda’s own dependency solver to figure out recursively all the dependencies that are needed. We only include dependencies that are not already available in the defaults channel. That’s because defaults is already used by default in Anaconda, so there is no need for us to duplicate what’s already there.

In addition, we package some software that’s currently only available as pip packages on pypi. We use a couple of methods to do this. One is using the terrific setuptools-conda software by fellow Aussie Chris Billington. The other is a new build.py program we wrote, which is used for compiled software such as sentencepiece and OpenCV.

The packages are built and copied automatically twice every day thanks to these GitHub Actions workflows.

The result

The result of all this is that you rely just on the defaults and fastchan channels to install nearly everything you need, especially if you’re working with software in the PyTorch and Hugging Face ecosystems. Even more important than installation is updates – you can now update all your packages at once with a single command! To have this all handled automatically, create a file ~/.condarc containing the following:

  - fastchan
  - defaults

Then you can just use conda install and conda upgrade without needing to even pass -c fastchan. If you run conda upgrade --all your entire environment will be brought fully up to date (similar to using sudo apt upgrade to keeping a Ubuntu installation up to date).

Future work

I hope that fastchan will be a useful starting point for folks thinking about Python packaging and deployment. There’s a lot more that could be added to make it better. For instance, currently the only guarantee made by fastchan is that the packages provided can be installed correctly together. It doesn’t actually check that they work correctly. Ideally, integration tests would be run on both CPU and GPU to ensure that code that uses the libraries together gives the expected results.

It would also be great if there were a community-driven way for anyone to request packages get added to fastchan, and also to add their own integration tests. Integration tests are particularly important to ensure that no-one adds or changes a package which causes breakage on dependent packages (or at least to ensure that broken downstream packages are clearly marked as such).

fast.ai, with the mission of making deep learning more accessible, isn’t an obvious home for a conda distribution. We created fastchan because we needed it for ourselves and our users. Hopefully in the future the key players such as PyTorch, NVIDIA, Anaconda, and conda-forge will solve the distribution problem together, and make fastchan obsolete!

20 Years of Tech Startup Experiences in One Hour

I’ve just returned to Australia to live, after a decade as an entrepreneur in San Francisco. For my first in-person talk in Australia, I shared my thoughts on how to build a successful tech startup nearly anywhere in the world. I spent nearly three months researching and preparing for this talk, interviewing dozens of entrepreneurs, investors, and academics. I also drew from my 20+ years of experience as an entrepreneur — ten years in Australia, and ten years in the US.

Creating a tech startup in the San Francisco Bay Area (i.e. San Francisco, Silicon Valley, and Oakland) is easier than most other parts of the world (except, perhaps, for a couple of startup hubs such as Israel). When I got to San Francisco I found myself in the midst of a bustling ecosystem of technically sophisticated cashed-up investors, bold founders with big ambitions and a real desire to help each other, entrepreneurial academics who often had multiple startups they were advising and were common destinations for their students for internships and employment, and big forward-thinking customers with innovation labs in the heart of San Francisco.

In Australia, things couldn’t be more different. More is invested in tech startups in a day in the US than in a year in Australia. Short-termism is rife at all levels. Entrepreneurs have to deal with pointless roadblocks put in their way by bureaucratic institutions.

And yet, Australia is full of brilliant talent, just waiting to be unleashed on the world. I believe that there are ways for potential Aussie founders to create successful global startups. And I believe that these lessons are equally valuable for founders in many other parts of the world, where the startup ecosystem is weak, and industry is conservative and slow moving.

For more, see my talk:

Or alternatively, read this summary of my talk from Aman Arora, who flew all the way from Sydney to Brisbane to attend, and was kind enough to write up his takeaways in a thoughtful article.

I violated a code of conduct

Update Oct 30, 2020: NumFOCUS has apologized to me. I accept their apology. I do not accept their assertion that “At the time of the interview, the committee had not determined that there was a violation of the code of conduct, only that there were two complaints filed and being examined.” The email to set up the call said “We would like to schedule a meeting so that we can discuss the results of our investigation with you” - nothing further. During the call, the committee stated the list of violations, and said “that is what the reporters stated, and what we found”. I asked why they didn’t take a statement from me before that finding, and they said “we all watched the video, so we could see for ourselves the violation”. The committee offered in their apology email to me to have a follow-up discussion, and I declined the offer.

Summary: NumFOCUS found I violated their Code of Conduct (CoC) at JupyterCon because my talk was not “kind”, because I said Joel Grus was “wrong” regarding his opinion that Jupyter Notebook is not a good software development environment. Joel (who I greatly respect, and consider an asset to the data science community) was not involved in NumFOCUS’s action, was not told about it, and did not support it. NumFOCUS did not follow their own enforcement procedure and violated their own CoC, left me hanging for over a week not even knowing what I was accused of, and did not give me an opportunity to provide input before concluding their investigation. I repeatedly told their committee that my emotional resilience was low at the moment due to medical issues, which they laughed about and ignored, as I tried (unsuccessfully) to hold back tears. The process has left me shattered, and I won’t be able to accept any speaking requests for the foreseeable future. I support the thoughtful enforcement of Code of Conducts to address sexist, racist, and harassing behavior, but that is not what happened in this case.


In my recent JupyterCon keynote, “I Like Jupyter Notebooks” (re-recording provided at the bottom of this post, if you’re interested in seeing it for yourself), I sought to offer a rebuttal to Joel Grus’ highly influential JupyterCon presentation “I Don’t Like Notebooks”. Joel claimed in his talk that Jupyter is a poor choice for software development and teaching, and I claimed in my talk that it is a good choice. The NumFOCUS committee found me guilty of violating their code of conduct for having not been “kind” in my disagreement with Joel, and for “insulting” him. The specific reasons given were that:

  • I said that Joel Grus was “wrong”
  • I used some of his slides (properly attributed) and a brief clip from one of his videos to explain why I thought he was wrong
  • That I made “a negative reference” to his prior talk
  • I was also told that “as a keynote speaker” I would “be held to a higher standard than others” (although this was not communicated to me prior to my talk, nor what that higher standard is)

Code of Conducts can be a useful tool, when thoughtfully created and thoughtfully enforced, to address sexism, racism, and harassment, all of which have been problems at tech conferences. Given the diversity issues in the tech industry, it is important that we continue the work of making conferences more inclusive, particularly to those from marginalized backgrounds. Having a code of conduct with explicit rules against violent threats, unwelcome sexual attention, repeated harassment, sexually explicit pictures, and other harmful behavior is the first step towards addressing and stopping those behaviors. The JupyterCon code provides the following examples of unacceptable behavior, none of which are at all similar to what I did (i.e. saying that someone was wrong on a technical topic, and explaining how and why):

  • Violent threats or violent language directed against another person
  • Discriminatory jokes and language
  • Posting sexually explicit or violent material
  • Posting (or threatening to post) other people’s personally identifying information (“doxing”)
  • Personal insults, especially those using racist or sexist terms
  • Unwelcome sexual attention
  • Advocating for, or encouraging, any of the above behavior
  • Repeated harassment of others. In general, if someone asks you to stop, then stop

My experience with the NumFOCUS code of conduct raises a few key issues:

  • The CoC enforcement process involved conflicting & changing information, no opportunity for me to give input, the stress of a long wait of unknown duration with no information about what I was accused of or what would happen next, and the committee members violated their own CoC during the process
  • There were two totally different Codes of Conduct with different requirements linked in different places
  • I was held to a different, undocumented and uncommunicated standard
  • The existence of, or details about, the CoC were not communicated prior to confirmation of the engagement
  • CoC experts recommend avoiding requirements of politeness or other forms of “proper” behavior, but should focus on a specific list of unacceptable behaviors. The JupyterCon CoC, however, is nearly entirely a list of “proper” behaviors (such as “Be welcoming”, “Be considerate”, and “Be friendly”) that are vaguely defined
  • CoC experts recommend using a CoC that focuses on a list of unacceptable behaviors. Both the codes linked to JupyterCon have such a link, and none of the unacceptable behavior examples are in any way related or close to what happened in this case. But NumFOCUS nonetheless found me in violation.

I would rather not have to write this post at all. However I know that people will ask about why my talk isn’t available on the JupyterCon site, so I felt that I should explain exactly what happened. In particular, I was concerned that if only partial information became available, the anti-CoC crowd might jump on this as an example of problems with codes of conduct more generally, or might point at this as part of “cancel culture” (a concept I vehemently disagree with, since what is referred to as “cancellation” is often just “facing consequences”). Finally, I found that being on the “other side” of a code of conduct issue gave me additional insights into the process, and that it’s important that I should share those insights to help the community in the future.


The rest of this post is a fairly detailed account of what happened, for those that are interested.

My talk at JupyterCon

I recently gave a talk at JupyterCon. My partner Rachel gave a talk at JupyterCon a couple of years ago, and had a wonderful experience, and I’m a huge fan of Jupyter, so I wanted to support the project. The conference used to be organized by O’Reilly, who have always done a wonderful job of conferences I’ve attended, but this year the conference was instead handled by NumFOCUS.

For my talk, I decided to focus on Jupyter as a literate and exploratory programming environment, using nbdev. One challenge, however, is that two years earlier Joel Grus had given a brilliant presentation called I Don’t Like Notebooks which had been so compelling that I have found it nearly impossible to talk about programming in Jupyter without being told “you should watch this talk which explains why programming in Jupyter is a terrible idea”.

Joel opened and closed his presentation with some light-hearted digs at me, since I’d asked him ahead of time not to do such a presentation. So I thought I’d kill two birds with one stone, and take the opportunity to respond directly to him. Not only was his presentation brilliant, but his slides were hilarious, so I decided to directly parody his talk by using (with full credit of course) some of his slides directly. That way people that hadn’t seen his talk could both get to enjoy the fantastic content, and also understand just what I was responding to. For instance, here’s how Joel illustrated the challenge of running cells in the right order:

I showed that slide, explaining that it’s Joel’s take on the issue, and then followed up with a slide showing how easy it actually is to run all cells in order:

Every slide included a snippet from Joel’s title slide, which, I explained, showed which slides were directly taken from his presentation. I was careful to ensure I did not modify any of his slides in any way. When first introducing his presentation, I described Joel as “a brilliant communicator, really funny, and wrong”. I didn’t make any other comments about Joel (although, for the record, I think he’s awesome, and highly recommend his book.

The Code of Conduct violation notice

A week later, I received an email telling me that two CoC reports were filed regarding my JupyterCon keynote presentation. I was told that “The Code of Conduct Enforcement Team is meeting tomorrow to review the incident and will be contacting you to inform you of the nature of the report and to understand your perspective”.

The CoC wasn’t mentioned at all until after I’d been invited to speak, had accepted, and had completed the online registration. I had reviewed it at that time, and had been a bit confused. The email I received linked to a JupyterCon Code of Conduct, but that in turn didn’t provide much detail about what is and isn’t OK, and that in turn linked to a different NumFOCUS Code of Conduct. A link was also provided to report violations, which also linked to and named the NumFOCUS CoC.

I was concerned that I had done something which might be viewed as a violation, and looked forward to hearing about the nature of the report and having a chance to share my perspective. I was heartened that JupyterCon documented that they follow the NumFOCUS Enforcement Manual. I was also heartened that the manual has a section “Communicate with the Reported Person about the Incident” which says they will “Let the reported person tell someone on the CoC response team their side of the story; the person who receives their side of the story should be prepared to convey it at the response team meeting”. I was also pleased to see that much of the manual and code of conduct followed the advice (and even used some wording from) the brilliant folks at the Ada Initiative, who are extremely thoughtful about how to develop and apply codes of conduct.

One challenge is that the JupyterCon CoC is based on Django’s, which has very general guidelines such as “Be welcoming” and “Be considerate”, which can be taken by different people in different ways. The NumFOCUS code is much clearer, with a specific list of “Unacceptable behaviors”, although that list includes “Other unethical or unprofessional conduct”, which is troublesome, since “unprofessional” can be catch-all gate-keeping mechanism for whatever those in the “profession” deem to be against their particular norms, and which those outside the in-group (like me) can’t be reasonably be expected to know.

Some of these issues are discussed in an excellent presentation from Valerie Aurora, who explains that “a code of conduct should contain” “behaviors which many people think are acceptable but are unacceptable in your community”, and that “If you want to list good behaviors or describe the community ideal of behavior, do it in a separate document”, and in particular “Do not require politeness or other forms of ‘proper’ behavior”. Pretty much all of the JupyterCon code of conduct is a list of forms of ‘proper’ behavior (e.g. “be friendly”, “be welcoming”, “be respectful”, etc.) While broader and more subjective values, such as “be kind”, can be useful as part of a conference’s values, it is less clear if or even how they should be enforced via a code of conduct.

Overall, I felt very stressed, but hopeful that this would be resolved soon.

The calls

The promised call happened the next day. However, the representative told me that they would not be informing me of the nature of the report at that time, and would not be seeking to understand my perspective at that time. I asked why the change of plans. The representative explained that they had had a committee meeting and had decided to wait until they had spoken to the two reporters.

I was stunned. The representative could not even commit to a time when they would get back to me, or tell me what would be happening next. I told them that I thought that telling someone that they had a violation report, but then not saying what it is, or when or whether they would be able to provide their side of the story, or providing any time-frame for any next step was cruel. I told them that my emotional resilience was not high, since I’ve been dealing with challenging family health issues, and that I hoped they would consider changing their approach for other people in the future, so they wouldn’t have to deal with an open-ended and obscure charge like I did.

The representative explained that I had “made at least two people feel uncomfortable”. I told them that I really didn’t think that was fair. We shouldn’t be held responsible for other people’s feelings. As a proponent of Nonviolent Communication I believe that we should share how we feel in reaction to the words or deeds of others, but should not blame others for these feelings. Furthermore, if it is a requirement that talks make people feel comfortable, that should be clearly communicated and documented (NumFOCUS did neither).

The next call did not happen for another week (I had made myself available to meet any time). I was shocked to read that the purpose of the call would be to “discuss the results of our investigation”. I could not understand how they could have completed their investigation and have results, without any input from me. Nonetheless, I agreed to the call; I figured that all I needed to do was dial in, hear the results, and I was done.

The reports

One the call, I was surprised to find myself facing four people. The previous call had been with just one, and suddenly being so greatly outnumbered made me feel very intimidated. One of the representatives started by telling me exactly what the finding was. The reporters claimed, and the committee agreed, that there had indeed been a code of conduct violation, specifically in failing to be “kind to others” and in “insulting others”.

I was stunned. I think Joel is great, and I know for a fact that he doesn’t mind being called “wrong” (since the call I checked with him). I most certainly did not insult him. I said that I think his approach to coding is sub-optimal, and specifically that it would benefit from using Jupyter. I showed a clip of him live coding to demonstrate that. I found it shocking that part of the findings of the committee would be a claim as to why I showed a particular slide, especially considering they never even asked. I have no desire to discredit Joel, and I don’t think that my view that his coding setup is sub-optimal should be considered a slight on his character.

Could it be argued that I was not “kind”. I guess it could. I did a parody. In some ways, this is kind – it shows that (and I explicitly said this) that I think his presentation is brilliant and highly influential, to the extent that I put in a significant amount of time studying it and working with the jokes and structure as best as I could. On the other hand, I did indeed say he is wrong, and tried to show the errors he made by pointing them out directly on his slides; I don’t think that’s unkind, but it seems that NumFOCUS committee disagrees. Personally, I don’t think it can be argued I was insulting him. It’s quite possible to debate someone and say they’re wrong, without claiming they’re a bad person or saying mean things about their person. The JupyterCon CoC even mentions this: “When we disagree, try to understand why. Disagreements, both social and technical, happen all the time and Jupyter is no exception”.

There is a huge disparity between the examples that are provided on the Jupyter and NumFOCUS codes compared to what I was being charged with. Here’s the list from NumFOCUS of “unacceptable behaviors”:

  • The use of sexualized language or imagery
  • Excessive profanity (please avoid curse words; people differ greatly in their sensitivity to swearing)
  • Posting sexually explicit or violent material
  • Violent or intimidating threats or language directed against another person
  • Inappropriate physical contact and/or unwelcome sexual attention or sexual comments
  • Sexist, racist, or otherwise discriminatory jokes and language
  • Trolling or insulting and derogatory comments
  • Written or verbal comments which have the effect of excluding people on the basis of membership in a specific group, including level of experience, gender, gender identity and expression, sexual orientation, disability, neurotype, personal appearance, body size, race, ethnicity, age, religion, or nationality
  • Public or private harassment
  • Sharing private content, such as emails sent privately or non-publicly, or direct message history, without the sender’s consent
  • Continuing to initiate interaction (such as photography, recording, messaging, or conversation) with someone after being asked to stop
  • Sustained disruption of talks, events, or communications, such as heckling of a speaker
  • Publishing (or threatening to post) other people’s personally identifying information (“doxing”), such as physical or electronic addresses, without explicit permission
  • Other unethical or unprofessional conduct
  • Advocating for, or encouraging, any of the above behaviors

They also provide this samples of impact assessment on their enforcement guide:

These are behaviors that I strongly agree should be stopped, and the community should unite to stand behind this. But these are not the behaviors that the NumFOCUS committee focused on in this case, or in the sections of the CoC that I was found to have violated.

I have no idea what happened here – why some people decided to use a code that was, apparently, written to protect people from sexism, violence, racism, and intimidation, in this way. I know that I’ve made many enemies this year with my advocacy of universal masking, and have had to deal with constant harassment and even death threats as a result. I’ve also received a lot of abuse over recent years from some due to my attempts to democratize AI, from those who have felt their privileged positions threatened.

What now?

After they told me of the reports and their finding that I had violated the code of conduct, they asked if I had anything to say. I told them I didn’t. I’d only mentally prepared myself for what they said the call was about: to inform me of the findings. I told them I didn’t think it would be that useful, since they’d already completed their investigation and made their findings. I didn’t have a emotional resilience to engage in a discussion, and I told them that. One person then chuckled in response, and as I struggled to hold back tears he started talking at some length about how the next phase is for me to help them decide on next steps.

I had already told the committee that I wasn’t able to have a discussion. One of the NumFOCUS “unacceptable behaviors” is: “Continuing to initiate interaction (such as photography, recording, messaging, or conversation) with someone after being asked to stop.” Since he was ignoring my request, I interrupted him, repeated that I couldn’t carry on, and terminated the call. I really didn’t feel like having a committee of people I didn’t know watch me sobbing.

I’m an independent, self-funded researcher. I don’t have a legal team, a comms team, or colleagues to support me. I’m a rare kind of voice at conferences, which are mainly populated by people from big companies, well-funded universities, and hot startups.

It seems that perhaps the NumFOCUS policy just is not designed to consider the rights and mental health of people that are accused. Their policy says “As soon as possible, let the reported person know that there is a complaint about them (before the response team meeting)”, and that in approaching the accused, they should say ‘This behavior isn’t appropriate for our event/meetup’, and they should “Emphasize the result/impact of the behavior and that it should cease/stop”. In short, many parts of the document, including this one, assume guilt, and do not show any consideration for the accused. The potential for misuse and weaponization of such a code is of concern.

I’ve tried to make myself available for public speaking events when I can, in order to support the community. However, the potential cost is too great, and there is no real upside for me personally, so I don’t expect to be accepting invitations in the future, at least not for quite a while. I will of course complete those commitments I’ve already made.

I was not able to cope with the NumFOCUS CoC process. Although I’m not in the best position at the moment to handle something like that, I’m much better off than many. For one thing, I’m a white, cis, straight male, and I have had some success in my life which has helped my self-confidence. I’m also financially independent, and do not need the approval or support of the influential NumFOCUS organization. Many people, facing the same situation, may well feel forced to go along with the process, even if it is an emotional burden they are not well able to deal with. Many people who do not benefit from the privilege I have may not even realize they have the ability to say “no”. It was assumed by the committee that I’d have the mental toughness to be ready to face, via video, four people I didn’t know, as they told me of my “violations” and demanded I help them decide on next steps. Limiting NumFOCUS conference speakers to only those ready and able to handle such a situation may significantly limit the diversity of NumFOCUS conferences. NumFOCUS recently “screwed up badly” and has a lot of work to do to improve diversity in its community. Improving its Code of Conduct and enforcement process to meet the ideals of kindness, fairness, respect, and consideration that it demands of others, may help in this direction.

I don’t want this situation to stop my work from being available, so I’ve created a new independent recording of the talk, using the exact same slides and material. However I didn’t use a script for either talk, so the wording won’t be identical. The video is below. The PowerPoint slides are here.

PS: To the many friends I have at NumFOCUS, and those involved in the many projects I use and admire at NumFOCUS: this isn’t about you. You are all still just as awesome as ever, and I very much hope that my experiences with your Code of Conduct committee won’t in any way effect our relationship.

Avoiding the smoke - how to breath clean air

If you’re in western USA (like us) at the moment, you might be finding it hard to breath. Breathing air that contains the fallout from fires can make you feel pretty awful, and it can be bad for long-term health as well. Wildfire smoke contains fine particulate matter, known as “PM2.5”, which can be inhaled deep into the lungs. The “2.5” here refers to the size of the particles — they are 2.5 microns or smaller. To see the air quality in your area, check out this AirNow map. Once it’s orange, you might find you start feeling the effects. If it’s red or purple, you almost certainly will. (Sometimes it can appear smokey outside, but the air quality can be OK, because the smoke might be higher in the atmosphere.)

The good news is that there’s a lot you can do to make the air you breathe a lot better. You might be wondering why a data scientist like me is commenting on air filtration… The reason is that I was a leader of the Masks4All movement, including writing the first and most comprehensive scientific paper on the topic, which meant I studied filtration very closely for months. In fact, the size of particles we want to block for wildfires is very similar to the size of particles we want to block for covid-19!


The three ways that you can breathe cleaner air are to use a mask, filter your home central airconditioner or heater, and use fans with filters. I’ll show you the details below. (There’s quite a few links to places you can buy products in this post; I don’t get any commission or anything from them, they’re just things that I’ve personally found helpful.)


Therefore, you won’t be surprised to learn that one of the most effective things that you can do is to wear a mask. To block most PM2.5 particles you’ll want a mask that’s well-fitted and uses a good filter material. I’ve already prepared advice on that topic for COVID-19, and pretty much all of it is exactly the same for wildfire PM2.5, so go read this now. One bit that’s less of an issue is the “Sanitation” section — wildfire PM2.5 particles aren’t bearing disease, so you only have to worry about sanitation if your mask is actually getting dirty (or if you’ve been out in public with it on).

Personally, I like the O2 nano mask, or any well-fitted mask that you can insert a Filti filter in to. Recent aerosol science tests show that a neck gaiter folded to create two layers works well too (but make sure you add a nose clip to remove gaps around your nose). Check out Etsy for lots of mask designs that include a filter pocket and nose clip.

Choose from thousands of mask designs with a filter pocket
Choose from thousands of mask designs with a filter pocket

Filtering your home air

To clean the air in your home, the basic idea is to have it getting continually pushed through a filter. A filter is simply a piece of material which air can get through, but PM2.5 particles can’t. No filter is perfect, but there are readily-available options which work very well. Filters have a MERV rating, which tells you how many small particles they remove. For wildfire, you generally want MERV 13.

Don’t just buy the highest rating filter you can find. Filters with higher ratings have smaller holes (generally speaking), which means they also don’t let air through as fast. Remember, we want your home air going through the filter quickly, to ensure all your air is getting cleaned, so we don’t want the filter to negatively impact air-flow too much. I recommend Filtrete™ Healthy Living Air Filters. These have good air flow even for the MERV 13 spec.

Adding a filter to your central air

If you’ve got central heating or air conditioning, then you’re in luck. That will have strong fans, covering all of your rooms. The trick is to filter the air coming in to the system. Nearly all home systems simply pull their air in through a large vent inside your home. Some units have a filter slot in the unit itself, whereas for some the input vent is in a totally separate location in the house. Note that air conditioners blow air out to outside the house, but they don’t suck air in from outside the house (except, generally, for more fancy commercial building HVAC systems).

Once you’ve found the inlet vent that your central air is pulling in from, add a filter to it. If there’s already one there, make sure it’s MERV 13 or 14. You should change it every 3 months or so (depending on the brand). A vent with a filter installed looks like this:

An inlet vent, showing filter underneath
An inlet vent, showing filter underneath

NB: Most filters have an arrow on the side showing the direction of airflow. So make sure you put it the right way around! Also, make sure you buy the right size. Measure the size of your vent, and buy a filter that is at least big enough to cover the hole. If there are gaps, the air will go through them, instead of your filter!

If there’s not a obvious place to add a filter to your vent, you’ll need to get creative. It might not look pretty, but you could always just remove the vent cover and fasten the filter straight over the top, using tape, poster tack, etc.

Once you’ve got your filter in place, the most important thing is to set your central air settings such that it has the fan running all the time. Most systems have an “auto” setting , which only turns the fan on when heating or cooling. You don’t want that! Set the fan to “on”, not to “auto”. That way, you’re getting as much air through that filter as possible.

Adding filters to fans and portable A/C

I recommend having an air purifier in every room. Most air purifiers don’t really do that much, because they’re normally quiet and small (which means they don’t move much air). There are extra large purifiers for sale, but they’re very expensive, and often sold out at the moment.

But we can create our own air purifier that works as well or better than the big expensive ones. An air purifier is simply a fan blowing air through a filter. So if we use a big fan and a good filter, then we have a good air purifier! The trick is to buy a 20 inch “box fan” (which is just a fan in a 20 inch square box), and stick a 20 inch filter in front of it. We pick 20 inches because that’s pretty big, and a bigger fan and bigger filter means more filtration can happen in a given time.

I bought a few of these box fans: PELONIS 3-Speed Box Fan. I’m not saying this one is any better or worse than any other — just buy whatever you can get your hands on. You want one that has a high speed setting, to push lots of air through.

For filters, anything of the right size and MERV 13 or 14 spec should be fine. I bought this pack of 6 20 inch Filtrete filters. Generally, higher quality filters will allow better air flow. Also thicker filters can increase airflow too; e.g. instead of the 20x20x1 filters I got, you could try 20x20x4 (4 inch thick) filters.

The fans I bought have the on/off/speed switch on the front, so I first turned that to the maximum speed setting, since once I attached the filter I couldn’t access the switch any more. Then I stuck some of this adhesive foam all the way around the front face of the fan, trying to leave no gaps. The idea is that when I then stick the fan on top of this, there will be as few gaps as possible. It would probably work just as well to stick a long piece of poster tack all around the front face. Finally, I stuck the filter to the front of the fan by using a generous quantity of high quality packing tape.

The completed DIY air purifier
The completed DIY air purifier

These things are pretty noisy! But it’s a lot better than having a smoky house. They’re also pretty good for helping keep COVID-19 at bay, so if you have a shop or business, sprinkle a few of these around the place if you don’t have good filtered HVAC with a high change rate.

Another approach I’ve found useful is to buy a compact portable air conditioner. These come with a hose that blows hot air out through your window, and sucks air in through the front or back of the unit. You can stick a filter in front of where it sucks air in, using a similar approach to the fan discussed above.


Many thanks to Jim Rosenthal of Tex-Air Filters, and to Richard Corsi for the home-made air purifier idea. Jim has a fancier version for those with the budget. Thanks also to Jose-Luis Jimenez, Linsey Marr, Vladimir Zdimal, Adriaan Bax, and Kimberly Prather for many discussions that have helped me improve my (still limited!) understanding of aerosol science.