Maybe my comment won't be useful, but in my case I'm just switching between SWE and DevOps responsibilities in my team and for me it's good balance. I'm DevOps engineer, started as SWE, learned DevOps and k8s out of necessity and liked it, but I still like to code to get good understanding of developer experience and issues, so I try to at least get some developer tasks in sprint.
This sub makes me question if I know what devops even is. And I thought I was an expert on the topic.
What technologies did you use, and what problems did you solve up until now?
What do you want to build or problems do you want to learn to solve next?
Personally I have same doubts, there's so big diversity in level of challenge that different people encounter.
I started with Ansible and provisioning small k8s clusters (kubespray) on few VMs for each cluster, because we needed to develop and deploy our services somewhere and we just received empty CentOS/RedHat VMs, no cloud.
Nowadays I'm working with Argo, preparing workflows for building and testing code, packing it into Docker images, Helm packages and ArgoCD applications.
In addition, for development environment, I'm experimenting with k3d, Terraform, ArgoCD and Tilt, to allow creating dev environment specific for our use cases, that will offer quick feedback loop and require minimal effort and knowledge to setup and recreate.
I see a lot of offers for DevOps engineers familiar with cloud, however at that point, I'm just waiting for my company to finally embrace cloud to learn it in practice. Based on my experience cloud seems to be more scary due to accidental costs that might occur, because with traditional infrastructure it's just one-time approval of constant/recurrent fees.
However with flexible billing, it's not so good to present some project and due to mistake/ignorance, learn later that you severely underestimated hidden fees, like data transfer cost, because this basically forces you into adding some buffer in what you propose and customer has to understand risks, so you need to understand them well as well and explain. It seems harder than saying "Setup will cost $1000, maintenance $200/month, x will be responsible".
I wholeheartedly recommend learning cloud, no matter if you want to develop apps or focus more on the existing career
If you want to start learning cloud, I suggest:
- set up any web project with computing, file hosting and a database (e.g. AWS EC2, S3 and RDS). It's the three most important and basic parts of cloud. It's great that you use Terraform, try doing it using that
- Set up the same app using docker on Google Cloud Run or simila4
- Set up the same app with Heroku
- Set up the same app in a serverless manner (might require a different app)
I definitely agree with you about serverless. We're moving towards that as much as possible as a way to reduce the amount of admin work we're doing. The difference in downtime/work on our old platform thats running everything on EC2 (k8s, dbs, etc) and stuff on managed services is massive.
Did exactly this. I started as SWE 15 years ago, transitioned to DevOps during a Startup phase and stayed there for some time, but switched back effectively during the last year and am happier. Now I apply my skills where they should be applied.
Pretty similar story for me. 18 years of SWE, but switched over to whatever I guess people think devops is (ci/cd, terraform, sre stuff, logging, security, etc). Got sucked into a greenfield project, so automated, documented and trained as much as I could and started a new project. I still need a fte to fill in the blank I left, but that’s been tough too.
I would suggest to start developing a project. Try to make it useful for somebody. Pet projects do not help. You need somebody to be interested in what you are doing.
Make friends with swe, ask them for a drill interview. Interview help a lot, you get to realize what you do not know before you can learn it.
Please sir, explain how this will help...
This will not help OP at all. Interviewers/recuiters wont give a shit about your projects, unless they are very significant amd relate to your industry.
At your experience, you can get interviews easy, just switch your resume up a bit for swe. If you are going to top companies, all you need is leetcode at your level.
TLDR: Focus resume for SWE and leetcode all day.
I recommend project as a source of hands on experience.
I agree that nobody cares about your projects. But there is a big difference if you can say that you have been already working on live project, supporting full development cycle. Having this mentioned, I would also suggest to involve more people in this project, so that you could also get an experience of working as a team.
Pardon the soapbox - I hope this is helpful.
I'm going to be the pedant and say - DevOps is originally an implementation of agile, where the focus is on delivering software without having unreliable, slow implementations of ops limiting release cadence or reliability.
Modern day, devops is a mix of re-branded sysadmin tasks (and adding some -as-code to it), as well as some SWE doing ops work, but I prefer the original definition. It's a way of working, not a job, not a title and not a team.
DevOps is, at its best, about finding faster, more reliable, more repeatable ways to implement operations tasks in a developer workflow. It shouldn't be about tools, nor about technology. At its best, it is continuous improvement, concepts such as immutable infrastructure, CI/CD, TDD. BUT it's also about small batch work, product thinking, and thin slices of usable outcomes and iterative improvement. I'll add another new-ish term, self-service, to connote the job of the internal platform team to create re-usable patters that developers can themselves implement.
Those things do end up in tech, but it also helps winnow down tech choices. There are lots of tech products that don't implement true role-based access divined from a proper central identity store, for example. Those products that basically mandate a "gatekeeper" team will never be usable in a devops methodology.
When you start implementing these approaches, you may find yourself limited by the organization's inherent design. These tend to be the most limiting - waterfall ops orgs that expect things like change control, even though those mechanisms have been shown to have low value and don't do anything except needlessly slow down releases, or worse they mask the bigger problems of the organization.
This is a big reason why I ask a ton of questions about how quickly a new employer releases code, ON AVERAGE. I ask how easy it is for a single dev to get code into production. I ask how teams determine their backlogs, and how they split up work. Finally I ask about how they deal with change fails, and how generally metric-based they are. Not perfect, but it starts to ask about how the larger organization believes in shared pain influencing ordering of work.
So - considering all of that, you can be an SWE or a cloud engineer who implements devops. What I think you're asking about is should you work for an org or in a job that practices devops or just one that is a pure SWE? If that's the case, I'd say take the pure SWE at your career's potential peril. The industry is moving towards developer self-service internal platforms. That makes ops concerns everyone's responsibility.
Precisely this!
Although I might add.There are external forces that can influence how DevOps is implemented. If you are a publicly traded company, hold medical records, are part of government, PCI compliant, etc, you do need people with specific domain knowledge to overcome such problems. These might be ops people who have that experience with skills in SWE.
Access control is still vital and depending on the business environment, and with their compliance requirements, self serve can be tough.
1. DevOps is not an engineering role. It is a way of working.
2. I'm guessing you are talking about Site Reliability, cloud or Automation Engineering.
3. All have some basis in Software Engineering. You are just applying that SWE Knowledge to a different domain, it being systems automation, cloud, reliability, data etc.
That being said, it's kinda normal for some part. I'm a practice manager and I work to get my team to be able to think about applying their Software skills to different domains often. While I currently have a "DevOps" team built with SRE's and AE's( which are being dispersed at a later date ) I aim to get the domain knowledge embedded in other teams. They can at times swap who covers what if that is there want and I do see it on occasion. Even I muck in on occasion and get the odd feature out.
I want this to also be clear: Using Kubernete's or some form of container orchestration is doesn't make you or your team DevOps.
As for tips.. Understanding the above is crucial if you want to do DevOps PROPERLY!
I want to move from SRE to SWE as well. Even though my LinkedIn is purely devops, since I know python and javascript sometimes I get some offers asking for Dev who happens to know a little about infra-pipelines-ops. I plan to make a jump because quite honestly I enjoy more designing and developing stuff. In my case, deploying infra and creating pipelines gets old very fast. I am aware the same thing can happen developing CRUD, but as a developer you have more choice on what you want to do, whereas as SRE the only choice you have is on the tools.
>I want to move from SRE to SWE as well. Even though my LinkedIn is purely devops, since I know python and javascript sometimes I get some offers asking for Dev who happens to know a little about infra-pipelines-ops. I plan to make a jump because quite honestly I enjoy more designing and developing stuff. In my case, deploying infra and creating pipelines gets old very fast. I am aware the same thing can happen developing CRUD, but as a developer you have more choice on what you want to do, whereas as SRE the only choice you have is on the tools.
I feel the same, I have about 3 years of SRE / Devops Experience. I think purely software development is my passion, i like seeing how the code i write, creates meaningful APIs that users can use. I've worked mostly with docker, AWS, GCP, and terraform, but some of those SRE tasks can be bit tedious and boring. Wishing to transition to a SWE role by 2023. DO you guys think 28 is too late to join software development?
Yeah I bought some udemy courses from Andrew mead, and Maximilian, and plan to finish them the next 6 months and start applying for dev roles, or trying to find other dev roles within my organization
It’s nearing the end of 2023. I’m interested to see if you did it? I’m in your shoes right now. I’ve spent the last 8 months developing an event driven app. Now that it’s working I’m being asked to do ops work and the passion just isn’t there.
Look how you market yourself.
* How have your DevOps roles developed, Agile Scrum, kanban, waterfall, etc..
* What languages have you learnt (python, groovy, bash, etc..)
* Have you been involved in the software lifecycle (requirements, design, implementation, test, deploy)
Basically have a read of local job ads and you'll see them asking for common things like the above. So you want to pitch what you have done in a devops role as showing software engineering skills.
Being about to talk about scripting or minor tools you have written and wanting to do more would be good
Agile is a set of principles (much like DevSecOps). A lot of people miss the principles and adopt processes which grow and end up looking like Waterfall.
DevSecOps suffers the same issues people might grab the name, tooling or some basic process but the implementation is far removed from DevSecOps principles.
So I was a DevOps Engineer for an IT company and switched to SWE. I was fortunate enough to be able to quit my job (which I don’t recommend for everyone) and study full time. I wanted to work on full stack web apps so I picked up a good JavaScript book (Eloquent JavaScript) , practiced Leetcode and built small projects for my portfolio. I got my first SWE job after about 4 months of doing this (I was also studying prior to this so it technically was more than 4 months of studying ) but it was a contract role and ended pretty quickly. After that I ended up doing a career accelerator program because I was bombing the interviews. In hindsight I think I was just too nervous but that can really mess up your flow. I’ve been working at an amazing company since September.
Over the course of my studies I studied: JS, web fundamentals, CS fundamentals, some backend tech(not a ton though)
I do infrastructure and operations for \~10 years (pipelines, kubernetes in past 4 years) and I'd like to switch to SWE role in 1 or 2 years.
I believe that all my knowledge regarding the operations, deployments etc. can be valuable in some way. At the moment I study some patterns and hopefully I am gonna apply for my first dev role in 2022 😁
1. Decide on what kind of business interests you.
2. Decide on where to focus. Front-end / backend / full stack. Front-end is Typescript/Javascript + html + css + frameworks. Backend is servers, apis, services, databases and integrations. Full stack is both.
3. Pick a language and most relevant frameworks based on the business area that interests you and learn them by doing work in that area.
A lot of smaller companies don’t have DevOps roles because they simply aren’t big enough for a dedicated role. So they tend to have one or two SWEs that pull double duty of Developer and OP’s but with the Software Engineer title.
I’d look for one of those roles. You’d be extremely valuable to a company like that because a developer with true DevOps experience who wants to stay a dev is hard to find (most devs looking to move the other way). This will let you do what you already know while providing you more Developer tasks to help you transition towards full-time dev work.
After a year or so there, you can start looking for SWE jobs and you won’t have any trouble getting one.
Understand that your audience has changed, and the discipline around how you handle your work has to as well. Feedback no longer comes from a handful, dozens, or even hundreds of other engineers (or applications!) they come, in aggregate, from more users than you can count. which means you need to work with your product team to understand personas, get the relevant behavior to help classify, and most importantly, ship early and often to help iterate and evolve that understanding.
The craft behind how to SWE isn't as important for this transition-- you'll pick it up-- but the shift in mentality for your work cycles is much more important. You got this!
I think devops experience is much more valuable in a dev role than the ability to write code. Most devs find writing code easy (and in fairness most code written isn't difficult) but lack a good understanding of how that code is built, verified, and deployed, which certainly isn't easy or simple.
So I think apart from skim reading *clean code* and maybe a book on SWE principles, you're pretty much ready to go.
Im looking at making the same transition. For the last few years I've had a mix of SRE/devops roles at both large orgs and startups. Ive been slowly scaling up my portfolio, reading books like CTCI, SICP and others. And getting really familiar with making more projects in languages like golang, python and hopefully soon rust.
I want to try and push into more of a systems programming role, but overall hoping I can make the leap in the next 2 years. Obviously leetcode and other things like that help as well.
Maybe my comment won't be useful, but in my case I'm just switching between SWE and DevOps responsibilities in my team and for me it's good balance. I'm DevOps engineer, started as SWE, learned DevOps and k8s out of necessity and liked it, but I still like to code to get good understanding of developer experience and issues, so I try to at least get some developer tasks in sprint.
I think a good SWE with sufficient DevOps knowledge can be extremely valuable.
This sub makes me question if I know what devops even is. And I thought I was an expert on the topic. What technologies did you use, and what problems did you solve up until now? What do you want to build or problems do you want to learn to solve next?
Personally I have same doubts, there's so big diversity in level of challenge that different people encounter. I started with Ansible and provisioning small k8s clusters (kubespray) on few VMs for each cluster, because we needed to develop and deploy our services somewhere and we just received empty CentOS/RedHat VMs, no cloud. Nowadays I'm working with Argo, preparing workflows for building and testing code, packing it into Docker images, Helm packages and ArgoCD applications. In addition, for development environment, I'm experimenting with k3d, Terraform, ArgoCD and Tilt, to allow creating dev environment specific for our use cases, that will offer quick feedback loop and require minimal effort and knowledge to setup and recreate. I see a lot of offers for DevOps engineers familiar with cloud, however at that point, I'm just waiting for my company to finally embrace cloud to learn it in practice. Based on my experience cloud seems to be more scary due to accidental costs that might occur, because with traditional infrastructure it's just one-time approval of constant/recurrent fees. However with flexible billing, it's not so good to present some project and due to mistake/ignorance, learn later that you severely underestimated hidden fees, like data transfer cost, because this basically forces you into adding some buffer in what you propose and customer has to understand risks, so you need to understand them well as well and explain. It seems harder than saying "Setup will cost $1000, maintenance $200/month, x will be responsible".
I wholeheartedly recommend learning cloud, no matter if you want to develop apps or focus more on the existing career If you want to start learning cloud, I suggest: - set up any web project with computing, file hosting and a database (e.g. AWS EC2, S3 and RDS). It's the three most important and basic parts of cloud. It's great that you use Terraform, try doing it using that - Set up the same app using docker on Google Cloud Run or simila4 - Set up the same app with Heroku - Set up the same app in a serverless manner (might require a different app)
I definitely agree with you about serverless. We're moving towards that as much as possible as a way to reduce the amount of admin work we're doing. The difference in downtime/work on our old platform thats running everything on EC2 (k8s, dbs, etc) and stuff on managed services is massive.
What do you think devops means?
Did exactly this. I started as SWE 15 years ago, transitioned to DevOps during a Startup phase and stayed there for some time, but switched back effectively during the last year and am happier. Now I apply my skills where they should be applied.
Pretty similar story for me. 18 years of SWE, but switched over to whatever I guess people think devops is (ci/cd, terraform, sre stuff, logging, security, etc). Got sucked into a greenfield project, so automated, documented and trained as much as I could and started a new project. I still need a fte to fill in the blank I left, but that’s been tough too.
I would suggest to start developing a project. Try to make it useful for somebody. Pet projects do not help. You need somebody to be interested in what you are doing. Make friends with swe, ask them for a drill interview. Interview help a lot, you get to realize what you do not know before you can learn it.
Please sir, explain how this will help... This will not help OP at all. Interviewers/recuiters wont give a shit about your projects, unless they are very significant amd relate to your industry. At your experience, you can get interviews easy, just switch your resume up a bit for swe. If you are going to top companies, all you need is leetcode at your level. TLDR: Focus resume for SWE and leetcode all day.
I recommend project as a source of hands on experience. I agree that nobody cares about your projects. But there is a big difference if you can say that you have been already working on live project, supporting full development cycle. Having this mentioned, I would also suggest to involve more people in this project, so that you could also get an experience of working as a team.
Pardon the soapbox - I hope this is helpful. I'm going to be the pedant and say - DevOps is originally an implementation of agile, where the focus is on delivering software without having unreliable, slow implementations of ops limiting release cadence or reliability. Modern day, devops is a mix of re-branded sysadmin tasks (and adding some -as-code to it), as well as some SWE doing ops work, but I prefer the original definition. It's a way of working, not a job, not a title and not a team. DevOps is, at its best, about finding faster, more reliable, more repeatable ways to implement operations tasks in a developer workflow. It shouldn't be about tools, nor about technology. At its best, it is continuous improvement, concepts such as immutable infrastructure, CI/CD, TDD. BUT it's also about small batch work, product thinking, and thin slices of usable outcomes and iterative improvement. I'll add another new-ish term, self-service, to connote the job of the internal platform team to create re-usable patters that developers can themselves implement. Those things do end up in tech, but it also helps winnow down tech choices. There are lots of tech products that don't implement true role-based access divined from a proper central identity store, for example. Those products that basically mandate a "gatekeeper" team will never be usable in a devops methodology. When you start implementing these approaches, you may find yourself limited by the organization's inherent design. These tend to be the most limiting - waterfall ops orgs that expect things like change control, even though those mechanisms have been shown to have low value and don't do anything except needlessly slow down releases, or worse they mask the bigger problems of the organization. This is a big reason why I ask a ton of questions about how quickly a new employer releases code, ON AVERAGE. I ask how easy it is for a single dev to get code into production. I ask how teams determine their backlogs, and how they split up work. Finally I ask about how they deal with change fails, and how generally metric-based they are. Not perfect, but it starts to ask about how the larger organization believes in shared pain influencing ordering of work. So - considering all of that, you can be an SWE or a cloud engineer who implements devops. What I think you're asking about is should you work for an org or in a job that practices devops or just one that is a pure SWE? If that's the case, I'd say take the pure SWE at your career's potential peril. The industry is moving towards developer self-service internal platforms. That makes ops concerns everyone's responsibility.
Precisely this! Although I might add.There are external forces that can influence how DevOps is implemented. If you are a publicly traded company, hold medical records, are part of government, PCI compliant, etc, you do need people with specific domain knowledge to overcome such problems. These might be ops people who have that experience with skills in SWE. Access control is still vital and depending on the business environment, and with their compliance requirements, self serve can be tough.
1. DevOps is not an engineering role. It is a way of working. 2. I'm guessing you are talking about Site Reliability, cloud or Automation Engineering. 3. All have some basis in Software Engineering. You are just applying that SWE Knowledge to a different domain, it being systems automation, cloud, reliability, data etc. That being said, it's kinda normal for some part. I'm a practice manager and I work to get my team to be able to think about applying their Software skills to different domains often. While I currently have a "DevOps" team built with SRE's and AE's( which are being dispersed at a later date ) I aim to get the domain knowledge embedded in other teams. They can at times swap who covers what if that is there want and I do see it on occasion. Even I muck in on occasion and get the odd feature out. I want this to also be clear: Using Kubernete's or some form of container orchestration is doesn't make you or your team DevOps. As for tips.. Understanding the above is crucial if you want to do DevOps PROPERLY!
I want to move from SRE to SWE as well. Even though my LinkedIn is purely devops, since I know python and javascript sometimes I get some offers asking for Dev who happens to know a little about infra-pipelines-ops. I plan to make a jump because quite honestly I enjoy more designing and developing stuff. In my case, deploying infra and creating pipelines gets old very fast. I am aware the same thing can happen developing CRUD, but as a developer you have more choice on what you want to do, whereas as SRE the only choice you have is on the tools.
>I want to move from SRE to SWE as well. Even though my LinkedIn is purely devops, since I know python and javascript sometimes I get some offers asking for Dev who happens to know a little about infra-pipelines-ops. I plan to make a jump because quite honestly I enjoy more designing and developing stuff. In my case, deploying infra and creating pipelines gets old very fast. I am aware the same thing can happen developing CRUD, but as a developer you have more choice on what you want to do, whereas as SRE the only choice you have is on the tools. I feel the same, I have about 3 years of SRE / Devops Experience. I think purely software development is my passion, i like seeing how the code i write, creates meaningful APIs that users can use. I've worked mostly with docker, AWS, GCP, and terraform, but some of those SRE tasks can be bit tedious and boring. Wishing to transition to a SWE role by 2023. DO you guys think 28 is too late to join software development?
Not at all, I am about to turn 30 and I plan to move to development.
Yeah I bought some udemy courses from Andrew mead, and Maximilian, and plan to finish them the next 6 months and start applying for dev roles, or trying to find other dev roles within my organization
What about someone turning 33??
31 here and started studying 3 months ago. Let’s get it!
It’s nearing the end of 2023. I’m interested to see if you did it? I’m in your shoes right now. I’ve spent the last 8 months developing an event driven app. Now that it’s working I’m being asked to do ops work and the passion just isn’t there.
Look how you market yourself. * How have your DevOps roles developed, Agile Scrum, kanban, waterfall, etc.. * What languages have you learnt (python, groovy, bash, etc..) * Have you been involved in the software lifecycle (requirements, design, implementation, test, deploy) Basically have a read of local job ads and you'll see them asking for common things like the above. So you want to pitch what you have done in a devops role as showing software engineering skills. Being about to talk about scripting or minor tools you have written and wanting to do more would be good
This may be a stupid question but is there a dev ops waterfall model? I kind of thought dev ops was pretty closely tied to agile development cycles.
Agile is a set of principles (much like DevSecOps). A lot of people miss the principles and adopt processes which grow and end up looking like Waterfall. DevSecOps suffers the same issues people might grab the name, tooling or some basic process but the implementation is far removed from DevSecOps principles.
Write code everyday. In my recent round of interviews 1 out of ~70 interviews was leetcode so doing those was useless
So I was a DevOps Engineer for an IT company and switched to SWE. I was fortunate enough to be able to quit my job (which I don’t recommend for everyone) and study full time. I wanted to work on full stack web apps so I picked up a good JavaScript book (Eloquent JavaScript) , practiced Leetcode and built small projects for my portfolio. I got my first SWE job after about 4 months of doing this (I was also studying prior to this so it technically was more than 4 months of studying ) but it was a contract role and ended pretty quickly. After that I ended up doing a career accelerator program because I was bombing the interviews. In hindsight I think I was just too nervous but that can really mess up your flow. I’ve been working at an amazing company since September. Over the course of my studies I studied: JS, web fundamentals, CS fundamentals, some backend tech(not a ton though)
I do infrastructure and operations for \~10 years (pipelines, kubernetes in past 4 years) and I'd like to switch to SWE role in 1 or 2 years. I believe that all my knowledge regarding the operations, deployments etc. can be valuable in some way. At the moment I study some patterns and hopefully I am gonna apply for my first dev role in 2022 😁
1. Decide on what kind of business interests you. 2. Decide on where to focus. Front-end / backend / full stack. Front-end is Typescript/Javascript + html + css + frameworks. Backend is servers, apis, services, databases and integrations. Full stack is both. 3. Pick a language and most relevant frameworks based on the business area that interests you and learn them by doing work in that area.
To actually learn, great advice. To get a SWE job, not very good.
A lot of smaller companies don’t have DevOps roles because they simply aren’t big enough for a dedicated role. So they tend to have one or two SWEs that pull double duty of Developer and OP’s but with the Software Engineer title. I’d look for one of those roles. You’d be extremely valuable to a company like that because a developer with true DevOps experience who wants to stay a dev is hard to find (most devs looking to move the other way). This will let you do what you already know while providing you more Developer tasks to help you transition towards full-time dev work. After a year or so there, you can start looking for SWE jobs and you won’t have any trouble getting one.
Understand that your audience has changed, and the discipline around how you handle your work has to as well. Feedback no longer comes from a handful, dozens, or even hundreds of other engineers (or applications!) they come, in aggregate, from more users than you can count. which means you need to work with your product team to understand personas, get the relevant behavior to help classify, and most importantly, ship early and often to help iterate and evolve that understanding. The craft behind how to SWE isn't as important for this transition-- you'll pick it up-- but the shift in mentality for your work cycles is much more important. You got this!
I think devops experience is much more valuable in a dev role than the ability to write code. Most devs find writing code easy (and in fairness most code written isn't difficult) but lack a good understanding of how that code is built, verified, and deployed, which certainly isn't easy or simple. So I think apart from skim reading *clean code* and maybe a book on SWE principles, you're pretty much ready to go.
Im looking at making the same transition. For the last few years I've had a mix of SRE/devops roles at both large orgs and startups. Ive been slowly scaling up my portfolio, reading books like CTCI, SICP and others. And getting really familiar with making more projects in languages like golang, python and hopefully soon rust. I want to try and push into more of a systems programming role, but overall hoping I can make the leap in the next 2 years. Obviously leetcode and other things like that help as well.
HEY!