RabbitMQ vs Apache Kafka explained - General

Usually, I share my stuff here in this blog, but from time to time I share some external resources.

A couple of years ago I was

Continue Reading »

Let your team evolve! - Career

A painting titled "Why so many people don't evolve appropriately in their career!" (mostly juniors and mids, but sometimes also seniors) ... Here is why!

My edit based on the original comic by BizarroComics.

I've been working in the tech industry for several years now, and what helped me the most that seniors gave me a chance to move forward. (of course, you still need to put a lot of effort from your side).

The best seniors I've worked with were not only strong in pure technical but also they were really good in tech-related stuff ... and mainly how to make people around them get better! (especially juniors)

In my career I've recognized a pattern, the entire people's career is affected heavily by their first job! And people acts later affected by that. If their first job was great and worked with smart, open, humble, and supportive people so their career later will be much much better, and vice versa.

So dear senior, seniority is not just technical! It's also about working with people and make sure they are going forward!

Here are some takeaways based on what I saw in the last couple of years.

1. Junior development could be started from day one

I saw many seniors were treating juniors like "babies"! They always think that they, the juniors, still young and not experienced to do many things. And they need to wait a bit more before they involve in proper tasks.

People's development could be started from day one. And as a senior, you don't need to wait anytime to support juniors around you. And juniors need to learn "how to think" to solve problems instead of just looking for a solution for a problem. It's kinda like "MVP pyramid", where you have small a chunk from many skills instead big chunk from a single skill.

2. You don't need to be a senior to start developing people

There is no correlation between your experience and developing people. You don't need to wait till you are a senior to support the people around you. One junior or mid in a group of juniors could enhance the whole group significantly.

That could be done by asking questions, support other people, or making a competitive state in the group. You could be this person or you find someone else to pair with them and go forward.

3. If you didn't have seniors to support you, find them!

We all know that life is not perfect. And it's hard to find that great senior who could help and support you in your career. Many seniors who are strong technically could be not that informative or interested/good in people's development at all.

Whatever the reason, that great senior that you are looking for could be not in your current company! So you need to find them. You need to find a mentor even outside your current company to guide you in your career.

Again, life is not that perfect! In reality, it's hard to find that mentor and if you found them it's harder to keep in touch with them for a long time. So you mostly will need to find more than one person and learn the best from each one.

4. Don't wait for someone to make your personal development plan

Last but not least, a word for juniors ... most of the time you will need help from seniors to make your personal development plan; however you don't need to wait and you can make your own. You just need to put more effort to make one by asking more seniors and collecting all data could help you to build your plan.

...

Those some points I've been realized during my career and I didn't find many people focus on them, so I just like to emphasize them.

Hope you a happy career! :-)

Continue Reading »

Now I'm a Certified Kubernetes Administrator + 10 exam tips

On 17.09.2019 and in less than 36 hours of the exam, I got an email that I passed from the first try and I'm now a Certified Kubernetes Administrator (CKA) 🎉🎉

It's not my first performance-based exam, I had before

Continue Reading »

Your company doesn't need a hero but a team! - Work culture

What I like about working in startups and small-mid companies is that they’re flexible and you can have a visible change and a direct impact. Ironically that's the same reason why heroes and heroism find their way in that ecosystem.

If you have been working in the IT industry for some time and especially in startups, mostly you would have met that kind of people at work ... heroes!

Who are "heroes"?

So who exactly is a "hero"? (sometimes also called "Ninja")

Heroes are some people at work who can do crazy stuff. They are doing everything needed to get things done. They have all kinds of access and privileges. They know all the info that cannot be found anywhere. They are doing the hard tasks that only they can do and solve problems that no one else can solve. However, all of that’s mostly done with no clear mid- and long-term planning, undocumented, and on an ad-hoc style! (so being a hero is not about performance but work practices!)

Managers mostly like them because they, the heroes, get lots of things done quickly for the company. In fact, heroes are not necessarily bad people, assholes, or jerks. Sometimes they are also good and nice but their way of work is just harmful!

How harmful could it be?

Wait a minute! Doesn't that sound good? Many things are getting done fast and on time! Isn't it better if we have more of those heroes?

NO! Unfortunately not! All of that comes at a cost!

Toxic culture

First of all, heroes are heroes because the rest are "normal". Those heroes simply limit the other people in the team and keep them from growing, and the only way to pair with heroes is to be another hero, just like them. But in the end, a company is like a film, there is no film full of stars!

Not only that but also wrong expectations raised against other team members when they don’t do the hero-way! Why aren’t they the next hero?

Technical debt

