Welcome to another episode.

My name is Helen Scott.

And today I'm going to be interviewing  Anna.

So  Anna is a creative.

She uses her communication and her storytelling,
and she's used it to tell Git in a simple

way.

So,  Anna, welcome.

 Thanks for having me, Helen.

I'm excited.

I'm excited too.

I'm just gonna see how many stories of my
Git frustration I can weave into this interview.

So  Anna's published her first book, "Learning
Git."

It's on the O'Reilly platform.

You published it June last year,  Anna?

June last year.

June last year.

So, I've got a copy of the book.

I've been very efficient, and put it back
on my bookshelf over here.

For the purposes of this interview, let's
start right at the beginning.

Tell us a little bit more about you and what
you enjoy doing, before we get started into

the book.cv
I think what I enjoy doing is taking a complicated

topic or a topic that confuses people, and
making it simpler and more approachable.

And presenting the information in a way that
it's easier to learn for beginners.

So that's what I did with Git.

And that's what I also do in my day job, because
I work as a technical writer.

So in my day job, I also take various topics
and explain them in a simpler way, and present

information in a simple way, so that people
can consume it better.

Fantastic.

And that's so important.

Having a technical writing background myself
as well, it's just super important that when

a user comes...looks for the documentation,
that it is written in such a way that you

can actually help them to move forward and
get past the problem that's made them go and

look at the documentation in the first place,
right?

Yes.

Okay.

So, I'm going to not derail this interview
completely with how annoyed I can get at Git

sometimes, but I think maybe some of our audience
might share some of these frustrations.

What was your primary motivators behind writing
this book?

Okay.

So, the reason I wrote this book is because
I needed this book.

So I'm just going to backtrack a little and
say that my entryway into the world of tech

was through the world of UX design, so user
experience design.

So, at some point in my life, I did a UX design
bootcamp, and I worked as a UX designer.

And then when I was working as a UX designer,
I'd realized that I knew how to design apps

and websites, so sort of like an architect.

But I didn't know how to actually build those
apps and websites.

I wasn't like the construction company that
gets the blueprints and actually builds them.

I got really curious about how these things
are built.

So I ended up doing a coding bootcamp.

That's kind of a three-to-four-month intensive
program, learned the basics of web development,

and then worked as a front-end developer.

The first time that I Git introduced to get
was in that coding boot camp.

But it was one hour where they just kind of
told us Git add, Git commit, Git push, go.

Off you go.

And obviously, that may have been sort of
enough when you were just working on your

projects in the coding boot camp.

But once I got my first job as a junior front-end
developer, and I had to work with a team of

developers and senior developers, I was terrified
of Git.

I mean, every time I had to do something that
I deemed was complicated, which was almost

everything, I would call on the senior developers,
and ask them to help me.

And I was always worried I was about to destroy
the repository, and take down the entire platform

and the entire website.

And this was like a massive ecommerce platform,
so that would have not been good.

Little did I know that that was not the case.

And that that was never gonna happen.

But anyways, so at some point during that
job, I realized I want to conquer this fear.

I want to learn how to use Git, and I want
to understand how it works, so that I can

be an independent developer, and not have
to ask for help all the time.

So I started learning, looking for online
resources to learn Git.

And what I realized was that there weren't
really any online resources that were designed

for people like me, that were really new to
tech, that had transitioned into tech from

non-technical backgrounds, and that explained
things in a simple way.

Then at some point, this creative idea came
to me of how I could teach Git using colors,

and storytelling, and visuals.

I mean, this was after I'd kind of understood
some of the basics.

So the first thing that I did was actually
make an online course teaching Git.

And that's still available online.

At the moment, it's on Udemy.

Who knows where it will be in the future.

But that journey...

When I was making the online course, I still
wanted to write a book.

But I felt that the barrier to entry to write
the book was higher than to make an online

course.

Because with online courses, you just kind
of record your voice, make some slides, record

them.

So I could do that a lot easier and publish
it online a lot easier.

But once I released that online course, I
started getting reviews, I started getting

feedback.

I realized my way of teaching Git really resonated
with a lot of people.

There were a lot of people that, just like
me, had not been served by the Git teaching

resources out there up until now.

