Author Archives: Jason

Don’t “trust the science”

I think “trust the science” is a bad thing to say. I think it hurts the cause of science. Here’s why.

The first problem with “trust the science” is the “trust” part. I don’t think a scientifically-minded society (presumably the kind of society the “trust the science” people want) would use trust as one of the main tools in its intellectual toolbox. In fact, a scientifically-minded person is not a trusting person (at least when it comes to knowledge acquisition) but rather a questioning and skeptical person.

Every time a scientifically-minded person is presented with a claim, that person should ask, “Why should I believe that this is true?” They should require evidence that supports the claim as a condition to believing that claim. They should use logic and reason to scrutinize the claim and rigorously try to find any holes, flaws, lies, tricks, mistakes or confusions in the claim. Only once the claim has passed a thorough set of scrutinizing tests should the person upgrade the idea’s status from “claim” to “belief”. And even then, the belief should be tentative, subject to revision in light of new information.

The other problem with “trust the science” is the “the science” part. Saying “the science” seems to suggest that science is a body of knowledge. But science isn’t a body of knowledge, it’s a technique for gaining knowledge.

When you’re talking about a technique that works, trust doesn’t come into the picture. I don’t “trust” trigonometry, I just use it. For me to trust trigonometry would be neither necessary nor helpful. When I plug numbers into the Pythagorean Theorem and solve the equation, the Pythagorean Theorem gives me the right answer whether I trust it or not. I don’t trust that trigonometry works, I acknowledge that it works.

Unlike the Pythagorean Theorem, science isn’t guaranteed to always give the right answer. Science is carried out by human beings. Humans are notoriously fallible and subject to self-delusion and dishonesty. A scientific claim should be given credence with proportion to (among other things) how much opportunity there has been for that claim to undergo scrutiny.

There are of course certain ideas in science that have been subjected to intense scientific scrutiny over and over and, each time, those ideas have survived intact. A couple famous examples of such ideas are Darwin’s theory of evolution and Einstein’s theory of general relativity. These ideas have survived scrutiny so successfully that no serious person questions them anymore – although I have no doubt that a good scientist would question these theories if extraordinary and credible new evidence were to arise that contradicted them. But despite how solid the theories of evolution and general relativity are, I’ve never heard these ideas referred to by a scientist as “the science”. And I’ve certainly never heard a scientist make a call to trust the science. Instead (particularly in the example of evolution) scientists appeal to evidence, logic and reason. We should believe that the theory of evolution is true not because scientists say it’s true, but because the theory of evolution accords with evidence, logic and reason better than any other theory that has been put forth to try to explain the origin of species.

One argument that I’ve heard in favor of “trust the science” is that laypeople don’t have access to the source material, and so there’s no choice but to trust the science. But that’s not “trusting the science”, that’s trusting authority. Trusting authority is fine, with certain qualifications (although it’s often very bad too). If for example Richard Dawkins tells me that there are 68 species of kangaroo, then I’m inclined to take his word for it. I generally trust Richard Dawkins to be able to convey true facts about biology, and I don’t feel inclined to fly to Australia to verify for myself that there are in fact 68 species of kangaroo. But that’s not me “trusting the science”, that’s me trusting Richard Dawkins.

Obviously, the thing people have been talking about when they’ve recently implored people to “trust the science” is “the science” on COVID-19 and the COVID-19 vaccines. Even if science were a body of knowledge, which of course it’s not, it would be hard for me to accept the idea that there’s a single body of claims regarding coronavirus vaccines that could be called “the science on COVID-19 vaccines”. And it would also be hard for me to tell what that body of knowledge supposedly was. I think the real message when many people say “trust the science” is “trust the authority figures who are saying to get the vaccine”.

When the COVID-19 vaccines first became available, I got vaccinated as soon as I could. It wasn’t even a question. The reason wasn’t because I “trusted the science” or trusted any authority figures who were giving advice about COVID-19 vaccinations. The reason was because I had already made up my mind long ago, based on common sense and an understanding of history, that vaccines are on average very safe and hugely effective in fighting disease.

