Back to Engineering: An engineer’s gainings through time

EDIT: As of August 21, I am joining the Ansible Lightspeed engineering team. Stay tuned for another possible article about it!

EDIT2: Here is the new article: Back to Engineering Vol. 2: A Path to Wisdom

TL;DR: As of December 1st, I am starting a new job in Red Hat, this time as a Principal Software Engineer in the Kafka/Strimzi team. If you are curious about my Red Hat journey so far, read the rest:)

It’s been almost 5 years in Red Hat. I started my journey in Red Hat as a middleware consultant. After about 2.5 years I moved to the Red Hat Training team and have been working here as a Senior Content Architect, till now. Because it has changed recently. I am moving back to software engineering!

Before Red Hat, I was a Senior Software Engineer at Sahibinden.com, one of the highest-traffic-consuming websites in Turkey. Apart from some Business Intelligence journey or coding in .Net and PHP, most of my career consists of writing code in Java. So I called myself a “Java developer” most of the time and developed web application backends with several types of frameworks such as Struts 1.2 (yeah I am that old), JBoss Seam Framework, and Spring Framework (not Spring Boot!).

At some point, in the company I was working at, I felt that I am doing similar things in similar loops so I was in a kind of vicious cycle that I had to break. This way I wouldn’t be able to improve myself to be better in my career so I decided to learn some “new stuff” in my spare time in a scheduled way. Cloud, Kubernetes, and cloud-native were popular terms back then and I started to teach myself in very small chunks (The Kaizen Way) and tried not to break the chain.

Anyway, as a developer who was not much aware of the new cloud-native world, I learned about AWS, Kubernetes, OpenShift, and Fabric8, which was a Java library for Kubernetes.

It was early 2018, I remember reaching out to my Red Hat software engineer friend, Ali Ok, for an open position in Red Hat, asking if he can be a referral or not (Red Hat has a great job referral mechanism, which is called “Ambassador Program” and they value referrals a lot). The position was for a “Middleware/AppDev Consultant”, which requires the applicant to take care of the customer deliveries for Red Hat middleware, cloud-native apps, and most importantly: OpenShift CI/CD!

I don’t want to expand this part of the story too much but I joined a couple of interviews (including Java code interviews via Hackerrank at that time) and finally got the job and started at Red Hat as a Middleware/AppDev Consultant.

The Consultancy

I spent my ~2.5 years as a Middleware/AppDev Consultant, worked with about 20 different customers, and traveled to many countries including Senegal (West Africa), learned and taught a lot of Red Hat technologies such as Apache Camel (Fuse), Infinispan (Datagrid), Jenkins for OpenShift CI and ArgoCD for OpenShift CD, Quarkus (pretty new), and most importantly a technology that I am in love of; Apache Kafka. My Kafka journey did not start with Red Hat (as I knew a bit about Kafka from my previous job), but it became my “niche” technology in Red Hat. (For the curious ones: This presentation includes my short story with Kafka.)

Working with customers can be hard because their requests might vary, and communication and the way of working can vary depending on the people’s personalities (like everywhere) or the company culture.

As a software engineer, whose job was to just write code and almost only have to talk in the meetings, it was really hard for me initially because you could have “randomness” in that area, which makes the processes “unpredictable”.

An example of an unpredictable situation that I remember of is, once I contacted a customer to arrange a meeting and we arranged the meeting for a start of delivery (delivery here means the consultancy work/labor for the customer). There were only 3 or 4 people in the meeting request in my calendar so I was very relieved as I was not a good public speaker back then, so doing things among 3-4 people always meant it would be a small meeting in a small room. Easy start! I prepared only my hardware in relief and went to bed for the next day.

I went to the customer’s office the next morning, met the person who welcomed me to their company and we headed to the meeting room. When we came by the door of the meeting room, because of the external view I suspected that it was a big room. Well, sometimes we had small meetings in big meeting rooms, so that was something I was used to and that had to be a similar case.

He opened the door of the meeting room and there was a big long desk full of people around it (I could not count but it must be more than 40), waiting for me and my unprepared presentation as an intro for development processes with OpenShift.

Well, of course, I did not say “sorry but I didn’t prepare the presentation” or “I can’t show you anything today”, but sat down and requested about 5 minutes to be “prepared”. What do you think I did after this?

Well luckily, my dear colleague Cenk Kulacoglu, who is now the manager of the Red Hat Consultancy team in Turkey (he was a senior architect back then), had taught me to be prepared in any time. I had seen him he always had a couple of presentations in his Google Drive so that he could either present them or change them regarding the customer needs. That was what I did for that customer.