My approach to organizing information and
presenting concepts worked for them.

And then I was like, all right, since it works,
let's write this book.

I am also a writer in my personal time, and
I love to journal.

So, writing is my medium of choice.

That's kind of how this book came about.

This is the book that I wish I had had in
my first week of that coding boot camp.

Or especially in that first week of my new
job as a front-end developer.

A hundred percent.

100%.

And just in hearing that story, there's so
much that resonated with me.

People have talked about, regardless of how
you ended up in the profession, whether you're

coming through a degree, you're coming through
a boot camp, you're self-taught, whatever

it is.

How much you learn about version control,
and, you know, Git is part of that, is really

variable.

In my experience, sometimes 
it's purely conceptual.

It's like, there is this thing that you can
do.

You will learn about it on your job.

And then you turn up at your job and you're
like, "Oh, I'm terrified of going to study

the whole repository."

So I think we've all been there.

And I think we've all had experience of knowing
who or even being at times that expert in

Git on the team, that people go to when they've
gone beyond the Git pull or, you know, Git

update, Git push.

They've gone beyond the basics, and they're
like, "Oh, I'm in trouble now.

Something's not working."

So I think certainly, I identified with a
lot of what you said there, and I expect our

audience did as well.

So much frustration.

The other thing that actually has been very
surprising is that it's not just developers

that use Git, there are so many other people
that work with developers or that do other

jobs that use Git.

And this I've discovered since publishing
the book.

Game artists.

Mechanical engineers also use Git.

Sometimes UX designers have to collaborate
with devs, and share assets or whatever.

Even product managers.

And actually one of the biggest audiences
my book actually got was technical writers,

because they often have this thing that we
call Docs as Code Approach.

And they use Git to manage the repositories
for the documentation websites.

So some technical writers come from a technical
background, but some don't.

And so, technical concepts don't come naturally
to them.

My book has really served various different
audiences, including junior developers and

experienced developers, but also just so many
other professions.

Which, yeah, has been very eye opening.

And again, identified with that, because it
was back in my technical writing career, and

I started using Git.

And I needed that Git expert in the team,
that developer, and I was like, "I've got

it in reverse.

Please help me."

So let's move swiftly on to talking about
the book itself, which is why the majority

of the audience will be here.

Can you give us an overview of the book and
talk about its structure a little bit more,

please?

Definitely.

So, the book is for absolute complete beginners.

If you have a bit of experience, you can maybe
try to skip a chapter.

Normally, you should do it from the beginning
to the end, though, because it's a hands-on

learning experience, where you're working
on a specific repository throughout the entire

book, which is actually called the rainbow
repository.

Because you're listing the colors of the rainbow.

I'll explain that a little bit more later.

But the first chapter actually just starts
off with installing Git and an introduction

to the command line, because some people actually
haven't worked in the command line and aren't

familiar with it.

So, it really is a book for absolute beginners.

Then I build this thing that I call the Git
diagram, which is my way of creating a mental

model of the different areas of Git and how
they fit together.

So, you have your project directory, the working
directory, the local repository.

Then inside the local repository, you have
the staging area and the commit history.

When I was learning Git, I came across diagrams
that tried to kind of depict these different

areas, and how they interact.

They didn't really make sense to me.

So I've actually created my own representation
of these areas.

This is really key to my teaching methodology.

Because the main part of my teaching methodology
is creating a mental model of how things work,

and making things tangible.

So, we build the Git diagram.

Once we have that, we go over the process
of making commits.

We introduce branches and what they are.

And we create visualizations for all of these
things.

So I visualize what branches look like.

They're just pointers to commits.

Then what else?

I have a list here.

I go over merging, and I introduce the two
types of merges, fast forward merges, three-way

merges.

We're at chapter five now.

And there we just go over the experience of
doing a fast-forward merge, not yet a three-way

merge.

That's a bit more spicy, and it comes later
on in the learning journey.

And then in chapter six is when we actually
go from working just in the local repository,

just on your computer, on your own.

We introduce hosting services.

so GitHub, GitLab, Bitbucket, 
and remote repositories, 

basically.

One thing I should mention right now, just
a quick parenthesis, is that, the book is

not prescriptive.

You can use whichever hosting service you
want.

You can use whichever text editor you want.

I didn't want to exclude anyone that uses
maybe a different technology.

And I wanted to make the book accessible to,
yeah, anything.

So yeah, so that's closing parenthesis now.

Moving on, chapter seven, we jump into creating
and pushing to a remote repository.

So we're really into, you know, local repository,
remote repository.

Chapter eight, we go over cloning and fetching
data.

So, in chapter eight, is where the learning
experience, we simulate that you're working

with another person.

So, in the book, we say that a friend of yours
wants to join you on your rainbow project.

So they create a...

Well, they clone your remote repository, and
they create a local repository called Friend

Rainbow.

And I mean, if you have a friend that you
can actually do all the exercises with, then

that's ideal.

But the most realistic thing is that you just
create a second local repository on your computer,

and you just kind of pretend it's on someone
else's computer.

But this is really important, because at the
end of the day, Git is a collaboration tool,

right?

It's version control and collaboration.

So, if you don't have any representations
of how the collaboration happens, then that

leaves out basically more than half of Git.

Chapter eight, you're learning how to clone,
how to fetch data from a remote repository.

And chapter nine, finally, we get into the
spicy topic of...

Well, not that spicy.

Three-way merges are pretty simple.

But then chapter 10, we get into merge conflicts,
which is the spicier topic, and the thing

that a lot of people are afraid of.

Chapter 11, rebasing.

Rebasing, I'd say is the most advanced thing
that I cover in my book.

Like I said, this book is a real basics and
beginner book.

So, rebasing is, yeah, at the end.

And finally, the last chapter is pull requests
or merge requests, whatever terminology you

want to use.

And obviously, pull requests, merge requests,
they're not actually a feature of Git itself.

They're a feature of the hosting services.

So GitHub, GitLab, Bitbucket, and others.

There are others.

I'm just not going to start naming 20 different
hosting services.

But I thought that they were so important
because they really...

Yeah, they're essential, almost for everyone's
workflow.

So I thought, okay, I'll make an exception
and include them, even though this is a book

about Git.

That's kind of an overview.

And like I mentioned, you're working on this
rainbow project, and it's hands on.

You are with your computer, doing the exercises.

So you are supposed to do the book from chapter
1 to chapter 12.

Because if you don't, then you'll miss out,
you won't be able to follow along.

But I have created an appendix, where I've
offered instructions on how someone can start,

like, create the minimum set up for their
project to start off on any chapter.

Because, yeah, maybe you read the book once,
and then you just want to review chapter eight,

or you just want to review chapter nine.

And you don't have to go from chapter one
all the way to that chapter just to be able

to review it.

But yeah, that's the kind of overview of the
book.

Brilliant.

So for my next question, I'm going to use
the book as my demo, so the audience can see

what I'm talking about when I ask this next
question.

For example, you've made extensive use of
color in this book.

And you've mentioned the 
rainbow project repeatedly.

What made you choose that theme?

And why?

When my creative idea of how I could teach
Git in a simple way came to me, it was all

about using color.

Because I thought to myself, one of the really
confusing or difficult things with Git, when

you're teaching it, is that there's commit
hashes.

So every commit...

A commit is a version of your project.

Every commit has a commit hash, so 40 characters,
letters, and numbers, that's unique.

And it's like a name for the commit.

But if you're teaching Git, and you're having
to refer to, well, remember commit, six, nine,

Z, blah, blah, blah, blah, blah.

That is so confusing.

Who wants to learn like that?

So I thought to myself, how can I use color
instead?

And so let me give an example.

In the rainbow project, the very first thing
you add to your project, you create a rainbow.txt

file.

So a txt file, very simple.

I keep everything really simple.

And I'll make a comment about that in a second.

And the first thing you add is just...red
is the first color of the rainbow.

You just add that sentence, first line of
your file, and you add that to the staging

area, and you make a commit.

And then I represent that commit in the diagrams
as a circle, that is red.

And so from then on, I can just say, the red
commits.

And that just simplifies the learning experience.

It makes it a lot more memorable, and also
very much more visual.

Because I'm not having to include, like, a
little commit hash in my diagram to try to

refer to the commit.

That's why I use color in my teaching methodology.

And the rainbow was just a really nice way
to structure it.

You know, we all...well, many of us, or most
of us know that the order of the colors of

the rainbow.

So it's a very familiar thing.

It was easy to then, yeah, structure the whole
book that way.

Although at the end, I ran out of colors.

I just had to add some random colors.

I actually have...

At the end, you add another file to your project
called othercolors.txt, and you start adding,

like, pink is not a color in the rainbow.

And gray is not a color in the rainbow.

Because I literally ran out of colors.

But also because I wanted to show, you know,
how you add new files to your project.

But the other thing I wanted to say about
keeping things simple, is that one of the

decisions I made with this book is that it
would have no code in it.

So, the files in your project are just dot-txt
files, which are just really plain text files.

They're not even markdown files.

Like, it is so simple.

Because I thought if I make the project that
you work on in the book, a web development

project, or a data science project, a Java
project, a Python project, anything, it will

exclude some people for whom that is not familiar.

And let's say, yeah, fine, well, those people
can go and look it up.

It just complicates things.

It's not necessary.

I wanted someone to just be able to focus
on learning the concepts of Git, rather than

having to also learn other tech concepts,
which are not relevant to just learning Git.

So, yeah, that's kind of...that was my way
of approaching how to teach this stuff.

That's great.

And I think what's really helpful and insightful
is, the very deliberate decisions that you

made along the way.

You know, this didn't just happen by accident,
you made a very deliberate choice that I'm

going to represent hashes with blobs of color,
and therefore I'm going to refer to those.

And you made a very deliberate choice to use
txt files, a concept that is going to be familiar

to your entire audience.

So I really liked that you made those conscious
decisions upfront to create the learning journey

that, you know, you said yourself you wanted
when you first started working with Git.

YOne more I can add is screenshots.

I decided not a single screenshot in my book.

Because I thought to myself, the minute I
add a screenshot, the book is out of date.

And since I was able to do with...

So true.

Helen knows this because she wrote a book
with lots of screenshots.

But you have to have screenshots in yours.

Sorry, off topic.

I think that was another really, really conscious
decision of mine, of, since it's not necessary,

don't include screenshots.

Because again, they're not relevant to everyone.

Everyone has a different operating system,
and a different version, and UI changes.

And the minute that the book goes to print,
it would be out of date.

So, that was another really conscious decision
I made for this book.

Good call out.

Good call out.

And yes, the pain is real.

Just ask my co-author, Trisha Gee, who updated
them all.

Okay, so the next question is kind of a double
question.

You can answer it in any order you like.

But it's, who should read this book?

And equally as importantly, who is this book
not for?

So who should read this book?

I think anyone that wants to learn Git.

So they've never used Git, and someone's told
them they have to, or they realize they have

to for their work or for their personal project.

So anyone that wants to learn Git.

Anyone that's confused by Git.

I have talked to developers with 10 years'
experience, that still are afraid of Git and

don't have a mental model that they can reliably,
like, use and feel confident with.

And they even tell me, this book helped me
to put things together.

So, yeah, junior developers, anyone that doesn't
yet really understand how the pieces come

together.

Because what happens is, when you don't have
a good mental model of Git, once you start...

Like, maybe you're okay with doing the Git
add, Git commit, Git push.

But once you start going to the more advanced
topics, you don't really understand how they

work.

And that's where you start getting really
confused and scared.

And it all becomes a bit challenging.

So that's who I think could benefit from this
book.

Also, I would say anyone that's a visual learner,
and anyone that's kind of more like a tactile,

like, wants to like see...kind of make things
tangible type of learner.

I do have to say, you know, this book isn't
for everyone.

Not everyone's a visual learner.

And I totally appreciate that.

And that means that this book will appeal
to a certain type of learner, but not to another.

Now, let's get to the topic of who this book
is not for.

It's not for anyone that uses Git, and really
has their own mental model of how it works,

and it works for them.

And they never really struggle with understanding
things.

I mean, they don't need it.

It's not for anyone that's looking for an
advanced guide to Git, you know, that goes

over advanced features of Git, more niche
commands.

It's not for them.

That stuff is not in the book, so they'll
not get anything from it.

It's also not for anyone that's looking for
a resource that will teach them what their

Git workflow should be, or what best practices
should be.