For all I know it may be true that the COVID-19 vaccine is a significantly more risky vaccine than most “regular” vaccines. But it doesn’t matter, because what matters is not the comparison of the COVID-19 vaccine to other vaccines but rather the comparison of getting the COVID-19 vaccine versus the risk of getting COVID-19 itself. Obviously (to me), the risk of getting COVID-19 is a much worse risk to take. Again, no “trusting the science” involved. Not even a high level of very accurate knowledge required. Just a little bit of easy logic.

I hope the phrase “trust the science” goes permanently out of fashion. Science is one of the best things humanity has ever come up with. Science is responsible for a large number of dramatic improvements to the human condition, including the eradication of horrible diseases and virtually every other medical advance. But there’s no such thing as “the science” as in a body of knowledge, and it doesn’t make any more sense to “trust” science than to “trust” (to use the example again) trigonometry. Saying “trust the science” misunderstands science and helps make an already scientifically-illiterate society even more scientifically-illiterate. Instead I think we should acknowledge the validity of science as a knowledge acquisition method and make use of our own reason, logic and critical thinking.

February 2020 Revenue Report

I launched Rails Testing for Beginners to my new subscribers in February.

2020 February $235
2020 January $268
2019 December $0
2019 November $0
2019 October $168
2019 September $0
2019 August $426
2019 July $40
2019 June $0
2019 May $481
2019 April $98
2019 March $1037
2018 October $400
2017 June $185
2017 May $480
2017 April $735
2017 March $352
2017 February $449
2017 January $371
2016 December $428
2016 November $871
2016 October $1580
2016 September $1053
2016 August $868

January 2020 Revenue Report

I’m not making an individual post for December 2019 because there were no sales.

In January I launched a new product called Production Rails, which made about $268 in sales. I ended up deciding the creation of the product was a mistake and I refunded everyone.

2020 January $268
2019 December $0
2019 November $0
2019 October $168
2019 September $0
2019 August $426
2019 July $40
2019 June $0
2019 May $481
2019 April $98
2019 March $1037
2018 October $400
2017 June $185
2017 May $480
2017 April $735
2017 March $352
2017 February $449
2017 January $371
2016 December $428
2016 November $871
2016 October $1580
2016 September $1053
2016 August $868

2019 Review and 2020 Goals and Plans

2019 has been a pretty interesting year. Here are some of the high points.

What went well in 2019

I didn’t flail around too much with product endeavors

My earnest attempts at building a successful product business started around 2008. In the time since then there have been a number of periods, some lasting many months, where I was completely without direction, just wildly flailing. These periods sucked because they were so obviously unproductive.

From February 2018 to now (December 2019), I’ve been pretty much steadily focused on the business I refer to as CodeWithJason.com. Obviously it’s good to stick with one thing for a long time, as long as it’s a good thing. I’ve definitely been guilty in the past of going around and laying foundation after foundation without sticking around to build the whole house. In this case I actually have stuck around long enough to build a good portion of the house.

I stuck with one client the whole year

In my career I’ve worked for a lot of different bosses and freelancing clients. A good portion of the people I’ve worked for and the teams I’ve worked with I frankly haven’t cared for that much, and haven’t worked for that long. (I’ve also worked for a number of startups that have had financial troubles, and so a number of relationships have ended that way.) Fortunately, in the late summer of 2018, I started a relationship with a client I like working with a lot, so much so that I expect he and I will work together for the indefinite future. (This relationship is what prompted me to quit freelancing.)

I got some good conference speaking gigs

Before the fall of 2018 I had never spoken at a conference at all. As of now I’ve spoken at 9 conferences, if I’m not mistaken. I’d say my biggest two speaking achievements of 2019 were speaking at RubyConf India, which was my first international conference talk, and RailsConf, which is of course the flagship Rails conference. I also really enjoyed speaking at RubyHACK in Salt Lake City and Southeast Ruby in Nashville.

My podcast endeavors went well

In May of 2018 I semi-experimentally started a podcast called The Ruby Testing Podcast. It was successful beyond my expectations. My guests included Michael Hartl and Kent Beck. To date I’ve gotten over 30,000 downloads.

Encouraged by my success with The Ruby Testing Podcast, and wanting to no longer be limited to the topic of testing, I decided to start a broader podcast called Rails with Jason. I’ve been happy with how it has turned out content-wise, for the most part, and I’ve had a number of big-name guests.

