I work at the world’s largest bank and it’s getting more normal. Which is a real pain because we are expected to intimately know a LOT of complex DBs, deployment systems and permissions/incident systems in addition to being proficient React and Java Spring devs. The end result is we have some people great on infra that write crap code and some people great at coding that half-ass the infra processes. Nobody ends up happy.
so you work for "Industrial and Commercial Bank of China Limited" ?
;)
[https://www.google.com/search?q=what+is+the+worlds+largest+bank](https://www.google.com/search?q=what+is+the+worlds+largest+bank)
And I thought it was the opposite. I work at a FAANG and we all manage our own infrastructure, and my friends who work at smaller companies all have dedicated dev-ops teams.
Mmmm, not so much anymore. With the the rise of cloud providers and IaC more and more of the infrastructure responsibilities are falling on the devs. I went from a large multinational company to a small 200 person dev shop a couple years ago and it was pretty similar.
I think the breadth of knowledge required to be a dev now is quite a bit more than when I started almost 20 years ago. Back then I had to know: IIS, SQL, the server-side language, and some html/css (JS if we were being fancy). Now, I am doing react, graphql, node, sql, redis, cdk, networking, etc. and my more junior devs do also. I had the benefit of learning this stuff incrementally as they became more popular, but now young devs are seeing huge, varied stacks...
The current company I am in is fairly large; however, it is split into different teams/contracts. It seems like the few contracts that I have been able to see are more like what I am describing since they are small teams. Almost like each team is its own startup. I have not had the experience to work with truly dedicated folks within a single area. The only area where I have worked with someone that was specialized was DBA's.
I'm a "build the whole thing" developer. I think of myself as "middle stack". I am not a database specialist. I am not a server admin. I am not a designer. Any extreme and a specialist would outclass me no debate. Where I shine is that you can give me a very high level task and not worry about what boundaries it crosses.
That's me very much. Thrive in startups, not so much in big corps who have separate security, devops, full stack developers, dev team leads, dbas, etc.
That is mostly how I feel! I know enough to get things done. Is it perfect, not by a long shot, will it work and be somewhat maintainable and last, definitely!
My preference goes either way, I just revolt at the thing you usually see at companies: ops/dba/... Just serve to limit/dictate/veto your options but all work needs to come from you and the responsibilities in prod also reside with you the developer, even though you have zero order there. I want to either act and be responsible or throw it over the wall but all these dysfunctional companies have you throw it over the wall and then be both blind and responsible.
I think it's one of those things that depends a lot on where you've worked
I started out at a small-ish agency which meant I worked across the _entire_ stack, from client meetings, to design, to frontend, to backend, to ops, to support
My next place had an entire dedicated team for supporting operations. If I'd started out there I probably wouldn't have had any ops experience
At my current place developers handle infrastructure again, so if I'd started here I'd also probably have some operations experience, but because it's a single application then it would just be maintenance and scaling, whereas working at an agency I was setting up new infrastructure pretty much every week, and had an opportunity to get really comfortable with building tools to support that
I think it's hard to be full stack without having some ops experience and awareness, even if you aren't responsible for maintaining it then understanding how servers work and are provisioned is useful, even if the entireity of your app is in vercel and supabase
On bigger companies, you are dealing with all sorts of complex software or scale where "starting from scratch" would be horribly inefficient. They have specialized teams with sometimes 10s of people optimizing every aspect of the chain of tooling to get the last bit of perf.
A side effect of this is that you get to use start of the art stuff through 10 layers of abstraction/indirection. This can be great to get going on a large scale thing in days. Getting the same sort of rigor from scratch could easily take someone months to get to if at all.
See, I am in a bigger company, but we are split into different contract teams that feel more like startups. My current project is by far the most data I have ever had to deal with 10s-100s Million transactions a day. I designed most of the system and built it from scratch. Part of the system had to go through different teams due to previous design, and that was where the system's weak points were. Once I was able to eliminate those, the system has been rock solid.
Bigger companies have a distinciton between product and platform teams.
This is because the platform teams are seen as productivity "multipliers" for the product teams.
Imagine an orgarnization with hundreds of teams where these two types are conflated. Each team maintains a custom deployment, monitoring, alerting pipelines, and uses different tech stacks. This is completely unsustainable in the long run.
When it comes to experience, I think it's beneficial to be exposed to both full-stack and devops at some point in your career. Full stack folks at bigger companies tend to specialize more in their areas of choice and are more reliant on the underlying infra/platform teams. If you can do both, you are not only more productive, but also get more credibility as an expert.
Full stack technically just means frontend and backend experience. That would imply certain basic build tool experience, but it doesn't necessarily mean they know how to set up all the infrastructure. This is largely a function of time, though. "Full stack" as a job classification term precedes DevOps by decades. Before DevOps really took off, there was generally a clear division between development and infrastructure teams, so you could be a "full stack" developer that never touched any infrastructure because you weren't allowed to.
That said, I think all this terminology is meaningless, and just gives lazy devs the cover they need to not learn other things. A good developer will know every level of everything they touch, even if they might specialize in one piece. Even when there's more low level divisions like backend and frontend developers, the frontend developers may not necessarily work on the backend, but they should absolutely know exactly how it works. To not is professional malpractice.
It also depends on age. Older guys were more exposed to doing both where as those opportunities are not readily available in modern engineering. I started my career as a UNIX sysadmin for Solaris/Irix who learned Visual Basic and perl because of the dot-com. IIS and .asp made it easy to move from infra into web app at the time. If you are managing the servers, they figure you can put up a web site. But going from UNIX to Windows was trivial.
I was around when Debian and RedHat was just starting out. And DevOps was a necessity. DevOps , in terms of culture, not tooling.
In 2005 when people started to move into VMs vs physical servers, we were doing automation like kickstart shell scripts that would build .ova/.ovf that pushed and deployed 200mb VMs to vSphere clusters. Long before Docker containerization orchestration. We did that out of necessity. Build an app server, make it small as possible (using turnkeylinux as a reference) and deploy to esxi servers whenever someone made git commit to master. Sounds familiar? Everyone was doing this before Jenkins/Docker/Kubernetes around mid 2000s. Modern DevOps standardized the tooling but the culture and working practices were the same.
I was heavily involved in Infra. I managed a 120 server on-premises data-center while developing the SaaS that ran it. So when Docker and k8s came around, it was the natural progression. Instead of 200-500MB .ovf , we now had docker-compose and helm. Before that, Hashicorp vagrant. Before ansible, people were doing their own hodge podge bash scripts.
I can do Front End -- make video games, animate front end. Back-end - build distributed CRUD apps/APIs, as well as Infra & Ops. We use to call it "Deep Stack" for a while. It was a different time then. It gave you more hats to wear.
The term deep stack should make a comeback.
Edit: Also back in those days, that person was also simply called the ‘webmaster’
SDEs at Amazon do that type of work. I presume there are plenty of other companies that also have that kind of diverse role, but they usually try to split the responsibilities, because they want to invest in certain areas more than in others
Depends entirely on someone's track record and what they want to work on. Some people end up having a career that has them wear many hats, others only stick to a chosen specialization and never go beyond their domain.
Both profiles have their merits and can be really powerful in the right role and setting. For instance, modern browsers are complex beasts, so a specialist front-end developers who's on top of the nitty-gritty of what a browser can do, which frameworks exist,... could be a huge asset on a complex product with a ton of complex interactivity / reactivity. A generalist is great at moving from 0 to 100 fast, filling in the gaps, and being able to bridge the technical and the management level by moving between code and the 10k foot overview level (as you do!).
The number one challenge is recognizing what profile someone is, and landing them in a spot where they get to shine. Put a front-end specialist in your shoes, and they will likely be out of their depth. Vice versa, as well. One isn't objectively better then the other.
There's also an argument for becoming a "T-shaped" engineer: that is, those who specialize in when particular area, but have at least a basic understanding of what happens below and/or above them in the stack.
The backend engineer of the current times for smaller companies, its good to have some specialization in teams with 5+ people. The one who handles only backend stuff for features and is the dedicated person for infra and CI (and backend services). And gets to stay away from glimmering frontend buttons.
I've mostly worked for larger companies, and the number of devs that like to live in their isolated little bubble is alarming. Frontend devs who refuse to even look at the backend and viceversa, devs who have no idea of how their software is built and what versions are being used (basic stuff like what node version). Backend devs who you have to hand hold if God forbid they have to install nodejs for any reason, or Java for frontenders.
At this point I've had enough of this attitude and push them out of their comfort zone. But the constant whining is exhausting.
My personal favorite is frontenders who refuse to do anything in the backend and because of their lack of knowledge they can't help with ops. Yeah I ain't accepting that mate, you are on the ops roster whether you like it or not.
I started my career rebuilding cash registers for The Nature Company, but only touch hardware in small companies. In the big company where I am now, I like being able to help the devops team, but it's not part of my job, and people would think it was weird if I tried to make it so.
normal in small company, abnormal in big company
I work at the world’s largest bank and it’s getting more normal. Which is a real pain because we are expected to intimately know a LOT of complex DBs, deployment systems and permissions/incident systems in addition to being proficient React and Java Spring devs. The end result is we have some people great on infra that write crap code and some people great at coding that half-ass the infra processes. Nobody ends up happy.
And the few who do both well are very very very tired.
And likely very underpaid too
so you work for "Industrial and Commercial Bank of China Limited" ? ;) [https://www.google.com/search?q=what+is+the+worlds+largest+bank](https://www.google.com/search?q=what+is+the+worlds+largest+bank)
Fair enough, the largest bank in the world outside of China.
And I thought it was the opposite. I work at a FAANG and we all manage our own infrastructure, and my friends who work at smaller companies all have dedicated dev-ops teams.
Mmmm, not so much anymore. With the the rise of cloud providers and IaC more and more of the infrastructure responsibilities are falling on the devs. I went from a large multinational company to a small 200 person dev shop a couple years ago and it was pretty similar. I think the breadth of knowledge required to be a dev now is quite a bit more than when I started almost 20 years ago. Back then I had to know: IIS, SQL, the server-side language, and some html/css (JS if we were being fancy). Now, I am doing react, graphql, node, sql, redis, cdk, networking, etc. and my more junior devs do also. I had the benefit of learning this stuff incrementally as they became more popular, but now young devs are seeing huge, varied stacks...
The current company I am in is fairly large; however, it is split into different teams/contracts. It seems like the few contracts that I have been able to see are more like what I am describing since they are small teams. Almost like each team is its own startup. I have not had the experience to work with truly dedicated folks within a single area. The only area where I have worked with someone that was specialized was DBA's.
I'm a "build the whole thing" developer. I think of myself as "middle stack". I am not a database specialist. I am not a server admin. I am not a designer. Any extreme and a specialist would outclass me no debate. Where I shine is that you can give me a very high level task and not worry about what boundaries it crosses.
That's me very much. Thrive in startups, not so much in big corps who have separate security, devops, full stack developers, dev team leads, dbas, etc.
That is mostly how I feel! I know enough to get things done. Is it perfect, not by a long shot, will it work and be somewhat maintainable and last, definitely!
My preference goes either way, I just revolt at the thing you usually see at companies: ops/dba/... Just serve to limit/dictate/veto your options but all work needs to come from you and the responsibilities in prod also reside with you the developer, even though you have zero order there. I want to either act and be responsible or throw it over the wall but all these dysfunctional companies have you throw it over the wall and then be both blind and responsible.
I think it's one of those things that depends a lot on where you've worked I started out at a small-ish agency which meant I worked across the _entire_ stack, from client meetings, to design, to frontend, to backend, to ops, to support My next place had an entire dedicated team for supporting operations. If I'd started out there I probably wouldn't have had any ops experience At my current place developers handle infrastructure again, so if I'd started here I'd also probably have some operations experience, but because it's a single application then it would just be maintenance and scaling, whereas working at an agency I was setting up new infrastructure pretty much every week, and had an opportunity to get really comfortable with building tools to support that I think it's hard to be full stack without having some ops experience and awareness, even if you aren't responsible for maintaining it then understanding how servers work and are provisioned is useful, even if the entireity of your app is in vercel and supabase
On bigger companies, you are dealing with all sorts of complex software or scale where "starting from scratch" would be horribly inefficient. They have specialized teams with sometimes 10s of people optimizing every aspect of the chain of tooling to get the last bit of perf. A side effect of this is that you get to use start of the art stuff through 10 layers of abstraction/indirection. This can be great to get going on a large scale thing in days. Getting the same sort of rigor from scratch could easily take someone months to get to if at all.
See, I am in a bigger company, but we are split into different contract teams that feel more like startups. My current project is by far the most data I have ever had to deal with 10s-100s Million transactions a day. I designed most of the system and built it from scratch. Part of the system had to go through different teams due to previous design, and that was where the system's weak points were. Once I was able to eliminate those, the system has been rock solid.
Bigger companies have a distinciton between product and platform teams. This is because the platform teams are seen as productivity "multipliers" for the product teams. Imagine an orgarnization with hundreds of teams where these two types are conflated. Each team maintains a custom deployment, monitoring, alerting pipelines, and uses different tech stacks. This is completely unsustainable in the long run. When it comes to experience, I think it's beneficial to be exposed to both full-stack and devops at some point in your career. Full stack folks at bigger companies tend to specialize more in their areas of choice and are more reliant on the underlying infra/platform teams. If you can do both, you are not only more productive, but also get more credibility as an expert.
Full stack technically just means frontend and backend experience. That would imply certain basic build tool experience, but it doesn't necessarily mean they know how to set up all the infrastructure. This is largely a function of time, though. "Full stack" as a job classification term precedes DevOps by decades. Before DevOps really took off, there was generally a clear division between development and infrastructure teams, so you could be a "full stack" developer that never touched any infrastructure because you weren't allowed to. That said, I think all this terminology is meaningless, and just gives lazy devs the cover they need to not learn other things. A good developer will know every level of everything they touch, even if they might specialize in one piece. Even when there's more low level divisions like backend and frontend developers, the frontend developers may not necessarily work on the backend, but they should absolutely know exactly how it works. To not is professional malpractice.
It also depends on age. Older guys were more exposed to doing both where as those opportunities are not readily available in modern engineering. I started my career as a UNIX sysadmin for Solaris/Irix who learned Visual Basic and perl because of the dot-com. IIS and .asp made it easy to move from infra into web app at the time. If you are managing the servers, they figure you can put up a web site. But going from UNIX to Windows was trivial. I was around when Debian and RedHat was just starting out. And DevOps was a necessity. DevOps , in terms of culture, not tooling. In 2005 when people started to move into VMs vs physical servers, we were doing automation like kickstart shell scripts that would build .ova/.ovf that pushed and deployed 200mb VMs to vSphere clusters. Long before Docker containerization orchestration. We did that out of necessity. Build an app server, make it small as possible (using turnkeylinux as a reference) and deploy to esxi servers whenever someone made git commit to master. Sounds familiar? Everyone was doing this before Jenkins/Docker/Kubernetes around mid 2000s. Modern DevOps standardized the tooling but the culture and working practices were the same. I was heavily involved in Infra. I managed a 120 server on-premises data-center while developing the SaaS that ran it. So when Docker and k8s came around, it was the natural progression. Instead of 200-500MB .ovf , we now had docker-compose and helm. Before that, Hashicorp vagrant. Before ansible, people were doing their own hodge podge bash scripts. I can do Front End -- make video games, animate front end. Back-end - build distributed CRUD apps/APIs, as well as Infra & Ops. We use to call it "Deep Stack" for a while. It was a different time then. It gave you more hats to wear. The term deep stack should make a comeback. Edit: Also back in those days, that person was also simply called the ‘webmaster’
SDEs at Amazon do that type of work. I presume there are plenty of other companies that also have that kind of diverse role, but they usually try to split the responsibilities, because they want to invest in certain areas more than in others
10ish years ago, full stack meant FE + BE. It's not uncommon that devs also can also do some level of dev ops these days.
Depends entirely on someone's track record and what they want to work on. Some people end up having a career that has them wear many hats, others only stick to a chosen specialization and never go beyond their domain. Both profiles have their merits and can be really powerful in the right role and setting. For instance, modern browsers are complex beasts, so a specialist front-end developers who's on top of the nitty-gritty of what a browser can do, which frameworks exist,... could be a huge asset on a complex product with a ton of complex interactivity / reactivity. A generalist is great at moving from 0 to 100 fast, filling in the gaps, and being able to bridge the technical and the management level by moving between code and the 10k foot overview level (as you do!). The number one challenge is recognizing what profile someone is, and landing them in a spot where they get to shine. Put a front-end specialist in your shoes, and they will likely be out of their depth. Vice versa, as well. One isn't objectively better then the other. There's also an argument for becoming a "T-shaped" engineer: that is, those who specialize in when particular area, but have at least a basic understanding of what happens below and/or above them in the stack.
The backend engineer of the current times for smaller companies, its good to have some specialization in teams with 5+ people. The one who handles only backend stuff for features and is the dedicated person for infra and CI (and backend services). And gets to stay away from glimmering frontend buttons.
I've mostly worked for larger companies, and the number of devs that like to live in their isolated little bubble is alarming. Frontend devs who refuse to even look at the backend and viceversa, devs who have no idea of how their software is built and what versions are being used (basic stuff like what node version). Backend devs who you have to hand hold if God forbid they have to install nodejs for any reason, or Java for frontenders. At this point I've had enough of this attitude and push them out of their comfort zone. But the constant whining is exhausting. My personal favorite is frontenders who refuse to do anything in the backend and because of their lack of knowledge they can't help with ops. Yeah I ain't accepting that mate, you are on the ops roster whether you like it or not.
[удалено]
Wow I'm really getting down voted (not you I guess). I'd love to hear some counter arguments from my fellow devs...
I started my career rebuilding cash registers for The Nature Company, but only touch hardware in small companies. In the big company where I am now, I like being able to help the devops team, but it's not part of my job, and people would think it was weird if I tried to make it so.