In the book, I don't teach you, like, oh,
well, the best branching workflow is this,

and this, and this.

Or, yeah, I don't know, this is how you should
set things up.

Like I said, the book is not at all prescriptive.

And actually, to be honest, the rainbow project
is not a really realistic project of a software

project.

I mean, you're listing the colors of the rainbow.

That's not really what you're usually doing
when you're building software.

So for a lot of developers, for example, the
example in the book is not so realistic.

It's more about building that mental model.

Although I do have a second example in the
book, which is called the example book project,

which is a little bit more realistic, because
it uses storytelling to provide a bit more

of a realistic use of Git.

But again, it's not.

And the other thing is, anyone looking for
other best practices, like, how should I be

naming my branches?

What should I be including in a commit?

Let me think, what else?

So those kinds of things, I don't provide
any guidance on that.

Because, like I said, I focus on teaching
a mental model.

And those things are really up to...they're
really kind of dependent on your opinion,

on which company you work in, which sector
you work in, what your background is, what

you personally like in branch names, and in,
yeah...or commit messages.

So, it was not something that I wanted to
confuse people with and clutter up the book

with.

I think there's plenty of other resources
in the world that provide guidance on that.

And the final thing is that this book is not
a reference.

So it's really kind of a learning journey.

It's a hands-on learning journey.

But it's not the kind of book that you would
be like, oh, you know, each chapter...

I don't know, it's not a reference guide.

So, to be honest, the Git website is the best
reference.

I mean, it is a reference.

They have a reference.

So, Git-scm.com, you got a reference there.

And other people have built a reference.

So yeah, I think that's kind of who the book
is for and who the book isn't for.

Okay.

So, we've mentioned previously that the book 

is designed to be a sequential 
learning experience.

Start at the beginning, progress, especially
if you're new to Git.

But there's going to be people out there that
will definitely have the question of, how

much Git experience do I need if I'm going
to buy this book?

And what's the answer to that one?

Zero.

That's an easy answer.

I could just, like, zero.

I have nothing else to say.

No, zero, really, like I mentioned in the
very first chapter, we go over the process

of downloading Git, and kind of setting it
up, setting up like the basics.

And I even introduce the command line.

Like, I tell you, this is the app that is
the command line, open the command line.

This is the command prompt.

This is where you enter commands.

You write a command and you press enter.

And I introduce some, like, very basic commands
like CD, change directory, or LS, like, list

the files, the visible files.

I introduce the concept of visible files and
hidden files.

I introduce, like, I don't know, mkdirs, or
make directory.

Just a couple of super basic commands.

So, yeah, and we go from the very start.

Like, chapter two is, you know, introducing
that Git diagram.

And so, zero, zero, zero.

I user tested.

We'll get into that later.

But I literally gave this book to my brother,
my dad, people that are...well, at least my

brother, not at all in the tech space.

Or at least, you know, not developers of any
kind, at the moment, at least.

So, yeah, it's zero.

Brilliant.

We're gonna get to that now.

So people who get value from this book, no
Git experience is necessarily, none whatsoever.

Road tested with your dad and brother, amongst
other people.

And tells a sequential journey.

Anybody who is looking to understand the mental
model of Git, anybody who perhaps has been

using Git, but is a little bit less confident
around some of the operations.

Whether they're the more advanced ones like
rebase, or the spicy three-way merge, which

is absolutely what I'm always going to call
the three-way merge from this point forward

in my career, always going to prefix it with
spicy.

And anybody who just needs to brush up on
some of those underlying concepts, because

Git is very...

What are the words?

You need to build on top of the basics.

If you don't understand the basics in Git,
then the more advanced stuff, the more advanced

commands tend to be more challenging than
perhaps they would be if you had a good grasp

of the underlying mental model.

It's true.

Awesome.

Okay.

So let's stick with advanced topics.

Is there anything that you really, really,
really wanted to get into the book, but just,

you know, you've got to draw the line somewhere?

Is there anything that you're like, "Oh, I
really wanted to put that in, but I just..."

You know, you had a cut off for it.

That's a really good question.

And I've been asked this before.

But to be honest, I think I am in quite a
unique position, that unlike many other authors,