What didn’t go as well in 2019

The conferences were expensive

All the conferences I spoke at required some level of out-of-pocket expense.

When I first started seriously pursuing conference speaking around mid-2018 or so, my hope and expectation was that my conference talks would lead to lucrative consulting engagements (training gigs, specifically) that would give me a worthwhile return on my investment. Unfortunately those consulting leads never came in, or at least they haven’t yet. I can’t say these investments didn’t pay off, I can only say they haven’t yet, because it wouldn’t surprise me at all if I get a consulting lead 10 years from now from someone I met at a conference this year. I’ve found that the gestation time for consulting leads is often several years.

Anyway, the point is that I spent a bunch of money speaking at conferences and as of now I haven’t recouped my investment. So I’m probably going to take it easy on conferences in 2020. I plan to speak at perhaps one conference or maybe none.

CodeWithJason.com grew less than I expected

When I launched Rails Testing for Beginners in March, I did $988 in sales, which was the biggest launch in my limited career of doing product launches. Unfortunately things have only gone downward from there. Here’s a graph of year-to-date sales.

More concerning than the revenue numbers, my email list has only grown by a net of about 200 subscribers since March, or about 24 per month on average. That’s 288 new subscribers a year, which hardly seems like enough to sustain a viable business. I’m not ready to quit yet though. I think it’s reasonable to expect that audience growth can be somewhat exponential. Maybe in 2020 my email list will instead grow by 400 subscribers, and then 800 in 2021, and so on. We’ll see how things go. And of course, I intend to try to figure out how to deliberately make that number go up faster.

Other stuff that happened in 2019

In the later half of 2019 I had two great product ideas. One was a Rails CI tool with ridiculous parallelism built in that would allow you to run any test suite in under 10 seconds (I built a POC and it really worked!). Another was a tool that would make AWS + Rails deployment almost as easy as Heroku (which I also built a working POC for).

Unfortunately I discovered that each one of these two ideas would require a lot more time to get going than I really have available. Fortunately, I’m experienced enough now to bail early on doomed ideas instead of burning years of my life beating a dead horse.

Plans for 2020

Since I no longer consider myself a freelancer, and since I have a “day job” that I’m okay with keeping indefinitely, that makes that part of my 2020 plans easy. Unlike previous years, I won’t be spending time trying to get consulting clients or anything else on that side of things.

That leaves my product endeavors to focus on for 2020. Here are my plans in that area.

For CodeWithJason.com, I plan to improve and expand Rails Testing for Beginners, then re-launch it. In fact, I’ve already expanded RTFB from 99 pages to 189 pages by bringing in a bunch of the Rails testing blog posts I’ve written over the last several months. I’ve also begun radically redesigning and improving the sales page.

I also plan to try again with the AWS + Rails thing, but smaller this time. Building a whole software product to make AWS + Rails deployments easier is too time-consuming. So maybe I can do something smaller, like just write a blog post about how to deploy Rails to AWS. Then maybe I can build a tool or even just a set of scripts that makes parts of that deployment process easier.

I also decided to set a model financial goal for CodeWithJason.com. My 2019 revenue was about $2100 (which could conceivably still go up), so I’ll see if I can roughly double my revenue for 2020, and hit $5000.

November 2019 Revenue Report

November’s revenue report is pretty boring. No sales.

Here’s my revenue for past months.

2019 November $0
2019 October $168
2019 September $0
2019 August $426
2019 July $40
2019 June $0
2019 May $481
2019 April $98
2019 March $1037
2018 October $400
2017 June $185
2017 May $480
2017 April $735
2017 March $352
2017 February $449
2017 January $371
2016 December $428
2016 November $871
2016 October $1580
2016 September $1053
2016 August $868

October 2019 Revenue Report

In October my revenue was $168. I didn’t do any launches or anything. These sales were just “natural”.

Here’s my revenue for past months.

2019 October $168
2019 September $0
2019 August $426
2019 July $40
2019 June $0
2019 May $481
2019 April $98
2019 March $1037
2018 October $400
2017 June $185
2017 May $480
2017 April $735
2017 March $352
2017 February $449
2017 January $371
2016 December $428
2016 November $871
2016 October $1580
2016 September $1053
2016 August $868