What heroes are actually doing is like getting a loan, you have a lot of money to spend now, but you drown in debt later ... the technical debt. Maybe everything works "just fine" for now, but later, many things will not.

Teams (and maybe the whole company) will end with fire fighting and an ad-hoc work style. And then when you realize what was wrong, the cost of re-engineering the mess, and fix it, is usually horrible.

Limited growth

When heroes are off or on a vacation, other people tend to be afraid of making changes, because it's not clear how things are working. Furthermore, when heroes are not there, many incidents happen because most of the time they keep things “just work”.

Also if the heroes are not communicating their work (through documentation, short presentations, awareness sessions, etc), then their absence due to any reason (death, accident, etc) means that their team and maybe the whole company are paralyzed.

After all, those heroes are humans and have their limits, hence companies cannot depend on people "individually" but as a "team".

What are heroism signs?

It's not so hard to find traces of hero practices … you just need a closer look, especially on the team level.

• Do all team members have a common understanding of what they do?
• Do the team members say "no" from time to time or is it always "yes"?
• Does the team work extra hours or until late?
• Does the team have a clear mid-term plan? (between 6 to 12 months)
• Does the team have a proper onboarding plan for a new member?
• Is the team in a "freeze mode" when a member is off or on a vacation?
• How much does planning take place before the actual implementation?
• How many returned incidents does the team have and on which interval?
• How many parts of work are undocumented or have no clear way to do them?

Those are the most common signs. The more you have, the bigger the problem.

Reduce heroism and build sustainable solutions!

At the end of the day, when you realize how heroism is harmful to the company, it's probably too late. Mostly you will be on the horns of a dilemma!

If you keep heroes and their way of work, the longer they stay the harder to change. And if you tried to get rid of those practices quickly, you put yourself and the company in an ultimate risk!

It's also worth mentioning, and believe it or not, having heroes as a part of a company is not really a problem per se! In the early stages of the company life, they could help the company growth a lot. The actual problem is when the "hero-way" becomes the default way to work with no proper plan to move towards sustainability.

Unfortunately, there is no silver bullet to fix this. But here are some takeaways you could think about:

• Plan, plan, plan. It's the way to a smooth transformation and mitigate the hero effect.
• Build a work culture and practices. Something like Agile and DevOps that encourage teamwork instead of solo work.
• Sooner rather than later. But if something will not be done now, there should be a reference and plan for it.
• Get rid of silos. Silos are the best place to grow heroes.
• Be prepared. Mostly, heroes will leave once there are a process and a proper workflow.
• People are different. Having a process doesn't mean you ignore individual differences.
• Change is a risk. Most of the time it needs to be done slowly, but also firmly.
• Finally, don’t go so far! Having sustainable processes is pretty important, but too much of “process” also hurts! Find the sweet spot of balance, otherwise you will lose “agility”.

That's all! And I hope you have more sustainability and less heroism :-)

Continue Reading »

Cloud Native Maturity Model - DevOps

Few years ago when I started to do more CI/CD practices, I wrote these 2 posts:

• Continuous integration tools and best practices
• Continuous Delivery and Maturity Model

Nowadays, CI/CD become a market de facto standard. So what's next? "Cloud Native"!

Continue Reading »

DevOps, J-Curve, and change management - Agile

I've been working professionally in the tech industry for more than 7 years. The change has been always one of my things. I started to do that starting from my first day in this career!

And that's actually why I love the "DevOps movement", because it's about "change"!

Continue Reading »

Import existing infrastructure AWS, GCP, and others - Terraform

Automation and infrastructure as code became a really important thing in tech industry. Actually the became a de facto!

But in real world and especially in startups world when you have limited

Continue Reading »

Control collecting Prometheus client library metrics - Golang

Recently I played with Prometheus more deeply. I wanted to expose some metrics from a REST service written in Golang. I needed to deal with Prometheus instrumentation

Continue Reading »

Automating my laptop system setup - Ansible

As I always say, I like to avoid manual boring work, and manual repetitive work is always boring for me! So I used to automate my system I use on my laptop with most of stuff I used to use.

Although I'm not big fan of changing my main system too much. And as I'm the author of

Continue Reading »

Monitor Keycloak - TICK/Prometheus

One of pretty interesting components I worked with it last 2 years was "Keycloak" by Red Hat! Keycloak has many use cases, and I did see many projects use it in different ways especially

Continue Reading »

What I learned from refactoring Terraform provider - Golang

Beginning of 2018 was my real expose to Golang. It's almost a year now! (before that was just playing around where I can just

Continue Reading »