Coding is a passion for many software developers. A lot of us do it because we simply like it, not because it pays for fancy steak dinners, or make our loved ones proud. But why do we like it? From my own experience, the reason for that passion is different from one developer to another. It’s about what makes you ‘tick’. For some developers, they enjoy the logical constructs that work together to build a piece of software. For others, they are obsessed with the mental challenges that come with programming.

For me, I simply enjoy building things from scratch. The more I got to know myself, the more it became obvious to me that this is why I enjoy writing code. I particularly enjoy building complex things that can exhibit intelligent behavior. I can only do that as much as I want with a computer and some code.

Five years ago, I took my first steps to explore the Go programming language. I remember when first hearing about the language, my first thought was: such a weird name for a language!! for a while after that,  I only remembered it by  the fact that it’s ‘that new language with the weird name’.

I didn’t pick up Go till later. At the time, I worked with the C# programming language a lot, and I am still a big fan. However, the fact that -at the time- C# was not very portable bothered me a lot. The fancy tools (Visual Studio + plugins), as well as a large number of the available libraries for C# were mostly only Windows based. Later on, Microsoft made a lot of effort to address that with the emergence and evolution of .Net core, as well as all the improvements to the Mono project. I love the Mono project, and have built almost all my open source C# projects with it (except for one). However, I just didn’t feel the ecosystem was there for full portability 5 years ago.

So I started my search for something new to use in my personal projects and at work. I am a backend engineer who enjoys speed and loves portable code, so my next thought was Java. What made the language number one for backend programming was it’s portability, and relative openness from it’s early days. I already had decent experience with Java, and I liked it. However, I felt like I was aching for something fresh, something with a different thinking paradigm. That was when I looked seriously at Go.

There is a reason why Go is so much loved by it’s community. The language simply ‘grows on you’ over time. About 6 months into my learning journey with Go, I started writing articles about the language in my website. My first article was a practical tutorial about how to use Go with protocol buffers ( Protobuff version 2).

Writing a useful tutorial proved to be not a simple undertaking, yet an extremely rewarding thought process . A tutorial is simply a sequence of instructional steps that you share with your audience, in order to make them understand and use some piece of technology. You have to think of a game plan for which concepts to discuss first, then which concepts to discuss second, up till the end. For each step/concept/topic you cover in your tutorial, you have test it out first at your end, make sure it is not a lie, do some more research from different sources to ensure you haven’t missed any critical pieces of information, then you write the step in your tutorial with the expectation that it must be reviewed later , at the end, with the other steps to hunt down any inconsistencies in your tutorial.

It took me close to four weeks to finish the tutorial. I emerged from the other end possessing much more knowledge than from when I started. It is funny how much we think we know, until we decide to dig deeper beyond our comfort zone. After publishing the article on my website, I decided to share it on a LinkedIn Go group, then went to sleep. I woke up the next morning with thousands of visits to my website. At first, I thought it was from the LinkedIn group, but then I realized the number of visitors far surpassed the number of members in the LinkedIn group that I submitted the article to the night prior. It turned out that someone shared my tutorial on hacker news that night, and it went to the front page from there.

That was an amazing moment for me. It gave me much more confidence about what I was doing, and made me realize that investing my time and effort to learn and share have created a new milestone in my career.

I continued to write technical articles on my website, mostly in Go. I learned that you can never please everyone. Some people liked my articles, while others weren’t happy with the same articles for one reason or another. Some of criticisms were very useful, some were very kind, while others were just plain cruel!! When you open yourself to the world of the internet by sharing your knowledge and opinions, you don’t just grow your skills, but you also get access to deeper aspects of other human beings. Aspects that people don’t typically share with people who know them, and see them everyday.

A very important lesson that I learned was the fact that the world doesn’t revolve around my content. When you write an article or a story or produce any kind of creative output, you must pour a lot of yourself into it. This is a vital piece of the creative process, or else you would come across to your audience as not genuine and unoriginal. Your creation will usually look perfect in your eyes,  but then when your precious creation goes out to the world, holes will get poked into it right and left by other people. If you shut out their input, you won’t evolve your creativity. That doesn’t mean you change your output to just make everybody happy, no one will ever achieve that, and nobody ever did. It rather means that you put your own feelings aside, then focus on the genuine feedback to your output that can help you evolve and grow, instead of the feedback that sets you back and doesn’t add insights to your future work.

One day, I got contacted by a technical publisher, they offered to work together in order to publish an advanced video course on the Go language. I was instantly intrigued. I knew from the start that it would be massive project to accomplish on my own without external motivation, like editors pushing me to finish before deadlines! A short while later, we started the project. I dove deeper and deeper into Go more than I ever had. The experience was extremely demanding, but quite satisfying. The product of that effort was the Mastering Go Programming video course.

Very shortly after finishing our first course, we started working on a second course. It was shorter than the first course, as it mainly focused on the third party packages ecosystem, and on select topics that are very useful for Go production apps. The second course was named Modern Golang Programming.

Working on the both courses amplified my knowledge not only in Go, but also in software architectures, development tools, and the art of producing creative contents. After the courses got released, I got to learn more about marketing, sales,targetting audience, and much more important skills. I knew from the onset that producing useful content for other people is no easy task. However, I didn’t get to appreciate the amount of personal and social time that you have to sacrifice, in order to build a creation that other people can relate to and like, till later in the projects.

I enjoy writing a lot, and have always wanted to write a book. I don’t just want to write one technical book, I want to write all sorts of books. I have technical topics in my head that I can tell will make great books, I also have ideas for long and short novels that I would love to write about at some point in my life.

My first opportunity to write a full book manifested itself while I was working on my second course, a manager from the publishing company suggested I help them plan an outline for a book on cloud native programming with the Go language. I said sure. Next thing I knew, we were at the tail end of a 3 hour call where we discussed all aspects of cloud native programming. It became obvious then that I should be one of the authors of that book. I was very overwhelmed at the time with the other projects that I had in my plate, so it was decided that a coauthor has to get involved in order to produce a good piece of work at an acceptable time frame.

Six months later, we had a contract signed and an amazing coauthor on board. My coauthor is Martin Helmich, who not only possess deep technical knowledge in all aspects of modern software architecture, but also has powerful experience with writing books and publications. I enjoyed my work with Martin immensely.

The process of co-writing a technical book was not easy. There were tons of late nights, missed social occasions, and just pure mental effort. The experience doesn’t end when the book is done. You then have to worry about marketing the book. Doubts start to rise. Will people like it? Will they hate it? Would they give me terrible reviews that I would feel like I rest at the bottom of a mud pit? Or would they give me glowing reviews that I feel like the king of a sky high castle? I guess time will answer that.  For now, I will sit back, relax a bit, and see what happens!!

I think here will make for a good conclusion, lest the article morphs from a good story to a bunch of ramblings!! Thank you for reading about the journey of my first book. If you are a technical reader, and would like to have a look at my first book, click the image below: