Author Archives: Jason

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.

September 2019 Revenue Report

My September revenue report is pretty simple: my revenue was $0. Not surprising because I didn’t do any launches.

Here’s my revenue for past months.

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

I’ve quit freelancing for the indefinite future

Over the last 8 years I’ve spent a lot of time studying, thinking about, and writing about freelancing. I’ve been a freelancer on and off—mostly on—since 2011. I had had a dream for a long time of building a high-income, low-labor lifestyle as a successful consultant, kind of like what Alan Weiss has done.

Since I’ve written a decent amount about freelancing on this site in the past, I feel it’s appropriate to give the following update: I’ve given up on my freelancing dream. It’s a good thing, though, because the only reason I decided to leave the path I was on is because I found what I believe to be a better path. (Also, I discovered that freelance programming is basically a sham and 99% of “freelance” programmers are just contractors and glorified employees and that the kind of success I was fuzzily envisioning is not really possible, but that’s a different story.)

What’s the new path I’m on? I don’t want to get too much into the details publicly but I’ll say that I’ve found myself in a monogamous relationship with a client who I like more than any other client I’ve worked with. He and I have been working together for just over a year. All the aspects of the working arrangement are good, about as good as one could hope for. It’s basically a job, but a really good job. I expect that my client and I will work together for many years to come and I don’t expect to be working with any other clients on the side during this time. So, no more freelancing. I’m not saying never again, because who knows what will happen 5 or 10 years from now, but no more freelancing for the foreseeable future.

What I’m NOT ready to give up on yet, or probably ever, is my endeavor to build a successful product business. I don’t think that part of me can ever be killed. You can follow my progress in that area in my Entrepreneurship Journal.

Suite Magic test runner: project aborted

Recently I had an idea for what I thought was (and still think is) a good idea for a product: a test runner/CI tool that can run any Rails test suite in about 30 seconds, no matter how big the test suite is. I even had a rough proof-of-concept working.

However, I decided to abandon the project. The reason is simple: I realized that the work involved in building this product/business would almost certainly be too much. As someone who earns my living working more or less full-time doing coding (and as someone who has a wife and kids), I can only afford to put in so much time per week on side projects.

I know the pain of trying to take on something too big because I’ve tried it before. From early 2011 to late 2015 I tried to build a business selling hair salon scheduling software, and among other reasons for failure, I was never able to achieve “escape velocity” due to the limited amount of bandwidth I had to work on the business.

So, that’s my reasoning. Now that I’ve made that decision, my plan is to continue to focus on blogging about Rails and making Rails podcasts, which I do at CodeWithJason.com and the Rails with Jason podcast, respectively. As I move forward with these things I intend to keep my eyes open to other entrepreneurial opportunities.

August 2019 Revenue Report

Unlike June and July, I did do a launch in September. I didn’t launch a course like I was planning, and nobody bought the service I launched. But I did relaunch my book and made $327. I launched to roughly 100 new subscribers and made 5 sales, so about a 5% conversion rate, not bad.

Incidentally, I also sold a copy of the Angular for Rails Developers video package for $99. I didn’t even realize that that product was still purchasable. I guess it is since someone bought it.

Below is my revenue for every month worth mentioning.

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

July 2019 Revenue Report

July’s revenue was low for the same reason June’s revenue was low: I didn’t do any launches. In both June and July I was focused on building my email list.

I’m writing this on August 5th, 2019. This week I’m launching a new service. I plan to launch a course next month. Hopefully after those things happen I’ll see an increase in revenue.

Below is my revenue for every month worth mentioning.

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

June 2019 Revenue Report

I made exactly $0 in sales in June. This isn’t too surprising as I didn’t do any launches. During June I was focused on building my email list.

Below is my revenue for every month worth mentioning.

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

May 2019 Revenue Report

In March 2019 I launched my new book, Rails Testing for Beginners, and made $988 on the launch with a couple sales later in the month.

April was launchless. My revenue was only $98.

This month I launched a video package to accompany the book. I earned $481 which was less than I expected but in hindsight it makes sense. My list hadn’t grown much since the book launch so almost everyone who got the video launched to them had already had the book launched to them. I did the math afterward and out of ~700 email subscribers, about 5% of them ultimately bought something, whether it be the book by itself or the book + video package. A 5% overall conversion rate isn’t bad.

Now that I have this higher-tier product my focus for the next while will be to get a bunch more subscribers to launch to. I’m tentatively thinking that I’ll wait until I have at least 1000 subscribers to do another launch.

Below is my revenue for every month.

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