How can i know if im ready for a devops engineer position? What is all the bullshit that i need to know to be devops engineer? Lets aim high and talk about senior position

You need to have a focussed mind first of all.

You'll need to love trial and error. That's all what devops is for me. A lot of waiting. Most boring part of development ever

Can you stitch together cloud and self hosted services to achieve the following:

Security
Observability
Scalability
High availability

Can you troubleshoot, fix, ever generally maintain such systems?

Can you coach developers, cloud architects, sysadmins, and managers on how effective infrastructure and procedures improve revenue streams?

Can you automate all the above, and keep everything running smooth for minimal costs and maximum benefit?

https://roadmap.sh/devops <--- learn what skills to level up in here

@retoor the whole of programming is trial and error. In fact this entire fucking shit life is trial and error to begin with

@b2plane programming is not trial and error at all. I know exactly what I do

@retoor u cant learn something new fast but you need to implement it quickly. There may not be enough time. Therefore trial and error

@b2plane that's where we differ

@b2plane that is literally the slowest way to develop. It's faster to learn, design, build tests, implement, and refactor.

Programming by iteration is absolutely the slowest way to get it done.

@lungdart i think we're not talking about the same thing. I personally have to pause the whole project to go ahead and spend several days just learning terraform. Or kubernetes. Etc. And then come back when i finish the course. Large topics like that are difficult to implement even by trial and error. Im talking about smaller libraries for example instead of learning NextJS framework at its core, I'd have to learn React first. But i skip learning react an just watch advanced nextjs tutorials with real world projects being built, very advanced stuff and that way learning the framework through "trial and error" practical way. Then i start my own project and although i know nothing about how useState works, useEffect, serverSideProps, i try and fail until it works and that way learn what's the proper way of using it

@b2plane we're talking about the same thing.

Not understanding how something works, trying it, seeing what happens, changing things to see how it behaves, until it works.

This is a very amateur way to code, it's the slowest way to code, and it's unmaintainable.

Instead, read the docs and understand every single line you write, and every argument you give it, and why you are doing it the way you're doing it. It's more work up front, but saves you want 50% of the effort in the long run.

I've fired many "sr" devs who coded like you describe. And chewed out managers who try to enforce it using arbitrary deadlines and fear.

@lungdart im not gonna do shit you or any other "expert" dev tell me on how i should study. Everyone studies on a way thats most efficient to them. Your way of studying new technology could be efficient for you but not for me. It is ridiculous and absurd to judge all the animals by the same type

@b2plane I'm not talking about studying software and libraries, I'm talking about implementing features fast.

Often, when learning a library, building proof of concepts is required to validate functionality, especially when documentation is poor or invalid.

But when it comes to implementing new products, you should know whatever thing you write does. If you need to play with a tool first to do that, that's encouraged.

@lungdart give me code example of something that should be understood when implementing

Or at least describe it to me

Or tell me the exact example the "sr" devs did that made them bad devs

"senior" is the new "junior."

And "junior" is the new "entrylevel."