May 8, 2025 • 63 mins
Hey folks, in this week’s episode, I sat down with the incredible Ridhwana Khan — a South African technical writer for the Rails Foundation and lead engineer at Circle. We had a fantastic chat about all things Ruby on Rails, but especially the underappreciated art (and science!) of writing documentation.
Ridhwana took us behind the scenes of the official Rails Guides — how they’re updated, expanded, and reviewed — and gave us a real sense of the thoughtful, collaborative work that powers one of the best-documented frameworks out there. She also shared her personal journey: from freelancing into Rails doc writing, to her passion for building inclusive communities like Rails Girls South Africa and Black Girls Code.
Some standout takeaways:
This episode was equal parts inspiring and insightful — especially if you’ve ever looked at the Rails codebase and thought, “how the heck does this work?” Ridwana makes it feel accessible, and she’s proof that curiosity and community-building go a long way in tech.
Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
Ridhwana took us behind the scenes of the official Rails Guides — how they’re updated, expanded, and reviewed — and gave us a real sense of the thoughtful, collaborative work that powers one of the best-documented frameworks out there. She also shared her personal journey: from freelancing into Rails doc writing, to her passion for building inclusive communities like Rails Girls South Africa and Black Girls Code.
Some standout takeaways:
- Metaprogramming = Superpower: We talked about the "magic" in Rails internals — especially metaprogramming — and how understanding it can make you a better developer. Ridwana gave a real-world use case from her time at Dev.to where metaprogramming enabled highly flexible custom profile fields. Elegant and practical!
- Docs as a Gateway to Contribution: Whether you're new or experienced, contributing to Rails docs is a great way to get involved. Ridwana encouraged folks to read the source code, dig into tests, and not be afraid to open a PR — even if it's small.
- Working on Circle: Ridwana’s team focuses on Circle's marketing and email hub features — think broadcasts, workflows, and analytics. She's leading the team (and hiring!), and we geeked out over async work, remote culture, and what makes for a great engineering org.
- Life in Cape Town: From houseplants to penguins, we veered off into Ridwana’s love of nature, her Arduino hobby projects, and even how Shark Week got us thinking about visiting South Africa someday.
This episode was equal parts inspiring and insightful — especially if you’ve ever looked at the Rails codebase and thought, “how the heck does this work?” Ridwana makes it feel accessible, and she’s proof that curiosity and community-building go a long way in tech.
Become a supporter of this podcast: https://www.spreaker.com/podcast/ruby-rogues--6102073/support.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:04):
Hey folks, Welcome back to another episode of the Ruby
Rogues podcast. This week, I'm your host, Charles Maxwood, and
I am talking to Ridwana Kahn from South Africa. Very cool.
I've always wanted to go down there and see different
areas down there. But anyway, you gave a talk at
(00:25):
Rails World. You talked about a whole bunch of the
internals on Ruby on Rails, and it looks like you
also help write the Rails guides, which is awesome. That's
one of the nicest things about rails is when I'm
talking to people and it's like, well, how do I
even get started? It's like, we've got these great guides.
Just go, you know, go spend a half hour or
(00:46):
so with them, and then you're pretty much off to
the races. So why don't you go ahead and introduce
yourself as far as anything else you want people to
know about you, why you're popular or famous and all
that stuff.
Speaker 2 (00:59):
Yeah, So I'm Ridwana, like you mentioned, I'm a technical
writer for the Rails Foundation. I've been helping to improve
the official Ruby on Rails guides for the last year
or so. I'm also a lead engineer at a company
called Circle where I focus on building tools that empower
creators and communities, and I have about over a decade
(01:25):
of experience in software development. Over my career, I've worked
mostly within the Ruby and Rail space as well as JavaScript.
I think if I had to sum up the things
that I'm passionate about, it would be making code more
accessible through documentation, and that's why I write the Ruby
on Rails guides, thought for engineering, and just inclusive community building,
(01:48):
which is why I work at Circle because there are
community building platform and I've built many communities over my career.
I try to both communities where I see a gap.
So the most obvious one is sort of the woman
in Tech gap. So over my career I've both communities
(02:09):
like women in Tech. I've both Rails goals in South Africa,
Rails Bridge, Black Gull's Code Ladies that You Ax, which
is the intersection of a development and user experience. So
just really passionate in that space. And on a personal note,
if I'm not coding, I'm trying to keep an eye
(02:30):
on my ever growing collection of house plants and trying
to keep them alive. They're constantly dying. I also really
enjoy traveling and going to speak at conferences. It's one
of my favorite things to do. And finally, just hanging
out with my very opinionated feline peer programmers or per programmers,
(02:53):
Zoe and Zeus. If you watch my talk at Rails World,
you've seen some really goofy photos of them. Yeah, it's
basically me.
Speaker 1 (03:03):
Very cool. So I have you Circle before? We used
it for I try to set up a community for
the podcasts, and I tried it out, so yeah, that's cool.
I didn't know they were a rail.
Speaker 2 (03:18):
Shop, so yeah. And before Circle, I was at dev
dot two also known as Forum, also a community platform.
So I've just been moving around community platforms recently.
Speaker 1 (03:31):
Right, Yeah, I was going to say I'm detecting a trend.
So I am curious as we dive in, right, because
I think a lot of times when we talk to people, it's, oh,
you're doing this very cool thing with code. And I'm
sure you do cool things with code. I'm not trying
to say you don't. But the thing that's interesting to
me is I think a lot of people don't really
(03:52):
think about, Okay, what goes into the documentation, what goes
into the rails guides and things like that, and I'm curious,
how did you get involved there? Did you just I
don't know, go tell the foundation, Hey, you need to
fix the easer. I don't know what will happen there.
Speaker 2 (04:09):
No. I think around last year, I want to say
around January twenty twenty four, Amanda from the Rails Foundation
was actually looking for writers to work on the Rails
Foundation Ruby on Rails guides, and so they put out
a post to say they're looking for two freelance writers
(04:32):
to work on the Ruby on Rails guides. And during
that time, I was sort of between different gigs and
I'd been using the Ruby on Rails guides a lot,
and so I decided, why not let me apply and
see how it goes. And yeah, I started writing for
(04:55):
the Rails Foundation myself and another writer, Boomy. We started
off and we worked with a couple of other peoples
to people to review the guides, and that's how it
all got started.
Speaker 1 (05:10):
Very cool. So is that paid or are you doing
it because you love us?
Speaker 2 (05:21):
I mean, I'm doing it because I love y'all and
I love the guides and I love what I do.
But it is also paid, Okay?
Speaker 1 (05:29):
Cool?
Speaker 2 (05:33):
Yeah?
Speaker 1 (05:33):
I mean I had I guess I hadn't really thought
too much about it, but now that I'm thinking about it,
I'm like, oh, wow, so are there because the guides
have been around for a while, are there any new
guides or is it mostly just updating what was already there?
Speaker 2 (05:47):
So initially we started with updating what was there, but
when Rails eight got released, we had a couple of
new guys that we needed to implement, and we've done
that as with the release. So it's a combination of both.
We look at the old guides, we audit them, we
(06:08):
see what needs to be updated, and we update them.
But then we're also as Reels releases new features, we
go in and we create new guides. Also, if contributors
create prs for new features, sometimes that means we go
through the pull requests and we update the guides with
(06:29):
new information on new sections.
Speaker 1 (06:32):
Gotcha, So how much time are you spending every week
working on the guides?
Speaker 2 (06:38):
So we put a pause a little bit recently is
the new year started, but I'll be begin it up
again later this month. I spend around I want to say,
I forget the actual number of hours because we've put
a pause on it for the last three months and
we're just starting again, but I think it's around two
(07:02):
in two hours a week. I stand to be corrected.
It's been a while.
Speaker 1 (07:08):
Uh huh, that makes sense. And what's the process. So,
I guess the process is different if you're auditing versus
writing new ones. But yeah, what does the process look like?
Speaker 2 (07:19):
Yeah? So, I mean I don't do a lot of auditing.
We have a specific contributor that helps with the auditing,
so Patrick Patrick Hosh he does the auditing of the
guides and a lot of the reviewing of the guides.
But essentially what he does is he comes in, he
audits them, he checks which ones we need to update,
(07:44):
and then once he's audit audited it, we use base
camp and we basically keep track of which guides need updating.
Then one of the writers will go in and they'll
look at the existing guides. The trick will already have
some notes in on what he thinks can be improved.
We look at it with fresh eyes. We then decide
(08:06):
what can be improved from our side. Sometimes that's how
I started diving into the source code. I dive into
the source code see how the internals work, because I
feel that if you really understand how the internals of
Rails works. Then you're able to explain the things better.
Once that's done, we send out a PR. It goes
(08:27):
through internal review first within our team. Once internal review
is done, we then create a PR for the open
source community to be able to review the guides. Maybe
they pick up some areas or gaps that we may
have missed, and then finally we emerge it.
Speaker 1 (08:48):
Very cool. So are they in the Rails repo or
are they somewhere else?
Speaker 2 (08:56):
Yeah, so they're in the Rails repot and usually we
encourage which open source contributors to have a look through them.
The guides are marked with a label RF docs and
it has a label sorry in the title. We usually
have a prefix rf docs and then it has a
label Rails Foundation. So if you're trying to find any
(09:19):
of the docks, you can do that, and we really
encourage the Rails community to review them because it means
that if you're learning Rails, or even if you've been
using Rails for a long time, you basically know we
some of the gaps lie what you've struggled with, and
when you review them, you can bring some of their
fresh perspectives to our prs.
Speaker 1 (09:42):
Right, makes sense. So yeah, I'm curious how deep into
the internals have you gotten, because I mean your talk
was a half hour, so you didn't get too deep
into things, But it sounds like you spend a bit
of time looking at how RAILS is actually put together
under the hood.
Speaker 2 (10:02):
Yeah, I think. I mean, depending on what guide I'm
writing at the time, I then dive into the internals,
and sometimes it requires a deeper dive. Sometimes it doesn't.
I feel like when you're writing documentation, it's not really
enough just to describe what a method does in a surface.
You need to understand how it works, why it behaves
(10:23):
the way it does. And that's taken me to some
of the more complex parts of RAILS are code based.
So for example, in the talk I talk about mime types,
I've traced through how RAILS handles the different mind types
using math. Missing I've done. I've dug really deep into
active recorde associations because that's a very big part of
(10:46):
RAILS as well when you're writing applications, so things like
the definitions of the dynamic methods and so on, I've
looked at I think I mentioned in the talk, as
well as validations. So RAIL uses like the dynamic callbacks
things like that. I've dove into some parts like that,
(11:07):
and I think that the most common pattern is just
the meta programming aspect of it. Right, So trying to
find those patterns across the different parts of Rails or
components in Rails and then trying to understand it a
little bit better. The Rails codebase is really huge, and
there's like always more to learn, but the magic is
(11:30):
beginning to feel a little bit less like magic is
you start understanding more of it.
Speaker 1 (11:38):
Yeah, I mean it seems like we've talked to different
people about metaprogramming on this podcast over the years, and
so yeah, a lot of what you put up there
was like I was like, oh, I see how that works,
and yeah, so I can kind of get the idea
that yeah, it feels a whole lot less magic and
(11:58):
a whole lot more. Oh. You know, this is a
tool that we used, and you know, and so it's
able to you know, for example, you know when it's
defining methods using defined method right, it just puts things
in place, It does the work. And one thing I
hadn't thought of with the mind type mind type is
you define the method and then you just call it.
(12:19):
I was like, oh, that that makes sense. So yeah,
I really liked that, and really liked just the clean
approach to explaining how all this stuff works.
Speaker 2 (12:31):
Yeah, I think the main aspect really and again I
have to emphasize it's the patterns. Rails is a lot
of magic. But once you identify some of the patterns,
and once you understand how meta programming works, you sort
of start putting these puzzle pieces together and you're able
to understand the code a lot better. And then you'll
(12:53):
see with the different components, there'll be one pattern here,
and then it's applied in this different place. And what
I tried to also do within the talk is show
how those patterns are applied across the different components. So
if you understood it in one component, you can go
and dive into a different component and it has very
similar patterns. And once you think of it like that,
(13:16):
it feels a lot more approachable. Because when I started
off in rails, and even like up until a few
years ago, I there was all this magic happening in rails.
So when you reach a point of like, hey, I'm
doing this thing, but it's a little bit more complex,
and now Rails isn't playing nicely with me. You don't
(13:39):
really know where to go from there. But if you
try reading the source code or you try looking into
how Rails is actually working, you're able to move past
that blocking point and do more complex things. I mean,
ideally you don't want to break away from the magic,
but unfortunately there is real of it is when you
(14:01):
both complex applications, you end up needing more tools under
your belt, and I feel like understanding the code base
is a tool under your belt.
Speaker 1 (14:13):
Yeah, that makes sense for me. What I found was,
as I've learned, I learned Rails first, and then they're
Ruby later. As far as like what all the other
things are that Rails kind of makes it so you
don't have to deal with right off the bat was
I would build stuff and then yeah, I would get
stuck on something right It'd be like, I don't know
(14:34):
why it is doing this, Why is it acting this way?
Why is it, you know, doing this thing to whatever
it is that I'm trying to work on. And it
it became pretty apparent once I started to learn Ruby.
It was like, oh, it's doing this because Ruby works
this way, and so it's just using the Ruby mechanism
(14:55):
to do the thing. And so yeah, I love that
idea of saying, Okay, look go look at the internals.
It may be something you haven't done before, but it's
it's not a mystery, it's not complicated or hard. It's just,
you know, it's something that maybe you need to learn
a little bit more about. And then you look at
(15:15):
it and you go, huh, Okay, this is where this
is coming from. This is why I have this the
way that it is.
Speaker 2 (15:23):
Yeah, And another aspect of it is that when you
go through the Rails code base, you're also not only
learning about Rails itself, but you're potentially learning how to
solve problems elegantly. Right. So, Rails does solve problems elegantly
and very often when we're working on our features within
(15:45):
whatever application or companies were working for with you solving
similar problems in just different use cases or different forms.
And so by going through the Rails code base, you
were able to also learn problem solving skills.
Speaker 1 (16:05):
Yep. Absolutely, So let's talk about some of those skills
or some of the things that you've seen in the
code base. You kind of went straight to metaprogramming, and
I've seen plenty of people over the years basically talk
about how metaprogramming is scary or you can get yourself
into trouble with it. I don't know how do you
(16:28):
feel about that argument about using metaprogramming or not.
Speaker 2 (16:36):
I think that using meta programming, I think you're going
to have a lot of people saying meta programming is
the best, and some people saying that you shouldn't use
meta programming. I think that there's a use case for
meta programming. Meta programming is a superpower and it can
(16:57):
lead to really elegant, expressive code, but it also can
lead to very scary and intimidating code that's very hard
to follow. So I appreciate meta programming, but I also
respect that it has a lot of complexity and it
can make code harder to debug, especially if you're not
(17:19):
familiar with the patterns, or if it's overused without like
clear naming or clear direction. So I wouldn't say that
I feel strongly that everybody should use meta programming. I
think that meta programming needs to be used based. I
think metaprogramming has a place, and depending on your use case,
(17:41):
meta programming may be a good fit. But if you're
using metaprogramming for any for everything, you may just be
over complicating things.
Speaker 1 (17:51):
M hm, yeah, I think that's I think that's a
fair way to put it. I do a lot of
work on my cars or my house or whatever, and
what I found is that most of the time, you know,
just just the regular tools work right, you know, and
even if I pull out the power to tools, right,
they work. But occasionally I've got to open up a
(18:13):
wall with a saw, or I've got to use some
other tool that, yeah, you know, may have some safety
hazard to it or something if you're not using it properly.
And that's the way I think about metaprogramming is is
you know, you don't want to take more out of
the wall than you have to, so to speak, you know,
(18:34):
you don't you have to be careful not to hurt
yourself with it. Sometimes the code can be hard to
debug when you're using metaprogramming, and so, yeah, you know,
what I find is most of the time when I'm
reaching for something like metaprogramming, I am doing something on
the level of rails, right, And so what I'm doing
is I'm actually using it to provide myself with the
(18:56):
pattern I want to see in my code, and so
that winds up being in like the lib folder, you know,
somewhere else where. It's it's not code that I'm going
to go touch all the time, and it's not code
that I'm using to solve all my major problems. What
I'm doing is I'm just basically using the metaprogramming to
create a better tool for me to solve the problem.
Speaker 2 (19:19):
Yeah, and I think I think your example, by the way,
was great about how you do work around why I
work around the house, and sometimes you need to bring
out the right tools. In my talk, I talk about
like a real world use case where we use meta programming,
which I think is really valuable. So when I was
(19:40):
working at dev dot two or known as forum as well,
we were building of course community software, and we needed
a way during onboarding to letter from communities define custom
profile fields for their members. So, for example, in the talk,
I use the example of a go gardening community, and
(20:01):
for a gardening community, during onboarding, we may want a
profile field that a user can enter their favorite plant,
or a developer community might ask if you're available for hire.
So these fields need to be highly customizable, and they
might need to be dynamically edited at run time. They
(20:23):
also might support different data types like strings, booleans, dates, etc.
So rather than hard coding a bunch of different profile
attributes that are different for different communities, we use mata
programming to dynamically define gatters and setters for the custom
fields is the community has created them, and it meant
(20:46):
that communities could define as many custom fields as they
want and the system would just respond. There were no
migrations or extra model code or no like hardwired logic.
It just made the system really flexible. And I feel
like that's a great example of how meta programming is
used in a real practical way to solve a problem.
(21:07):
But like you say, I feel like they are very
like meta programming. In my career, I think that's probably
like one of the very few cases I've needed to
use metaprogramming, And maybe there's like one or two others,
But over ten years you're mostly building standard applications that
(21:30):
don't necessarily require that level of customization, right.
Speaker 1 (21:35):
Yep, absolutely, So what other things have you found going
back to rails internals, What other things have you found
that maybe you wanted to add to the talk but
didn't have time or have thought were interesting that people
don't really see or know in the Rails codebase.
Speaker 2 (21:54):
I think there's so many gems no pun intended in
the Rails hood base. One of the things that I
really enjoy about, like exploring the rail's internals, is seeing
how thoughtfully things are architected. So when you like how
it gives you a whole ecosystem of dynamic methods. How
(22:19):
things are named really well, such as very thoughtful processes,
how things sorry very thoughtful naming. Also how the different
components are well separated, things like how well the code
is documented. I think that's really a superpower. If you
(22:40):
go through the Rail's code base, you'll find sort of
method definitions, you'll find how the Rails API documentation is
within the code base, and you can see what the
different methods are doing. So I think there's a lot
of sort of other practices that the Rails team uses
(23:04):
within their sort of actual development, and I found a
lot of those useful alongside the matter programming aspect and
the great architecture. I also think so may one more
thing to air the like the PR. I found that
(23:26):
when I'm writing documentation, I also sometimes tend to go
through like the open issues or poor requests to see
did someone touch on this. Maybe there's something I don't
really understand and I want to understand it better, but
maybe the rail's code base doesn't provide as much information.
I find that when I go through poor request reviews
(23:50):
or even issues, contributors and the core team are very
for both about explaining things. They do a really great
job about articulating themselves and working together to form a solution.
So it's really nice to go through poor requests, to
(24:11):
go through issues, and I really encourage people to just
if you're not contributing to rails, or you're not reviewing
documentation prs or even just normal rails code, like just
browsing the issues and the poor requests casually can provide
a ton of information and useful knowledge.
Speaker 1 (24:35):
Makes sense. So do you have any advice for people?
Let's say that you know somebody. I mean, I have
to admit I haven't really contributed to rails. I think
I've I've filed bugs. I think I've maybe put in
one poor request in my whole life against rails. So
if somebody wants to get involved and they're sitting there
(24:57):
and they're thinking, okay, well, I just want to understand it,
you know, and maybe they want to contribute to the docs,
or maybe they you know, just want to understand things
better and you know, maybe help with some little thing
here or there. Like where do you recommend that people
start with the RAILS code based to just understand what's
going on in there? Yeah?
Speaker 2 (25:16):
I feel like I am so I get so excited
when someone asks me this question. I'm biased, but I
feel like starting with documentation is a really good way
to get into contributing to RAILS or just understanding things better.
Rails places a lot of value on clear, accessible documentation.
(25:39):
So if you're reading a guide or an API document
and something's confusing or missing, just open up a pr
to improve it to add value to the next person.
You don't need to be a core contributor to that.
You don't need to be writing the guide to do that.
You just need to be someone who wants to make
(25:59):
it clear for the next person reading the guides. And
especially I feel like a lot of people that are
new to the industry or that feel they feel they
don't have enough knowledge to contribute to RAILS or something
or the other. That's how I felt for a long time.
I feel like documentation is a clear way to contribute
(26:24):
because if you're not understanding something in the documentation, I
can guarantee you there's hundreds of other people that are
not understanding it as well. Another way to get yourself
familiar with the rail's code based if you're looking to
just dive a little bit deeper, I think read the tests.
They incredibly instructive. So the Rail's test suite is massive,
(26:46):
but it's very descriptive. It shows you how methods are
supposed to behave. It often gives you breadcrumbs to trace
back to the source code. And when you're trying to
understand something or if you think you know fixing a bug,
test are often the best entry point, and writing or
improving tests or just reading the test is a fantastic
(27:07):
way to start. And then if you're looking actively to contribute,
you can look for a good first issue or you
can look, like I mentioned, the docs, TIG the rails
getthub repots very well organized, so there's very often open
issues that are labeled as like a good first issue
or where we need contributions on the documentations. And finally,
(27:31):
like don't be afraid to read this was called Even
if you don't understand it, that's fine. Just a lot
of reading of it. Eventually your mind starts to put
the pieces together. It's like the more you read, the
more somehow your mind just like connects different parts of it.
You start seeing patterns emerge. There's lots of tools as
(27:53):
well that I mentioned in my talk unlike things that
will help you to navigate the rails scode better. So
use some of those tools to navigate the rail source code.
And finally, you don't have to do it alone. There
are so many people in the rail's community who are
so kind and supportive and willing to help. So whether
(28:15):
it's in rail slack or discord or get up discussions,
you can ask questions and you can get unstuck. I
think the main thing, finally, to wrap it all up,
is that rail's contributing to rails isn't really about being
perfect or knowing everything. It's about just being curious and
wanting to make rails better, even if it's in small ways.
Speaker 1 (28:40):
Awesome, All right, Well, I'm just trying to think where
else we go from here? Are there are there things
that you want to add or change or bring forward
(29:01):
with the rails documentation or areas that we should dove
into that it doesn't.
Speaker 2 (29:09):
I think, yeah, I think there's there's a couple of
places or where or we could improve the documentation. There's
a couple of guides and I'm whipping up the guys
is we speak, so bear with me as I do this.
There's a couple of guides which I think could really
(29:31):
use some improvement, and we've got them noted. So. For instance,
one of the ones that I'm hoping to work on
within this year is the active record query interface. It's
a really big guide. I think it's in a good start,
it's in a good place, but I think they could
also be a lot of improvements. We could explain things
(29:51):
a lot better. We could maybe move out sections, make
them smaller, more approachable sections. I think it's one of
the biggest guides, and so I think just breaking it
up into smaller, more digestible pieces will make it a
little bit more approachable. There's also some other sections that
(30:14):
could use some improvement. I think we're already in a
I think the Rails Guides in general is one of
the better guides we have out there across languages. I
think the Rails Foundation has been doing an amazing job,
but there are just individual ones that are working progress.
So like the rails initialization process that's a work in progress,
(30:36):
as well as the active support instrumentation things like active
record encryption. So the first thing we want to do
is we want to finalize those working progress guides because
they may consider they may have right now not like
the full picture picture of what their topic income. So
(31:00):
we just want to fill out that information and cover
the bases, and then we'll go about improving some of
the other guys and breaking them down. But we're hoping
to achieve a lot this yeah, and improve it significantly,
as well as create some new guys that haven't been
(31:20):
covered with RAILS eight.
Speaker 1 (31:24):
Yeah, there are a lot of things that I see
you can do with RAILS eight or I mean even
some of the stuff that came out in Rail seven
that aren't super well documented, right, and I see people
use them and they do amazing things with them, and
it's like, man, why hasn't anyone really just broken this down?
So yeah, I'm looking forward to some of that. Yeah,
(31:50):
So I'm a little curious. I want to kind of
switch over to both Cape Town and to Circle. So
what do you do at Circle exactly, Like, do you
work on a specific part of the platform or do
you just kind of hit whatever needs to be hit.
And by the way, I'll just explain because I've used
Circle and what I find is if you work at
(32:12):
a place, you kind of look at it differently from
the way that people use it look at it sometimes.
So Circle is essentially a forum. You can think of
it as kind of a focused Facebook. It kind of
feels like that Facebook group. And then on top of
that you can add like courses and other things to
(32:32):
your community. You can set it up as a paid
community or a free community. And yeah, it's a really
well put together system. So yeah, so what kinds of
things do you work on there? And yeah, what kinds
of concerns or improvements do you find at work?
Speaker 2 (32:50):
Yeah? So Circle is really established, well written product. We
have some really big communities using it, and it's one
of the It's one of the companies that I've worked
(33:11):
for that is constantly improving and always looking to batter
the product. And it's very exciting because they constantly building
new features but also improving the features that exist in
the application itself. So specifically, I work on what we
(33:32):
call the Email Hub or marketing Hub team at Circle,
and we're basically responsible for things like email broadcasting and
sort of that domain whereby you able to send our
broadcasts to either community members or what we call contacts
(33:55):
within the system or leads. And there's just a lot
of are things that tie into it, so for example,
analytics and that ties into things like workflows where for instance,
when you're onboard a community, you might want to send
a broadcast and then we might want to wait for
five days and send them a follow up things like that.
(34:18):
It's a relatively new team at Circle. I think we
launched the email hub slash marketing hub feature last year.
I want to say around September October. It was around
Rails world time, so it's relatively new. We're actually hiring
(34:39):
for the team at the moment, so I'm leading the
team and we have our two engineers and we're looking
to hire another two engineers for the team. So I've
been doing lots of interviews and hiring at the moment.
Our tax stack is Ruby on Rails and we use
JavaScript as well. It's a pretty big engineering team, so
(35:01):
each sort of sub engineering team is focused on a
particular part of the platform. So we have like a
CRM team and a CMS team and you sort of
focus on a specific domain.
Speaker 1 (35:18):
Very cool. Yeah, I just got hired at Price Picks
and so I've been got you know, we're seeing some
of this stuff, and I'm on the growth team where
we it's kind of your traditional R and D where
we come up with ideas on what we could do
better and then go and invent it and see if
it works. But yeah, I love what you're talking about
where it's yeah, the growth. That's always exciting to see
(35:41):
companies growing and then yeah, just yeah, constantly looking for
that level of improvement. Those are the best companies to
work at. So if people want to apply, how do
they do it?
Speaker 2 (35:55):
We are on we have If you go on the
so called website, you should see a careers Yes, a
careers link and you can view the open roles and
you can find the roles. They're role for a senior
full stack engineer on the Marketing Hub team and you
(36:15):
can apply through this. It's very exciting you'll be working
with me, so please apply. It's also a fully remote opportunity,
which is nice. Those are real and few nowadays.
Speaker 1 (36:30):
Yeah, So you're based in Cape Town. Is your team
like all over the.
Speaker 2 (36:34):
World or yeah, so we have developers from pretty much
all over the world. We in the marketing Hub team
right now, it's myself and then we have two developers
in India, and we're hoping to hire someone in a
(36:54):
European time zone and then maybe sort of North America,
just so that we have that full time zone support,
but also ensuring that we're not too far apart that
we can't collaborate when we need to. So maybe like
with a one hour two hour overlap just in case
we need some sink time, so that gives us sort
(37:18):
of good collaboration across the board. But for the most part,
we use as in tools like Slack and Notion. We
document things very well.
Speaker 1 (37:29):
And yeah, nice, Where where's the company based out of?
Speaker 2 (37:38):
To be honest, I guess since there isn't actually a
head office, No, there's I guess. Yeah, I mean on
the on the on the invoices and stuff. You're probably
it's I think I stand to be corrected. I want
to say the US New York, but again that may
not be actual.
Speaker 1 (38:01):
Sounds good. So, so what's the community like in Cape Town?
I mean Are there a lot of rails developers out there?
Speaker 2 (38:09):
Or yeah they are. We used to have, I want
to say, a well known conference, because when I went
to Rails World and a couple of other conferences, people
have asked me about this conference. It's called Ruby FUSA,
and we ran it in South Africa for a couple
(38:30):
of years. But we haven't run it, I think since COVID.
But there's a really big Ruby community here. There used
to be a lot of meetups previously. I want to
say that since COVID, that's sort of when things slowed
down a little bit. I'm also not originally from Cape Town.
I was based in I was living in Joburg, Johannesburg,
(38:54):
and then moved to Cape Town only like five years ago.
Johanna's Burg also has a really big Ruby community. Is
to have constant meetups every couple of weeks, and yeah,
it's really good. I will say though, because I work
for a lot of US Over my career, I've worked
for a lot of US companies, my community tends to
(39:16):
be more sort of global. I tend to attend conferences
where I'm sort of traveling, and so it's been a
little bit more difficult to keep in touch with the
rails community within Cape Town. But I'd like to see
(39:36):
Ruby Fuza hit the ground running again. That would be
really cool.
Speaker 1 (39:42):
That would be cool. Yeah, So are there any other
personal projects or anything else that you're working on or
is it mostly the Rails Guides?
Speaker 2 (39:54):
So between the Rails Guides and then I like to
tinker on just personal tracks, I've been trying to tinker
with arduinos and connecting that with sort of Yeah, it's
really cool. I've really been enjoying it. I like seeing
like the physical aspect of like things working. So I've
(40:15):
been working on this like sort of with moisturee detectors
and sort of like a like merging my passion for
keeping my house plants alive together with like a little
gardening system. So I've been tinkering with that and it's
been really fun. But between writing code the Rails Guides
(40:37):
and then are doing some of the tinkering, and then
also speaking at conferences, I've been very busy over the
last few months. My next conference is I'm really excited
about is Ruby kontailiand and that's next huge January. One
(40:58):
of the keynotes speakers, So I'm really excited about that.
Speaker 1 (41:03):
Oh nice, that would be so fun.
Speaker 2 (41:06):
Yeah. I've never been to Thailand as well, so super
excited about that.
Speaker 1 (41:12):
Yeah. So do you have any I guess you've been
on the conference circuit for a while. I think I
went and looked at your website and it listed a
whole bunch and I was like, oh, wow, she's been
to quite a few. Do you have any advice for
people who are thinking they want to speak at conferences?
It seems like a lot of people decide they want
to speak, they put in a CFP, and yeah, they
(41:32):
get rejected at the first bunch and then they give up.
Speaker 2 (41:35):
So yeah, I think that I'd say just go for it,
like even if it feels scary at first, Like I think,
if you have a passion for it and you want
to do it, you should. I think the main thing
that I have to say is you don't have to
(41:56):
be an expert. You just need to be curious and
willing to People sometimes assume that conference speakers know everything
about a topic. That's not true. I very often I
will put together ACFP about something that I know nothing
about but want to learn more about, and those make
(42:18):
for the most interesting talks. So things that you're interested in,
things that you may have learned that you think others
might find useful. And especially I find that the cfps
that have the most success rate, at least from my
personal experience, is the cfps that talk about that have
(42:42):
a story that is something that you've experienced and you
want to share with the world. So, for instance, my
reals will talk demystify in the rails code base that
came from a storyline of being a technical writer and
diving into the documentation and some of the difficulties that
(43:05):
I experienced and then sort of what I did in
order to be able to learn how to demastify the
rail's code base. So a lot of the time it's
things that you know, sorry, things that you've experienced, and
you want to tell that story. I feel like writing
(43:25):
an abstract first, even before you have like a full
idea of the talk, that's okay. Sometimes people write their
talks first, or they try to have every not necessarily
to write their talks, but they try to have every
aspect ined out first before you're submitting. They feel that
they need to know everything before submitting. You really don't
(43:47):
have to. It just needs to be a pitch and
then just ensure that you have enough time before the
conference talk of course, and then you can learn on
the way, right, Yeah, and start small and then grow.
So if you've never spoken before, a good opportunity. I
remember when I started talking, the first kind of places
(44:11):
that I submitted my talks to were like local rails
communities that meetups that I went to and I would
talk there. I would get a little bit more confident
in front of people, I would get feedback on a talk,
and then I started applying to the bigger ones. And
that way, you can also put in your cfps that like, hey,
(44:33):
I have spoken at these different communities, I have experienced
speaking things like that.
Speaker 1 (44:40):
Yep, makes sense. All right, Well, I think I'm going
to start leading us toward toward the end of the
show and picks. But before we do that, like, where
do people find you? If they're looking for you on
the internet and they want to.
Speaker 2 (45:00):
Connect, So you can find me on Twitter? What do
we call it? X It's been a few years, but
I still say Twitter.
Speaker 1 (45:09):
I still call it.
Speaker 2 (45:10):
You can find me on AX. My username is Redwana
under school K. My name has a silent age, so
it's our id H w a n a under school k.
You can find me on LinkedIn as well. Sometimes I
post the and I username is Redwuana, but mostly on X.
Speaker 1 (45:30):
Very cool. All right, well let's go ahead and do
the picks. Then I'll start it out and just kind
of show you how we do it, and then you
can shout out about whatever you want. Uh So, the
first pick that I have is it's a board game,
and I almost always do a board game of some
kind if I haven't played anything new, I'll just pick
(45:52):
one that I like that I've played that I probably
picked before. But we played a new one yesterday with
my So I played board games every Wednesday night with
my friends, and we played a game called Colt Express
and it's a train robbery game board game. Geek waits
(46:13):
it at one point eight four, which is kind of
So two is what is about where I tell people
the casual gamers are kind kind of going to go, Okay,
this was a little bit complicated, but not so complicated
that I didn't like it, and it was fun, right.
A one is like the game should play with your kids, right,
(46:35):
so you know, and so it's got enough to it
to where there's some competition and stuff, and some of
the ones are really fun, right, there's simple dynamics you
just but anyway, so this one's one point eight four,
so it's almost a two. It's called Cult Express and
uh it plays two to six players. My friend has
the the Cult Express Big Box Edition, which has two
(47:00):
of the expansions in it, so his will play up
to nine. And apparently there's another expansion that adds another
player too as well, so you can play with a
lot of people. Came out twenty fourteen, and what it
is is it actually has a little train cars that
you put together for your game board, and so you
(47:21):
have the locomotive and then you have one train car
per player, and there's loot on the floor of the
train cars, and so then what you wind up doing
is you have a deck of cards, and the cards
allow you to shoot at the other players. You can
punch the other players. You can move up to the
(47:44):
roof of the car or back into the main part
of the car, and you can move across the car,
so you can move from one car to the next.
And there's a marshal and if you wind up in
the car with the marshal, then then he shoots you
and you move to the roof of the car. The
marshal doesn't go on the roof, and so then the
rest of it is when you owe, and then you
(48:05):
can pick up loot, you can move the marshal. I
think that's it. So if you shoot another player, you
put the shot card in their deck, right, and it's
a no op card, so it dilutes their deck. It
makes them harder, It makes it harder for them to
get what they want. If you punch a player, then
you make them drop a piece of loot. You know,
(48:27):
picking up loot's worth anywhere from two hundred and fifty
to five hundred dollars. There are gems that are worth
five hundred dollars. And there's a lock box or a
strong box on the locomotive where the Marshal starts that's
worth a thousand dollars. And so you just move around
the train and try and get as much money as
possible in five turns. And the way you play the
turn is whoever's first, they put a card on the pile,
(48:52):
and then you go around the circle and everyone else
plays a card right, and so you can see what
they're playing. On the turns where you play face up,
but there there's sometimes there are twists where you go
you go around the circle the other direction right, and
so you may get If you're first, you know you're
it doesn't change a lot for you. But if you're set,
(49:12):
if your last and it changes the direction, you get
to play, the first player plays and then you get
to play again, and so you know that that may
change the dynamics. There's others where you play and face down,
so for for those cards on that on that round,
you don't you don't see what the other players did,
so you can't react to it. There's another where you
(49:35):
play two cards at a time and so you play
twice right, and so you can move and then pick
up loot because you know that you're gonna be able
to get there before anyone else. Or you move and
you punch another player and make them drop loot because
you know that they're going to be there. And then
if you shoot the most shots then you you get
(49:55):
a thousand dollars. So anyway, then you tally it all
up at the end, and and anyway, it was a
lot of fun, a lot of fun. So and the
game board is really unique because it is it's actually
a train that you just set up on the table
and so, you know, I mean it's real small. But anyway,
it was a lot of fun, really really enjoyed that.
(50:17):
It took us about an hour and fifteen minutes to play,
but we were learning how to play, so I think
you could probably play it. We played it with five people.
We probably play it in forty five minutes, I think.
So anyway, very very fun. So I'm gonna pick Cult
Express and then I'm going to shout out about a
(50:38):
few others. So yesterday we had a team lunch with
my team and basically we got sent gift cards for
door Dash, right, so I had food show up at
my house and then we played wiki race and that's
(50:58):
at wikidashrace dot com. And the way that wiki race
works is you and you could put in your own
things that that you start at and end at, but
it starts you on a page on Wikipedia and then
you have to click links to get to the other page. Right,
And so one of the ones we played that it
(51:19):
was like some soccer player from like the nineteen fifties
that you know, there were probably like four links that
went there, right, and so, and I can't remember we
started at but it was something like completely weird, right,
and so you start figuring out some of the tricks
right where it's okay, well, I know this guy's from England,
and so I'm going to get to England, right, and
(51:42):
so I click some of the links that take me
to the world and then countries and then England right,
and then I know he played on these teams, so
I go to the soccer leagues and then England right,
and so anyway, it was It's very, very fun, and
it's basically a race, so whoever gets their first wins,
you know, and then when somebody wins, it shows their
(52:05):
progression through Wiki Wikipedia. There was one that we got
that everybody eventually just gave up on. So it is
possible to get some that just are hard to figure out.
I'm sure, well I'm not sure it was possible. I
just think it was really, really, really tough to figure
that one out. But anyway, it was really fun, and
(52:27):
they picked some really obscure Wikipedia articles sometimes, and so
that's fun too, because part of the game that we
figured out pretty fast was Okay, the first step to
figuring out how to complete this chain is to open
another tab in my browser and go look up the
thing that I'm trying to get to because I have
no idea who this person is or what this thing is, right,
(52:49):
and so you go look it up and it's like
it's like, oh, it's a plant South America, right, all right,
so you know, then you start figuring it out. So anyway,
tons of fun and so I'm gonna pick Wiki Race
and then I'm just trying to think through things because
there was something else I wanted to pick and I
(53:10):
can't remember what it was, but anyway, I'll just say
it for next time. Do you have some stuff you
want to shout out about?
Speaker 2 (53:18):
Yeah? So that also very cool. I'm very into games
and so I'm definitely going to check them out. So
a problem that I've been having recently is just being
able to, I guess, document meetings a little bit better.
So having to write down notes from every meeting and
(53:41):
then consolidate it all together has been a really big
pet peeve of mine. That's very tiring and sometimes really
unnecessary to have to take things from different places and
then put it together. So I've been looking for a
good tool that will be able to help me a
little bit with no taking, especially with AI and its advancements.
(54:04):
So recently I've been exploring a few of these. So
the one that I've been using has been CRISP dot AI.
I don't know if you've part of it, but it's
basically an AI assistant for collaborative meetings. So some of
the team meetings are basically enable CRISP and it will
(54:27):
It does recording if you want it to, or it
can do transcribing, so it will give you the entire
sort of transcribed version as well as the audio recording
of the meeting. But that's not the coolest part. The
coolest part is that it will give you a summary,
It will give you the action items from the meeting.
(54:49):
It will give you a detailed outline if you ask
it to. But then also it has this AI chat
that is attached to sort of every meeting once it's
been uploaded, and with the AI chat you can get
pretty specific. So if there's a specific part of the
meeting that you want to dive into, you can just
(55:13):
ask the AI chat to summarize or detail certain parts
of the meeting, which is really nice. Sometimes the output
of the meeting is I maybe need to I have
specific questions and I just want to summarize these, summarize
the meeting, and answer these by answering these specific questions.
(55:38):
And so I just go in and I put in
the questions in the AI chat and it will basically
spit out the solutions that we came up with in
the meeting. So really really cool. I've been exploring that
against a different AI too, which is Granola AI, and
(55:58):
that's like an AI note piered people in meetings. So
the difference being is that CRIS will transcribe the entire
meeting and potentially if you wanted to record as well,
whereas Granola will simply just provide you with sort of
notes for the meetings, so it will take your raw
(56:21):
meeting notes and make them into something more legible. So
both those tools have been pretty interesting, and I found
that it's made meetings a lot easier, especially like team meetings.
We'll be making big decisions and I just want to
summarize it. I also find myself sometimes so focused on
(56:44):
taking notes that I'm not processing what someone's saying in
real time. So the fact that I can just give
my notes over to a tool and let the tool
handle the note take in and I can be present
and process. What people are saying makes it a lot
easier and a lot more efficient for me personally.
Speaker 1 (57:06):
Nice. So one thing I'm going to clarify for folks,
crisp Ai is billed with a K. It took me
a second to find it. But yeah, very cool, very
very cool. All right, Well, I don't think there's anything else.
I'm gonna go ahead and wrap it up. Thank you
for coming. This is fun.
Speaker 2 (57:27):
Yeah, thank you for inviting me. And I hope that
you will end up visiting Cape Town one day because
it really is beautiful.
Speaker 1 (57:35):
Yeah, I've I have to admit, so I'm going to
leave this on the recording, but I'm curious, you know,
I'll just bring it up. So, my wife is a
huge Shark Week person. Right, So every year in the summer,
Discovery Channel does Shark Week and they have a ton
of documentaries out in Cape Town, right where they're have
(57:56):
the sharks jumping out of the water or you know,
they're they're just out there kind of filming them doing
their thing and you know, chasing seals and whatever. And
then you know, sometimes they do show part of the
town or at least the coast and it just looks amazing.
It just looks like, oh wow, this would be a
really cool place to visit. And I don't know that
(58:19):
I would necessarily want to go out on a boat
looking for sharks, but you know, I think it would
be a blast. And I have to say that my wife,
after watching some of these shows, she might be the
one going, I want to go out on the boat
looking for sharks.
Speaker 2 (58:34):
Yeah, but well, there's other there's other there's other animals
that you can go looking for, like dolphins. And we
have a penguin beach Corboulders Beach when you can intacte Oh,
there you go penguins, Yeah, you can. You can interact
with the fun cute ones.
Speaker 1 (58:52):
Yeah. So, so what's the best part of living in
Cape Town. I'm just curious.
Speaker 2 (58:59):
I think the nature is the best part. It's along
the coast. It's absolutely gorgeous. There's this drive called Chapman's Peak.
If you look it up on the internet, it's just
beautiful scenery along the coast. On the one side, you
see the sea, on the other side you see the
(59:21):
mountains and it's just absolutely gorgeous. We have Table Mountain,
which I mean, based on the name, it's basically like
a table top. There's lots of hiking opportunities in Cape Town.
There's a lot of if you're an outdoor person, there's
a lot of things to do, lots of like diving, swimming,
(59:43):
lots of long drives, lots of good sunset views, and
I think people here are just very relaxed and laid back.
I will say that took me a long time to
get used to. I'm still I'm five years in Cape
Town and I'm still not used to that because from Johannesburg,
we're very like hustle and very serious about things hand.
(01:00:06):
Cape Town is just a vibe that's a real's that's
the way I can describe it, a very child vibe.
So yeah, lots of fun things to do in Cape Town.
People are very friendly as well. I find South Africa
to be one of like the friendliest people around. Like
(01:00:30):
you'll walk in the street and you'll say hello to
people and you'll smile at them. Not every city is
like that in the world, but South Africans are really
friendly people.
Speaker 1 (01:00:44):
Nice. So I think a lot of people if they
pay attention to South Africa, you know, they've probably heard
of Cape Town. I think most people are I think
Johannesburg's the biggest city in South Africa, and so yeah,
I mean how accessible is it. I'm assuming you have
direct flights in and out of there because it's not
(01:01:06):
a small city.
Speaker 2 (01:01:08):
But yeah, so my family lives in Johannesburg, so I
basically fly up to Johannesburg, I want to say, every
four to six weeks to see them and just spend
some time with them. It helps that I work remotely,
so it means that I am I'm just able to
(01:01:28):
walk out of any of the city. My husband's family
stays in Delbin, so we fly in and out of
Delbin pretty often as well. Yeah, it's very easy to
get to the different cities, and each city offers something different.
So Cape Town is I don't know if you know this,
but Cape Town has a part of Cape Town and
(01:01:50):
we call it Cape of Good Hope or Cape Point.
It's where the Atlantic and the Indian Ocean meet, and
so you can actually see a some point of the
year where you can see like the different colors of
the ocean and they sort of meeting at that point.
It's really beautiful. But unfortunately you're not really able or
(01:02:11):
I personally don't swim in the in the ocean. Here,
the Atlantic Ocean is really cold and just not for me.
But if you travel to Dlbin, that's the Indian Ocean,
and the Indian Ocean is just beautifully warm and really
nice to swim in. So very often we'd cop over
to Durbin and go swimming at the beach and things
(01:02:34):
like that. And then in Johannesburg you'd mostly like do
a lot of shopping there. There's a lot of big buildings,
a lot of corporates there as well, so higher earning potential,
a lot of people that are just very busy doing things,
a lot of good takeouts, yeah, and just a lot
of shopping malls. And then we have the Kruger National
(01:02:57):
Park as well. So if you want to see what
we call the Big five in South Africa, which is
the lion, leopard, elephant, rhino in Buffalo, you'd basically go
to Kuruga National Park and you could do a safari
and see them. No, we do not have animals walking
(01:03:18):
around the streets of South Africa. I know, sometimes I
can ask the question, now, really that's not the case.
I mean sometimes we have had a tiger on the
loose once or twice, but not on a daily basis.
So yeah, really good safaris as well. Lots of very
cool things to.
Speaker 1 (01:03:38):
Do, cool, very cool. All right, well, I'll I'll stop
asking you questions about South Africa. But thanks for coming.
Was this is awesome, no problem.
Speaker 2 (01:03:51):
I had so much fun. Thank you for inviting me.
Hey folks, Welcome back to another episode of the Ruby
Rogues podcast. This week, I'm your host, Charles Maxwood, and
I am talking to Ridwana Kahn from South Africa. Very cool.
I've always wanted to go down there and see different
areas down there. But anyway, you gave a talk at
(00:25):
Rails World. You talked about a whole bunch of the
internals on Ruby on Rails, and it looks like you
also help write the Rails guides, which is awesome. That's
one of the nicest things about rails is when I'm
talking to people and it's like, well, how do I
even get started? It's like, we've got these great guides.
Just go, you know, go spend a half hour or
(00:46):
so with them, and then you're pretty much off to
the races. So why don't you go ahead and introduce
yourself as far as anything else you want people to
know about you, why you're popular or famous and all
that stuff.
Speaker 2 (00:59):
Yeah, So I'm Ridwana, like you mentioned, I'm a technical
writer for the Rails Foundation. I've been helping to improve
the official Ruby on Rails guides for the last year
or so. I'm also a lead engineer at a company
called Circle where I focus on building tools that empower
creators and communities, and I have about over a decade
(01:25):
of experience in software development. Over my career, I've worked
mostly within the Ruby and Rail space as well as JavaScript.
I think if I had to sum up the things
that I'm passionate about, it would be making code more
accessible through documentation, and that's why I write the Ruby
on Rails guides, thought for engineering, and just inclusive community building,
(01:48):
which is why I work at Circle because there are
community building platform and I've built many communities over my career.
I try to both communities where I see a gap.
So the most obvious one is sort of the woman
in Tech gap. So over my career I've both communities
(02:09):
like women in Tech. I've both Rails goals in South Africa,
Rails Bridge, Black Gull's Code Ladies that You Ax, which
is the intersection of a development and user experience. So
just really passionate in that space. And on a personal note,
if I'm not coding, I'm trying to keep an eye
(02:30):
on my ever growing collection of house plants and trying
to keep them alive. They're constantly dying. I also really
enjoy traveling and going to speak at conferences. It's one
of my favorite things to do. And finally, just hanging
out with my very opinionated feline peer programmers or per programmers,
(02:53):
Zoe and Zeus. If you watch my talk at Rails World,
you've seen some really goofy photos of them. Yeah, it's
basically me.
Speaker 1 (03:03):
Very cool. So I have you Circle before? We used
it for I try to set up a community for
the podcasts, and I tried it out, so yeah, that's cool.
I didn't know they were a rail.
Speaker 2 (03:18):
Shop, so yeah. And before Circle, I was at dev
dot two also known as Forum, also a community platform.
So I've just been moving around community platforms recently.
Speaker 1 (03:31):
Right, Yeah, I was going to say I'm detecting a trend.
So I am curious as we dive in, right, because
I think a lot of times when we talk to people, it's, oh,
you're doing this very cool thing with code. And I'm
sure you do cool things with code. I'm not trying
to say you don't. But the thing that's interesting to
me is I think a lot of people don't really
(03:52):
think about, Okay, what goes into the documentation, what goes
into the rails guides and things like that, and I'm curious,
how did you get involved there? Did you just I
don't know, go tell the foundation, Hey, you need to
fix the easer. I don't know what will happen there.
Speaker 2 (04:09):
No. I think around last year, I want to say
around January twenty twenty four, Amanda from the Rails Foundation
was actually looking for writers to work on the Rails
Foundation Ruby on Rails guides, and so they put out
a post to say they're looking for two freelance writers
(04:32):
to work on the Ruby on Rails guides. And during
that time, I was sort of between different gigs and
I'd been using the Ruby on Rails guides a lot,
and so I decided, why not let me apply and
see how it goes. And yeah, I started writing for
(04:55):
the Rails Foundation myself and another writer, Boomy. We started
off and we worked with a couple of other peoples
to people to review the guides, and that's how it
all got started.
Speaker 1 (05:10):
Very cool. So is that paid or are you doing
it because you love us?
Speaker 2 (05:21):
I mean, I'm doing it because I love y'all and
I love the guides and I love what I do.
But it is also paid, Okay?
Speaker 1 (05:29):
Cool?
Speaker 2 (05:33):
Yeah?
Speaker 1 (05:33):
I mean I had I guess I hadn't really thought
too much about it, but now that I'm thinking about it,
I'm like, oh, wow, so are there because the guides
have been around for a while, are there any new
guides or is it mostly just updating what was already there?
Speaker 2 (05:47):
So initially we started with updating what was there, but
when Rails eight got released, we had a couple of
new guys that we needed to implement, and we've done
that as with the release. So it's a combination of both.
We look at the old guides, we audit them, we
(06:08):
see what needs to be updated, and we update them.
But then we're also as Reels releases new features, we
go in and we create new guides. Also, if contributors
create prs for new features, sometimes that means we go
through the pull requests and we update the guides with
(06:29):
new information on new sections.
Speaker 1 (06:32):
Gotcha, So how much time are you spending every week
working on the guides?
Speaker 2 (06:38):
So we put a pause a little bit recently is
the new year started, but I'll be begin it up
again later this month. I spend around I want to say,
I forget the actual number of hours because we've put
a pause on it for the last three months and
we're just starting again, but I think it's around two
(07:02):
in two hours a week. I stand to be corrected.
It's been a while.
Speaker 1 (07:08):
Uh huh, that makes sense. And what's the process. So,
I guess the process is different if you're auditing versus
writing new ones. But yeah, what does the process look like?
Speaker 2 (07:19):
Yeah? So, I mean I don't do a lot of auditing.
We have a specific contributor that helps with the auditing,
so Patrick Patrick Hosh he does the auditing of the
guides and a lot of the reviewing of the guides.
But essentially what he does is he comes in, he
audits them, he checks which ones we need to update,
(07:44):
and then once he's audit audited it, we use base
camp and we basically keep track of which guides need updating.
Then one of the writers will go in and they'll
look at the existing guides. The trick will already have
some notes in on what he thinks can be improved.
We look at it with fresh eyes. We then decide
(08:06):
what can be improved from our side. Sometimes that's how
I started diving into the source code. I dive into
the source code see how the internals work, because I
feel that if you really understand how the internals of
Rails works. Then you're able to explain the things better.
Once that's done, we send out a PR. It goes
(08:27):
through internal review first within our team. Once internal review
is done, we then create a PR for the open
source community to be able to review the guides. Maybe
they pick up some areas or gaps that we may
have missed, and then finally we emerge it.
Speaker 1 (08:48):
Very cool. So are they in the Rails repo or
are they somewhere else?
Speaker 2 (08:56):
Yeah, so they're in the Rails repot and usually we
encourage which open source contributors to have a look through them.
The guides are marked with a label RF docs and
it has a label sorry in the title. We usually
have a prefix rf docs and then it has a
label Rails Foundation. So if you're trying to find any
(09:19):
of the docks, you can do that, and we really
encourage the Rails community to review them because it means
that if you're learning Rails, or even if you've been
using Rails for a long time, you basically know we
some of the gaps lie what you've struggled with, and
when you review them, you can bring some of their
fresh perspectives to our prs.
Speaker 1 (09:42):
Right, makes sense. So yeah, I'm curious how deep into
the internals have you gotten, because I mean your talk
was a half hour, so you didn't get too deep
into things, But it sounds like you spend a bit
of time looking at how RAILS is actually put together
under the hood.
Speaker 2 (10:02):
Yeah, I think. I mean, depending on what guide I'm
writing at the time, I then dive into the internals,
and sometimes it requires a deeper dive. Sometimes it doesn't.
I feel like when you're writing documentation, it's not really
enough just to describe what a method does in a surface.
You need to understand how it works, why it behaves
(10:23):
the way it does. And that's taken me to some
of the more complex parts of RAILS are code based.
So for example, in the talk I talk about mime types,
I've traced through how RAILS handles the different mind types
using math. Missing I've done. I've dug really deep into
active recorde associations because that's a very big part of
(10:46):
RAILS as well when you're writing applications, so things like
the definitions of the dynamic methods and so on, I've
looked at I think I mentioned in the talk, as
well as validations. So RAIL uses like the dynamic callbacks
things like that. I've dove into some parts like that,
(11:07):
and I think that the most common pattern is just
the meta programming aspect of it. Right, So trying to
find those patterns across the different parts of Rails or
components in Rails and then trying to understand it a
little bit better. The Rails codebase is really huge, and
there's like always more to learn, but the magic is
(11:30):
beginning to feel a little bit less like magic is
you start understanding more of it.
Speaker 1 (11:38):
Yeah, I mean it seems like we've talked to different
people about metaprogramming on this podcast over the years, and
so yeah, a lot of what you put up there
was like I was like, oh, I see how that works,
and yeah, so I can kind of get the idea
that yeah, it feels a whole lot less magic and
(11:58):
a whole lot more. Oh. You know, this is a
tool that we used, and you know, and so it's
able to you know, for example, you know when it's
defining methods using defined method right, it just puts things
in place, It does the work. And one thing I
hadn't thought of with the mind type mind type is
you define the method and then you just call it.
(12:19):
I was like, oh, that that makes sense. So yeah,
I really liked that, and really liked just the clean
approach to explaining how all this stuff works.
Speaker 2 (12:31):
Yeah, I think the main aspect really and again I
have to emphasize it's the patterns. Rails is a lot
of magic. But once you identify some of the patterns,
and once you understand how meta programming works, you sort
of start putting these puzzle pieces together and you're able
to understand the code a lot better. And then you'll
(12:53):
see with the different components, there'll be one pattern here,
and then it's applied in this different place. And what
I tried to also do within the talk is show
how those patterns are applied across the different components. So
if you understood it in one component, you can go
and dive into a different component and it has very
similar patterns. And once you think of it like that,
(13:16):
it feels a lot more approachable. Because when I started
off in rails, and even like up until a few
years ago, I there was all this magic happening in rails.
So when you reach a point of like, hey, I'm
doing this thing, but it's a little bit more complex,
and now Rails isn't playing nicely with me. You don't
(13:39):
really know where to go from there. But if you
try reading the source code or you try looking into
how Rails is actually working, you're able to move past
that blocking point and do more complex things. I mean,
ideally you don't want to break away from the magic,
but unfortunately there is real of it is when you
(14:01):
both complex applications, you end up needing more tools under
your belt, and I feel like understanding the code base
is a tool under your belt.
Speaker 1 (14:13):
Yeah, that makes sense for me. What I found was,
as I've learned, I learned Rails first, and then they're
Ruby later. As far as like what all the other
things are that Rails kind of makes it so you
don't have to deal with right off the bat was
I would build stuff and then yeah, I would get
stuck on something right It'd be like, I don't know
(14:34):
why it is doing this, Why is it acting this way?
Why is it, you know, doing this thing to whatever
it is that I'm trying to work on. And it
it became pretty apparent once I started to learn Ruby.
It was like, oh, it's doing this because Ruby works
this way, and so it's just using the Ruby mechanism
(14:55):
to do the thing. And so yeah, I love that
idea of saying, Okay, look go look at the internals.
It may be something you haven't done before, but it's
it's not a mystery, it's not complicated or hard. It's just,
you know, it's something that maybe you need to learn
a little bit more about. And then you look at
(15:15):
it and you go, huh, Okay, this is where this
is coming from. This is why I have this the
way that it is.
Speaker 2 (15:23):
Yeah, And another aspect of it is that when you
go through the Rails code base, you're also not only
learning about Rails itself, but you're potentially learning how to
solve problems elegantly. Right. So, Rails does solve problems elegantly
and very often when we're working on our features within
(15:45):
whatever application or companies were working for with you solving
similar problems in just different use cases or different forms.
And so by going through the Rails code base, you
were able to also learn problem solving skills.
Speaker 1 (16:05):
Yep. Absolutely, So let's talk about some of those skills
or some of the things that you've seen in the
code base. You kind of went straight to metaprogramming, and
I've seen plenty of people over the years basically talk
about how metaprogramming is scary or you can get yourself
into trouble with it. I don't know how do you
(16:28):
feel about that argument about using metaprogramming or not.
Speaker 2 (16:36):
I think that using meta programming, I think you're going
to have a lot of people saying meta programming is
the best, and some people saying that you shouldn't use
meta programming. I think that there's a use case for
meta programming. Meta programming is a superpower and it can
(16:57):
lead to really elegant, expressive code, but it also can
lead to very scary and intimidating code that's very hard
to follow. So I appreciate meta programming, but I also
respect that it has a lot of complexity and it
can make code harder to debug, especially if you're not
(17:19):
familiar with the patterns, or if it's overused without like
clear naming or clear direction. So I wouldn't say that
I feel strongly that everybody should use meta programming. I
think that meta programming needs to be used based. I
think metaprogramming has a place, and depending on your use case,
(17:41):
meta programming may be a good fit. But if you're
using metaprogramming for any for everything, you may just be
over complicating things.
Speaker 1 (17:51):
M hm, yeah, I think that's I think that's a
fair way to put it. I do a lot of
work on my cars or my house or whatever, and
what I found is that most of the time, you know,
just just the regular tools work right, you know, and
even if I pull out the power to tools, right,
they work. But occasionally I've got to open up a
(18:13):
wall with a saw, or I've got to use some
other tool that, yeah, you know, may have some safety
hazard to it or something if you're not using it properly.
And that's the way I think about metaprogramming is is
you know, you don't want to take more out of
the wall than you have to, so to speak, you know,
(18:34):
you don't you have to be careful not to hurt
yourself with it. Sometimes the code can be hard to
debug when you're using metaprogramming, and so, yeah, you know,
what I find is most of the time when I'm
reaching for something like metaprogramming, I am doing something on
the level of rails, right, And so what I'm doing
is I'm actually using it to provide myself with the
(18:56):
pattern I want to see in my code, and so
that winds up being in like the lib folder, you know,
somewhere else where. It's it's not code that I'm going
to go touch all the time, and it's not code
that I'm using to solve all my major problems. What
I'm doing is I'm just basically using the metaprogramming to
create a better tool for me to solve the problem.
Speaker 2 (19:19):
Yeah, and I think I think your example, by the way,
was great about how you do work around why I
work around the house, and sometimes you need to bring
out the right tools. In my talk, I talk about
like a real world use case where we use meta programming,
which I think is really valuable. So when I was
(19:40):
working at dev dot two or known as forum as well,
we were building of course community software, and we needed
a way during onboarding to letter from communities define custom
profile fields for their members. So, for example, in the talk,
I use the example of a go gardening community, and
(20:01):
for a gardening community, during onboarding, we may want a
profile field that a user can enter their favorite plant,
or a developer community might ask if you're available for hire.
So these fields need to be highly customizable, and they
might need to be dynamically edited at run time. They
(20:23):
also might support different data types like strings, booleans, dates, etc.
So rather than hard coding a bunch of different profile
attributes that are different for different communities, we use mata
programming to dynamically define gatters and setters for the custom
fields is the community has created them, and it meant
(20:46):
that communities could define as many custom fields as they
want and the system would just respond. There were no
migrations or extra model code or no like hardwired logic.
It just made the system really flexible. And I feel
like that's a great example of how meta programming is
used in a real practical way to solve a problem.
(21:07):
But like you say, I feel like they are very
like meta programming. In my career, I think that's probably
like one of the very few cases I've needed to
use metaprogramming, And maybe there's like one or two others,
But over ten years you're mostly building standard applications that
(21:30):
don't necessarily require that level of customization, right.
Speaker 1 (21:35):
Yep, absolutely, So what other things have you found going
back to rails internals, What other things have you found
that maybe you wanted to add to the talk but
didn't have time or have thought were interesting that people
don't really see or know in the Rails codebase.
Speaker 2 (21:54):
I think there's so many gems no pun intended in
the Rails hood base. One of the things that I
really enjoy about, like exploring the rail's internals, is seeing
how thoughtfully things are architected. So when you like how
it gives you a whole ecosystem of dynamic methods. How
(22:19):
things are named really well, such as very thoughtful processes,
how things sorry very thoughtful naming. Also how the different
components are well separated, things like how well the code
is documented. I think that's really a superpower. If you
(22:40):
go through the Rail's code base, you'll find sort of
method definitions, you'll find how the Rails API documentation is
within the code base, and you can see what the
different methods are doing. So I think there's a lot
of sort of other practices that the Rails team uses
(23:04):
within their sort of actual development, and I found a
lot of those useful alongside the matter programming aspect and
the great architecture. I also think so may one more
thing to air the like the PR. I found that
(23:26):
when I'm writing documentation, I also sometimes tend to go
through like the open issues or poor requests to see
did someone touch on this. Maybe there's something I don't
really understand and I want to understand it better, but
maybe the rail's code base doesn't provide as much information.
I find that when I go through poor request reviews
(23:50):
or even issues, contributors and the core team are very
for both about explaining things. They do a really great
job about articulating themselves and working together to form a solution.
So it's really nice to go through poor requests, to
(24:11):
go through issues, and I really encourage people to just
if you're not contributing to rails, or you're not reviewing
documentation prs or even just normal rails code, like just
browsing the issues and the poor requests casually can provide
a ton of information and useful knowledge.
Speaker 1 (24:35):
Makes sense. So do you have any advice for people?
Let's say that you know somebody. I mean, I have
to admit I haven't really contributed to rails. I think
I've I've filed bugs. I think I've maybe put in
one poor request in my whole life against rails. So
if somebody wants to get involved and they're sitting there
(24:57):
and they're thinking, okay, well, I just want to understand it,
you know, and maybe they want to contribute to the docs,
or maybe they you know, just want to understand things
better and you know, maybe help with some little thing
here or there. Like where do you recommend that people
start with the RAILS code based to just understand what's
going on in there? Yeah?
Speaker 2 (25:16):
I feel like I am so I get so excited
when someone asks me this question. I'm biased, but I
feel like starting with documentation is a really good way
to get into contributing to RAILS or just understanding things better.
Rails places a lot of value on clear, accessible documentation.
(25:39):
So if you're reading a guide or an API document
and something's confusing or missing, just open up a pr
to improve it to add value to the next person.
You don't need to be a core contributor to that.
You don't need to be writing the guide to do that.
You just need to be someone who wants to make
(25:59):
it clear for the next person reading the guides. And
especially I feel like a lot of people that are
new to the industry or that feel they feel they
don't have enough knowledge to contribute to RAILS or something
or the other. That's how I felt for a long time.
I feel like documentation is a clear way to contribute
(26:24):
because if you're not understanding something in the documentation, I
can guarantee you there's hundreds of other people that are
not understanding it as well. Another way to get yourself
familiar with the rail's code based if you're looking to
just dive a little bit deeper, I think read the tests.
They incredibly instructive. So the Rail's test suite is massive,
(26:46):
but it's very descriptive. It shows you how methods are
supposed to behave. It often gives you breadcrumbs to trace
back to the source code. And when you're trying to
understand something or if you think you know fixing a bug,
test are often the best entry point, and writing or
improving tests or just reading the test is a fantastic
(27:07):
way to start. And then if you're looking actively to contribute,
you can look for a good first issue or you
can look, like I mentioned, the docs, TIG the rails
getthub repots very well organized, so there's very often open
issues that are labeled as like a good first issue
or where we need contributions on the documentations. And finally,
(27:31):
like don't be afraid to read this was called Even
if you don't understand it, that's fine. Just a lot
of reading of it. Eventually your mind starts to put
the pieces together. It's like the more you read, the
more somehow your mind just like connects different parts of it.
You start seeing patterns emerge. There's lots of tools as
(27:53):
well that I mentioned in my talk unlike things that
will help you to navigate the rails scode better. So
use some of those tools to navigate the rail source code.
And finally, you don't have to do it alone. There
are so many people in the rail's community who are
so kind and supportive and willing to help. So whether
(28:15):
it's in rail slack or discord or get up discussions,
you can ask questions and you can get unstuck. I
think the main thing, finally, to wrap it all up,
is that rail's contributing to rails isn't really about being
perfect or knowing everything. It's about just being curious and
wanting to make rails better, even if it's in small ways.
Speaker 1 (28:40):
Awesome, All right, Well, I'm just trying to think where
else we go from here? Are there are there things
that you want to add or change or bring forward
(29:01):
with the rails documentation or areas that we should dove
into that it doesn't.
Speaker 2 (29:09):
I think, yeah, I think there's there's a couple of
places or where or we could improve the documentation. There's
a couple of guides and I'm whipping up the guys
is we speak, so bear with me as I do this.
There's a couple of guides which I think could really
(29:31):
use some improvement, and we've got them noted. So. For instance,
one of the ones that I'm hoping to work on
within this year is the active record query interface. It's
a really big guide. I think it's in a good start,
it's in a good place, but I think they could
also be a lot of improvements. We could explain things
(29:51):
a lot better. We could maybe move out sections, make
them smaller, more approachable sections. I think it's one of
the biggest guides, and so I think just breaking it
up into smaller, more digestible pieces will make it a
little bit more approachable. There's also some other sections that
(30:14):
could use some improvement. I think we're already in a
I think the Rails Guides in general is one of
the better guides we have out there across languages. I
think the Rails Foundation has been doing an amazing job,
but there are just individual ones that are working progress.
So like the rails initialization process that's a work in progress,
(30:36):
as well as the active support instrumentation things like active
record encryption. So the first thing we want to do
is we want to finalize those working progress guides because
they may consider they may have right now not like
the full picture picture of what their topic income. So
(31:00):
we just want to fill out that information and cover
the bases, and then we'll go about improving some of
the other guys and breaking them down. But we're hoping
to achieve a lot this yeah, and improve it significantly,
as well as create some new guys that haven't been
(31:20):
covered with RAILS eight.
Speaker 1 (31:24):
Yeah, there are a lot of things that I see
you can do with RAILS eight or I mean even
some of the stuff that came out in Rail seven
that aren't super well documented, right, and I see people
use them and they do amazing things with them, and
it's like, man, why hasn't anyone really just broken this down?
So yeah, I'm looking forward to some of that. Yeah,
(31:50):
So I'm a little curious. I want to kind of
switch over to both Cape Town and to Circle. So
what do you do at Circle exactly, Like, do you
work on a specific part of the platform or do
you just kind of hit whatever needs to be hit.
And by the way, I'll just explain because I've used
Circle and what I find is if you work at
(32:12):
a place, you kind of look at it differently from
the way that people use it look at it sometimes.
So Circle is essentially a forum. You can think of
it as kind of a focused Facebook. It kind of
feels like that Facebook group. And then on top of
that you can add like courses and other things to
(32:32):
your community. You can set it up as a paid
community or a free community. And yeah, it's a really
well put together system. So yeah, so what kinds of
things do you work on there? And yeah, what kinds
of concerns or improvements do you find at work?
Speaker 2 (32:50):
Yeah? So Circle is really established, well written product. We
have some really big communities using it, and it's one
of the It's one of the companies that I've worked
(33:11):
for that is constantly improving and always looking to batter
the product. And it's very exciting because they constantly building
new features but also improving the features that exist in
the application itself. So specifically, I work on what we
(33:32):
call the Email Hub or marketing Hub team at Circle,
and we're basically responsible for things like email broadcasting and
sort of that domain whereby you able to send our
broadcasts to either community members or what we call contacts
(33:55):
within the system or leads. And there's just a lot
of are things that tie into it, so for example,
analytics and that ties into things like workflows where for instance,
when you're onboard a community, you might want to send
a broadcast and then we might want to wait for
five days and send them a follow up things like that.
(34:18):
It's a relatively new team at Circle. I think we
launched the email hub slash marketing hub feature last year.
I want to say around September October. It was around
Rails world time, so it's relatively new. We're actually hiring
(34:39):
for the team at the moment, so I'm leading the
team and we have our two engineers and we're looking
to hire another two engineers for the team. So I've
been doing lots of interviews and hiring at the moment.
Our tax stack is Ruby on Rails and we use
JavaScript as well. It's a pretty big engineering team, so
(35:01):
each sort of sub engineering team is focused on a
particular part of the platform. So we have like a
CRM team and a CMS team and you sort of
focus on a specific domain.
Speaker 1 (35:18):
Very cool. Yeah, I just got hired at Price Picks
and so I've been got you know, we're seeing some
of this stuff, and I'm on the growth team where
we it's kind of your traditional R and D where
we come up with ideas on what we could do
better and then go and invent it and see if
it works. But yeah, I love what you're talking about
where it's yeah, the growth. That's always exciting to see
(35:41):
companies growing and then yeah, just yeah, constantly looking for
that level of improvement. Those are the best companies to
work at. So if people want to apply, how do
they do it?
Speaker 2 (35:55):
We are on we have If you go on the
so called website, you should see a careers Yes, a
careers link and you can view the open roles and
you can find the roles. They're role for a senior
full stack engineer on the Marketing Hub team and you
(36:15):
can apply through this. It's very exciting you'll be working
with me, so please apply. It's also a fully remote opportunity,
which is nice. Those are real and few nowadays.
Speaker 1 (36:30):
Yeah, So you're based in Cape Town. Is your team
like all over the.
Speaker 2 (36:34):
World or yeah, so we have developers from pretty much
all over the world. We in the marketing Hub team
right now, it's myself and then we have two developers
in India, and we're hoping to hire someone in a
(36:54):
European time zone and then maybe sort of North America,
just so that we have that full time zone support,
but also ensuring that we're not too far apart that
we can't collaborate when we need to. So maybe like
with a one hour two hour overlap just in case
we need some sink time, so that gives us sort
(37:18):
of good collaboration across the board. But for the most part,
we use as in tools like Slack and Notion. We
document things very well.
Speaker 1 (37:29):
And yeah, nice, Where where's the company based out of?
Speaker 2 (37:38):
To be honest, I guess since there isn't actually a
head office, No, there's I guess. Yeah, I mean on
the on the on the invoices and stuff. You're probably
it's I think I stand to be corrected. I want
to say the US New York, but again that may
not be actual.
Speaker 1 (38:01):
Sounds good. So, so what's the community like in Cape Town?
I mean Are there a lot of rails developers out there?
Speaker 2 (38:09):
Or yeah they are. We used to have, I want
to say, a well known conference, because when I went
to Rails World and a couple of other conferences, people
have asked me about this conference. It's called Ruby FUSA,
and we ran it in South Africa for a couple
(38:30):
of years. But we haven't run it, I think since COVID.
But there's a really big Ruby community here. There used
to be a lot of meetups previously. I want to
say that since COVID, that's sort of when things slowed
down a little bit. I'm also not originally from Cape Town.
I was based in I was living in Joburg, Johannesburg,
(38:54):
and then moved to Cape Town only like five years ago.
Johanna's Burg also has a really big Ruby community. Is
to have constant meetups every couple of weeks, and yeah,
it's really good. I will say though, because I work
for a lot of US Over my career, I've worked
for a lot of US companies, my community tends to
(39:16):
be more sort of global. I tend to attend conferences
where I'm sort of traveling, and so it's been a
little bit more difficult to keep in touch with the
rails community within Cape Town. But I'd like to see
(39:36):
Ruby Fuza hit the ground running again. That would be
really cool.
Speaker 1 (39:42):
That would be cool. Yeah, So are there any other
personal projects or anything else that you're working on or
is it mostly the Rails Guides?
Speaker 2 (39:54):
So between the Rails Guides and then I like to
tinker on just personal tracks, I've been trying to tinker
with arduinos and connecting that with sort of Yeah, it's
really cool. I've really been enjoying it. I like seeing
like the physical aspect of like things working. So I've
(40:15):
been working on this like sort of with moisturee detectors
and sort of like a like merging my passion for
keeping my house plants alive together with like a little
gardening system. So I've been tinkering with that and it's
been really fun. But between writing code the Rails Guides
(40:37):
and then are doing some of the tinkering, and then
also speaking at conferences, I've been very busy over the
last few months. My next conference is I'm really excited
about is Ruby kontailiand and that's next huge January. One
(40:58):
of the keynotes speakers, So I'm really excited about that.
Speaker 1 (41:03):
Oh nice, that would be so fun.
Speaker 2 (41:06):
Yeah. I've never been to Thailand as well, so super
excited about that.
Speaker 1 (41:12):
Yeah. So do you have any I guess you've been
on the conference circuit for a while. I think I
went and looked at your website and it listed a
whole bunch and I was like, oh, wow, she's been
to quite a few. Do you have any advice for
people who are thinking they want to speak at conferences?
It seems like a lot of people decide they want
to speak, they put in a CFP, and yeah, they
(41:32):
get rejected at the first bunch and then they give up.
Speaker 2 (41:35):
So yeah, I think that I'd say just go for it,
like even if it feels scary at first, Like I think,
if you have a passion for it and you want
to do it, you should. I think the main thing
that I have to say is you don't have to
(41:56):
be an expert. You just need to be curious and
willing to People sometimes assume that conference speakers know everything
about a topic. That's not true. I very often I
will put together ACFP about something that I know nothing
about but want to learn more about, and those make
(42:18):
for the most interesting talks. So things that you're interested in,
things that you may have learned that you think others
might find useful. And especially I find that the cfps
that have the most success rate, at least from my
personal experience, is the cfps that talk about that have
(42:42):
a story that is something that you've experienced and you
want to share with the world. So, for instance, my
reals will talk demystify in the rails code base that
came from a storyline of being a technical writer and
diving into the documentation and some of the difficulties that
(43:05):
I experienced and then sort of what I did in
order to be able to learn how to demastify the
rail's code base. So a lot of the time it's
things that you know, sorry, things that you've experienced, and
you want to tell that story. I feel like writing
(43:25):
an abstract first, even before you have like a full
idea of the talk, that's okay. Sometimes people write their
talks first, or they try to have every not necessarily
to write their talks, but they try to have every
aspect ined out first before you're submitting. They feel that
they need to know everything before submitting. You really don't
(43:47):
have to. It just needs to be a pitch and
then just ensure that you have enough time before the
conference talk of course, and then you can learn on
the way, right, Yeah, and start small and then grow.
So if you've never spoken before, a good opportunity. I
remember when I started talking, the first kind of places
(44:11):
that I submitted my talks to were like local rails
communities that meetups that I went to and I would
talk there. I would get a little bit more confident
in front of people, I would get feedback on a talk,
and then I started applying to the bigger ones. And
that way, you can also put in your cfps that like, hey,
(44:33):
I have spoken at these different communities, I have experienced
speaking things like that.
Speaker 1 (44:40):
Yep, makes sense. All right, Well, I think I'm going
to start leading us toward toward the end of the
show and picks. But before we do that, like, where
do people find you? If they're looking for you on
the internet and they want to.
Speaker 2 (45:00):
Connect, So you can find me on Twitter? What do
we call it? X It's been a few years, but
I still say Twitter.
Speaker 1 (45:09):
I still call it.
Speaker 2 (45:10):
You can find me on AX. My username is Redwana
under school K. My name has a silent age, so
it's our id H w a n a under school k.
You can find me on LinkedIn as well. Sometimes I
post the and I username is Redwuana, but mostly on X.
Speaker 1 (45:30):
Very cool. All right, well let's go ahead and do
the picks. Then I'll start it out and just kind
of show you how we do it, and then you
can shout out about whatever you want. Uh So, the
first pick that I have is it's a board game,
and I almost always do a board game of some
kind if I haven't played anything new, I'll just pick
(45:52):
one that I like that I've played that I probably
picked before. But we played a new one yesterday with
my So I played board games every Wednesday night with
my friends, and we played a game called Colt Express
and it's a train robbery game board game. Geek waits
(46:13):
it at one point eight four, which is kind of
So two is what is about where I tell people
the casual gamers are kind kind of going to go, Okay,
this was a little bit complicated, but not so complicated
that I didn't like it, and it was fun, right.
A one is like the game should play with your kids, right,
(46:35):
so you know, and so it's got enough to it
to where there's some competition and stuff, and some of
the ones are really fun, right, there's simple dynamics you
just but anyway, so this one's one point eight four,
so it's almost a two. It's called Cult Express and
uh it plays two to six players. My friend has
the the Cult Express Big Box Edition, which has two
(47:00):
of the expansions in it, so his will play up
to nine. And apparently there's another expansion that adds another
player too as well, so you can play with a
lot of people. Came out twenty fourteen, and what it
is is it actually has a little train cars that
you put together for your game board, and so you
(47:21):
have the locomotive and then you have one train car
per player, and there's loot on the floor of the
train cars, and so then what you wind up doing
is you have a deck of cards, and the cards
allow you to shoot at the other players. You can
punch the other players. You can move up to the
(47:44):
roof of the car or back into the main part
of the car, and you can move across the car,
so you can move from one car to the next.
And there's a marshal and if you wind up in
the car with the marshal, then then he shoots you
and you move to the roof of the car. The
marshal doesn't go on the roof, and so then the
rest of it is when you owe, and then you
(48:05):
can pick up loot, you can move the marshal. I
think that's it. So if you shoot another player, you
put the shot card in their deck, right, and it's
a no op card, so it dilutes their deck. It
makes them harder, It makes it harder for them to
get what they want. If you punch a player, then
you make them drop a piece of loot. You know,
(48:27):
picking up loot's worth anywhere from two hundred and fifty
to five hundred dollars. There are gems that are worth
five hundred dollars. And there's a lock box or a
strong box on the locomotive where the Marshal starts that's
worth a thousand dollars. And so you just move around
the train and try and get as much money as
possible in five turns. And the way you play the
turn is whoever's first, they put a card on the pile,
(48:52):
and then you go around the circle and everyone else
plays a card right, and so you can see what
they're playing. On the turns where you play face up,
but there there's sometimes there are twists where you go
you go around the circle the other direction right, and
so you may get If you're first, you know you're
it doesn't change a lot for you. But if you're set,
(49:12):
if your last and it changes the direction, you get
to play, the first player plays and then you get
to play again, and so you know that that may
change the dynamics. There's others where you play and face down,
so for for those cards on that on that round,
you don't you don't see what the other players did,
so you can't react to it. There's another where you
(49:35):
play two cards at a time and so you play
twice right, and so you can move and then pick
up loot because you know that you're gonna be able
to get there before anyone else. Or you move and
you punch another player and make them drop loot because
you know that they're going to be there. And then
if you shoot the most shots then you you get
(49:55):
a thousand dollars. So anyway, then you tally it all
up at the end, and and anyway, it was a
lot of fun, a lot of fun. So and the
game board is really unique because it is it's actually
a train that you just set up on the table
and so, you know, I mean it's real small. But anyway,
it was a lot of fun, really really enjoyed that.
(50:17):
It took us about an hour and fifteen minutes to play,
but we were learning how to play, so I think
you could probably play it. We played it with five people.
We probably play it in forty five minutes, I think.
So anyway, very very fun. So I'm gonna pick Cult
Express and then I'm going to shout out about a
(50:38):
few others. So yesterday we had a team lunch with
my team and basically we got sent gift cards for
door Dash, right, so I had food show up at
my house and then we played wiki race and that's
(50:58):
at wikidashrace dot com. And the way that wiki race
works is you and you could put in your own
things that that you start at and end at, but
it starts you on a page on Wikipedia and then
you have to click links to get to the other page. Right,
And so one of the ones we played that it
(51:19):
was like some soccer player from like the nineteen fifties
that you know, there were probably like four links that
went there, right, and so, and I can't remember we
started at but it was something like completely weird, right,
and so you start figuring out some of the tricks
right where it's okay, well, I know this guy's from England,
and so I'm going to get to England, right, and
(51:42):
so I click some of the links that take me
to the world and then countries and then England right,
and then I know he played on these teams, so
I go to the soccer leagues and then England right,
and so anyway, it was It's very, very fun, and
it's basically a race, so whoever gets their first wins,
you know, and then when somebody wins, it shows their
(52:05):
progression through Wiki Wikipedia. There was one that we got
that everybody eventually just gave up on. So it is
possible to get some that just are hard to figure out.
I'm sure, well I'm not sure it was possible. I
just think it was really, really, really tough to figure
that one out. But anyway, it was really fun, and
(52:27):
they picked some really obscure Wikipedia articles sometimes, and so
that's fun too, because part of the game that we
figured out pretty fast was Okay, the first step to
figuring out how to complete this chain is to open
another tab in my browser and go look up the
thing that I'm trying to get to because I have
no idea who this person is or what this thing is, right,
(52:49):
and so you go look it up and it's like
it's like, oh, it's a plant South America, right, all right,
so you know, then you start figuring it out. So anyway,
tons of fun and so I'm gonna pick Wiki Race
and then I'm just trying to think through things because
there was something else I wanted to pick and I
(53:10):
can't remember what it was, but anyway, I'll just say
it for next time. Do you have some stuff you
want to shout out about?
Speaker 2 (53:18):
Yeah? So that also very cool. I'm very into games
and so I'm definitely going to check them out. So
a problem that I've been having recently is just being
able to, I guess, document meetings a little bit better.
So having to write down notes from every meeting and
(53:41):
then consolidate it all together has been a really big
pet peeve of mine. That's very tiring and sometimes really
unnecessary to have to take things from different places and
then put it together. So I've been looking for a
good tool that will be able to help me a
little bit with no taking, especially with AI and its advancements.
(54:04):
So recently I've been exploring a few of these. So
the one that I've been using has been CRISP dot AI.
I don't know if you've part of it, but it's
basically an AI assistant for collaborative meetings. So some of
the team meetings are basically enable CRISP and it will
(54:27):
It does recording if you want it to, or it
can do transcribing, so it will give you the entire
sort of transcribed version as well as the audio recording
of the meeting. But that's not the coolest part. The
coolest part is that it will give you a summary,
It will give you the action items from the meeting.
(54:49):
It will give you a detailed outline if you ask
it to. But then also it has this AI chat
that is attached to sort of every meeting once it's
been uploaded, and with the AI chat you can get
pretty specific. So if there's a specific part of the
meeting that you want to dive into, you can just
(55:13):
ask the AI chat to summarize or detail certain parts
of the meeting, which is really nice. Sometimes the output
of the meeting is I maybe need to I have
specific questions and I just want to summarize these, summarize
the meeting, and answer these by answering these specific questions.
(55:38):
And so I just go in and I put in
the questions in the AI chat and it will basically
spit out the solutions that we came up with in
the meeting. So really really cool. I've been exploring that
against a different AI too, which is Granola AI, and
(55:58):
that's like an AI note piered people in meetings. So
the difference being is that CRIS will transcribe the entire
meeting and potentially if you wanted to record as well,
whereas Granola will simply just provide you with sort of
notes for the meetings, so it will take your raw
(56:21):
meeting notes and make them into something more legible. So
both those tools have been pretty interesting, and I found
that it's made meetings a lot easier, especially like team meetings.
We'll be making big decisions and I just want to
summarize it. I also find myself sometimes so focused on
(56:44):
taking notes that I'm not processing what someone's saying in
real time. So the fact that I can just give
my notes over to a tool and let the tool
handle the note take in and I can be present
and process. What people are saying makes it a lot
easier and a lot more efficient for me personally.
Speaker 1 (57:06):
Nice. So one thing I'm going to clarify for folks,
crisp Ai is billed with a K. It took me
a second to find it. But yeah, very cool, very
very cool. All right, Well, I don't think there's anything else.
I'm gonna go ahead and wrap it up. Thank you
for coming. This is fun.
Speaker 2 (57:27):
Yeah, thank you for inviting me. And I hope that
you will end up visiting Cape Town one day because
it really is beautiful.
Speaker 1 (57:35):
Yeah, I've I have to admit, so I'm going to
leave this on the recording, but I'm curious, you know,
I'll just bring it up. So, my wife is a
huge Shark Week person. Right, So every year in the summer,
Discovery Channel does Shark Week and they have a ton
of documentaries out in Cape Town, right where they're have
(57:56):
the sharks jumping out of the water or you know,
they're they're just out there kind of filming them doing
their thing and you know, chasing seals and whatever. And
then you know, sometimes they do show part of the
town or at least the coast and it just looks amazing.
It just looks like, oh wow, this would be a
really cool place to visit. And I don't know that
(58:19):
I would necessarily want to go out on a boat
looking for sharks, but you know, I think it would
be a blast. And I have to say that my wife,
after watching some of these shows, she might be the
one going, I want to go out on the boat
looking for sharks.
Speaker 2 (58:34):
Yeah, but well, there's other there's other there's other animals
that you can go looking for, like dolphins. And we
have a penguin beach Corboulders Beach when you can intacte Oh,
there you go penguins, Yeah, you can. You can interact
with the fun cute ones.
Speaker 1 (58:52):
Yeah. So, so what's the best part of living in
Cape Town. I'm just curious.
Speaker 2 (58:59):
I think the nature is the best part. It's along
the coast. It's absolutely gorgeous. There's this drive called Chapman's Peak.
If you look it up on the internet, it's just
beautiful scenery along the coast. On the one side, you
see the sea, on the other side you see the
(59:21):
mountains and it's just absolutely gorgeous. We have Table Mountain,
which I mean, based on the name, it's basically like
a table top. There's lots of hiking opportunities in Cape Town.
There's a lot of if you're an outdoor person, there's
a lot of things to do, lots of like diving, swimming,
(59:43):
lots of long drives, lots of good sunset views, and
I think people here are just very relaxed and laid back.
I will say that took me a long time to
get used to. I'm still I'm five years in Cape
Town and I'm still not used to that because from Johannesburg,
we're very like hustle and very serious about things hand.
(01:00:06):
Cape Town is just a vibe that's a real's that's
the way I can describe it, a very child vibe.
So yeah, lots of fun things to do in Cape Town.
People are very friendly as well. I find South Africa
to be one of like the friendliest people around. Like
(01:00:30):
you'll walk in the street and you'll say hello to
people and you'll smile at them. Not every city is
like that in the world, but South Africans are really
friendly people.
Speaker 1 (01:00:44):
Nice. So I think a lot of people if they
pay attention to South Africa, you know, they've probably heard
of Cape Town. I think most people are I think
Johannesburg's the biggest city in South Africa, and so yeah,
I mean how accessible is it. I'm assuming you have
direct flights in and out of there because it's not
(01:01:06):
a small city.
Speaker 2 (01:01:08):
But yeah, so my family lives in Johannesburg, so I
basically fly up to Johannesburg, I want to say, every
four to six weeks to see them and just spend
some time with them. It helps that I work remotely,
so it means that I am I'm just able to
(01:01:28):
walk out of any of the city. My husband's family
stays in Delbin, so we fly in and out of
Delbin pretty often as well. Yeah, it's very easy to
get to the different cities, and each city offers something different.
So Cape Town is I don't know if you know this,
but Cape Town has a part of Cape Town and
(01:01:50):
we call it Cape of Good Hope or Cape Point.
It's where the Atlantic and the Indian Ocean meet, and
so you can actually see a some point of the
year where you can see like the different colors of
the ocean and they sort of meeting at that point.
It's really beautiful. But unfortunately you're not really able or
(01:02:11):
I personally don't swim in the in the ocean. Here,
the Atlantic Ocean is really cold and just not for me.
But if you travel to Dlbin, that's the Indian Ocean,
and the Indian Ocean is just beautifully warm and really
nice to swim in. So very often we'd cop over
to Durbin and go swimming at the beach and things
(01:02:34):
like that. And then in Johannesburg you'd mostly like do
a lot of shopping there. There's a lot of big buildings,
a lot of corporates there as well, so higher earning potential,
a lot of people that are just very busy doing things,
a lot of good takeouts, yeah, and just a lot
of shopping malls. And then we have the Kruger National
(01:02:57):
Park as well. So if you want to see what
we call the Big five in South Africa, which is
the lion, leopard, elephant, rhino in Buffalo, you'd basically go
to Kuruga National Park and you could do a safari
and see them. No, we do not have animals walking
(01:03:18):
around the streets of South Africa. I know, sometimes I
can ask the question, now, really that's not the case.
I mean sometimes we have had a tiger on the
loose once or twice, but not on a daily basis.
So yeah, really good safaris as well. Lots of very
cool things to.
Speaker 1 (01:03:38):
Do, cool, very cool. All right, well, I'll I'll stop
asking you questions about South Africa. But thanks for coming.
Was this is awesome, no problem.
Speaker 2 (01:03:51):
I had so much fun. Thank you for inviting me.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
My Favorite Murder with Karen Kilgariff and Georgia Hardstark
My Favorite Murder is a true crime comedy podcast hosted by Karen Kilgariff and Georgia Hardstark. Each week, Karen and Georgia share compelling true crimes and hometown stories from friends and listeners. Since MFM launched in January of 2016, Karen and Georgia have shared their lifelong interest in true crime and have covered stories of infamous serial killers like the Night Stalker, mysterious cold cases, captivating cults, incredible survivor stories and important events from history like the Tulsa race massacre of 1921. My Favorite Murder is part of the Exactly Right podcast network that provides a platform for bold, creative voices to bring to life provocative, entertaining and relatable stories for audiences everywhere. The Exactly Right roster of podcasts covers a variety of topics including historic true crime, comedic interviews and news, science, pop culture and more. Podcasts on the network include Buried Bones with Kate Winkler Dawson and Paul Holes, That's Messed Up: An SVU Podcast, This Podcast Will Kill You, Bananas and more.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.