I told you about this story because being a consultant, not only makes you improve yourself technically but also improves your soft skills so that you can give more to your clients.

In consultancy, you can not only learn how to be “always being prepared” to overcome the “unpredicted situations”, but also many other skills that I think improved me in many ways:

• Public speaking: I was shy about speaking in public probably because of a couple of traumas I had in my childhood. I had a chance to overcome this with the “unpredicted situations” many times. When you expect to see 3 people but learn that you have to present to 40, it improves you. Now I am pretty relaxed talking in front of public.
• Presentation skills: I learned a lot from my craftership master Lemi Orhan Ergin in the past, and I think I had a chance to evolve it in my way with the style that I learned by just preparing slides. The key part is the “flow” and you learn it by doing. And if there are times that you have to do it in just 30 minutes to prepare a deck, then you learn it better:) (This is another story that I will not give any detail about.)
• Presenting skills: A presentation is not only about slides, but you have to learn how to explain the topic to the audience, especially if they are your customers, you have to do it better because they want to learn from you and they are consulting with you. You must distill the knowledge and present it with the tools (presentation) and your public speaking abilities.
• Persuasion/Negotiation skills: Well sometimes you have to convince the people/customer you work with. When you are a consultant, you are the one who is consulted so you might need to use your persuasion or negotiation skills from time to time.
• Fast learning: You must learn things faster in the moving environment of consultancy because you will always be expected to know things, especially if that things belong to a wide group, such as middleware or CI/CD.
• Flexible attitude (Politics skills): This is not about any politician or what they do but this is more about managing yourself and your clients. You must be always nice to the customers and should not be too direct. Sometimes there will be misunderstandings, or sometimes there can be really tough customers, you have to manage them all so you should not have one and only one solution for the same thing but many. This is not about a “customer is always right” thing, but about using your persuasion, negotiation, and “niceness” skills and being flexible as much as you can. This is one of the things that I learned very later on.
• And many more that I might not remember… You can add your own in the comments section below.

WHO Built This

Just before finalizing my days as a consultant, I had a chance to work with a very special team; Red Hat Open Innovation Labs team, on a very special project; the World Health Organization (WHO) Learning Experience Platform (LXP), at a very special (and weird) time of the year; just after the pandemic happened!

It was a great experience with the WHO team, trying to implement and stabilize a real DevOps culture within their organization and creating a functioning application for their LXP project in just 8 weeks.

Enough for the words for this, for the curious mere mortals, here is how we did it:

Gaining these kinds of experiences as a “Software Engineer” or consultant makes you think differently. Being physically in a customer environment is one thing, having a kind of remote customer engagement, which is worldwide, timezone dependant, and important (because it is directly about health in a pandemic time), is another thing.

After my ~2.5 years of consultancy journey, because of having a small taste of working in a remote worldwide environment, and a bit of love for writing and creating content to teach people, I decided to move to another team, where I can access these benefits and improve myself on creating training content. I moved to the Red Hat Training (internally aka. Global Learning Services – GLS) team.

The “Content” Development

In February 2021 I joined the Red Hat training team, with the enthusiasm and excitement of having a chance to create professional content. I would write books for training and I was very excited about that.

Before being a consultant, I had been admiringly looking at the techie people who created content consistently. Some consistently wrote blog posts, others created YouTube content.

Especially the writing part took a lot of interest in me because if think if I did not become a “techie” I would be a writer; a novel writer. I remember I left similar notes to every close friend of mine in the high school diary book like “…in the future it is likely you find me in a book…”, giving the message to both their subconscious and mine. It is kind of childish but I have to admit that I liked writing because I had been writing short stories and poems at that time (poems in both English and Turkish. Edgar Allan Poe was -and still is- my favorite).

After years, in university, I lost my interest in writing and things went more with Maths and 0-1s but while trying to learn things on the web, I realized writing (actually creating content) is still a thing, which will not be rotten away. I tried to create some forums first, wrote one by myself with PHP, then used vBulettin and similar things but end up creating the site and writing a couple of posts or two then forget the website.

Later on, I understood that it is not a matter of quality, but quantity and consistency. This is another topic though, so I am leaving this for another article.