who had a lot more in their books, and needed
to cut down, or just, yeah, the books got

way too big.

I had a very clear idea of what the basics
were, maybe because I'd already made the online

course, which already had the basics.

And so, I didn't really have that situation.

I didn't have anything that I was like, "Oh,
but I really wish I could fit this in."

The only thing I would say maybe that I was
considering squeezing into one of the chapters

was stashing.

But I mean, it's not like a huge, massive
thing that I really, really, you know, was

like, "Oh, I can't believe this won't fit
in."

Because to be honest, you know, the book is
still pretty lean.

It's very minimalist.

So, if I had ultimately decided that this
is essential, I would have included it.

Actually, in my case, I think the pull request,
merge request chapter was actually not even

part of my original plan.

And I think later on, I realized, no, this
is really important.

I need to add this on.

So actually, my book was like too lean.

And I was, like...

I think you've been rebasing, I was kind of...

No, rebasing, I think I had from the beginning.

But yeah, I was like, super lean.

And I was, like, okay, but maybe I should
add a little bit extra.

So, I think, I felt that the most generous
thing that I could do for my readers, and

for my learners, was to be 
as simple and minimalist 

as possible, and just give the bare basics.

And in that way, just make it less overwhelming.

Because tech is so overwhelming.

There's just so much information, and so much
going on.

So if I could just create one learning experience,
which would not be overwhelming, I was like,

yes, I shall do this.

Fantastic.

Thank you.

So I'm wondering if in our audience today,
we might have some budding authors, other

people out there who perhaps want to author
a book.

I know I've co-authored a book.

So I absolutely appreciate the effort that
goes into the process and then some.

Do you have any advice for anybody who might
be listening, who's thinking, "Oh, yeah, I

know a thing.

I'm gonna write a book about that thing."

So anything I'm about to say is just gonna
come from my own experience.

So you never know, it might not apply to others.

And anything I'm gonna say is probably just
going to refer to technical book authors,

because I have not yet written another kind
of book.

So I don't want to say that I can speak on
that.

But for technical book potential authors,
I would say one of the things that I really

appreciated in my journey was, that I sort
of wrote this book as if it was an app.

Like, I made a prototype and then I user tested
that prototype.

And then I took all the feedback and I iterated.

And then I user tested again.

And then I took all the feedback, and I iterated.

And the first prototype was ugly.

It was very, very ugly.

And it was very rough.

And it was not at all the finished product.

I actually user tested when I just had four
chapters ready, because I thought, well, let

me check if this is making any sense to anyone.

Because if I've done four chapters, and it
doesn't make any sense, there's no point in

writing the other eight chapters.

Or, you know, it's better for me to figure
out what they are, what works for my audience,

before I write those other eight chapters.

So I had up to, like, 30 user testers throughout
the two years that I was working on this book.

And I think that was invaluable.

The experience of having a diverse user testing
audience.

I mean, it went from the ages of 18 to 60.

And from various professions, from all over
the world.

It was all remote user testing.

Wait, actually no, I also did some in person.

But most of it, almost all of it was remote.

So I got people from all over the world.

And it really did make my book a lot better.

There were a lot of things I needed to change.

I think sometimes, yeah, we just want to think
that we're like this genius that, like, can

create the best thing out of the outset.

And, like, oh, my God, my ideas are so good.

But sometimes, our creations need to have
that chemical reaction with the audience in

order to really become what they need.

Just one funny story, since we're at it.

At the beginning, I thought that my book would
actually...people would have, like, a pencil

case with them and paper, and they would actually
draw out the commits.

So in the beginning of the preface, I was
like, "Oh, you have to buy colored pencils,

and you should, like, follow along, and you
should draw the commits."

And when I did that user testing, nobody did
that.

And I had the colored pencils with me, I brought
them, and nobody did it.

So then I was like, okay, well, I guess this
isn't something...

You know, if somebody does want to do it,
they can.

But it wasn't something that made sense.

I mean, that's just a non-technical example.

But there were plenty of other things where,
yeah, I got feedback of, this doesn't make

sense to me, or you forgot about this.

I'm a Mac user.

So there were a lot of Windows users that
told me, like, "Hey, you need to mention this,

you need to mention that because this doesn't
make sense for me, or this doesn't apply to

