Subscribe
Share
Share
Embed
Thoughts on online work, dependability, tools, and craft
Hey, this is Philip from
Contraption Company.
I'm here in London talking
with my friend Ayush Nowitia.
We're talking about his book, The Rails
and Hotwire Codex, which I originally
discovered online as I was learning
Ruby on Rails, and it really helped me
appreciate Ruby on Rails and want to use
it in professional applications, including
on projects like Booklet and Find.
ai.
Uh, Ayush and I have been able to
work together a little bit with Find.
ai, so it's been really cool to get to
know him more and be able to see some of
his knowledge applied to our code base.
And I'm excited to talk to him today
because I love finding people who
I consider craftspeople and like
getting really deep on the tools
and products that they're using and
going above and beyond on learning in
terms of following their curiosity.
And I think he's a really
great example of that.
He's actually the type of person I
love working with and learning from.
And I think his book is
an excellent resource.
I'm curious to learn more about how he's
also using the internet to build this
diversified business and have multiple
different revenue streams, and how we
went about self publishing a technical
book and what it takes to do that.
So let's dive in.
Philip: Well, thank you
for joining the podcast.
Ayush: Oh, pleasure.
Thanks for having me.
Cheers.
Philip: We had free cocktails
accidentally upstairs.
Some picantes.
How is it?
Ayush: That's good.
Philip: It's good.
This one's sweeter than
the ones I normally have.
Ayush: Okay, yeah, it's not that spicy.
No.
You promised me more spice.
Sometimes it's, sometimes it
Philip: really hits because
I think it, how spicy it is
depends on the time of day.
So when it's fresh, it's not that spicy.
But if you start ordering them at
like 2am, then the pepper's been
sitting in it for like hours and
then it really catch up on you.
But I agree, it's not spicy.
Ayush: It's good though.
Philip: Good.
Ayush: Perfect for a
nice hot day in London.
Yes.
Philip: Well, thank you for, uh, coming
in to talk, I wanted to learn more about
.
Ayush: The Rails
Philip: and Hotwire Codex.
Because I think it's really cool to
find people that work on projects
that are interesting and work related,
but that they really take a lot of
initiative on, and your book is massive.
I think I told you, I When I got
it for the first time, I decided to
print it out because I like reading
technical books on paper and I couldn't
fit it into one textbook sized book.
And so it was two textbook sized
books that sat like this big on my
bookshelf and I went through it.
It was really cool.
And I was really impressed by how in
depth the tutorial was because I think
that there's a lot of tutorials out
there that are good for beginners.
But when you're looking for something
that's more advanced and wants to
talk about like how do we build a real
application and how do we deal with
kind the scaling issues, how do we get
deeper into the framework and learn about
things like active storage and some of
those different components of Rails.
I thought it really, did a really good
job of that and the demo application,
which is kind of like a Gumroad
copy, uh, was really excellent.
So I thought it'd be fun to chat.
Ayush: Yeah, cheers.
Thanks for all the nice words.
What you described has quite a lot
to do with, uh, it's pretty much
exactly what my aims were with the
book, so it's really nice to hear
that that's kind of come across.
And yeah, the book kind of snowballed
a little bit with size, like, Yeah,
you're right, like, uh, when you got
it printed out, it's a wise thing
to have it in, like, two volumes,
because, uh, I've got three, uh, three
hard copies of My Place is Ultra.
My mom got printed out just as KeepSix,
and, uh, the printer was a friend of hers.
He was just very reluctant to do
it as a single book because he's
like it's just gonna fall apart.
It's too big It's just gonna
break and my mom was like no
one is going to read that book.
It's showpiece Just do it as one book.
My son wants it that way I've got
like these three bricks sat on my
bookshelf in my study and i'm like
How did that come out of my brain?
Philip: Wow, that's really cool
because When I tried printing it I
had to search so many places that
would print You And the max number
of pages I found was a thousand.
So that's why I just put it in, too.
So it's like you found someone that
would print over a thousand pages.
It's really impressive.
So, I'm curious to learn how you ended
up working with Ruby and Rails and why
you found it interesting, because you
have a background in computer science.
You studied it in university.
And then you worked more on mobile
and iOS, which I find interesting.
Those backgrounds tend to kind of
gravitate towards more what I would
describe as like technical languages, like
strong typed and more like low level in
terms of um, how they're made and I think
that Ruby is very different than that.
So how did you discover Ruby and why
do you like it or do you not like it
compared to things like Java or Kotlin?
Ayush: Uh, so I kind of fell into
this whole mobile world a little bit.
Kind of an accident.
So like, yeah, I studied computer
science at university and my
final year project, the final year
dissertation was an Android app.
So Um, you get these
things called Finch robots.
I think they developed at Stanford
or something like that to kind
of teach kids programming.
And my final year dissertation
was, I hooked up a Raspberry
Pi to one of these robots.
It just has like two wheels and a
little sensor in the front and a
very basic API to kind of control
the wheels and speed and stuff.
So I hooked up a Raspberry Pi
on top of that and then built
an Android app to control it.
Theoretically make it play football.
Philip: Yeah.
Ayush: Um, and so the Funer project
had a heavy Android component to it.
I.
Kind of wanted to do iOS because I had an
iPhone and was an Apple fan, still am an
Apple fan, but my project tutor said that
we don't have the expertise to help you.
If you get stuck with iOS, you're kind
of screwed because you're on your own.
We do have Android skills in house,
so you got to do an Android app.
It's like, fine, whatever.
And then companies tend to pigeonhole you.
So like when I started applying
for graduate jobs, And I had
this Android thing on my CV.
Everyone was like, Oh,
you're an Android specialist.
So I ended up on a graduate program
at a, an agency called AKQA.
And they put me in Android and
I'm like, I don't like Android.
Like I want to do iOS just because if
I'm going to be stuck in mobile, at
least I would let me do something I
like, which is like, I have an iPhone.
I want to do iOS.
So just through like networking
and blagging, I managed to get
myself onto an iOS project.
Uh, at that company.
And, uh, but they knew I could do Android,
so they kind of put me in a dual role.
You can do a bit of both, right?
Like, how hard is it?
But yeah, that's how I kind of
fell into this whole mobile world.
And, um, a lot of my motivation
kind of comes from product
rather than technical problems.
So like, I don't really care if the
technical side of things is boring.
Um, I like building good products.
Um, I'd probably the best way to describe
it is I call myself product engineer
and with mobile, you're kind of just
beholden to the big corporations, right?
Philip: Yeah.
Ayush: Um, if Apple decides They
don't want you on the store, your
entire business is, is, goes, uh,
disappears in a poof overnight.
And this has happened, like, you, you
know, uh, like, it's been well documented
the problems that Hay and Basecamp
have had with, with the App Store.
Yeah.
Um, So I was kind of
getting fed up of that.
Uh, I wanted to just build
products and be able to sell them.
And the web was looking more and more like
the place to kind of do that more easily.
Uh, the other aspect was Swift was
kind of taking over iOS development
and I kind of like Swift as a
language, but I also kind of perceived
the direction it was going in.
I perceived it to be like
the Javafication of Swift.
Philip: Yeah.
Ayush: Where I felt instead of
solving actual problems, they were
like chasing academic perfection
for the programming language.
Philip: Yeah.
Ayush: And I just found
that quite annoying.
Um, Objective C actually
has quite a lot of features.
uh, similarities with, with Ruby.
The, the metaprogramming
is very much at the core of
Objective C and the iOS runtime.
So, uh, and there's a lot of
Ruby in the iOS ecosystem.
Like, at the time, as we're talking mid
to late 2010s, when I did, uh, mobile, the
most popular dependency manager for iOS
was CocoaPods, which was written in Ruby.
Philip: I didn't know that.
Ayush: Yeah.
So now you have Swift package manager,
which is native, but at the time it
was CocoaPods, which is a Ruby tool.
There was a tool called Fastlane, which
is like a CI kind of build platform
that you can open source build platform.
You could use to, um, build a CI
pipeline and CD pipeline for your apps.
That was a Ruby tool.
So I had encountered Ruby quite a lot
just in my work as an iOS developer.
And I quite liked the language.
I saw the similarities.
Uh, with Objective C in terms of
metaprogramming and all the, the,
uh, DHH would call it sharp knives.
And I like that.
I like that philosophy.
Um, and I was kind of aware of Rails.
I was aware of DHH being
quite vocal on Twitter.
And some of the things he says
was, it really resonated with me,
especially things around Twitter.
TDD because I can't write tests first.
Never been able to do it.
Still can't do it.
Philip: Yeah.
Ayush: Uh, And everyone in the
tech industry was telling me I'm
wrong except this one guy and I'm
like, okay, maybe Maybe there's
some Uh connection there and he was
obviously the guy who created rails.
I'm like, well, maybe If we have that
similarity, maybe rails is something
that's for me And I, I bought the Ruby
on Rails tutorial while I was still doing
mobile and just had a play around with it.
It was pretty good.
Maybe it's something I
should look at in the future.
And then I decided, like, I
don't want to do this mobile
stuff and you want to go web.
Rails was like an obvious
choice, to be honest.
I didn't even consider anything else.
Philip: So when you did that
change, did Rails seem like a niche
framework to you or did it seem
super mainstream at that time?
Ayush: It seemed mainstream.
It just seemed like.
It seemed like it wasn't the
cool kid on the block anymore,
but I didn't care about that.
I was already, this is like, we're talking
about five years into my tech career.
I was already starting to get a bit jaded.
So I didn't really care
about the cool factor.
Philip: Yeah, that makes sense.
It's one of these things where
some people tell me that Rails
seems like a niche framework.
And other times, if you just look
at who's using it in production,
like between Rails and Ruby.
It's like Shopify, it's Stripe, it's
Airbnb, uh, GitHub, uh, there's a bunch
of different big companies using it.
And I think that that enterprise usage
just means that maybe it's not as
exciting, but like, it's also not dead.
Like, these companies are
contributing a lot to the language.
I think it's really exciting.
What about kind of comparing, so the
Apple world is very curated, right?
The Apple is providing you now the
language and The framework for iOS
coming into the rails ecosystem.
Is there anything that appealed to
you with kind of the opinionated
nature of the framework?
Ayush: Yeah, I quite liked it just
because it standardized a lot of stuff.
Like, um, when I did iOS, uh, there were
so many different opinions flying around.
Usually it was just, uh,
the latest hype cycle.
Philip: Yeah.
Ayush: Um, the, like you open
to iOS code bases, they'd be
set up completely differently.
Um, I think not a lot of people had a good
understanding of MVC and, uh, that's why
they didn't really implement it properly.
So you had all these other, uh,
patterns kind of coming up like
Viper and stuff like that, which were
just so unbelievably complicated.
And they all came, I think,
from a Java style of thinking
and trying to apply that.
to iOS APIs, which are very much like
dynamic in nature and built to be like
with Objective C and Swift in mind.
They just didn't work and that
kind of stuff was driving me mad.
So like coming to Rails was a breath
of fresh air because it's like, Okay,
here's a good implementation of MVC.
Everyone kind of knows where
stuff goes up to a point.
Philip: The folders are
all pretty standard.
Ayush: Yeah.
Uh, I mean, in Rails as well,
you do have certain debates.
Like I think, uh, service objects
versus concerns will be a debate that
rages on, um, very much, uh, uh, both
feet in the concerns world, but, um,
yeah, and I've seen quite a few Rails
code bases, some of them better than
others, but they all, I found it quite
easy to kind of navigate through.
And I, I think when I, uh, a few days
into my first, Rails contract job.
I remember tweeting something around.
Um, Like I just started a rails
contract and one or two days.
I was completely up to speed with the code
base because Everything was exactly where
I'd expect it to be like I see a page.
I see the url.
I know which controller is rendered it
I know Which model is just because all?
Conventions, right?
Philip: Yeah,
Ayush: I used to really struggle
in ios to just follow stuff around
because there's no standardization
Philip: did the lack of Like strong
typing or things like that make it
at all difficult to navigate Ruby
code base for the first time for you?
Because I'm thinking that like when
I introduce people to Ruby and Rails,
especially if they're coming from
like a Java background, they have
trouble saying like, how do I look
up where this function is defined?
Ayush: Um, not as difficult
as I thought it would be.
Like yeah, the stuff you say like where
a function is defined, I just use search,
like you see, I just search def, whatever.
And, uh, I find it like, I think
just good old, old school search
is a very underrated tool.
Um, sometimes I did struggle if
people had, um, not expressed within
the code itself, what types certain
things were like, you know, within the
variable name, you can make it obvious
what type that, that variable is.
So yeah, there were some struggles
there, but nothing, too bad to be honest.
Like, um, I, I'm not the biggest
fan of type languages anyway.
Like, um, yeah, I mean, both Swift
and Objective C were typed, but Swift
has a type inference engine, so very
often, um, just didn't really need
to think about it too much because, I
mean, you declare types in the method
signature and stuff, but when you're
assigning variables, it would just
infer the type and things like that.
So, um, yeah, I didn't have as
much trouble as I thought I might.
Um, I think it's easier than
A lot of people might think.
Philip: Yeah.
Nice.
So 2020, you started learning
Ruby and Rails, right?
And then 2023, you
published your book, right?
Ayush: Uh, December 22.
Philip: December 22.
Wow.
So you went, so December, so where within
2020, did you start learning Rails?
And at what point did you
start working in Rails?
Ayush: Uh, so I started in January 2020.
So I quit my job at Transvoice, which
was my last mobile job in August.
I was pretty burnt out, so I
took four months off completely,
didn't look at code at all.
And then in January 2020, I picked up
the Ruby on Rails tutorial properly
and worked through it diligently as
opposed to in the past when I just
kind of done it in a piecemeal way.
Philip: Yeah.
Ayush: Um.
And then I built my first app, which
is just a simple blogging app called
chapter 24, which is now defunct
because the code is horrendous.
Philip: But that's kind of like the
process of learning a new language, right?
It
Ayush: was all part of
the learning process.
It gave me something that
I had in the public eye.
So it did help me get started
with freelancing as well.
Cause I had something I'd built.
It
Philip: wasn't open source though, right?
No,
Ayush: it wasn't open source, but it was
a product I'd built that people could use.
So it's still something.
Philip: Yeah.
Ayush: Um, So I think I finished
that I think around mid to late 2020.
And then I was just mucking about
with other stuff for the rest
of the year and then started my
first Ruby Rails contract in 2021.
Philip: So what I'm getting at here
is I think it's really impressive
that you went from saying like,
I've learned Ruby on Rails to
publishing a book within two years.
Ayush: Yeah, all three, 20, 21 and 22.
But, uh, yeah, uh, yes, that actually
I felt was an advantage because
I was in a unique position where
I was an experienced developer.
So I had good programming practices kind
of honed from my work on mobile for five
years in a professional environment.
Philip: Yeah.
Ayush: But I was pretty new to
the stack and I was approaching
it a bit like an idiot, really.
Uh, because I'm like, I just
need to write good code.
This is a code coding platform.
I just need to approach it like, how
would I solve this programming problem?
Um, and I found the step up from
the Ruby on Rails tutorial to like
a production app fairly tricky.
So like in the first two or three
months of my first freelance
job, It was a vertical learning
curve for a lot of advanced stuff
I had no idea about in Rails.
And I thought that it would be
good to kind of capture that in,
in some way because, um, now I
have all those things internalized.
I couldn't write that book now.
If I started today, I wouldn't be
able to write it because a lot of the
stuff I teach is now internalized.
I just take it for granted.
I'm like, Oh, everyone knows this, right?
But that's not true.
But when you're learning.
Um, everything is like a bit more,
uh, of like, I can peel it back
and empathize more with a learner
because I'm learning as well.
Um, so I just had an idea randomly,
like I've got a pretty unique
career trajectory here where I've
done iOS, I've done Android, and
now I'm doing web as specialisms
at different parts of my career.
Turbo and TurboNative were
fairly new at the time.
This was, we're talking now, mid 2021.
And, um, I was like, maybe I can
combine my skills and write a book
that teaches you how to do all
three, because there's a lot of
books that teach you app development.
There's books that teach
you Rails development.
There's nothing that teaches you all
three, because Turbolinks native, which
is the predecessor to Turbonative.
I was aware of it.
I pitched for its inclusion
on, uh, on previous projects
when I was a mobile specialist.
And basically one moment I mentioned
hybrid, I'd lost the room and I'm
like, I guess it's never going to work.
But I was aware of that, that
kind of style of thinking.
I like it.
This is a good opportunity to
learn Turbonative, which I've kind
of ignored for a while because
then I've had the opportunity.
It's a good idea to kind of.
share my unique career trajectory.
Philip: Yeah.
Ayush: What if I write a book
with all three platforms?
And at the time I'm like, this could
either be a very good or very bad idea.
So I just, I thought I'm, I'm
motivated to do this right now.
And at the end of 2021, I just
decided like, if I don't do this
now, I'm never going to do it.
Philip: Yeah.
Ayush: Uh, and I tried kind of writing
it side by side with freelance work.
This is not working because.
Writing is very mentally intensive.
Philip: Yeah.
Ayush: And after a certain number of
hours of programming for a client,
I'm like, I don't have enough
in the tank to actually write.
Philip: Yeah.
Ayush: Uh, like put, put the energy
and to write, uh, write a book.
And I'm like, okay, I'm just gonna
take a break from client work, write
the books, see where this goes.
So the start of 2022, I just
ended my contract and went all in.
Philip: So just explaining
it for the listener.
So Ruby on Rails is an
older web framework.
When it was invented,
it was just front end.
Your web applications typically have
like the back end and the front end.
At that point, back end was
where all the complexity was,
and front end was just like HTML.
It wasn't that complex.
And then, as the web evolved, we
started to get more complex front
ends, with things like JavaScript.
And so, Rails kind of became pigeonholed
into being a back end framework.
It became pretty common to use
something like React on the front
end, with the Rails back end.
And the framework kind of evolved to
kind of fit into this niche of just
being API only, meaning just like
back end only if you wanted it to be.
And then DHH, founder of Rails, made
efforts to make Rails more full stack
in more of a Rails way by releasing
this set of tools called HotWired.
So HotWired is multiple different
things within it, but it's
basically front end, for Rails,
but it's in JavaScript technically.
You could use Hotwired without Rails,
but they're kind of architected together.
And so there's Hotwired is an ecosystem
and it's now installed by default on
Rails, but the stimulus, stimulus is
being able to do logic on the front ends.
More or less page transitions on
the front ends, making it seem fast.
And then there's another one strata
strata, which isn't really out yet.
Ayush: It is.
Oh, it is.
Yeah.
It came out last year.
Philip: Oh, and then you
integrate integrated it into
your book already, right?
Okay.
So as the framework has evolved,
you've also been updating the book.
So, so Rails is an ecosystem and now
it kind of means both backend and front
end, which is really cool because Brails
is kind of getting this reputation.
Now is the one person framework.
All you need is rails.
And I think that's really
impressive, but you basically.
Yeah.
Saw this evolution in the Rails
ecosystem as it was becoming back
end and front end, and then it was
also starting to become mobile.
So you can have back end, front end,
and mobile apps that look like they're
installed as an app on the phone, but
you're saying they're hybrid, which means
that there's, um, you're not having to
write straight iOS code, you're wrapping
it, wrapping some of the Rails code.
Yeah,
Ayush: you are writing Swift, so you
have, you will have a project in Xcode,
which is the development tool you
use for iOS apps and Android Studio,
which is the counterpart for Android.
You will have native
code, but not a lot of it.
So, the way it works is, um, the
backbone of the app, so like the
navigation, you have tab bars
at the bottom usually in apps.
That stuff is all native,
but the content itself is.
That is web.
So, your app kind of becomes
like a custom web browser.
Uh, so the shell in which the app
runs, that's kind of like a purpose
built web browser just for your app.
But the content inside it are just,
uh, you know, HTML pages from the web.
Philip: Yeah.
And so the target audience for this is
people who want to take their website
and make it available as an app.
And you can, my understanding is you can
sprinkle in native things like payments.
Yeah.
So it feels native, but a lot of
companies just want to have an app in
the app store because it's, um, really
good for conversions and interactions.
And, so,
Hot take on this, today, do you recommend
that most companies still do hybrid
web view web applications or is this,
do you think of it as a starter or as
a limited thing or do you think that
like most companies should just do
hybrid and never touch native iOS code?
Ayush: Um, I think for most
companies, I think this approach
to hybrid is probably the best way.
Because I think most apps are crowd apps.
Yeah.
Um, as much as people might not
want to admit it, it, it is a fact.
Yeah.
And for that kind of app, I
think, um, it just makes sense
to have this approach to Harvard.
Like, Uh, I gave a talk on this,
uh, last year at a couple of
conferences, which goes into depth,
so that if anyone's interested in
the talk, it's titled, uh, Native
Apps Are Dead, Long Live Native Apps.
If you put it on YouTube, you'll find it.
Um, the, the thinking is that
traditionally, hybrid apps were like,
you have one code base, uh, which is
fully HTML, CSS, JavaScript, and then
you build it for two different platforms,
which is not an approach I like.
Uh, I mean, you know, People
have been trying to do that for
years, like Java apps and stuff.
And more recently with Electron, uh,
anyone who uses Slack will know that
it's just horrendous on the desktop
because it's just a website in a box.
Um, but, uh, the way, um, the Turbo
Native approach kind of goes at
it is slightly different where you
do have two different code bases.
You do write a little bit of native
code, but it's just that the bulk of
it, It still is driven by the web.
And then the useful thing is also,
uh, there's an escape hatch to write
fully native code when you need to.
So like, let's say your users
spend 80 percent of their
time on one single screen.
Like let's say you have a feed on
the homepage or something where
users spend all their time You can do
just that one screen fully natively.
Yeah.
So that, that experience
is as slick as it can be.
But then other pages like a
profile page or a settings page,
which is not used that often.
Yeah.
You just, you reuse the
website for that in the app.
So you don't have to You can build
each screen like three times.
Yeah, that makes sense.
So I quite like this approach
because you're not all in
on native or all in on web.
You can kind of slide that
slider across the spectrum.
Philip: And if you have a very high
polished page, like the homepage
or whatever it might be, or the
feed, you can make that native.
Ayush: Exactly.
So that's what the, the Hay email
app does, the, the, that they
call the inbox is fully native.
And then other parts of the,
the app, which are not as
widely used, those are just web.
Philip: Yeah.
Hay had a lot of like strong opinions
and like some of them I think were
really good, like the screener, but
some of their things I forget about
because I think they're kind of faded
away from being like popular, like the
inbox and like the tracking pixel stuff.
Yeah.
And I feel like sometimes when I hear
it, I'm like, That was a weird decision.
It's like, the inbox.
It's your important inbox.
Ayush: Yeah.
Philip: So, you kind of looked at
this and said, I have the opportunity
to write a really niche book, right?
Because you were like, I'm sitting at the
intersection of Ruby on Rails and Native.
I think I'm the best person to write
an interesting book about this.
Is that right?
Ayush: Yeah.
Philip: And so this came from
like, a goal almost of, It sounds
like you wanted to teach people.
It sounds like you didn't come into this
thinking, I'm going to write a bestseller.
Is that fair?
Ayush: Yeah.
I, I wanted to teach people.
I wanted a manual for myself.
I, uh, a lot of my objectives were
selfish, uh, but a lot of them were not.
So like just wanting to teach and
share knowledge was a huge thing.
But, uh, I, I also knew that
I'm quite lazy as a person.
If I'm going to be like.
make a go of this whole freelancing thing.
I needed a way to have work find me
rather than the other way around.
And I thought writing a book would be
a good way to kind of have that happen.
Philip: Had you been involved
in open source up until this or?
Ayush: Uh, yeah, I had, cause I've been
in, I've been involved with the Bridgetown
project since I've been involved with
it since I think about September, 2020.
I've been on the core
team since December, 2020.
Yeah.
So, uh, yeah, I've been involved, uh, my
level of involvement goes up and down, but
on paper I've been involved since then.
Philip: So, why did you
decide to make a book?
Like, why not make a tutorial?
Why not make a YouTube series?
Did you, and you also
publish it independently,
so why did you go that path?
Ayush: Um, I didn't want to record videos.
That was the main reason of why
I didn't want to do a YouTube
series or a video course.
Um, I I prefer written word both
as, um, like writing, uh, or
sharing knowledge via written word.
And, uh, I prefer reading to
watching videos because I'm like,
I can do things like command F.
It's simple things like, like,
like that, uh, that I can do, which
you can't really do with videos.
And I can skim, I can skim a blog.
You can't really skim a video.
Yeah.
Um, so written word has always
been my preference of medium.
Um, I was worried for a bit, have I
bitten off more than I can chew writing
a whole book, but then, uh, I'm very
much a, like a, if it's worth doing,
it's worth overdoing kind of person.
So I'm like, let's just
do it, see how it goes.
Um, whether to self publish or
not, yeah, I, again, I couldn't
be bothered to approach publishers
and try to pitch to them.
Because I had no reputation
in the Ruby industry.
I was still pretty new to Ruby.
Uh, trying to sell to a publisher
would always be a very hard sell.
Uh, also I wanted complete creative
control, uh, beginning to end.
Um, like, there are all kinds
of silly things in the book.
Like, firstly, I'm really
proud of the cover.
The cover is drawn by my friend,
Adrian, who also does all
the branding for Bridgetown.
My pitch to him for that was basically,
you know those street musicians who
can play half a dozen instruments?
Can you give me that?
And then he came up with this absolutely
brilliant illustration based on
that crap pitch, uh, which I love.
And like you wouldn't get a
cover with like that for a
tech book from a publisher.
You just wouldn't like,
Philip: Well it's like the beauty
of independent is there's just so
much personality put into it, right?
Like we're talking about
the hay in the inbox.
Like you couldn't get inbox through
like, a product manager at Google, but
like, it's, it's just the fact that
there's so many of those little things.
Ayush: None like this
silly jokes in the book.
Like I think the one, when I'm teaching,
um, how to time travel in Unitas.
I've put a photo of the Back to
the Future DeLorean in there.
Um, what else?
Uh, I sign off, I sign off the coda of the
book with the word Kapla, which is Klingon
for good luck or something like that.
It's like, it's like your safe travels.
It's a greeting you give in
Klingon when you're like leaving.
Uh, so yeah, just silly things
like that that kind of show
my personality a little bit.
You couldn't get away with that,
you know, with a publisher and I
wanted to do all that kind of stuff.
Philip: Have you been
approached by a publisher today?
Like, would you, if you were to
write another, okay, in retrospect,
would you write another book or was
it too hard and would you stick with
the independent approach or would
you try to work with the publisher?
Ayush: Uh, I probably would write
another book but I wouldn't take a,
an extended break from client work
to do it because, uh, it was just too
stressful first draining my bank account
as I, like I said, I'm quite lazy.
Like when there's, um, not
someone else dependent on my work.
Like I, when I, when I do client
work, I know I can't just sit and
watch cricket on TV all day because
other people are relying on my work.
But when there's no immediate
consequence to not working and
there's cricket on TV, I'm like, hmm.
And cricket goes on and on,
it's an all day thing, and I'm
like, I'll just watch cricket.
And then two months later,
I'm like, why am I broke?
So I do things like that, which is
why I wouldn't go all in on writing
a book, because it's too stressful.
First, I drain my bank account,
and then recovering from
that, uh, was too difficult.
But I would probably go down
the independent route again,
again, just for the, you know,
creative control aspect of it.
Yeah.
Um, I don't really see why, uh, unless
you, unless you want to sell print
books, I don't really see why tech
authors would go after publishers.
These days, uh, I'm sure people who
have worked at the publisher can, can
prove me wrong about why they did that.
But, um, because they would
take a significant chunk of the
profits, right, as a publisher.
I don't see why, as the author, I
should give that up when I can just
build an ebook and stick it on Gumroad.
Yeah.
And give like a 10 percent
cut to them and get the rest.
Philip: I love that you have
this pattern of wanting to
build things instead of buy it.
You made a whole book building a
tutorial of how to make gumroad,
but when it came to selling your
book You just put it on gumroad
Ayush: Yeah, yeah, it's funny, isn't it?
Well, the main reason I did that was
just for tax reasons like because gumroad
are a merchant of record So yeah, I
don't need to worry about EU VAT If it
wasn't for that, there is a good chance.
I would have just done myself an idea
I am playing with at the moment Is to
build my own like platform, but use like
Paddle or something like that for billing.
So I don't have to worry about
that because, um, uh, and idea of,
uh, that Anita is probably gonna
crystallize over the next few months.
I don't know if it'll go anywhere,
but you have things like Go
Rails in and drifting Ruby.
In the Ruby and Rails world, which
are bite-sized screen costs, seven
to 10 minutes of tutorials and
people pay a subscription yearly.
Subscription tutorials Yeah.
For it.
And, uh, there are.
Two or three offerings out
there with video screencasts.
There's nothing text based.
So an idea that I've been playing with
is what if I write text based tutorials,
one a week, bite sized, and charge people
a subscription for it, and bring my book
over to that platform so like I can do
one off sales for certain things like a
book or anything, like I can do one off
sales and I can offer the subscription
service for text based tutorials.
So yeah, I do want to
build my own platform.
It's just that.
Uh, I can't be bothered to do it as yet.
Philip: Yeah, yeah.
So, it also seems like you
came at building the book
from a very niche perspective.
I think, I'm applying
the lens of startups.
Everyone in startups always says,
build something very niche for
a very small group of people
and be able to grow over time.
And it seems like you followed that
advice for the book writing world, where
you made this small Venn diagram of
this particular web framework and this
particular language with iOS and Android
and kind of these new technologies
that weren't super popular yet.
Can you talk about why you went
with something super niche instead
of writing like Ruby on Rails
tutorial codecs or something?
Ayush: Um, honestly, I didn't
really think about the audience
or the tech stack too much.
I was just like, well, I use Rails.
That's what I know.
Building a modern Rails app
involves all these things.
Yeah.
So I'm just going to teach that in
like a Like big one big wholesome way.
Yeah.
Um, so yeah, it was like the next step
up from the Ruby on Rails tutorial
by Michael Hartle, which I think is
like, uh, it's almost a rite of passage
for, for Rails developers, isn't it?
So I'm like, what, what can I, you know,
Offer as the next step up from that.
Yeah, and this is what
I kind of came up with.
I didn't think too much about the
target audience, to be honest.
Yeah.
Uh, it's a cliche, but I built,
uh, I wrote the book I wished I had
when I finished the real tutorial.
Yeah.
I know it's a cliche, but I,
this is the book I wish I had.
Philip: I love that you went so deep on
the iOS and Android parts, I think the
Ruby on Rails tutorial says, look how
easy to get started, but I think your
book says, look how far you can take this.
But for me, and maybe a lot of other
readers, maybe not, I looked at
the iOS and Android parts and said,
this is really useful knowledge.
To know where to come to if I wanted in
the future It's like knowing where I can
take things but I didn't end up using the
ios and android knowledge I think I got
stuck getting android studio going and
just kind of pain in the ass I think I
Ayush: have I think i'm literally the
words that i've used somewhere in the
book are that the android devtools are
possessed by an evil spirit I think
those are the exact words i've written
somewhere It's the bane of my life and
it's it's I know a lot of people have
bought my book just for the native
part You It's, it's funny you just say
that because um, I have made a decision
to remove it from the next edition.
Yeah.
But the native stuff is going
in, in the next edition.
Uh, do you think they'll continue
Philip: to maintain that
part of the Rails framework?
Ayush: I think they will
because, uh, they use it, right?
Basecamp?
Yeah.
And, and 30, uh, hey, well, 37
Signals as a company use it.
I think they will, uh, to what
degree remains to be seen.
Yeah.
Um, but.
Uh, when I, I updated
the book for Rails 7.
1 back in March.
And when I released that, I put the
announcement out that I'm removing all the
native stuff for the next edition, which
will be next year when Rails 8 is out.
And again, my reasoning
was purely selfish.
It's too stressful for me.
Like I, I haven't worked in a production
Android code base since 2017 and a
production iOS code base since 2019.
I started the book in 2021.
Which, the gap then was not that big.
We're in 2024 now.
And I haven't kept up to date
with mobile because keeping up
to date with web is hard enough.
And every time I go back into native
code, my stress levels just go shooting
through the roof because nothing
makes sense to me, nothing works.
I'm like, this is just
not worth it anymore.
Philip: But also Rails 8 is starting
to go deep into progressive web
apps, which is alternative to native
apps that offers a little bit of the
functionality like push notifications.
Ayush: Exactly.
So that's going to be, that's
the direction of the next
edition of the book as well.
It's going to be all progressive web apps.
So like, I don't know exactly what
shape Rails 8 will take because I
don't think that's known yet, but
I'm hoping that things like service
workers and push notifications, which
are like app like features, Yeah.
Um, but on the web platform
will feature heavily in Rails 8.
So I'm hoping to kind of teach all
that as an alternative and, uh,
anyone who buys my book, even after
the second edition is out, the first
edition will always be available on
Gumroad and like in the same place.
Yeah.
So it's like the basics of the
native stuff aren't going to
change, like some specifics might
change, but the basics won't.
Yeah.
So I'm hoping that if someone
is interested, that bit
will always be available.
It'll just be a little out of date.
Philip: Yeah.
Yeah.
That's the great part
about programming, right?
Is it's, it's a capture
of a point in time.
And so it's still comprehensive.
So you decided to write a book.
It seems like you told yourself you
thought it was going to be hard,
which is like, I think the kind of.
History of most programming projects is
what's the phrase like I didn't do it
because it was easy I did it because I
thought it would be easy But it seems
like you kind of took this path which
was I knew it was gonna be hard There's
always a bad sign Kind of context.
How long did you think it would
take you to write the book?
How long did it actually take you?
Ayush: It was so much harder than
I thought it would be Let's see.
So I think I wrote the first three
chapters You in November, December 2021
while freelancing at the same time.
But those were fairly easy chapters
to write because it's just getting
started, like setting up your
environment and then intro to Hotwire
is nothing fancy with all that.
When I started really getting into
the meat of the book, which is from
chapter four, uh, is when I realized
that I need to go full time on this.
So I took a break because I
had some commitments to my
client at the start of 2022.
So I finished those, I think, mid
March is when I went full time on it.
And I was like, I think I can
get this out by about August.
Okay.
So this is March, April,
May, June, July, August.
I've had six months.
Yeah.
I should be able to do it.
Uh, yeah, I got it out in December.
Philip: As far as overruns go, like,
that's definitely like an overrun,
but that's not like, um, The Sagrada
Familia overrun or something.
Yeah, but
Ayush: then, what happened there
was, there were two things.
Firstly, my ego is absolutely massive
that I wouldn't, I wouldn't let
myself give up on the project because
I couldn't let myself fail at that
because it's just, it's an ego thing.
Like, I, like I have started
this, I will finish it.
It's like a mission.
And then, It was really when I had a fire
lit under my ass with my bank account
going low, which is, it really was
in the summer on July time when I was
like, shit, I'm running out of money.
That was when I really, really got going.
Like I say, I was in full
time from, from March.
But I was slacking off a lot,
like, uh, A lot of cricket.
A lot of cricket, yeah.
A lot of cricket.
It's just like, uh, you wake up
one day and you're not feeling it.
Yeah.
And, like, when there's no immediate
consequences, it's just very easy to just
slack off and, like, watch TV all day.
Yeah.
And do, just, like, be lazy.
But yeah, it was like in the summer when I
was really starting to run out of money is
like, okay, I better get my shit together.
Yeah.
And then around October time,
uh, I had to start freelancing
again because I needed the money.
Yeah.
And then those last three months at
home stretch was unbelievably hard
because I was freelancing and writing
side by side, which is what I didn't
want to do earlier, but I had to do
it because by that time I'd already
started taking pre orders in September.
I opened pre orders, and I made a
commitment that the book would be
out before the end of the year.
And you know you should never
make commitments like that.
Philip: But it seems like you
had these deadlines that you talk
about, like, Oh man, I was running
out of money, it was a problem.
Oh man, I made this
commitment, it was a problem.
But did having those hard constraints
push you to finish the book?
Like, do you think you would have finished
it without making those commitments?
External promises or
Ayush: no, I would have dragged on because
the one thing that was not negotiable
for me was scope So it was a bit tricky
to have a deadline and a scope because
usually what you do to meet a deadline
is reduce scope Yeah, but that for me
personally was a non negotiable I had a
list of things that these are things that
I will absolutely cover in the book I do
not want to compromise on those things.
Yeah, and Um, so yeah, having a
deadline and a fixed scope was a bit
difficult, but it also was what pushed
me to be as productive as I could.
It was like, it's the kind of thing
that just stopped me from slacking off.
It's as simple as that.
Like without, without a deadline, um,
I would have taken a lot longer, not
because the work would have taken longer.
It's just because.
I would have been slacking off a lot more.
Philip: And as you started
the project, did you feel like
you knew everything already?
Or did you jump into it
with a lot of unknowns?
Because had you even built a code
base with some of the native tools
from Rails for iOS and Android?
Ayush: No, so a lot of it
was a learning experience.
That was another aim with the book was
like, if I'm going to be a freelancer,
essentially, uh, I'm a Rails gun for hire.
And if I'm that kind of person
I need to have a Holistic
knowledge of the framework.
I can't say that or I've
never used action text.
Yeah, I don't know how to help
you with that yeah, and Those are
things that you kind of learn only
when you build something with it.
So Writing a book is a great
way to build in, uh, complete
knowledge of the framework.
So I had a strong base, but there
were a lot of unknowns, like the
native stuff especially took a
lot longer than I had thought.
And when you're teaching something,
you have to understand it really well.
Philip: That's like the
classic Feynman thing, right?
You have to learn it
well enough to teach it.
It's like a very high standard.
Ayush: So, which also helped me to get
a very clear understanding of things.
Like, I had to go into the Rails
code base a lot to just understand
things to explain to the reader.
Yeah.
Uh, certain things that when I would read
it back and like, Uh, this doesn't make
any sense, I need to figure out a diagram.
And then I'd spend a couple of
hours trying to draw a diagram
that explains it simply, because
Simple is actually very difficult.
So it was a huge learning curve
for me just as a Rails developer,
more than a writer, I would think.
Philip: I think that's what originally
drew me to your book is I saw the
Hotwired family of packages coming online
and I was like trying to learn it and
there weren't many materials on there.
I think I got a Podia course
about building forums in Hotwire.
Ayush: Yeah, I think, uh,
Andrea from Mira has that.
Yes, I think I
Philip: bought that one.
And That was useful for learning
Hotwire a little bit, because
they released this framework.
They kind of dropped it and said,
we use this to build our own apps,
but we're not showing you our apps.
Ayush: Yeah.
But
Philip: these are some, like, tools
we use to build the apps, and so
there were these tools available,
and I was trying to figure out,
what do you do with these tools?
How do you deal with things like
pagination, things like that?
And then I went through this, other
tutorial, And still struggling
because there's just, there
weren't code examples out there.
And I wanted to kind of see,
like, how do you scale it?
Like, I'd want to reinvent
this from first principles.
And as there were almost no resources
and almost nobody using these tools,
then you dropped this book and this repo.
And I was like, I've built a very complex
product that uses, like, every available
feature, basically, in all of this.
And I thought it was so cool.
And it was, I think it was really
prescient that you kind of jumped into
the book without the knowledge already.
Because At that stage, I don't
think anybody outside of the
creators of the packages had
knowledge of how to deploy them.
You kind of were, uh, moving at
a rate that a development team
wouldn't be able to move at, right?
Because a development team would look
at that and say, there's unknowns,
therefore we're not going to adopt
this because we have no idea whether
this will take a month or a year.
And you kind of like going through and
learning it yourself meant that I think
you de risked the adoption of a lot of
these things by different teams because
all of a sudden there was this resource
that like show that you could deploy
it and like you had this reference spec
where you could boot up the code and
see how it worked if you had any issues.
Ayush: Yeah, that's, it's
really nice to hear that.
I hope, I hope that I have
helped to some degree in that.
But, um, yeah, it was, I didn't
have a grand plan or anything.
It was literally just, uh, wouldn't
it be fun to write a book that
has all my knowledge in it?
Uh, yeah, it's, it was a new tool.
I knew that the resources out there
were scarce, which is what made it.
Uh, harder to write.
Uh, it involved a lot of jumping
into the source code to understand
stuff to then explain to the reader.
Um, the other thing I've kind of seen
in tutorials is that they give you the
code examples and they say, okay, if you
want to accomplish this write this code.
But they don't explain
what's actually happening.
Yeah.
And active storage is a great example
of this which, um, is kind of like
the file upload feature of Rails.
Um, Like, even the official Rails
guides will tell you just write
these lines of code in your set.
But I'm like, wait, what
tables is this creating?
How does this actually work?
Like, I have no understanding
of what's actually happening.
So I had to like literally open up
a networking inspector in Safari and
see, okay, Oh, it's making that network
call to do this, that, the other thing.
And then I explained that to the reader.
And that was another thing that I think
made my book a bit unique, which , again,
was a non negotiable for me, which
I hoped has helped with, with sales.
And sometimes I just look at some
of the people who've bought my
book and I'm like, Whoa, okay.
That's flattering.
You
Philip: I think that's why your book was
so useful, right, is because we've all
been there as developers where sometimes
you hit something that doesn't seem like a
big problem in production, like a timeout
or something, and then you realize,
like, oh man, I really have to dig in to
figure out why active storage is timing
up on this file upload or something.
And I think that your, like, really
first principles, um, approach
there was really really important.
Useful because one of the things I
remember going through in your example
code for the first time was like
looking through things like helper
files and things, which you never
see in a simple code example, right?
A simple code example will just work
on the big files, but they're not
really like doing the refactoring
and putting together like helpers.
So with the writing of the book, talk
to me about the order of like the
structure of the book, how you wrote
it, like what programs did you write in?
And the code, and like what
order did those things happen in?
Did you just start writing and
then do the table of contents?
Did you write all the code
first and then write the book?
Like, how did that work?
Ayush: Uh, it was all, uh, cyclic.
So, I I started writing, so even the
tooling to write an ebook is really
flaky, like I'm surprised how hard
it is to just write some text and
have it come out as a PDF in EPUB.
So I started off with a tool called
SoftCover, which is like a later, yeah,
but then a friend of mine told me about
this other tool called ASCII Doctor.
Uh, which is a Ruby tool, uh, you don't
write in Markdown or LaTeX, you write
in a markup language called AsciiDoc.
Philip: Yeah.
Ayush: Uh, and it took me about a
week to get the project all set up
with that, but I eventually got there.
So I think I had three chapters written,
which I had to then sit and rewrite
in AsciiDoc, but it was for long
term, I think it was a good decision.
Um, in terms of, uh, like yeah,
the table of contents and stuff.
So I, I was thinking very
much chapter by chapter.
Uh, so.
I would write the code, uh,
create a branch, write the code,
uh, for the following chapter.
Philip: Yeah.
Ayush: Uh, cause I had a, a vague
structure in mind for how the book's
like authentication, then, uh,
system tests, then something else and
something else like, and then, uh, I
had like a vague structure in mind.
Um, so I would, uh, write the
code for the chapter, then
switch back to the main branch.
And, uh, start copying code across.
So, like, I would start writing, write
some prose, and then, after that, I
would hop into the other branch, like,
oh, what's the relevant code here?
What do I need to copy over?
So, like, I had the solution there,
but I was also, like, building
along with the reader, so to speak.
Because I found that process worked
the best for me, uh, because it
put me in the reader's shoes,
because I'm writing something, and
then, Uh, here's the code example.
Here's what you need to put in your
editor and then move on and on and on.
Um, And is
Philip: that the code that you
deployed with the book or did you
have to go back and redo it all again?
Ayush: No, that is the code
I deployed with the book.
Uh, yeah, so.
So you didn't have any
Philip: moments of saying in chapter 12,
like, Oh no, chapter one, what did I do?
Ayush: I did, but then I
had to go back and fix it.
So that's, uh, In the chapter, right?
So if
Philip: you found a problem in chapter
12, you would refactor in chapter 12.
Ayush: Yeah.
So continuity was one of the hardest
problems and it still remains a problem.
I, like, I think.
Most of the errata that I get written
emails about are continuity errors.
Just because I've gone down the road
somewhere, made a change, and then
not applied it everywhere so far.
Um, but I think that's just the
nature of software development, right?
You're going to change your
mind further down the line.
Philip: So in your head it seems
like you were thinking, I'm going to
build a repo, and almost one chapter
corresponds to one pull request.
So it's almost like an application
of multiple pull requests, or no?
Ayush: Yeah, something like that.
Like, in a production app, the
pull request would be smaller.
Philip: Yeah,
Ayush: that's fair.
It's just, yeah, like, the way I did it
was, uh, chapter by chapter, just for,
uh, some kind of logical breakdown, right?
Because, like, then I
could write a script.
A chapter and have the code for that
already, but, uh, like I was using that
code more as a reference because I wanted
the writing process to be organic because,
um, I need to be in the reader's shoes.
Right.
So, uh, it sounded a bit,
uh, cliched or whatever.
The narrative has to kind
of take its own shape.
Uh, so the only way you can do that is
if you let the narrative drive the path.
So I had all the code there for reference.
So very often, like I would build out
the code for a chapter and then while I'm
writing the chapter, stuff would change
just because I'm like, this makes more
sense from a narrative point of view.
And I would change stack that way.
Um, and yeah, throughout the writing
process, a lot of stuff changed.
Like retrospectively, I went back and
changed stuff all the time, which is why.
I was very reluctant to share drafts
of my book, like when I opened
pre orders, the only thing you
got were the first three chapters.
Yeah.
I was giving those away for free anyway
as a taster on the book's website.
You didn't get anything else.
And I got a lot of emails with people
saying, Oh, I'm very disappointed.
You've only shared the free stuff.
Like your book's coming out in
December and you've not like,
why is there nothing more?
Like, well, I'm writing it.
It's nearly done and you
can't see it until it's ready.
Because a lot of stuff's going to
change, even the stuff in the first
three chapters, which I had shared,
stuff changed, uh, before the final
release in those three months.
Um, I was just very reluctant to
share in progress work because
it's a moving target, right?
Yeah.
Um, I don't want to share incomplete work.
Philip: Yeah.
Did you know that you were always going to
do pre orders before the end of the book?
Or was that like a motivation as you were
picking up the freelance job to finish it?
Ayush: Uh, no, I knew
I was going to do it.
Um, more as a motivation to myself.
Just like To kind of prove to myself that
there are people who want to buy it and
I should I should actually finish it.
Philip: Yeah Was that the first
time you told other people publicly
that you were working on it?
I was secret more or less like
from the public eye for a year.
Ayush: Yeah, I was very private about
I shared it with very small set of
friends for feedback and things like
that, but I know a lot of people enjoy
building in public and I think it's it's
A lot of people do it without a good
reason, but let's not get into that.
Um, that was never my thing.
Uh, that doesn't appeal to me.
Uh, I had a very strong vision
for the product from day one.
Um, there are very few people
whose opinions that I trust.
So I shared it with those people.
I took their opinions on what they
are very helpful, uh, with, with a
lot of things, but I'm not the kind
of person who would ask Twitter or
whatever and say help me make this
decision because I'm like, that's.
Philip: Yeah.
Ayush: I don't like that.
Like, if a product decision
needs to be made, it needs to be
my decision based on my vision.
Philip: Yeah.
That's great.
I think it's also really smart
because I was listening to this Andrew
Huperman episode a while ago about like
dopamine and motivation in your brain.
And apparently like the anticipation
of something creates one spike.
almost as high as the spec of dopamine
you get from actually getting it.
So if you think, oh, I'm going to go
get an ice cream right now, like your
brain, it gets excited almost as much as
if you're actually eating the ice cream.
Oh, wow.
And I think there's a danger in
announcing things before they're done,
because you get this burst of energy
from the excitement of announcing it.
And then there's, this lol, you
actually have to do the thing and
if you're writing a book, right?
like it's really easy to announce a book
and like get all these pats on the back
that like you are launching this book
and then you have to go do the book and
I think that it was useful for you to
instead of Taking that spike of energy
at the beginning to get you started
You already had the motivation to get
started beginning and so you save that
spike of motivation almost to like get
you over the finish line Yeah, which I
think is a really smart way to do it, too
Ayush: Yeah, that's a great way to look.
I don't actually, that wasn't intentional,
but looking back at it, that's exactly
what I did, probably just subconsciously.
Uh, but yeah, yeah.
It's like when you're
Philip: at the bottom
of the trough, right?
Yeah.
Ayush: I think I needed that at the
time as well, because Like when I
announced the book in September,
I was still hoping for an October
release and it went into December.
It's just the way these things are.
Yeah,
Philip: well that was the deadline, right?
It's like things, what's the, the laws,
like things take as long as you get them.
Ayush: Yeah, I love
Douglas Adams quote on it.
I love deadlines.
I like the whooshing noise
they make as they fly by.
Philip: That's great.
Tell me about Ayush, the writer.
Do you consider the type of writing
you do to make you a writer?
Or do you consider it more of
like, technical, and had you
ever written anything before?
Ayush: Um, well, I've written
a, I write a blog, a technical
blog, uh, which I haven't updated
in a long time, but my writing
experience is pretty much just short.
technical tutorials.
Um, I think, I still don't really
think of myself as a writer.
I, uh, I think of myself as an average
writer who works very hard on his writing.
Like, I, I do believe my book
is very well written, but I
don't think I'm a good writer.
I had to work really, really
hard to get it to that level.
Like, uh, each chapter
got two rewrites minimum.
Like I would write a chapter and then move
on, go on to the next chapter, whatever,
like a month later, come back with,
uh, with a fresh mindset, rewrite it.
And I do that process two, three
times over, just to cut out as
much fluff as I possibly could.
Philip: Yeah.
Ayush: Phrase it like as,
uh, concisely as I could.
Uh, it was.
It's an absolute drag of a process.
If I was a better writer it
would have been easier to do.
But like I said, I think of
myself as an average writer who
works very hard on his writing
Philip: I think that
your writing was good.
But technical writing is such a
different type of writing than like
prose because I did a technical writing
class in college and I'm thinking
back to it and it was like one of my
most fun classes I did in college.
But, it was this weird class because
the teacher came from like the English
department, but was really deep into
teaching technical writing, and we would
like, review like Shakespeare and be like,
do not write like this in technical forms.
And then we'd review an IRS form, like our
tax agency in the USA, and be like, this
is like a better way to give instructions.
And, um, I think that technical
writing is a really different
style of writing, that, um,
I'm happy to hear that you are happy
with your writing, because I think that a
lot of people who would consider writing
a book, from a technical perspective
in particular, would think that the
writing was a really big challenge.
But I think that they might not
recognize that the style of writing
for a technical book isn't Shakespeare.
Like, you don't have to
be writing like that.
It's probably better if you don't, right?
Yeah.
Ayush: Yeah, it's, it's a very
different kind of writing.
Um, I think it's important to have some
lessons from like the world of fiction
just to kind of keep things engaged.
I like to keep a reader engaged.
It's very hard though, it wasn't.
It wasn't something I was
thinking about consciously.
Again, if I was a better writer, I would
have thought about that kind of stuff.
But, yeah, I think, um, as just a
professional programmer, I think
writing is almost a superpower.
Like,
it's not the kind of thing you're
just naturally good at or bad at.
It's a thing that can be learned.
Like, I think most skills, can
be learned up to a good degree.
Um, just in your professional
work, I think writing will really,
really help you, uh, just be
a better programmer, I think.
And, um, I think the best way to do it
is just try, like, try writing a blog.
Like, you learn something new,
write a blog post about it.
It's the only way you're
going to get better.
Like, I think, you know, even while
during writing the book, I became
a better writer as I went on.
So like when I would come back to the
early chapters, what was I thinking?
Like I can cut out entire sentences here.
Like why did I write all this?
But yeah, the best way to
improve is just keep doing it.
Philip: Yeah.
That's great.
And how did you edit the
book before you published it?
Did you have any external editors?
Did you run it through Grammarly?
Did ASCII Doc provide any
tooling for even spellcheck?
Ayush: Uh, no, I did everything
myself because I'm mad.
I did have a tool, I can't
remember what tool it was.
I can't remember the name.
It was a rudimentary
spellcheck and grammar check.
It was a command line tool, I can't
remember what it's called now.
So I just ran through that and
it was Kind of had some awareness
of ASCII doc, but not really.
So I had to kind of sift through
some of the errors to figure
out what's valid, what's not.
Uh, yeah, it was very rudimentary.
I was without training
wheels for most of it.
I think I would have liked to maybe
have an external editor, but then
there were two things I need someone
I trust and I didn't know someone.
Uh, who could do that kind
of thing, whom I trusted.
Philip: Yeah.
Ayush: And, um, I didn't really
have the money to pay either.
So, I didn't want to ask someone
to do it for free, obviously.
Yeah.
So, I just did everything myself.
Philip: So, you talked a lot about
kind of the motivation of like
getting the book over the finish line.
I think having a deadline is one way.
A lot, another way to kind of keep
working consistently is to work
on a project with someone else.
Like, I'm thinking of my software
for like, If I try to build something
alone, a deadline works, but if I'm
working with other people there's
kind of this, like, group motivation.
Would you ever try writing a book
with other people, or do you
think that would help with kind
of the, the pace of delivery?
Ayush: Probably not, because just the kind
of person I am, I would fight with them.
Okay.
You want the control.
Yeah, yeah.
Like, I'm fine like when I'm working
with a client or in a company or
something, because it's just, you
approach that slightly differently, right?
Uh, but when it's a project
that's kind of mine, I tend to
be a bit of a control freak.
Sure.
Uh, it's like, It wouldn't
be a healthy relationship.
And I know myself well enough
that, uh, it's going to end badly.
Philip: Yeah.
And so tell me about launch.
Do you feel like the book has done well
based on the standards you set out for
yourself and like where relative to
the pre launch and the actual launch,
did you start to feel like that?
Ayush: Yeah, I'm really, I've
been blown away, to be honest.
I had no audience at all.
No reputation in the Ruby
industry when I wrote this book.
And the response has been
pretty overwhelmingly positive.
I was very braced for people
to kind of criticize it because
the book is opinionated.
There are certain things that I am
very clear in the book about, like,
Like I think this is wrong or whatever.
Um, but I've not had criticism to be
honest, like I've had constructive
criticism, but nothing, no one's
saying that this is shit and that shit,
which, which I've been surprised about.
Um, I think, yeah, I'm, I'm,
I'm really glad I did it.
It was the, it's the most
challenging and most rewarding
professional project I've ever done.
Um, yeah, I think.
It was really a few months after the
main launch that I kind of looked
at the sales numbers and I'm like,
whoa, okay, this is doing well.
I did get a decent number of pre
orders as well, but it was, I
think only after the whole thing
was done, I had, I could breathe.
Philip: Yeah.
Ayush: Um, I had a stable contract
to kind of get me back on my feet
after all the time and money I'd
invested in writing the book.
I could just take a breath
and just look back and like, I
think that that was a good idea.
I think.
Philip: Yeah.
That's great.
Based on your experience, do you
think that you could ever make a
full time living doing writing?
Or do you think that the externalities
were more than, like, how much
you actually made on the book?
Ayush: Uh, I don't think I
ever want to, to be honest,
uh, just do writing full time.
Uh, I have thought about this a lot.
I think, uh, I do want to, I do.
Kind of have a bit more income from
products, either either SaaS products
or, um, another, uh, educational
product, maybe a subscription based
product or something like that.
But I think I just, I like freelancing.
I know you get to work on such
diverse, interesting projects.
I, uh, I do like freelancing, so I
don't think I ever want to completely
stop the freelance side of my business.
Um, I think I just get bored if I was
writing all the time, to be honest.
So yeah, like, um, but in terms of
just the economics of it, uh, I still
don't think I would consider myself
broken even on the book, like for
the time that I invested in it to the
money that it's made, um, I don't, I
think I'm still a bit away from what
I would consider a breakeven point.
So, um, in just cold hard numbers,
uh, maybe, uh, it's not viable,
but, uh, it's acted as a, as, as a
lead generator for freelance work.
Like we met because of the book.
So, um, in that regard, you can't put
a monetary value, uh, on that, right.
So, which was a key aim of the
book was to kind of help with,
with my freelancing career as well.
So, yeah, I don't, I don't know, to
be honest, uh, in cold, hard numbers,
maybe it's not been profitable, but
it's, it's been rewarding in other ways.
Philip: Yeah.
And it seems like you're, you
also learned a lot from this.
Like I know people who did.
Like master's degrees and
didn't work as hard as you're
describing, that you worked on
Ayush: this book.
Yeah, yeah, it's uh,
I've never liked school.
I've never liked college.
I hate giving exams.
For me, having some work to show
always has had a lot more value.
So this was kind of like, I guess, I
didn't work very hard at university.
It was a pretty easy course to be honest.
I kind of, I I got out of it
on second gear, to be honest.
Yeah, yeah.
This was my, probably my Everest.
Philip: Yeah, but it seems like you're
coming to the point now where you'd be
okay with writing another book, which
is, I think is great because that means,
you said this is the hardest thing you've
ever done, but you want to do it again.
Is that right?
Ayush: Uh, I'd be open to it.
I wouldn't go, I wouldn't,
I wouldn't go all in on it.
And like, I wouldn't, uh, stop
freelance work to go all in on it.
I would let it take as long as it
needs to take, but do it side by side.
Philip: Yeah.
Ayush: Um.
Yeah, never say never, but just so,
uh, the pure economics of it might
make me consider a different model.
Like the thing I touched on earlier
about a subscription based service,
like, um, especially in the Ruby world,
there has been success for people who
run like screencast series like Go
Rails and stuff, which you're aware of.
Um, there's nothing text based though.
Um, so that's an idea I've
kind of been playing with.
Let's see.
I
Philip: think that would
Ayush: be cool.
Yeah.
Like, uh, cause I can kind of seed
something like that with a lot of
content from the book cause the
book is this huge behemoth really.
Yeah.
I think there's a lot of value
in breaking that out into bite
sized chunks, uh, in the form of,
uh, blog post length tutorials or
series of four or five blog posts.
So.
Philip: Yeah.
Ayush: These are all ideas
I'm playing with in my head.
But I think just from.
A financial point of view, I think
subscription is a more viable way to
kind of justify investment, my investment
of time into written tutorials.
Philip: That's great.
You also could have done paid
articles instead of writing a book,
but it seems like there's been an
impact, either external or internal,
having done something really hard.
It seems like you built an audience,
it seems like you got confidence
in Ruby on Rails, it seems like you
gained respect within the community.
Maybe this is kind of like
a concluding question here.
Do you think that doing
something hard was worth it?
Ayush: Yes.
Um, yeah, I'm not really a big fan of
shortcuts, like, um, Yeah, I don't know
if this is going to be super controversial
or not in 2024, but I'm not, I'm not a
big user of AI in my development workflow.
I do use a little bit of chat GPT
and stuff for help, but I find
when I learn stuff the hard way.
I gain a very deep understanding of it.
And a great example of this was just a few
months ago on the back of a talk that I
saw on YouTube, which is, I think, about
the Async gem, uh, by Samuel Williams.
Philip: Yes.
Ayush: I went into this completely
tangential deep dive into Rack,
which is, uh, for people not familiar
with Ruby, it's a specification
for like Ruby web servers.
For no real reason, I kind of
just kind of went off on tangents.
It was like, Oh, I don't understand this.
I'm going to go, uh,
try to understand that.
And it was all through reading
source code, internet searches,
and just that kind of stuff.
The thing that initially the question
that I had, if I'd just gone and
put it into chat GPT or whatever, I
would have got an answer and I would
have stopped there because I was
going around things the hard way.
I now have this deep understanding of a
rack, which also led into a contribution
I made to the Bridgetown project.
Uh, like just because I had all this
understanding, like this applies to
Bridgetown, I can improve that product
with all this stuff that I understand now.
So that kind of snowballed into
this contribution that I made,
which is set Bridgetown bot.
Which is where it should be
going in the next few years.
I've made a first step towards that.
So, yeah, I do believe that you
should do things the hard way.
It's kind of like lifting weights, right?
You can't build good muscle mass
unless you really put in the effort.
There's no shortcut to it.
That said, I'm not against, like,
Using things like AI as a tool, I, uh,
Philip: Yeah.
Ayush: My kind of, the way I think about
it is I use it as a tool, not a crutch.
Philip: Mm hmm.
Ayush: So, I'm very much in favor of
doing things the hard way, and sometimes
I regret my life choices, but then
when I, at the other end of it, I'm
always glad that I chose that path.
Philip: Well, I think it seems to
make you a curious person, right?
Like, the fact that you're, when
you're looking for an answer, it seems
like your goal is not the answer,
but your goal is, you know, It's
understanding more than just the answer.
It's like the answer is a
question in and of itself.
Ayush: Yeah, exactly.
Um, Sometimes doing things
the hard way will take you
down paths you didn't expect.
You'll learn things you didn't expect.
You'll, you'll become curious about
other things that you probably
didn't even think about earlier.
Philip: The unknown unknowns, right?
And that's like a thing we often
talk about in the tech world.
Especially in like
engineering teams, right?
Sometimes you look at things and describe
it as an unknown unknown which means,
you know, I don't even know where to
start, and I have no idea how long
it'll take, or anything like that.
It seems like kind of embracing the
uncertainty is a form of communication.
Curiosity seems to have
worked really well for you.
Ayush: Yeah.
I mean, it's, it's a pretty crowded
space, uh, like, uh, both tech
education and, uh, freelancing and
you got to stand out somewhere.
Right.
And I think, um, the only way you can
stand out is if you do something that's
quite difficult, but that kind of
stands you above everyone else and, um,
seems to have worked by some miracle.
So I'm thankful that it has.
Philip: I think it also just represents
the future of work too, in that a
lot of people have a generic kind
of looking degree, but this really
is a, an opinionated hard thing
that differentiates your work.
And I think that the future of work
probably looks more like, uh, projects
and demonstrating what you've built,
I think, because It speaks way
more to, like, the character of the
person rather than, like, what they
were able to purchase or something.
Ayush: Yeah, exactly.
Philip: Well, thanks so much
for taking some time to chat.
Definitely recommend people check out the
book, especially if you started with the
Ruby on Rails tutorial and are looking
for something a little bit more advanced.
Is there anything else you want to plug?
Do you want to share your website or any
other places where people can find you?
Ayush: Uh, yeah, my business
website is radioactivetoy.
tech, so Um, I'm working with Philip
at the moment, so I'm not available for
work, but, uh, if you ever have any, uh,
Ruby needs in the future, check that out.
Uh, my blog is binary solo.
blog, and at some point I'm going
to bring my mailing list product
back to life, which is scattergun.
email.
Philip: That's great.
And what's the website for the book?
Ayush: RaiLs and HotwireCodecs.
com.
Philip: Cool, I'll add
a link in the notes.
Cool.
Awesome, so thanks a lot for chatting.
Hope you enjoyed the picante.
Ayush: Yeah, the picante was great.
Thanks for having me on the show.
It's a pleasure.
Philip: Awesome, thank you.
Ayush: Cheers.