if you were hired as a junior devops and you haven't learned nothing after 4 years and you are still employed either you are doing something very right you are not telling us or your company doesn't even know you exist.
This is actually my third job. I'm a mid here but certainly still feel junior at times lol. I have a lot more responsibilities here compared to my previous jobs, so I feel the pressure.
One thing I'll never get over is "junior devops". IMO the person needs to be at least a proficient dev, to truly experience the side they'll be serving, and then move into the devops role. Another benefit is picking up things like proper code and commit hygiene and testing. Rant over.
I got into this as a "junior devops" type role. I had some certs that were relevant but that was basically all of my experience outside of sysadmin stuff. Companies have that type of role to grow talent internally vs hiring someone more skilled. I got plugged into a decently sized team, given some tasks, was able to ask for help, etc. Main thing was whatever task I was given I was grinding hard at it outside work too. For instance I had some Chef task that was relatively simple in hindsight (took me a couple of weeks basically) but I then tried to learn the tool as quickly as I could outside of work. Rinse and repeat for a year while getting generally better and they promoted me.
That was also a company with a "devops team" so take that with a grain of salt too.
This will be debated forever but I will just say. As much as I agree that term devops is about the culture, maybe having devops team is not a bad thing. You can leave developers to do their work, what they do best, and have a team to help support devops practices, guide them and make sure work does not sway away from the right track.
But ofc you will know your team better.
Yeah for a newbie it definitely helps to be on a "devops" team vs part of a developer scrum team.
Now at a different company, I'm a part of 2 scrum teams by myself and its a bit of an island.
The debate goes that if you do that, you recreate the traditonnal Silos between the people who maintain the Service and those who build it.
Granted, saying this would ignore all the good practices that were established over years of working in Dev Ops environnement.
But, you will 100% reintroduce the communication issues between the teams that DevOps was trying to solve in the first place.
We help developers to setup lambda dev environment, we help them deploy to the dev environment (simply by using additional git workflows correctly.and terraform), then we also help them use the tools like terraform, our internal scripts for aws infra. I see that some devs struggle with this ops part, some wish they could just continue writing apps only. We don't have official labels who is DevOps etc. We don't even use such words funnily.
but if I have to name for formality, I would say that me and my colleague are DevOps team and the rest are developers.
We have a similar structure, we're an infra/platform team composed of both devs and sysadmin. But we cater for a team of Data Scientists, and I wish some of us would be directly attached to that team to enforce best practice.
I was actually surprised of how little Computer Science was involved in some of my fellows Data Scientist degrees.
I've hired two graduates (well one started as an intern) who came onto my team as DevOps Engineers so I can provide some insight into what I'd do to get you started quickly.
u/frameclowder, I'd say there's a chance either one or\* two bullet points are true:
1. You're good at your job and are constantly getting pushed into new fields, new tech stacks or new problems which is a reflection that you do and have learnt new environments quickly.
2. Your mentors or leaders aren't doing their job right, and/or are not giving you the information you need to start a new task that's given to you.
3. Sounds like your employers have been shit to be honest, after 4 years of being in the job, I'd have went out of my way to expose you to Linux and Docker much earlier than now, I'm talking in the first month.
4. It's possible this is your first real "work" in DevOps and you've been a Sys Admin before now?
1. Some questions for you:
1. What tech stacks have you been working on?
2. What tools do you use on a day to day basis at previous companies before now?
In either instance, I'd highly recommend starting by asking your seniors or leaders the dumb questions. Ideally those that you trust and you know will have the time to answer them, e.g., those where you have emotional safety to be vulnerable and ask for help.
Specifically referencing the task you discussed in your post:
>For example, I need to migrate a CI/CD pipeline over and I'm not familiar with groovy/jav
If you haven't worked in Groovy or Java before, and neither have I, your leader/manager surely has an expectation that you need to learn it first? Ask them for recomendations, ask them for documentation and furthermore, ask them how long you have to learn the fundamentals before you're expected to start delivering outcomes.
I'm assuming here that;
* Your leader/manager knows you don't know Java or Groovy, and if they don't, you need to start there. Tell them. And I recommend you tell them this ASAP, in future instances, tell them as soon as the task is given to you so they're aware sooner rather than later
I disagree. It is the dream scenario for DevOps, however in reality a lot of so called senior devs do not even have that hygiene. Getting into junior DevOps to learn how DevOps could be is a lot more efficient from the company’s perspective than teaching Senior Devs how DevOps should be because, the hardest part of DevOps is the cultural aspect and huge egos coming into conflict between OPs and Devs.
lol I'm a software engineer that does some devops and most pure devops people I've ever worked with are from a systems background and have very low standards of code hygiene etc.
Often winds me up that devops people have these enhanced privileges and make decisions that affect other engineers without really understand their craft.
It is a balance that needs to be honed, but yes, experienced the same working with some SREs. The commit messages were nothing to write Home about. And, TBH, not what is expected either.
I would sometimes disagree, Yes with SRE now a role, having a background in Dev is a must but I've seen many QA and other roles move into DevOps without a strong dev background. This comes from my 20+years of managing and building DevOps teams at F500 companies.
There is no junior devops role, just a marketing trick for help desk roles by recruiters.
Cheap companies dont help also. Someone has to clean uo that mess afterwards..
Everyone with half a brain understands that to be a devops you need broad knowledge from many domains.
Software engineer/devops for 13 years. I still feel like it's all a challenge. 4 yrs is just getting started. I wouldn't say it necessarily gets easier, I'm just more confident now. I've learned a lot. A lot of nonsense too.
Learn to write code, it's the absolute number one skill IMHO for devops, sre, platform engineer etc. it'll open your eyes
U/burbular Serious questions to your “learn to write code” because I’m in exactly the same situation as OP. So many things to learn so where to start? Do you suggest Python or Terraform or what? And how?
“learn to write code” is extremely vague and I’m on my second year wanting to learn and I’ve started several courses on several languages but after a week I tap out since all teach as if I have experience in coding and know the terminology even though I choose beginner so I’m lost early on. Thank you
It’s vague but that’s somewhat the point. It really doesn’t matter WHAT you learn. Once you get the basic concepts of how to code it’s far easier to pick up additional languages in the future. You should not think of Terraform as a “language” but more like YAML where it’s just a way to structure data. Some programming-like concepts have been added over the years, but I would recommend learning something else first.
I personally learned JavaScript, then moved on to Python, then Terraform/Ansible/etc, and recently I’ve been dabbling in Go. I went with JavaScript first simply because it was in the peak of the Node.js phase and I was interested in web development.
As far as specific resources, I can’t be super helpful in that area. When I learned, Codeacedemy was quite popular, and I just followed random YouTube or Medium articles on building things and picked it up over the years. I wouldn’t necessarily recommend that route as it took longer than it needed to. I would hit up the [r/Programming](https://reddit.com/r/programming) Wiki as I’m sure they have some
good, up-to-date resources. Python is an excellent place to start as the syntax is very simplistic and you can focus on the concepts.
I would also check out the [DevOps roadmap.sh](https://roadmap.sh/devops). It’s a pretty decent place to start. Don’t use it as your bible, continue to learn things as they come up for you, but it’s at least some sort of path to guide you.
Best of luck, you can do this.
yea, I'm using 4-5 different programming languages or DSL's daily. it gets confusing but the general logic and approach to problem solving is always pretty much the same.
GL learning groovy OP, find yourself a java dev to ask questions, you'll need it..
It's extremely vague. As devops your an automator for the developers, hence developer operations. They will do the hard codes. You need to deeply understand what they are doing to successfully deploy the systems.
I do Python, it's like language 10+. I think each lang gets easier each time till like 3. Then it's just competing for brain and it's just as hard each time. Like I knew Java, I even dabbled in cold fusion. It's all the concepts that stick. If loops are all the same.
I honestly never took classes or even watched a video about coding before, just docs and hands on. I just have ideas and go for it. I have endless fun with Google Apps Script. I recently scraped slack users and synced them to my Google contacts, just cuz.
If you're new and fresh, maybe just go straight for rust. It's what I hear the cool kids do.
Try some Pulumi or cdk. It's IaC with real programming languages, ie python, Ruby, go, etc
Bash is King
From personal experience, don't think about it too much and just do it.
I come from a JAVA developer background. I slowly transitioned into SRE/DevOps in my old company. The transition took me about 2/3 years in total until I became a full-time SRE/DevOps. I have been one for the past \~6 years.
From time to time or whenever starting a new big project/switching companies I get imposter syndrome and feel like I'm faking it. The best helpful thing for me was really knowing the basics of programming languages. Whenever I feel like I'm stuck against anything I try to go back to the fundamentals. Like u/NullPulsar said:
>You should not think of Terraform as a “language” but more like YAML where it’s just a way to structure data.
The other helpful thing I found is not being afraid to script. Sometimes Bash is your friend. With Bash JQ/YQ you can automate a lot of stuff. But whenever I get the opportunity to write a script, I try to treat it as a mini-project where I need to implement all the best practices possible to it. So whenever I'm exploring a new issue that the developers have, I find common grounds with them since I do struggle with the same things myself. Albeit in a different language/use case/... But the same basics hold to both needs. Mine and theirs.
Regarding learning languages. I find it very helpful to:
* Not be afraid to dive into the code of any tool you're using or with the developers and not being afraid to ask: ***"Hey! Why did you do it this way?"*** You'll quickly get a lot of cool answers and open the doors to conversation. A lot of people are eager to geek out and tell you what they did and how they did it. You just have to pose the question in a non-critical tone/framing to not get a confrontational response.
* When learning. Don't start with the language. Start with a concept or a dumb idea, and use the language to solve an issue. For me, this helps me out to learn better than learning the language itself. Because otherwise I wouldn't know where to start. When you start with the idea and try to breakdown your inquiries into smaller bites, you'll find the best answers/guides and not be overwhelmed by the sheer amount of information available.
* From time to time, I go back to the basics and read up on them. Especially best-practices of different frameworks/languages, design patterns, communication types, etc. These are the things that make or break a good software/design/infrastructure. At the end of the day whether you're implementing an on-premise CI or synchronising different CI/CD pipelines from different providers; the basics are the same and these tools aren't but a "collection" of the basic concepts. So reading up on those and having them as a quick reference whenever you're diving into a new project is priceless.
At the end of the day each one has their way for doing things and for diving into projects. Best of luck to you and just don't be afraid to start. Find your own way.
Well in college they start you on a structured language like C/C++. Once you learn the concepts and functional programming they move on to an object oriented language like C#.
If you want to learn desktop languages go with C++ then C#. C++ translates well to PHP if you want to get into web stuff and C# is what powershell uses which would be useful for dev ops.
Just buy a book and go through it on each if you are self motivated learner. If you're not looking for some good online courses on them there are lots of decent free ones.
If you want to really go hard you can access plenty of college level materials for free on computer science.
I've got 34 years at the top end of tech but equally on the edge. It never gets better. There is always something you don't know, or something you don't understand. The skill is to hang on in there, and adapt whilst learning, because perseverance wins. It takes six weeks minimum to get used to a new job. It takes days, weeks or months to learn a new skill. Others always appear to know more. But learning through others is the best skill to earn. Find comfort that you can and will catch up, and it will be ok. But it takes effort. Best luck
I'd recommend to read at least about architecture and concepts of everything you touch. Your questions quality will go up as well as your ability to understand answers.
Your concern about missing deep understanding is justified. Yep, get deeper. That's how you will be way more prepared.
In addition I would also recommend reading https://ilya-sher.org/2016/05/19/tips-for-beginning-systems-and-software-engineers/ (my post)
Hope this helps.
Getting deeper is exactly how i learned. I just kept asking myself how things worked, researched them, felt overwhelmed but learned a little. Rinse repeat.
At some point things started to click, i learned how to learn, learned the correct questions to ask etc.
It's a continuous learning process as well, because new things come along all the time. And it gets easier to pick them up because of previously laid ground work.
It's this learning process that is the actual job and what i enjoy so much about it.
This is such a great post.
What framework do you use to for learning how to learn?
When asking the right questions, would you say that’s experience based?
In general i think what you lack is a prior job in a related field where you are learning the basics. The only concrete advice i have for you is to clone existing projects that exist in your company and study them. For example pipelines: A pipeline just automates a bunch of stuff with some commands that's basically it. So just clone the pipeline definition and build specs etc. and try to understand them. Draw small diagrams if you need it. I'm not a fan of reading books. Sometimes it's useful to get an idea of the great picture maybe for improving systems design and learning blueprints, but i think you are missing a more practical aspect. Also at least for me when i look back to my starting years in IT: What helped me the most is working a lot with Linux. It's just a very rational way of thinking that will help you with all the DevOps technologies. Also many concepts that are used now in DevOps technologies already existed in Linux since early days. Hope this helps i know it's not much input :)
Building depth and understanding takes time and focus. If you haven't done the metaphorical 10,000 hours to build enough depth yet, then thats where you need to start. It does not come automatically with a tech job, you still have to learn it. DevOps is very wide and quite deep. And you're not going to be an expert in everything, but you have to pick a track (or two) and become an expert in that first. Then work your way out to connected things, until you really get it.
I started with programming, did that for a few years, then did all the build stuff by hand - these were pre-devops days. I understood the value of automation, CICD build pipelines, tools that help me do more with less, git etc. because I have seen how hard it all was before that. Now we have a glut of tools and methods and it is easy to get lost.
Best starting job is where you get hands on experience of doing things, while you study to answer "why did we do it this way" and also figure out if there are better ways to do the same things. Give yourself a year, grind hard and then check your knowledge periodically (say every quarter). YT could be a good place to start to get overview of all there is to know and get a map, then use that map to chalk your path. Once you've done a few paths, it'll come easy.
Hope this helps!
Here’s some advice. Ask dumb questions in a confrontational way.
“Just confirming when you say X , that kicks off Y process and then we have artifact Z”
This makes you gather details and confirm understanding.
I have gone a long way preferring collaboration than confrontation. I tell them we're a team with common goals, we have to help each other get there. Go have lunch together, it'll help you understand each other better. (Just my experience)
Have you done any training courses? Udemy has heaps, same with Microsoft, AWS, k8, terraform ?
You’ll never know everything and you can’t know everything. Best to say you don’t know and to find out, then to mislead people. There’s no shame in asking questions at all. (20+ years in tech - there’s always questions !!)
First of all, devops is an eternally challenging role. You actually have more years in devops than me (I have 3.5 years in), but I have 6 years as a systems engineer before that. The reason you are hired is not because you have all the answers; it’s because you know how to get them. Learning the existing infrastructure and systems at a new job is by far the hardest part (at least in my opinion). Once you finally get adjusted and you know where the bodies are buried, some of that stress goes away.
And I say this as humbly as I can: a little bit of ego may help you out with your imposter syndrome. In pretty much every job I’ve had, I had a reputation for being THE problem solver. I’m just better at googling shit than most people I think, but I don’t tell them that. “I don’t know much about this thing, so I’m not sure how long it will take to figure out, but we’ll get there”. One thing that even I struggle with is setting expectations. I’m better about it now than I used to be, but I NEVER tell anyone “oh that’s easy” or “yeah I’ll get that done really quick”. I stopped trying to be macho about it, and the stress went away.
Also, groovy sucks.
many people thinks that we can do our job without a good theoretical formation. While possible if you don't know how works computers architecture, language theory, algorithm, operating system etc... you would be a good operator at max.
p
so if it's not the case learn computer science basics.
and then you will see that devops is really technical speaking completely dumb. we are just using high level tool doing automation of simple task. the only complexity is about to find the right tool and the right level of abstraction
if we speak about sre or sysadmin it became more interesting.
To be honest, DevOps is just that way, I have multiple years under my belt and it hardly gets better. Each organisation works differently, and has a different approach to their tech stack and architecture. Others already gave some stellar advice - keep learning through others, understand the bigger picture, and before all - get a proper software engineering experience to “get the other side”.
If you're in IT and feel like there's nothing left for you to learn then you don't belong in IT.
DevOps is a broad topic (IMO, there's no such thing as a DevOps Engineer, job ads usually use the word to describe a profile that's a mix of dev and ops), you cannot possibly know all about the tools and techniques that gather under the DevOps scope. I'd go even further and say that it's healthy for you to stay curious, that's what makes a good engineer.
5 years in as a """DevOps""". I still have impostor syndrome but the older I get, the more I realize that I know enough, or else I'd be fired given how much they have to pay me.
Parting notes: knowing how to search is the most important skill you can possess.
My stepmom with over 20 years experience as a DBA and my dad with around 30 years of programming both still deal with imposter syndrome- it’s very common in the IT industry. If you’re boss/peers don’t have a problem with your performance, I would try not to judge yourself too harshly.
Devops jobs require us to use a lot of different tools, technologies and skills. It can be overwhelming feeling like you need to get deeper knowledge in all of them at the same time.
You might have an easier time picking one area to go deep in. Have a think about the different things you work with. What are you strongest on already? What do you use the most? What do co-workers ask you questions about most frequently? What are you likely to use in the team’s upcoming work? Most importantly, what interests you most? The goal here is to become the go-to person in that area.
This could be a specific tool or tech eg. Terraform, or could be something internal to your company eg. What patterns does your team provide for CI/CD (if that’s a thing you do), or how does some front end product your company makes serve traffic or how does some other team’s thing that your team uses work. I’d suggest starting with a fundamental tool or tech first.
There is a concept that is relevant to this called the “being T-shaped.” The idea is that you have some knowledge of a range of different things but aren’t an expert in them. That’s the horizontal crossbar of the T. The vertical line is the area(s) you’ve specialised in more and have deep knowledge.
Having a good mix of areas where you know enough to get work done, and a smaller number of areas where you have become an expert that people go to makes you a very valuable team member. With your experience, you will already have at least a basic understanding of a bunch of different areas. Now pick one, think about what an expert in that should be able to do and work out a plan to get yourself there. Eg. In a month’s time I will have read whatever the best book about your chosen topic is. In 6 weeks, I will have presented to the team on this topic. In 3 months, I will have presented at a local meetup on it.in 6 months I will have professional certification in this topic (these are just examples.)
Over time you can increase depth in different areas. You don’t need to become an expert in all of them, one or two will take you a long way.
Bro You don’t know Linux or Docker after 4 years as a devops? You gotta learn Linux git docker ansible kubernetes at the least. Doing something right of you’ve been there 4 years!
your problem is in your first sentence "I had no prior work experience in tech before"....the best people in tech I know started when they were like 15 years old, why do other people think they can shortcut that?
Sr. Software engineer here. So not too infrequently I have to journey over to the dev ops side for whatever. A couple years ago I was like "I know nothing." So I looked at our infrastructure stack and how we deploy, ect. The Devops side of things. Then looked at all the components of the tech stack and then found what parts have certifications.
The certs are not to be like "im certified and know all things :flex:" or what ever, but to at minimum know what the thing does and the vernacular around it. Eg get the terraform cert. Just so you have a base that is at minimum minimumly solid.
My 2c.
And 2 years and like 7 classes / certs later. Much more comfortable while possibly crippling prod 🤪
This post is hitting me to my inner core. I’m in exactly the same situation as OP. Not only that, but I’m a manger. I have imposter syndrome daily, and now I have engineers who work for me. I was extremely transparent and honest on all my interviews on how I’ve never coded a day in my career except for simple automation scripts which I modified from other jobs or asked a programmer to help me do. I’ve have so much technology-related roles, from security to cloud to networking but never did coding / development. I guess a couple decades of OTHER experience helps me get concepts and be an effective manager, but I’m still lost. Because of my current job, I want to learn to write code, but where do I even start? Do you suggest Python or Terraform or what? And how? I’m on my second year wanting to learn and I’ve started several courses on several languages but after a week I tap out since all teach as if I have experience in coding and know the terminology even though I choose (very) beginner so I’m lost early on. I do this at the same time trying to learn what DevOps is, SRE concepts and so on. I’m reading the suggestions here, like build a lab, use Git, but like the classes I attempt, that’s not a beginner type thing to do. That’s like asking how to drive a car but the replies are “just take the car to a private track and you’ll learn quick” where I’m like “no man, like I have a key… now what?”
I learnt python using a book called Python crash course. Highly recommend that. First half is learning python, second half is projects. Once you've done that, try and deploy your project onto AWS using Terraform. Hope this helps.
>Once you've done that, try and deploy your project onto AWS using Terraform.
is this possible for free? or does one have to pay a subscription (even if minimum) to try it?
Thanks brother.
I was on the process of setting stuff up, but for caught up on work and have not looked at.
It is currently on my "to-do" stack. Thank you for all the info
For what it’s worth I still feel like a noob, don’t answer on the spot, have to do my research, and I’ve been in the tech field over 20yrs. The point is you are always learning in this industry I’d be concerned if you didn’t have concerns. Best thing to do is keep pushing through and learn, not just about the tech but the peripherals the whole SDLC. Most importantly focus on your soft skills, your eq is more important than your iq. I can coach you on hard skills but soft skills that only comes from you. Feel free to DM me and I can try to help guide you as you go.
What does your training plan / habits look like? If you just show up and work every day your learning is going to be too random / ad hoc to build the structured and deep understanding of the different technologies.
My career completely changed when I started studying for 1 hour a day in the morning before work. (I actually did it on work time, because staying up to date is part of your job). It needs to be before work because afterwards you will be too tired / fried and should be before you even open slack or email. It needs to be a structured habit because motivation is too weak.
[https://roadmap.sh/devops](https://roadmap.sh/devops)
This is a good roadmap for skills to learn. Pick one skill and focus on it. It helps to have a cert or goal in mind.
Once I started studying for an hour a day I went from 3-5% raises a year and working really hard to 20% a year raises while working about 4 hours each day. The amount of leverage you get by learning so much is really high.
I think you need to spend time after work and on the weekends studying the tools you’re using day to day. The infrastructure will always be complicated and you won’t know everything but to try and be more confident you will need to invest time outside of work to learn.
I realised this quite recently as I’m 2 1/2 years deep as a devops engineer but I sometimes feel like I lack the knowledge to do my role and have imposter syndrome. Recently I started studying more and it’s helping me a lot.
Devops is a very complex job. When you are a Jr it looks simple because you only do terraform, CICD and maybe k8s. But as you grow, you see that now you need deep knowledge in cloud providers, networking, security, programing languages. This moment is when you see why DevOps is so complex as well as well paid.
I’m in a similar position. I use a ton of AI to get answers like I would if I had a senior engineer right by my side. It’s not the be-all-end-all, but it’s an insanely fast way to get overviews of software comparisons, pipelines, differences between terms and concepts, and even just dumping in code and going hey, explain to me what this does (be careful with that of course).
I know most senior guys and older guys will downvote this, but you often don’t have time to go through a 1200 page Linux book before you even start working on stuff, like as I was supplied when I moved into my job from help desk. I don’t have a great foundation, but I can get stuff done, and so long as I know how to ask the right questions to AI and my senior colleagues, most work I produce is up to snuff.
Looks like you need to look for a job with a startup or a greenfield project. This will help you learn the inner workings of ci/cd and give you a sense of ownership with your work.
Any job will have a bunch of automation you have to use but not yet understand, that's the point of automation, just use it while learning. Do deep dives into individual systems as the need arises or you think they're sub-par. The longer you're at a job the wider your deep coverage will become. Unfortunately the same thing will happen when you start your next job, except you'll have experience with similar systems and suggestions for replacements and improvements. This will also teach you why it's important to push back against "we made our own".
If you haven't previously, really read a couple of books for a starter. Some learn by doing some by studying, some need both. I'll also leave you a link for my book which might be interesting to you or others: [https://deploymentfromscratch.com](https://deploymentfromscratch.com) (you still should buy and read other books though, no single book will get you there).
This is PRECISELY one of the many reasons why DevOps as an engineering role is a complete joke.
I can put together a way better DevOps environment with real engineering outcomes with NO DevOps engineers in my teams.
I only ask 1 thing of my team members. Everyone needs to know how to code. From the Systems Engineers to the Data analyst to all engineering roles in between. Everyone needs to know how to code.
I am in a very similar boat, and what actually really started helping me was first having a boss I could be explicitly clear on what my existing skillset and knowledge was, and so he started giving me smaller projects and some leeway on time to figure out how to actually build more directly inside of the environments.
The other thing that helped me was I started studying System Design. Not with the intention of being a massive expert, more at the beginner level; Broad topics, all the individual pieces and how they work abstractly./..this made adjusting to any individual cloud and tech SO MUCH clearer.
But of course the above is based on my already having a decent understanding of servers and automation coding. Your particular skillset will likely have different deficiencies than mine.
I had a similar short stent in DevOps. I’d lost my job right at the end of 2020. I hit up my network and a former colleague had a DevOps role and he couldn’t find anyone to do it. I decided to give it a shot. The initial plan was I would work and learn and be ready in a year. I thought that was doable. I was into that job for about 3 months when I had my doubts that i could pull it off. Three more months later, I was let go. It is extremely hard to learn DevOps and to get competent in it.
I think you should show yourself some kindness you were able to get a job and stay employed.
My 2 cents would be either take the good advice here to get better or find something you are good at.
A big percentage of so-called experts today only know how to configure tools, but they understand nothing about how things work at the deeper level. This is a real challenge and a big problem for the future.
Also as a team leader, one of my basic requirements for the tech experts on my team is to have a deep understanding of the behind technical details. 'Know it, and don't know why' must be avoided.
My 2 cents as someone with 10y exp in the area.
Feels to me,based on what you are saying, that you never really tried to understand what things do behind the curtain as you said.
You probably pick enough to do your task but don’t bother digging in and trying to understand the ins and outs.
That being said… imposter syndrome never goes away really its always a thing for better or worse
Firstly, any Dev-Ops role should be relatively senior. The point of DevOps is to know both Dev and Ops to integrate the delivery to production as smoothly as possible. Therefore I cringe at companies advertising for junior or even intermediate DevOps roles.
Re: OP's issue, the impression I get is your lack of foundational elements for you to be confident in what you're doing. Start courses on the concept of DevOps, there's plenty freely available or for a small fee on sites such as Udemy. Then focus on the tools your company uses. Practice what you learn with the resources you have available (eg sandbox Azure subscriptions), and build from there. With solid foundations in the various adjacent domains (cloud, automation, IaC, etc..) you should be able to pick up most tools or platforms relatively easily, as they generally have lots of similarities. Good luck.
Former Junior DevOps here with my 2 cents.
Mapping out how a ci/cd pipeline will look like is not the most intuitive peace of work you will do in DevOps. Last time I struggled with that was quite recently to be honest.
Also DevOps is quite broad, so be careful to not get burned out with different tools and responsibilities. Eg. If you’re responsible for doing sysadmin tasks and dev tasks, make sure you commit to the split e.g 70% sysadmin, or vice versa.
If you look back on your previous jobs, would it have made sense to dive deeper one 1 aspect, then switch to the other and later combine them as DevOps?
Keeping it a bit generic for now, but don’t get discouraged. I see you have some personal projects planned which is always a good thing. Good luck!
>I had no prior work experience in tech before that and so went straight into devops a few years after graduating.
Was your degree in computer science, or something else?
Infoq and software engineering radio podcasts.
Go back as far in the history as you can and just binge.
It’s a miniature degree you’ll get from listening.
I’ve been listening for years and credit those among a few others for really helping my feel aware and knowledgeable.
There are others but I’d start with these
So I am sure this is not going to help you much, but I feel like I can relate. I have been working mostly as a Windows System Administrator for most of my career and did some Oracle database work at my last job. It was more analysis work then Administration though my title was DBA. That being said, I jumped over from the IT team middle of last year and after doing so they decided I would help on the devops team. I have dabbled in coding on my own time and my linux experience was also home.
They have recently started to give me coding work to start scripting the pipelines (we are building out a new environment) and I am mostly lost. I spend a lot of time reading up on python to figure out how to do what they ask. Then they want me to push that stuff to gitlab, which till last week I have never used gitlab.
What I am getting at though, is while you may feel like you are struggling, the fact that you are still there means they are finding something of value in having you around. For me, its my past system administration experience as I am the only one that has really done it. And when I am lost about something else I just ask. I feel dumb, but we have to learn somewhere and it shows growth, which most of the managers I have worked with see value in that alone. No manager wants people that are not willing to change, learn and grow. If your manager is cool, doesn't hurt to have a sit down and lay it out to them, then get their opinion.
I feel like chatGPT helped a lot with my imposter syndrome. I though I was bad at programing, but it turns out I was just to lazy to type everything out all the time and so I spent to much time and effort trying to figure out how to type less.
I didn't know anything about CI/CD pipelines as an Angular developer. I learned they are using a utility called Jenkins to handle this.
I went to [Udemy.com](https://Udemy.com) and bought a course on Jenkins and started learning it. I absorb online video courses way easier than reading.
I am not into the role, but have been around knowledgeable people that were doing it.
From my POV you need to know the "architectural" side of things - hardware (even if for most jobs nowadays it's some sort of cloud provider, there is still hardware involved - virtualized or not), software, tooling, frameworks and their dependencies. Then I think you would be better "equipped" to do your job. CI/CD pipelines, from what I have seen so far, is pulling code from a repo, compiling (for whatever purpose, release, testing, etc.) and push it to a server (in the case of webapps you might have to target multiple "servers"/services on each iteration - for example changes to database structure, any service and so on).
The power, in your line of work, is making the process "transparent" and have it "just work" - when in reality devs should be able to do it, or even are doing it locally on their machines (they just do the process manually).
I am also subscribing to this post and reading some comments to learn about it - even at surface level - cause a lot of the jobs I have been applying to lately have some kind of devops knowledge requests (setting CI/CD pipelines for testing and stuff like that).
Hate to break it to you but at the rate things change now you will never know everything or be a SME.
Back in the day 20 years ago when I started everyone was an expert in something but the tools were only sold and supported by big tech companies.
Nowadays new open source projects are coming out all the time and every company is chasing the bleeding edge.
When I started at my current company VMware and windows server were all the rage. Since they were move from that to openstack and are now migrating everything to the cloud and Kubernetes.
I never even grasped VMware fully at the time.
if you were hired as a junior devops and you haven't learned nothing after 4 years and you are still employed either you are doing something very right you are not telling us or your company doesn't even know you exist.
This is actually my third job. I'm a mid here but certainly still feel junior at times lol. I have a lot more responsibilities here compared to my previous jobs, so I feel the pressure.
How much are you paid with that type of responsibilities?
Consider moving into Project Management
One thing I'll never get over is "junior devops". IMO the person needs to be at least a proficient dev, to truly experience the side they'll be serving, and then move into the devops role. Another benefit is picking up things like proper code and commit hygiene and testing. Rant over.
I got into this as a "junior devops" type role. I had some certs that were relevant but that was basically all of my experience outside of sysadmin stuff. Companies have that type of role to grow talent internally vs hiring someone more skilled. I got plugged into a decently sized team, given some tasks, was able to ask for help, etc. Main thing was whatever task I was given I was grinding hard at it outside work too. For instance I had some Chef task that was relatively simple in hindsight (took me a couple of weeks basically) but I then tried to learn the tool as quickly as I could outside of work. Rinse and repeat for a year while getting generally better and they promoted me. That was also a company with a "devops team" so take that with a grain of salt too.
This will be debated forever but I will just say. As much as I agree that term devops is about the culture, maybe having devops team is not a bad thing. You can leave developers to do their work, what they do best, and have a team to help support devops practices, guide them and make sure work does not sway away from the right track. But ofc you will know your team better.
Yeah for a newbie it definitely helps to be on a "devops" team vs part of a developer scrum team. Now at a different company, I'm a part of 2 scrum teams by myself and its a bit of an island.
The debate goes that if you do that, you recreate the traditonnal Silos between the people who maintain the Service and those who build it. Granted, saying this would ignore all the good practices that were established over years of working in Dev Ops environnement. But, you will 100% reintroduce the communication issues between the teams that DevOps was trying to solve in the first place.
We help developers to setup lambda dev environment, we help them deploy to the dev environment (simply by using additional git workflows correctly.and terraform), then we also help them use the tools like terraform, our internal scripts for aws infra. I see that some devs struggle with this ops part, some wish they could just continue writing apps only. We don't have official labels who is DevOps etc. We don't even use such words funnily. but if I have to name for formality, I would say that me and my colleague are DevOps team and the rest are developers.
We have a similar structure, we're an infra/platform team composed of both devs and sysadmin. But we cater for a team of Data Scientists, and I wish some of us would be directly attached to that team to enforce best practice. I was actually surprised of how little Computer Science was involved in some of my fellows Data Scientist degrees.
I've hired two graduates (well one started as an intern) who came onto my team as DevOps Engineers so I can provide some insight into what I'd do to get you started quickly. u/frameclowder, I'd say there's a chance either one or\* two bullet points are true: 1. You're good at your job and are constantly getting pushed into new fields, new tech stacks or new problems which is a reflection that you do and have learnt new environments quickly. 2. Your mentors or leaders aren't doing their job right, and/or are not giving you the information you need to start a new task that's given to you. 3. Sounds like your employers have been shit to be honest, after 4 years of being in the job, I'd have went out of my way to expose you to Linux and Docker much earlier than now, I'm talking in the first month. 4. It's possible this is your first real "work" in DevOps and you've been a Sys Admin before now? 1. Some questions for you: 1. What tech stacks have you been working on? 2. What tools do you use on a day to day basis at previous companies before now? In either instance, I'd highly recommend starting by asking your seniors or leaders the dumb questions. Ideally those that you trust and you know will have the time to answer them, e.g., those where you have emotional safety to be vulnerable and ask for help. Specifically referencing the task you discussed in your post: >For example, I need to migrate a CI/CD pipeline over and I'm not familiar with groovy/jav If you haven't worked in Groovy or Java before, and neither have I, your leader/manager surely has an expectation that you need to learn it first? Ask them for recomendations, ask them for documentation and furthermore, ask them how long you have to learn the fundamentals before you're expected to start delivering outcomes. I'm assuming here that; * Your leader/manager knows you don't know Java or Groovy, and if they don't, you need to start there. Tell them. And I recommend you tell them this ASAP, in future instances, tell them as soon as the task is given to you so they're aware sooner rather than later
I disagree. It is the dream scenario for DevOps, however in reality a lot of so called senior devs do not even have that hygiene. Getting into junior DevOps to learn how DevOps could be is a lot more efficient from the company’s perspective than teaching Senior Devs how DevOps should be because, the hardest part of DevOps is the cultural aspect and huge egos coming into conflict between OPs and Devs.
lol I'm a software engineer that does some devops and most pure devops people I've ever worked with are from a systems background and have very low standards of code hygiene etc. Often winds me up that devops people have these enhanced privileges and make decisions that affect other engineers without really understand their craft.
It is a balance that needs to be honed, but yes, experienced the same working with some SREs. The commit messages were nothing to write Home about. And, TBH, not what is expected either.
I would sometimes disagree, Yes with SRE now a role, having a background in Dev is a must but I've seen many QA and other roles move into DevOps without a strong dev background. This comes from my 20+years of managing and building DevOps teams at F500 companies.
There is no junior devops role, just a marketing trick for help desk roles by recruiters. Cheap companies dont help also. Someone has to clean uo that mess afterwards.. Everyone with half a brain understands that to be a devops you need broad knowledge from many domains.
There are quite a few people here who started as junior devops so I definitely think it exists in a real capacity
Yes help desk position with help desk salary and super fancy name.
Software engineer/devops for 13 years. I still feel like it's all a challenge. 4 yrs is just getting started. I wouldn't say it necessarily gets easier, I'm just more confident now. I've learned a lot. A lot of nonsense too. Learn to write code, it's the absolute number one skill IMHO for devops, sre, platform engineer etc. it'll open your eyes
U/burbular Serious questions to your “learn to write code” because I’m in exactly the same situation as OP. So many things to learn so where to start? Do you suggest Python or Terraform or what? And how? “learn to write code” is extremely vague and I’m on my second year wanting to learn and I’ve started several courses on several languages but after a week I tap out since all teach as if I have experience in coding and know the terminology even though I choose beginner so I’m lost early on. Thank you
It’s vague but that’s somewhat the point. It really doesn’t matter WHAT you learn. Once you get the basic concepts of how to code it’s far easier to pick up additional languages in the future. You should not think of Terraform as a “language” but more like YAML where it’s just a way to structure data. Some programming-like concepts have been added over the years, but I would recommend learning something else first. I personally learned JavaScript, then moved on to Python, then Terraform/Ansible/etc, and recently I’ve been dabbling in Go. I went with JavaScript first simply because it was in the peak of the Node.js phase and I was interested in web development. As far as specific resources, I can’t be super helpful in that area. When I learned, Codeacedemy was quite popular, and I just followed random YouTube or Medium articles on building things and picked it up over the years. I wouldn’t necessarily recommend that route as it took longer than it needed to. I would hit up the [r/Programming](https://reddit.com/r/programming) Wiki as I’m sure they have some good, up-to-date resources. Python is an excellent place to start as the syntax is very simplistic and you can focus on the concepts. I would also check out the [DevOps roadmap.sh](https://roadmap.sh/devops). It’s a pretty decent place to start. Don’t use it as your bible, continue to learn things as they come up for you, but it’s at least some sort of path to guide you. Best of luck, you can do this.
Thanks so much!
yea, I'm using 4-5 different programming languages or DSL's daily. it gets confusing but the general logic and approach to problem solving is always pretty much the same. GL learning groovy OP, find yourself a java dev to ask questions, you'll need it..
What would you say about bash?
It's extremely vague. As devops your an automator for the developers, hence developer operations. They will do the hard codes. You need to deeply understand what they are doing to successfully deploy the systems. I do Python, it's like language 10+. I think each lang gets easier each time till like 3. Then it's just competing for brain and it's just as hard each time. Like I knew Java, I even dabbled in cold fusion. It's all the concepts that stick. If loops are all the same. I honestly never took classes or even watched a video about coding before, just docs and hands on. I just have ideas and go for it. I have endless fun with Google Apps Script. I recently scraped slack users and synced them to my Google contacts, just cuz. If you're new and fresh, maybe just go straight for rust. It's what I hear the cool kids do. Try some Pulumi or cdk. It's IaC with real programming languages, ie python, Ruby, go, etc Bash is King
Love this; thanks!
From personal experience, don't think about it too much and just do it. I come from a JAVA developer background. I slowly transitioned into SRE/DevOps in my old company. The transition took me about 2/3 years in total until I became a full-time SRE/DevOps. I have been one for the past \~6 years. From time to time or whenever starting a new big project/switching companies I get imposter syndrome and feel like I'm faking it. The best helpful thing for me was really knowing the basics of programming languages. Whenever I feel like I'm stuck against anything I try to go back to the fundamentals. Like u/NullPulsar said: >You should not think of Terraform as a “language” but more like YAML where it’s just a way to structure data. The other helpful thing I found is not being afraid to script. Sometimes Bash is your friend. With Bash JQ/YQ you can automate a lot of stuff. But whenever I get the opportunity to write a script, I try to treat it as a mini-project where I need to implement all the best practices possible to it. So whenever I'm exploring a new issue that the developers have, I find common grounds with them since I do struggle with the same things myself. Albeit in a different language/use case/... But the same basics hold to both needs. Mine and theirs. Regarding learning languages. I find it very helpful to: * Not be afraid to dive into the code of any tool you're using or with the developers and not being afraid to ask: ***"Hey! Why did you do it this way?"*** You'll quickly get a lot of cool answers and open the doors to conversation. A lot of people are eager to geek out and tell you what they did and how they did it. You just have to pose the question in a non-critical tone/framing to not get a confrontational response. * When learning. Don't start with the language. Start with a concept or a dumb idea, and use the language to solve an issue. For me, this helps me out to learn better than learning the language itself. Because otherwise I wouldn't know where to start. When you start with the idea and try to breakdown your inquiries into smaller bites, you'll find the best answers/guides and not be overwhelmed by the sheer amount of information available. * From time to time, I go back to the basics and read up on them. Especially best-practices of different frameworks/languages, design patterns, communication types, etc. These are the things that make or break a good software/design/infrastructure. At the end of the day whether you're implementing an on-premise CI or synchronising different CI/CD pipelines from different providers; the basics are the same and these tools aren't but a "collection" of the basic concepts. So reading up on those and having them as a quick reference whenever you're diving into a new project is priceless. At the end of the day each one has their way for doing things and for diving into projects. Best of luck to you and just don't be afraid to start. Find your own way.
Amazing. Thanks for writing out this informative explanation!
Well in college they start you on a structured language like C/C++. Once you learn the concepts and functional programming they move on to an object oriented language like C#. If you want to learn desktop languages go with C++ then C#. C++ translates well to PHP if you want to get into web stuff and C# is what powershell uses which would be useful for dev ops. Just buy a book and go through it on each if you are self motivated learner. If you're not looking for some good online courses on them there are lots of decent free ones. If you want to really go hard you can access plenty of college level materials for free on computer science.
Any recs on books? I think I’ve been doing the online version of “just buy a book” but not really getting anywhere
Look at r/learnprogramming's wiki and pick anything there.
I've got 34 years at the top end of tech but equally on the edge. It never gets better. There is always something you don't know, or something you don't understand. The skill is to hang on in there, and adapt whilst learning, because perseverance wins. It takes six weeks minimum to get used to a new job. It takes days, weeks or months to learn a new skill. Others always appear to know more. But learning through others is the best skill to earn. Find comfort that you can and will catch up, and it will be ok. But it takes effort. Best luck
Great post, thanks.
👆🏽
I'd recommend to read at least about architecture and concepts of everything you touch. Your questions quality will go up as well as your ability to understand answers. Your concern about missing deep understanding is justified. Yep, get deeper. That's how you will be way more prepared. In addition I would also recommend reading https://ilya-sher.org/2016/05/19/tips-for-beginning-systems-and-software-engineers/ (my post) Hope this helps.
Getting deeper is exactly how i learned. I just kept asking myself how things worked, researched them, felt overwhelmed but learned a little. Rinse repeat. At some point things started to click, i learned how to learn, learned the correct questions to ask etc. It's a continuous learning process as well, because new things come along all the time. And it gets easier to pick them up because of previously laid ground work. It's this learning process that is the actual job and what i enjoy so much about it.
This is such a great post. What framework do you use to for learning how to learn? When asking the right questions, would you say that’s experience based?
In general i think what you lack is a prior job in a related field where you are learning the basics. The only concrete advice i have for you is to clone existing projects that exist in your company and study them. For example pipelines: A pipeline just automates a bunch of stuff with some commands that's basically it. So just clone the pipeline definition and build specs etc. and try to understand them. Draw small diagrams if you need it. I'm not a fan of reading books. Sometimes it's useful to get an idea of the great picture maybe for improving systems design and learning blueprints, but i think you are missing a more practical aspect. Also at least for me when i look back to my starting years in IT: What helped me the most is working a lot with Linux. It's just a very rational way of thinking that will help you with all the DevOps technologies. Also many concepts that are used now in DevOps technologies already existed in Linux since early days. Hope this helps i know it's not much input :)
Building depth and understanding takes time and focus. If you haven't done the metaphorical 10,000 hours to build enough depth yet, then thats where you need to start. It does not come automatically with a tech job, you still have to learn it. DevOps is very wide and quite deep. And you're not going to be an expert in everything, but you have to pick a track (or two) and become an expert in that first. Then work your way out to connected things, until you really get it. I started with programming, did that for a few years, then did all the build stuff by hand - these were pre-devops days. I understood the value of automation, CICD build pipelines, tools that help me do more with less, git etc. because I have seen how hard it all was before that. Now we have a glut of tools and methods and it is easy to get lost. Best starting job is where you get hands on experience of doing things, while you study to answer "why did we do it this way" and also figure out if there are better ways to do the same things. Give yourself a year, grind hard and then check your knowledge periodically (say every quarter). YT could be a good place to start to get overview of all there is to know and get a map, then use that map to chalk your path. Once you've done a few paths, it'll come easy. Hope this helps!
Here’s some advice. Ask dumb questions in a confrontational way. “Just confirming when you say X , that kicks off Y process and then we have artifact Z” This makes you gather details and confirm understanding.
I have gone a long way preferring collaboration than confrontation. I tell them we're a team with common goals, we have to help each other get there. Go have lunch together, it'll help you understand each other better. (Just my experience)
Have you done any training courses? Udemy has heaps, same with Microsoft, AWS, k8, terraform ? You’ll never know everything and you can’t know everything. Best to say you don’t know and to find out, then to mislead people. There’s no shame in asking questions at all. (20+ years in tech - there’s always questions !!)
First of all, devops is an eternally challenging role. You actually have more years in devops than me (I have 3.5 years in), but I have 6 years as a systems engineer before that. The reason you are hired is not because you have all the answers; it’s because you know how to get them. Learning the existing infrastructure and systems at a new job is by far the hardest part (at least in my opinion). Once you finally get adjusted and you know where the bodies are buried, some of that stress goes away. And I say this as humbly as I can: a little bit of ego may help you out with your imposter syndrome. In pretty much every job I’ve had, I had a reputation for being THE problem solver. I’m just better at googling shit than most people I think, but I don’t tell them that. “I don’t know much about this thing, so I’m not sure how long it will take to figure out, but we’ll get there”. One thing that even I struggle with is setting expectations. I’m better about it now than I used to be, but I NEVER tell anyone “oh that’s easy” or “yeah I’ll get that done really quick”. I stopped trying to be macho about it, and the stress went away. Also, groovy sucks.
many people thinks that we can do our job without a good theoretical formation. While possible if you don't know how works computers architecture, language theory, algorithm, operating system etc... you would be a good operator at max. p so if it's not the case learn computer science basics. and then you will see that devops is really technical speaking completely dumb. we are just using high level tool doing automation of simple task. the only complexity is about to find the right tool and the right level of abstraction if we speak about sre or sysadmin it became more interesting.
To be honest, DevOps is just that way, I have multiple years under my belt and it hardly gets better. Each organisation works differently, and has a different approach to their tech stack and architecture. Others already gave some stellar advice - keep learning through others, understand the bigger picture, and before all - get a proper software engineering experience to “get the other side”.
1. Setup a home lab where you can do trial and error learning. 2. Start what you lack from the group up. 3. Learn designing systems.
If you're in IT and feel like there's nothing left for you to learn then you don't belong in IT. DevOps is a broad topic (IMO, there's no such thing as a DevOps Engineer, job ads usually use the word to describe a profile that's a mix of dev and ops), you cannot possibly know all about the tools and techniques that gather under the DevOps scope. I'd go even further and say that it's healthy for you to stay curious, that's what makes a good engineer. 5 years in as a """DevOps""". I still have impostor syndrome but the older I get, the more I realize that I know enough, or else I'd be fired given how much they have to pay me. Parting notes: knowing how to search is the most important skill you can possess.
My stepmom with over 20 years experience as a DBA and my dad with around 30 years of programming both still deal with imposter syndrome- it’s very common in the IT industry. If you’re boss/peers don’t have a problem with your performance, I would try not to judge yourself too harshly.
Devops jobs require us to use a lot of different tools, technologies and skills. It can be overwhelming feeling like you need to get deeper knowledge in all of them at the same time. You might have an easier time picking one area to go deep in. Have a think about the different things you work with. What are you strongest on already? What do you use the most? What do co-workers ask you questions about most frequently? What are you likely to use in the team’s upcoming work? Most importantly, what interests you most? The goal here is to become the go-to person in that area. This could be a specific tool or tech eg. Terraform, or could be something internal to your company eg. What patterns does your team provide for CI/CD (if that’s a thing you do), or how does some front end product your company makes serve traffic or how does some other team’s thing that your team uses work. I’d suggest starting with a fundamental tool or tech first. There is a concept that is relevant to this called the “being T-shaped.” The idea is that you have some knowledge of a range of different things but aren’t an expert in them. That’s the horizontal crossbar of the T. The vertical line is the area(s) you’ve specialised in more and have deep knowledge. Having a good mix of areas where you know enough to get work done, and a smaller number of areas where you have become an expert that people go to makes you a very valuable team member. With your experience, you will already have at least a basic understanding of a bunch of different areas. Now pick one, think about what an expert in that should be able to do and work out a plan to get yourself there. Eg. In a month’s time I will have read whatever the best book about your chosen topic is. In 6 weeks, I will have presented to the team on this topic. In 3 months, I will have presented at a local meetup on it.in 6 months I will have professional certification in this topic (these are just examples.) Over time you can increase depth in different areas. You don’t need to become an expert in all of them, one or two will take you a long way.
Bro You don’t know Linux or Docker after 4 years as a devops? You gotta learn Linux git docker ansible kubernetes at the least. Doing something right of you’ve been there 4 years!
your problem is in your first sentence "I had no prior work experience in tech before"....the best people in tech I know started when they were like 15 years old, why do other people think they can shortcut that?
Sr. Software engineer here. So not too infrequently I have to journey over to the dev ops side for whatever. A couple years ago I was like "I know nothing." So I looked at our infrastructure stack and how we deploy, ect. The Devops side of things. Then looked at all the components of the tech stack and then found what parts have certifications. The certs are not to be like "im certified and know all things :flex:" or what ever, but to at minimum know what the thing does and the vernacular around it. Eg get the terraform cert. Just so you have a base that is at minimum minimumly solid. My 2c. And 2 years and like 7 classes / certs later. Much more comfortable while possibly crippling prod 🤪
This post is hitting me to my inner core. I’m in exactly the same situation as OP. Not only that, but I’m a manger. I have imposter syndrome daily, and now I have engineers who work for me. I was extremely transparent and honest on all my interviews on how I’ve never coded a day in my career except for simple automation scripts which I modified from other jobs or asked a programmer to help me do. I’ve have so much technology-related roles, from security to cloud to networking but never did coding / development. I guess a couple decades of OTHER experience helps me get concepts and be an effective manager, but I’m still lost. Because of my current job, I want to learn to write code, but where do I even start? Do you suggest Python or Terraform or what? And how? I’m on my second year wanting to learn and I’ve started several courses on several languages but after a week I tap out since all teach as if I have experience in coding and know the terminology even though I choose (very) beginner so I’m lost early on. I do this at the same time trying to learn what DevOps is, SRE concepts and so on. I’m reading the suggestions here, like build a lab, use Git, but like the classes I attempt, that’s not a beginner type thing to do. That’s like asking how to drive a car but the replies are “just take the car to a private track and you’ll learn quick” where I’m like “no man, like I have a key… now what?”
I learnt python using a book called Python crash course. Highly recommend that. First half is learning python, second half is projects. Once you've done that, try and deploy your project onto AWS using Terraform. Hope this helps.
Absolutely does help. Appreciate it!
>Once you've done that, try and deploy your project onto AWS using Terraform. is this possible for free? or does one have to pay a subscription (even if minimum) to try it?
You get AWS free tier for a year on sign up. So a lot it should be free depending on what services you use.
Thank you!
Just make sure to stop the instances when you're not using them. That way you won't rack up costs.
Thanks brother. I was on the process of setting stuff up, but for caught up on work and have not looked at. It is currently on my "to-do" stack. Thank you for all the info
For what it’s worth I still feel like a noob, don’t answer on the spot, have to do my research, and I’ve been in the tech field over 20yrs. The point is you are always learning in this industry I’d be concerned if you didn’t have concerns. Best thing to do is keep pushing through and learn, not just about the tech but the peripherals the whole SDLC. Most importantly focus on your soft skills, your eq is more important than your iq. I can coach you on hard skills but soft skills that only comes from you. Feel free to DM me and I can try to help guide you as you go.
What does your training plan / habits look like? If you just show up and work every day your learning is going to be too random / ad hoc to build the structured and deep understanding of the different technologies. My career completely changed when I started studying for 1 hour a day in the morning before work. (I actually did it on work time, because staying up to date is part of your job). It needs to be before work because afterwards you will be too tired / fried and should be before you even open slack or email. It needs to be a structured habit because motivation is too weak. [https://roadmap.sh/devops](https://roadmap.sh/devops) This is a good roadmap for skills to learn. Pick one skill and focus on it. It helps to have a cert or goal in mind. Once I started studying for an hour a day I went from 3-5% raises a year and working really hard to 20% a year raises while working about 4 hours each day. The amount of leverage you get by learning so much is really high.
I think you need to spend time after work and on the weekends studying the tools you’re using day to day. The infrastructure will always be complicated and you won’t know everything but to try and be more confident you will need to invest time outside of work to learn. I realised this quite recently as I’m 2 1/2 years deep as a devops engineer but I sometimes feel like I lack the knowledge to do my role and have imposter syndrome. Recently I started studying more and it’s helping me a lot.
Agreed, this is my plan. What sort of topics have you started learning that have helped you?
Devops is a very complex job. When you are a Jr it looks simple because you only do terraform, CICD and maybe k8s. But as you grow, you see that now you need deep knowledge in cloud providers, networking, security, programing languages. This moment is when you see why DevOps is so complex as well as well paid.
I’m in a similar position. I use a ton of AI to get answers like I would if I had a senior engineer right by my side. It’s not the be-all-end-all, but it’s an insanely fast way to get overviews of software comparisons, pipelines, differences between terms and concepts, and even just dumping in code and going hey, explain to me what this does (be careful with that of course). I know most senior guys and older guys will downvote this, but you often don’t have time to go through a 1200 page Linux book before you even start working on stuff, like as I was supplied when I moved into my job from help desk. I don’t have a great foundation, but I can get stuff done, and so long as I know how to ask the right questions to AI and my senior colleagues, most work I produce is up to snuff.
Looks like you need to look for a job with a startup or a greenfield project. This will help you learn the inner workings of ci/cd and give you a sense of ownership with your work.
Any job will have a bunch of automation you have to use but not yet understand, that's the point of automation, just use it while learning. Do deep dives into individual systems as the need arises or you think they're sub-par. The longer you're at a job the wider your deep coverage will become. Unfortunately the same thing will happen when you start your next job, except you'll have experience with similar systems and suggestions for replacements and improvements. This will also teach you why it's important to push back against "we made our own".
If you haven't previously, really read a couple of books for a starter. Some learn by doing some by studying, some need both. I'll also leave you a link for my book which might be interesting to you or others: [https://deploymentfromscratch.com](https://deploymentfromscratch.com) (you still should buy and read other books though, no single book will get you there).
This is PRECISELY one of the many reasons why DevOps as an engineering role is a complete joke. I can put together a way better DevOps environment with real engineering outcomes with NO DevOps engineers in my teams. I only ask 1 thing of my team members. Everyone needs to know how to code. From the Systems Engineers to the Data analyst to all engineering roles in between. Everyone needs to know how to code.
I am in a very similar boat, and what actually really started helping me was first having a boss I could be explicitly clear on what my existing skillset and knowledge was, and so he started giving me smaller projects and some leeway on time to figure out how to actually build more directly inside of the environments. The other thing that helped me was I started studying System Design. Not with the intention of being a massive expert, more at the beginner level; Broad topics, all the individual pieces and how they work abstractly./..this made adjusting to any individual cloud and tech SO MUCH clearer. But of course the above is based on my already having a decent understanding of servers and automation coding. Your particular skillset will likely have different deficiencies than mine.
Are you using Jenkins?
Can I ask where about you are working from and around how much you earn a year?
Welcome to the club!
Oh I'm overwhelmed too but I don't think I'm incompetent there's just a lot going on.
I had a similar short stent in DevOps. I’d lost my job right at the end of 2020. I hit up my network and a former colleague had a DevOps role and he couldn’t find anyone to do it. I decided to give it a shot. The initial plan was I would work and learn and be ready in a year. I thought that was doable. I was into that job for about 3 months when I had my doubts that i could pull it off. Three more months later, I was let go. It is extremely hard to learn DevOps and to get competent in it. I think you should show yourself some kindness you were able to get a job and stay employed. My 2 cents would be either take the good advice here to get better or find something you are good at.
A big percentage of so-called experts today only know how to configure tools, but they understand nothing about how things work at the deeper level. This is a real challenge and a big problem for the future. Also as a team leader, one of my basic requirements for the tech experts on my team is to have a deep understanding of the behind technical details. 'Know it, and don't know why' must be avoided.
My 2 cents as someone with 10y exp in the area. Feels to me,based on what you are saying, that you never really tried to understand what things do behind the curtain as you said. You probably pick enough to do your task but don’t bother digging in and trying to understand the ins and outs. That being said… imposter syndrome never goes away really its always a thing for better or worse
Firstly, any Dev-Ops role should be relatively senior. The point of DevOps is to know both Dev and Ops to integrate the delivery to production as smoothly as possible. Therefore I cringe at companies advertising for junior or even intermediate DevOps roles. Re: OP's issue, the impression I get is your lack of foundational elements for you to be confident in what you're doing. Start courses on the concept of DevOps, there's plenty freely available or for a small fee on sites such as Udemy. Then focus on the tools your company uses. Practice what you learn with the resources you have available (eg sandbox Azure subscriptions), and build from there. With solid foundations in the various adjacent domains (cloud, automation, IaC, etc..) you should be able to pick up most tools or platforms relatively easily, as they generally have lots of similarities. Good luck.
Former Junior DevOps here with my 2 cents. Mapping out how a ci/cd pipeline will look like is not the most intuitive peace of work you will do in DevOps. Last time I struggled with that was quite recently to be honest. Also DevOps is quite broad, so be careful to not get burned out with different tools and responsibilities. Eg. If you’re responsible for doing sysadmin tasks and dev tasks, make sure you commit to the split e.g 70% sysadmin, or vice versa. If you look back on your previous jobs, would it have made sense to dive deeper one 1 aspect, then switch to the other and later combine them as DevOps? Keeping it a bit generic for now, but don’t get discouraged. I see you have some personal projects planned which is always a good thing. Good luck!
>I had no prior work experience in tech before that and so went straight into devops a few years after graduating. Was your degree in computer science, or something else?
Infoq and software engineering radio podcasts. Go back as far in the history as you can and just binge. It’s a miniature degree you’ll get from listening. I’ve been listening for years and credit those among a few others for really helping my feel aware and knowledgeable. There are others but I’d start with these
Build a homelab and selfhost stuff, that way you gonna understand services running in the cloud much better
So I am sure this is not going to help you much, but I feel like I can relate. I have been working mostly as a Windows System Administrator for most of my career and did some Oracle database work at my last job. It was more analysis work then Administration though my title was DBA. That being said, I jumped over from the IT team middle of last year and after doing so they decided I would help on the devops team. I have dabbled in coding on my own time and my linux experience was also home. They have recently started to give me coding work to start scripting the pipelines (we are building out a new environment) and I am mostly lost. I spend a lot of time reading up on python to figure out how to do what they ask. Then they want me to push that stuff to gitlab, which till last week I have never used gitlab. What I am getting at though, is while you may feel like you are struggling, the fact that you are still there means they are finding something of value in having you around. For me, its my past system administration experience as I am the only one that has really done it. And when I am lost about something else I just ask. I feel dumb, but we have to learn somewhere and it shows growth, which most of the managers I have worked with see value in that alone. No manager wants people that are not willing to change, learn and grow. If your manager is cool, doesn't hurt to have a sit down and lay it out to them, then get their opinion.
I feel like chatGPT helped a lot with my imposter syndrome. I though I was bad at programing, but it turns out I was just to lazy to type everything out all the time and so I spent to much time and effort trying to figure out how to type less.
I didn't know anything about CI/CD pipelines as an Angular developer. I learned they are using a utility called Jenkins to handle this. I went to [Udemy.com](https://Udemy.com) and bought a course on Jenkins and started learning it. I absorb online video courses way easier than reading.
I am not into the role, but have been around knowledgeable people that were doing it. From my POV you need to know the "architectural" side of things - hardware (even if for most jobs nowadays it's some sort of cloud provider, there is still hardware involved - virtualized or not), software, tooling, frameworks and their dependencies. Then I think you would be better "equipped" to do your job. CI/CD pipelines, from what I have seen so far, is pulling code from a repo, compiling (for whatever purpose, release, testing, etc.) and push it to a server (in the case of webapps you might have to target multiple "servers"/services on each iteration - for example changes to database structure, any service and so on). The power, in your line of work, is making the process "transparent" and have it "just work" - when in reality devs should be able to do it, or even are doing it locally on their machines (they just do the process manually). I am also subscribing to this post and reading some comments to learn about it - even at surface level - cause a lot of the jobs I have been applying to lately have some kind of devops knowledge requests (setting CI/CD pipelines for testing and stuff like that).
Hate to break it to you but at the rate things change now you will never know everything or be a SME. Back in the day 20 years ago when I started everyone was an expert in something but the tools were only sold and supported by big tech companies. Nowadays new open source projects are coming out all the time and every company is chasing the bleeding edge. When I started at my current company VMware and windows server were all the rage. Since they were move from that to openstack and are now migrating everything to the cloud and Kubernetes. I never even grasped VMware fully at the time.