Learning Git: A Hands-On & Visual Guide • Anna Skoulikari & Helen Scott

This interview was recorded for the GOTO Book Club.
http://gotopia.tech/bookclub

Read the full transcription of the interview here

Anna Skoulikari - Author of "Learning Git" & Senior Technical Writer
Helen Scott - Developer Advocate at JetBrains & Co-Author of "Getting to Know IntelliJ IDEA"

RESOURCES
Anna
https://twitter.com/AnnaSkoulikari
https://www.linkedin.com/in/annaskoulikari
https://www.annaskoulikari.com
https://github.com/annaskoulikari
https://www.udemy.com/course/git-learning-journey

Helen
https://twitter.com/HelenJoScott
https://www.linkedin.com/in/helenjoscott
https://www.helenjoscott.com
https://github.com/helenjoscott

Links
https://learning.oreilly.com/get-learning/?code=LEARNGIT23
Trisha & Helen: https://youtu.be/pfinplXtrkA

DESCRIPTION
This book teaches Git in a simple, visual, and tangible manner so that you can build a solid mental model of how Git version control works. Through the use of color, storytelling, and hands-on exercises, you will learn to use this tool with confidence.

The information is introduced incrementally so that you don't get bogged down with unknown terms or concepts. Learning Git is ideal for anyone who needs to use Git for personal or professional projects: coding bootcamp students, junior developers, data professionals, and technical writers, to name just a few!

This book covers how to:
• Download Git and initialize a local repository
• Add files to the staging area and make commits
• Create, switch, and delete branches
• Merge and rebase branches
• Work with remote repositories including cloning, pushing, pulling, and fetching
• Use pull requests to collaborate with others

* Book description: © O'Reilly

RECOMMENDED BOOKS
Anna Skoulikari • Learning Git
Trisha Gee & Helen Scott • Getting to Know IntelliJ IDEA
Michael Nygard • Release It! 2nd Edition
Tomasz Lelek & Jon Skeet • Software Mistakes & Tradeoffs
Ashley Peacock • Creating Software with Modern Diagramming Techniques

Bluesky
Twitter
Instagram
LinkedIn
Facebook

CHANNEL MEMBERSHIP BONUS
Join this channel to get early access to videos & other perks:
https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/join

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket: gotopia.tech

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Chapters

• 0:00 Intro
• 2:57 Simplified Git: A journey from fear to mastery
• 7:16 A practical guide to mastering Git
• 15:32 The rainbow project
• 21:01 Decoding the audience for this book
• 31:07 A user-tested approach to technical writing
• 36:51 Resources
• 38:57 Outro

Transcript

Intro

Helen Scott: Welcome to another episode. My name is Helen Scott. And today I'm going to be interviewing  Anna Skoulikari. 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.

Anna Skoulikari: Thanks for having me, Helen. I'm excited.

Helen Scott: I'm excited too. I'm just gonna see how many stories of my Git frustration I can weave into this interview. So Anna published her first book, "Learning Git." It's on the O'Reilly platform. You published it in June last year,  Anna?

Anna Skoulikari: June last year.

Helen Scott: 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.

Anna Skoulikari: 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.

Simplified Git: A Journey from Fear to Mastery

Helen Scott: 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?

 Anna Skoulikari: Yes.

Helen Scott: 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 were your primary motivators behind writing this book?

Anna Skoulikari: 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 boot camp, and I worked as a UX designer. And then when I was working as a UX designer, I 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 boot camp. 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 anyway, so at some point during that job, I realized I wanted 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. 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, who 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.

From Concept to Collaboration: A Practical Guide to Mastering Git

Helen Scott: 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.

Anna Skoulikari: 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.

Helen Scott: 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?

Anna Skoulikari: 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.

The Rainbow Project

Helen Scott: 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?

Anna Skoulikari: 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.

Helen Scott: 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.

Anna Skoulikari: 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...

Helen Scott: So true.

Anna Skoulikari: 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.

Helen Scott: Good call out. Good call out. And yes, the pain is real. Just ask my co-author, Trisha Gee, who updated them all.

Decoding the Audience for "Learning Git"

Helen Scott: 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?

Anna Skoulikari: 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.

Helen Scott: 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?

Anna Skoulikari: 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.

Helen Scott: 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.

Anna Skoulikari: It's true.

Helen Scott: 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.

Anna Skoulikari: 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.

Crafting Learning Journeys: A User-Tested Approach to Technical Writing

Helen Scott: 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."

Anna Skoulikari: 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.

Helen Scott: 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?

Anna Skoulikari: 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.

Helen Scott: Wonderful. A mystery.

Anna Skoulikari: Yes, a mystery.

Helen Scott: I do like a mystery.

Anna Skoulikari: 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.

Resources

Helen Scott: 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?

Anna Skoulikari: So the first thing I'll say is that I'm the only  Anna Skoulikari 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.

Outro

Helen Scott: 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?

Anna Skoulikari: 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.

Helen Scott: 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.

Anna Skoulikari: Bye. Thanks, Helen.