Exciting news, readers! I’ve started a new section of this blog called Blair’s Science Desk. I’m going to use this section to post tips about doing data-driven science.
In creating Science Desk, my goal is to separate two aspects of my writing. On the one hand, I like to write long pieces about original research. On the other hand, I also like to write short notes about doing science. When I started Economics from the Top down, it contained an equal mix of both types of writing. But over time, I’ve leaned more towards deep-dive posts, as the figure below makes clear.
My impression (and I could be wrong) is that readers are hungry for long-form content that is written accessibly. That’s good, because I enjoy writing it. And don’t worry, my post length isn’t going to continue heading north. I’ve found a happy medium with posts that are about the length of an academic paper, but are written in a way that is …. readable.
Still, I’m left with a problem. In addition to writing long form content, I like to write short pieces about research methods. But it is disjointing (for readers and myself) to intersperse the two types of writing.
That’s why I’ve started Science Desk. My intent is for it to function more like a traditional blog, with short posts about whatever crosses my mind. I know that this kind of technical babble isn’t for everyone, which is why I want it in a separate section. But hopefully some people will find it useful. A big part of doing empirical work is scouring the internet trying to learn how to solve your particular problems. I’ve spent countless hours doing that, and Science Desk is my attempt to pay it forward.
On a technical note
Speaking of technical stuff, I’m creating Science Desk using Hugo, an engine for building static websites.
What’s a ‘static website’ you say? I’ll tell you in a second. But first, some internet history. The internet is built on HTML, which is short for ‘hyper text markup language’. It’s a language that tells your browser how to render the content of a website.
In the beginning, people built websites by hand coding HTML. But as sites got more complex, this task became unwieldy. And so developers created systems for managing content. WordPress is probably the most famous such system. Instead of containing HTML, a WordPress site consists of a database that holds the website’s content. When someone visits the site, WordPress uses the database to render HTML. (Along the way, it applies various themes and styles.) Then it sends the result to your browser, which you read.
This content management approach is incredibly flexible. But it’s also complicated, and can be quite slow if not configured properly.
Enter static site generators. What these engines do, essentially, is move the content management from the web server to your home computer. In other words, you render your website before you upload it to the server. Then the server just has to send static HTML files to readers.
Now, you could hand code these HTML files. But that’s a lot of work. Static site engines like Hugo generate the HTML for you. And along the way, they can apply themes and styles, just like you would in WordPress.
Self hosting made easy
With easy-to-use blogging sites like Medium and Substack, why would you want to build a static website yourself? The biggest reason (at least for me) is that you have complete control over the site. Usually, though, this control comes with a cost, which is that you’re responsible for everything, including web hosting.
One reason that sites like Medium and Substack (not to mention WordPress.com) are so popular is that they take care of running the backend for you. And that’s great. Let’s face it, very few writers want the hassle of running a web server.
Here’s where static sites really shine. They give you complete control of your site, and yet they are extremely simple to host. To run a static site, you don’t need a traditional web server. All you need is cloud storage that can be made public. There are plenty of solutions for that, but I chose Linode, which is a medium-sized cloud company that is reasonably priced and has great customer service.1
Yes, there was a bit of a learning curve. But with a bit of coding, I can now spin up a site in minutes. I’m excited by the possibilities here, especially for teaching. Want a course website filled with content for students? No need to go through university bureaucracy. I can host my own site the way I like it.
No bells, no whistles
Back to Science Desk. When I started blogging, I was a total newbie, and so took the easy option of using WordPress.com. But today, I know more about how websites work. And, thanks largely to Cory Doctorow’s writing on Pluralistic.net, I’m aware of the perils of web centralization. I like Doctorow’s vision of a federated internet filled with content that is decentralized yet interoperable.
In many ways, Science Desk is an homage to the simpler, decentralized internet of the past. It’s got no bells and whistles and no distractions. That’s the way I like my science.
Support this blog
Economics from the Top Down is where I share my ideas for how to create a better economics. If you liked this post, consider becoming a patron. You’ll help me continue my research, and continue to share it with readers like you.
Stay updated
Sign up to get email updates from this blog.
This work is licensed under a Creative Commons Attribution 4.0 License. You can use/share it anyway you want, provided you attribute it to me (Blair Fix) and link to Economics from the Top Down.
- If you’re interested, here is a tutorial about how to build and host a static site on Linode’s object storage. Also, a hat tip to the LINUX Unplugged podcast for telling me about Linode.↩︎
You’ve prompted me to tell you this — if you think of complexity and writeup accessibility as pulling in opposite directions, then you can imagine a “complexity-accessibility product” with an upper bound that differs for different writers. Yours is one of the very highest bounds I’ve seen; I’m always amazed by your ability to do this. When I do analysis writeups at work I sometimes think “how would Blair Fix explain this?”
The simplistic take, which I can copy, is that you’re good at avoiding esoteric words when more familiar ones suffice, your sentences and paragraphs are short, you sprinkle visualizations liberally throughout that double as ‘article breaks’, and your writing style is conversational, sometimes even conspiratorial. This is simplistic because there’s something more to your style I can’t quite legibilize but which makes your voice distinctive. I don’t know what it is, but you have it in spades.
Anyway, thank you for writing, and for inspiring folks like me to try and explain complicated things more accessibly.
Hi Muhammad,
First, I’m glad you think that I’m good at explain complex ideas. The truth is that I work very hard at it.
I think you’ve highlighted some of the most important techniques. Part of learning to be an academic is learning the jargon that comes with the field. But to be a good communicator, you have to unlearn that jargon — or at least realize when you’re using it and make sure to explain it.
Also, abstractions make writing difficult to understand. So my rule of thumb is that every time I offer an abstraction, I try to immediately give a concrete example.
I also try to write as though I’m having a conversation with someone. I try to anticipate their questions, and bake them into the writing.
As for my specific style, well, I’m not sure I understand it myself. But I can say that I was deeply influenced by Richard Feynman’s style in the Feynman Lectures. It’s the opposite of most academic writing, which often sounds pompous. I like to write with a humorous tone. It works well when blogging. But sometimes peer reviewers don’t appreciate it 🙂