While I was working on the “Strimzi Kafka CLI”, writing blog posts about it, and creating video content, I always thought about writing better. If you are a software engineer who has this mindset that seeks a spec for everything technical, you also seek a spec for everything in the real world, like written content. I knew that my writing was not good (and still not perfect), but I probably sensed that there should be a better way to do that with a spec or something.

There are books around about creating content better such as Everybody Writes by Ann Handley and On Writing: A Memoir of the Craft by Stephen King, I bought both of them before I joined the training team and read both but it was the time I really learned about writing: writing, reviewing and get your content reviewed by your colleagues and the editors.

I learned that there is really a spec like developers have for their programming languages or frameworks. We used the Red Hat Style Guide and IBM Style Guide, which guided us a lot while we write. I think this is the actual process you really learn doing something. While I might be still chased by zombies of passive voice, I think my writing got improved a bit, good enough for helping a content creation agency with creating high-quality content for their customers. I am going to expand on this part later on in a different post about “Writing for Developers”.

Training the Experts

Working in a training team not only gives you a chance to improve your writing skills, but also you become a trainer by thinking from the trainee’s perspective.

We had a lot of discussions about how to present the content to the students, and how to write better quizzes, labs, and guided exercises, we even tried out different models of instructions so that we could get feedback about those and improve our end.

Training content is not like blog post content so you must think about its architecture (because it is actually a book), you have to have inclusive language, your style should be formal, you have to be clear with your instructions, and so on. Most importantly, because it is teamwork, you have to know how to work together and how to connect the dots of yours and other people’s because, in the end, it is a whole content that customers and Red Hat trainers use.

In the period that I’ve been involved in, I had a chance to work on many training contents including OpenShift CI/CD and OpenShift Serverless.

Here is a short list of the training courses we created during my tenure:

• Red Hat DevOps Pipelines and Processes: CI/CD with Jenkins, Git, and Test-driven Development
• Developing Event-Driven Applications with Apache Kafka and Red Hat AMQ Streams
• Cloud-native integration with Red Hat Fuse
• Developing Applications with Red Hat OpenShift Serverless and Knative

While I contributed writing content for these courses, I had a chance to use my connections from consultancy to reach out to people who are experts on those topics so we could get a lot of useful feedback before, during, and after the course development.

I can say that the Kafka one is my favorite one as I not only contributed to its content but also helped shape the outline of this course. It was the first course that I had a chance to start from scratch so I can admit I had a lot of fun. (Also thanks to my friends Jaime and Pablo who made this process fun for me. Long live the 3 Musketeers!)

I also had a chance to do a few Taste of Training (ToT) webinars where we demonstrated a training-relevant technology and did announcements about our present or future courses. You can find one about “Openshift Serverless” here still live on the Red Hat Webinars page, and another one about “Building event-driven systems with structure” is here on my YouTube channel:

In the training team, I had many chances to use my previous skills like presentation, people connections, fast learning, and product information, and learned new ones such as writing and training mechanics. Knowing how to write, as a developer, helped me a lot because when you write, you learn how to express your opinions better and you become more organized. Also if you start writing here and there, it is inevitable that you get some attraction which helps your self-marketing. I don’t write on popular technical content websites much but as I mentioned before, in my free time, I help a developer content creation agency where I can hone my writing or outlining skills.

It has been fun to work as a Content Architect at Red Hat but after some time I felt like I should focus on a single technology and work on it in a lower-level manner. Since I have been very much interested in Kafka and Strimzi for some time, I took a chance to move to the Red Hat Kafka engineering team, and luckily I was able to become a part of that team, which consists of very smart, talented and friendly people that I already know of!

The New Journey: Red Hat Kafka Engineering

As I mentioned at the very beginning of the article, it has been quite a time since I haven’t been doing R&D and writing low-ish-level code. I mean I wrote a lot of code for customer projects when I was a consultant, I wrote code for the guided exercises and labs for the training team, and wrote code for my open-source pet projects but writing the code for the product itself is a different thing. It is something that I haven’t been “directly” doing for 4+ years so I have to admit that I am a bit nervous and excited about it.

However, hopefully, I will have a chance to use my gainings from other teams and past experiences from them, and waking up the “software engineer” inside me with those past gainings, I believe, will create a beneficial combination for the team.

I am a lot excited that I will have a chance to do direct contributions to the Strimzi and AMQ Streams. I know that it is not like contributing from the outside because when you become a member, expectations become higher:)

I am starting my Principal Sofware Engineer role in the Kafka/Strimzi engineering team as of December 1st, so wish me luck with my new journey in Red Hat:)