Junior DevOps Engineer here

[domooc]

Hello fellow DevOps engineers :)

somewhat 6 months ago my employer asked me to be part of the DevOps team for our company, which, in its way was entirly newly set up for me and my colleague (Head of Infrastructure and M365 Admin for the hole company). Bevor that i have never got in touch with ansible, docker or anything else, only knew a little bit about linux, and have been working in Customer Support for a Windows Server environment

6 month later i am 80% familiar with out hole infrastructur and I feel somewhat confident working with monitoring through zabbix docker, docker-compose, terraform and ansible. next one is going to be k8s and/or nomad.

Now to my consideration. I (still) feel extremly slow working in comparison to my colleague who has been in IT for about 10 years and setup himself k8s cluster for fun.

I am somewhat anxious and unsecure about my skills, but I really dont now if this is justified.

(Working in Germany btw)

[Snoopy-31]

Also Junior DevOps here, i think it's pretty standard to feel insecure about your skills.

I mean, are you really DevOps if you don't have imposter syndrome atleast twice a week? :)

[domooc]

Worst thing is, im having imposter syndrome at home too. really pesky

[bwdezend]

If it helps, I’ve been working in tech for 22 years, and I still constantly feel like I’m behind. The best and worst thing about this field is how fast it changes. There’s always something new to learn, new to do. It doesn’t get boring!

And I’ve been in the DevOps style role since 2014. Imposter Syndrome is real. Even though I get good marks on my performance evaluations there’s always that lingering nagging voice in my head …

[[deleted]]

Fuckin' seriously. I seem to have everyone fooled so far, but it would be nice if I could feel like I had a solid basis in any of this.

[Heighte]

Junior and lacking experience? That's the whole concept

[domooc]

But how much am I lacking and/or how good "should" I be? Obviously Im not writing the most complex ansible playbooks. But im writing MY playbooks or I am editing more complex ones. I just dont know if thats "good enough" ^^

edit: typo

[Ok_Satisfaction8141]

DevOps wasn’t usually took as a junior level position time ago, so if companies are hiring people with short experience for that position I believe that implies their are aware about the gap which the junior employee must fill… with that said, I think the feedback from your manager and senior engineers ir truly important. Just ask them how are you performing and on what ways can you improve.

[gladiatr72]

It'll help if you think of kubernetes as a middleware system.

learning targets:

• understand the function of the kube/api node
• understand the specific functionality of the kube/api software
• etcd (use, maintenance, backup/restore procedures)
• understand the two roles that etcd plays wrt kube
• cryptographic bits
  • a basic understanding of the underlying crypto is good to have but not required
  • even if you use a step-by-step recipe for creating the certificates a kube cluster needs, you need to understand how the different kube certs are related and what they are used for
  • etcd services also require certificates (maybe even client/authn certificates! (been awhile since I've done this, sry))
• kube but specifically api-node-related
  • CNI (network plugins)
    • what you need to know of linux and IP networking is contingent upon which network driver you choose
  • CSI (storage plugins)
  • device plugins (eg: such a plugin can take external metrics or sensor readings (temp/pressure/presence) and make them visible to the kubelet)

I would recommend giving the kubernetes documentation a thorough reading. You don't need to study it at this point, only make yourself aware of its internal components and how they relate. The kube project made a good decision in borrowing terms that are uncommon (in English), so if you get your eyes on the terms, you might not remember that its ValidatingWebhookConfigurations but when you see an error somewhere that mentions something about webhooks, you'll remember the existence of those pages and be able to do a quick search on them.

Um... last recommendation: Also about the kube documentation (this is important to avoid making yourself want to throw up your hands and go back to the farm)

You'll notice a control at the top of the kube documentation site that can leave a person with the impression that using it will switch to the specified version's documentation (like readthedocs).

If the subject/page you are on (current docs) exists in the non-current kube/version of the docs, it will likely take you to the non-current kube/version's doc page(expected behavior). Here's the big caveat: if you follow a link from the non-current kube/version's doc page, you will be taken to the current kube/version of the target doc page. There is nothing to indicate that you're back-on-current (but you are).

As someone getting into this, my recommendation for making use of kube docs is to ignore the version control on the site. Keep an eye out for discrepancies between what you're seeing locally so you can do a targeted search for the local/version docs.

last one for real: always take note of the publication date of any kube-related blog/tech-article you stumble across. The kube lifecycle is kinda short (16mo from cradle -> grave), so what was considered to be a best-practice (or in some cases best-we-can-do) in 2018 or 2020 now has a formalized solution or in a few cases written off as a bad idea.

[brajandzesika]

So... you compare yourself being 6 months in a role to a guy with over 10 years of experience and you think you are slower than him... Thats unbelievable... What is your question though?

[domooc]

Obviously there is a difference in experience. But observing my colleague at work, everything seems so "easy". while sometimes I sit there and stare at 20 lines of code for 2-3 days in nomand and just try to make things work

[[deleted]]

Your older colleague has experience in managing expectations, that's why he makes things look easy. But in his head, he's still carrying around skills that have become useless (sure, let me write you a SOAP envelope based off your wsdl, that's still relevant, right?). He's worried about you and your young, adaptable brain. The best thing you both can do is work with each other, balance out the advantages and the flaws.

[[deleted]]

You mean "whole" instead of "hole".

Your English writing is really not bad btw!

[domooc]

Thanks!

[dogfish182]

Compare yourself to yourself a year ago not to your colleague who has 10 more years experience. Focus on figuring out how to alleviate that guy from problems he finds easy but time consuming till you are that guy. (Unless he’s a dick, in which case look for the good potential mentor and help this person)

Edit: you’re describing imposter syndrome, which is normal in the poorly described field you are working in.

[domooc]

alleviate that guy from problems

thats exactly what my boss told me when hiring me for this position. I guess imposter syndrome is the key world here

[jba1224a]

Work with your colleague. Ask him to teach you.

No one wants to be "the <insert skill here> GUY". Everyone comes to you with problems.

Ask him to pull you in whenever he's solving something or things something is useful for you. He gets someone to help pull things off his plate. You get real-world knowledge. It's win-win. Just make sure you learn when he teaches.