Pulling the plug on Exosuit

After about two months of working on it, I’ve decided to stop working on Exosuit, the tool I’ve been building to make Rails + AWS deployments easier.

The reason for my decision is that I decided that the amount of time it would take to get Exosuit off the ground (in terms of hours per day) is substantially more time than I have available.

I know from painful past experience that it’s not enough to build the product. The product also has to be marketed. The marketing work takes a serious amount of time and effort. For a relatively complex software project such as Exosuit, I don’t have time to do the programming work, the marketing work, AND have a day job.

For context, I had spent about 2 months working on the Exosuit “MVP” and in that time I maybe only got about halfway done, estimating generously. I would have spent another 2, 4 or 6 months building the thing before it would even have been un-fragile enough to let another person touch it. Throughout all that time, all marketing work would be 100% on hold. That seems like a really risky plan.

I still think the product idea is a good one. I hope to come back to it someday. I just don’t have the resources at the present to build it and turn it into a viable business.

My plan now is to turn my attention back to building my email list and selling Rails-related info products. That stuff hadn’t been going as well as I would have liked, but my current thinking is that it’s a better bet to try to improve what was already working than to try a totally new thing.

Why immortality would be terrible

Some people think it would be nice if humans could live forever. I’ve heard of people in Silicon Valley trying to work on ways to allow people to live indefinitely.

I think immortality is actually a real bad idea, and I think these Silicon Valley guys’ endeavor is naive and crazy. I’ll explain why, starting with total immortality (which is impossible, for reasons I’ll describe) and then turning to the idea of an indefinite lifespan (which theoretically is possible).

To me, the most glaring and obvious problem with immortality is the inevitability of something happening to you that’s both really bad and basically permanent. For example, imagine that 62,000 years into your life, you’re on a boat by yourself. The boat sinks to the bottom of the ocean and traps you. No one but you knows that this happened, so you spend the rest of eternity trapped at the bottom of the ocean. Or think about the inevitably of eventually being falsely accused of murder and spending the rest of eternity in prison. I can even imagine a war where prisoners of war are hooked up to torture machines that torture them for the rest of eternity. Those things would obviously be really bad.

I also imagine that an eternal life would mean an infinite accumulation of emotional pains and regrets. As I’ve gotten older I’ve noticed that I have a growing backlog of regrets that my brain seems to enjoy picking from at random and surfacing to me in my mind periodically. Imagine making some huge regretful error at age 19 and then having to live with that mental burden for the next 1000, 100,000, 100 billion years.

Plus there are the logistical issues. If we somehow figured out how to get people to live forever, it’s still true that every star in the universe will eventually burn out. Then what? Even the idea of uploading a person’s consciousness onto a computer for eternal habitation doesn’t answer that problem.

I think death is actually perfect. You’re guaranteed that nothing that bad can happen to because either the bad thing will kill you or you’ll eventually die some other way and be done suffering. Death is nature’s “escape hatch”. You can accumulate a lifetime of mental weight, but then the slate is wiped clean. The “reset button” gets hit when someone dies and a baby is born.

I didn’t mention an obvious thing about immortality: it’s a physical impossibility because there’s no way a body could survive complete destruction. Even if you move consciousness to computers, the physical computers themselves aren’t absolutely impervious to destruction. It seems that the “next best thing” is an indefinite lifespan. I’ll explain why I don’t think an indefinite lifespan would be better than a normal human lifespan.

I suppose that if we figure out how to make humans live indefinitely, then that will necessarily mean that people won’t ever die of disease. So the only causes of death would be accidents, murder and suicide. So from the moment you’re old enough to understand it, you’ll be aware that your life will, as an absolute certainty, end in an accident or murder or suicide, most likely an accident (or maybe most likely suicide). To me this idea seems quite uncomfortable. I personally much prefer the idea that the most likely scenario of my death is just a faint petering out, “dying of old age”.