me."

Or, you know, you need to simplify this.

You know, I'm not aware of this concept.

So, yeah, my monologue about user testing
and how good it is, is over now.

But yeah, I really recommend.

The importance of user testing.

And yeah, colored pencils, or not, in your
case.

Fantastic.

So we've spoken a little bit about your Udemy
course, we've spoken a little...well, a lot,

about your book.

What's next for you?

Is there anything else in the pipeline?

That's a good question, Helen.

I don't know what's next.

I do know that I've started working on a book.

I cannot share anything about it.

It shall remain a mystery.

People can...

You know, at the end, we'll talk about links
where people can find me.

But it may not end up being a technical book.

So I'm not sure yet.

I'm still exploring...

Well, I've started working on something.

But until I commit to a creative idea or a
creative project, I flirt with a lot of different

creative ideas and creative projects.

So, I definitely want to keep creating.

I love the process of creating something that
helps people and that explains things in a

simple way.

But what that next thing is going to be is
still under wraps.

So, we'll see.

For now, I'm just adjusting to my new technical
writer position, and enjoying kind of sharing

the journey I had with this book.

Wonderful.

A mystery.

Yes, a mystery.

I do like a mystery.

Maybe that's how I get people to follow me.

It's kind of self-serving.

If I make it mysterious, people have to come
and follow me to find out what it is when

I'm ready to share it.

I think that is the perfect segue.

So, if people want to find out about this
mystery in time, or learn more about your

book, or your courses, or whatever is coming
next for you, Anna, where should they go?

So the first thing I'll say is that I'm the
only  Anna Skoulikari on this planet.

So, just look me up,  Anna Skoulikari, two
Ns, A-N-N-A.

Last name S-K-O-U-L-I-K-A-R-I.

Just google me.

But other than that, I have a 
website, annaskoulikari.com.

So that is one good place.

The platform that I'm currently most active
on is LinkedIn.

So you can connect with me or follow me there.

And then other than that, you can find my
book all over the place, Amazon, and plenty

of other places.

You can find my online course on Udemy, at
the moment.

It's difficult to tell people where to find
you, because you always think, well, the social

media landscape changes all the time.

So this might not be relevant in a year or
two years from now.

And maybe I'll start using something else.

So I do have a Twitter.

I don't use it much.

Oh, I'm sorry, X.

Anyways, so I'd say my website and LinkedIn
are currently the best places to find out

more about me, and what I'm doing.

And then other than that, I just want to share
with the audience that I do have a link that

for the rest of 2024 is still going to be
active, which we can leave in the notes, which

gives people 30 day free access to the O'Reilly
online learning platform.

You can read my book, basically, in 30 days.

We can leave that in the notes.

And you actually have access to all the resources
on there.

If you want to take a peek at anything else,
feel free.

And it doesn't automatically subscribe, you
just get those 30 days, and then you can choose

whether you want to continue.

I think those are the best places.

Perfect.

And we will, of course, 
put all of that information 

in the show notes, including that link for

30 day access to the writing platform.

So I think that just about brings us to the
end of this interview.

So, Anna, do you have any final words that
you'd like to share today?

Oh, that's a good question.

Well, since the audience, there's going to
be a mix of junior developers, senior developers,

and various other people in the tech profession.

I'd say, if you yourself, maybe understand
Git, but you have a friend or anyone you know

that is struggling with it, feel free to recommend
them to take a peek at the book and see whether

it is the right learning journey and learning
resource for them.

It might be, it might not.

But if you do have anyone that is struggling
with Git, which many of us do, feel free to

kind of just share it with them, in case you
think it can serve them.

Fantastic.

Fantastic.

And I'd second that, especially with the 30
day free access.

I mean, that's a win-win.

You can check out the book.

I am fortunate enough to have this lovely
physical copy of it.

But, Anna, thank you.

Thank you for coming to this interview, for
sharing your knowledge and writing this book.

I've got a lot of value from it.

And I know that our audience will as well.

Thanks to the GOTO platform as well.

And yeah, thank you to you, the audience,
for tuning in and coming on this journey.

All the show notes will be available to you.

And that's it from us.

Thank you very much.

Bye.

Thanks, Helen.