Also, as you get older, more of your friends and family would be dead the older you got. This is of course the way it is now. It would be more pronounced if indefinite life were possible. A person who managed to live to 5,000 would probably have very few 5,000 year-old peers. If you started life with 250 people you cared about and 0.1% of them died each year, it would take, by my calculations, about 6,000 years for almost all of them to die. Then you’d just be super lonely from then on. You could always make new friends, I suppose, but they’d all be much younger, and from a different world.

So, although I often get quite uncomfortable when I think about the reality that I’ll inevitably die, I find it comforting to consider that, among the (non-supernatural) alternatives, it’s probably actually the best possible way for life to be.

Technical update on Exosuit progress (10/10/2019)

I’ve been working somewhat feverishly for the last few weeks on Exosuit, my Rails + AWS deployment tool.

What Exosuit can do as of now

Install. You can install Exosuit by doing brew tap jasonswett/exosuit && brew install exosuit. I think this is pretty nifty.

Launch. You can run the exo launch command to launch a new EC2 instance. Exosuit will mark this instance in the Exosuit config file as the “primary” EC2 instance.

SSH. You can run exo ssh to SSH into the primary instance.

Install stuff. You can run exo prepare to install some stuff on the primary EC2 instance. This part is a work in progress and is not a part of the publicly-documented API yet. It might never be. This is just kind of an intermediate step to help make all my manual work less manual.

Register an app. My vision is that eventually you can run exo create, git push exosuit master, then exo open and see your fully-ready Rails app at a production EC2 URL. Right now, you can run exo create and, if you have an account at app.exosuit.io, you can register the app with “the mothership”. Why do this? Because the vision is that when you register your app with the mothership, the mothership will create a repo at git.exosuit.io, the CLI tool will do git remote add origin http://git.exosuit.io/your-app-name.git, and then anytime you do git push exosuit master, the Exosuit Git server can listen and automatically push to your production EC2 instance. I know that’s a lot of stuff. I plan to write something to explain it in more detail sometime. It’s all modeled after my understanding of how Heroku works.

My next steps

My current milestone target is the ability to run exo create and have Exosuit create a repo at git.exosuit.io. To do this in a fully secure manner is definitely non-trivial.

I currently have the Exosuit CLI working to where it can hit https://app.exosuit.io/api/v1/apps (again, “the mothership”), including the user’s app name in the payload. This will create a record in the mothership database to keep track of the fact that this user has this app.

Next I need to make it so the mothership can say “Hey, Exosuit Git server, create a blank repo for such-and-such app, and let me know if it actually worked.” I have a pretty good idea of how I’m going to accomplish all this, it’s just going to be a lot of work.

I also came up with some thoughts as to what the free vs. paid tiers of Exosuit might look like.

My current thinking on the economics of the Exosuit project (October 2019)

In September I started an OSS project called Exosuit. From the beginning I envisioned that there would be an economic component to Exosuit, that some functionality would be free and some functionality would be paid.

Here’s what I currently have in mind.

Free tier

The free tier will offer the core promise of Exosuit: the ability to deploy to AWS as easily as deploying to Heroku.

The premise I have in mind is that you, the developer, have an idea for an app in mind, and you want the path that leads from “I have an idea in my head” to “I have an application running in production” to be as quick and frictionless a path as it can possibly be.

This ease and simplicity will have a trade-off, though: the infrastructure you get when you run git push exosuit master (or whatever) will, out of necessity, be less robust than a full-blown production application with load balancers, scalable instances, etc.

Instead of a complex, sophisticated AWS infrastructure you’ll get a single EC2 instance, a single RDS instance, and the necessary security groups to wrap each. To me this still seems plenty good enough for a brand new app that’s just at the idea stage.

Paid tier

The paid tier will provide tools to help you “graduate” from the simple free tier infrastructure for an infrastructure more appropriate for a successful business application with real users.

Some ideas include:

  • Easy way to put instances behind a load balancer
  • Easy ability to scale instances (cattle vs. pets)
  • Convenient way to build and manage production and staging environments
  • Tools for common operations, e.g. copying production data to staging, recovering from RDS backup
  • Domain management, including SSL

All this is totally tentative and might change. For the foreseeable future I’ll be focusing on the free tier because I see a compelling free tier as the best possible marketing for a paid tier.