5 ms·

Perhaps development work has reached complexity where it demands full-time attention? Perhaps there is a reason why DBA, SRE, Devops and Architects are separat

Perhaps development work has reached complexity where it demands full-time attention? Perhaps there is a reason why DBA, SRE, Devops and Architects are separate roles?

commandlinefan 7y ago
What, you're not a full-stack rockstar ninja?
- mgkimsal 7y ago
  In either case, someone needs to have moderate expertise in multiple areas of tech. If it's wrapped up in one person, the business needs backups to deal with the bus factor. If it's spread across multiple people, you now need to be selecting for people with moderate tech expertise AND the ability to communicate and work together with other people effectively. And you need someone to manage their process (in some manner - doesn't necessarily mean micromanaging). So the 'full-stack rockstar', if they have good communication skills, can exist and be valuable, but still isn't the best long term solution for a business of any size.
falcolas 7y ago
A DBA can't fix a developer's code. A good 3/4 of the list linked in TFA are things a DBA or Architect can't affect. At some point, a developer needs to be responsible for how they use a tool that's been provided for them. Abstractions break.
- gedy 7y ago
  Well likewise, many of the DBAs I've worked with don't try and understand the software needs, and want the world to revolve around what is optimal for them.
cookiecaper 7y ago
> Perhaps there is a reason why DBA, SRE, Devops and Architects are separate roles? It's mainly an artifact of the way we've broken up degree tracks, and the boundaries that each group is taught to stay inside, lest any particular group actually ends up culpable for a failure. Make fun of the "full-stack rockstar ninja" all you want, but the reality is that it is possible to have a functional understanding of all of these areas. It's just a matter of having the confidence and doing the legwork. To the extent that more of your people have a working knowledge of these domains, you'll not only have a better end product, but a much easier time getting stuff done. There's room for hyper-specialized expert consultants in each field, of course, but the myth of the myth of the full-stack developer exists primarily for political convenience. Most of this stuff is not any harder than the rest of it, and can be learned by anyone willing to sit down and learn it.
- msla 7y ago
  The phrases "functional understanding" and "working knowledge" are gigantic sucking tarpits. Before I got my current job, I felt confident in my knowledge of computer networking at the LAN level. I knew I wasn't going into the telecom world and I knew I didn't have the knowledge to debug BGP or ensure a CO was doing everything right, but LANs? Sure. No problem. I knew DHCP, Ethernet, TCP/IP, even stuff like PPP which is more niche now. Heck, I'd even passed a college course on the subject. OK... set up an ICMP server and make it useful. That's LAN, right? Certainly gonna be used on a LAN. I'm not saying it was hard. I'm saying that I'd never touched ICMP before except for ping and didn't know what the more advanced stuff even was. Did I have a "working knowledge" of basic networking? Did I have a "functional understanding" of how to get a building full of computers to talk to each other? It's always something. I thought I had a good, working knowledge of networking. Someone who'd actually done networking in a corporate setting would have disagreed, and pointed to a list of things I'd never touched because those things aren't useful in SoHo LANs and aren't theoretical enough for a classroom. Multiply that by a few dozen topic headings and watch people sink under the load.
  - cookiecaper 7y ago
    Unless you got yourself into a situation where you were expected to set up a whole office with the same speed and expertise as a full-time network engineer based on some gross misrepresentation of your skillset, I don't see how this story is particularly relevant. Maybe it's a good cautionary tale about presuming that SoHo is the limit of networking? Technical topics are indeed both very deep and very broad. The level of sophistication and depth is how you choose your specialization, but that doesn't mean you're never allowed to learn anything else. You should learn enough about each field to know the shores when you're standing there, to be able to communicate with the "natives"/specialists, and to know when you're getting out of the shallow end. This expectation should exist for everyone: DBA, application developer, devops, network, whatever. They should all know the territory and be able to work together cohesively to identify the best place to take something down deep. Depending on the constraints of the project, leaving the shallows means either a) developing more proficiency directly and getting deeper yourself; or b) acknowledging that you need someone with more expertise in that area to take it from there while you go back to handle things in areas you know better. The thing we must avoid is "well I'm not a network engineer so I don't look at Cisco configs, sorry". That should be replaced with "well I'm not a network engineer, so I have no idea what's happening here, but it's still interesting, can I sit behind you and learn?"
quickthrower2 7y ago
Hell Yes. Break it down further: the front end demands that. You could split further into front end architecture, front end UI performance (DOM etc.), web performance (taking into account network etc.), tooling. Even getting NPM to play nice could become a full time expertise! The "developer". Can do anything that involves smashing at a keyboard! It's like calling a politician a "talker". Oh well you could do ground control for the next moon launch then, that's just a "talker".

Perhaps development work has reached complexity where it demands full-time attention? Perhaps there is a reason why DBA, SRE, Devops and Architects are separate roles?

commandlinefan 7y ago

What, you're not a full-stack rockstar ninja?

mgkimsal 7y ago
In either case, someone needs to have moderate expertise in multiple areas of tech. If it's wrapped up in one person, the business needs backups to deal with the bus factor. If it's spread across multiple people, you now need to be selecting for people with moderate tech expertise AND the ability to communicate and work together with other people effectively. And you need someone to manage their process (in some manner - doesn't necessarily mean micromanaging). So the 'full-stack rockstar', if they have good communication skills, can exist and be valuable, but still isn't the best long term solution for a business of any size.

falcolas 7y ago

A DBA can't fix a developer's code. A good 3/4 of the list linked in TFA are things a DBA or Architect can't affect. At some point, a developer needs to be responsible for how they use a tool that's been provided for them. Abstractions break.

gedy 7y ago
Well likewise, many of the DBAs I've worked with don't try and understand the software needs, and want the world to revolve around what is optimal for them.

cookiecaper 7y ago

> Perhaps there is a reason why DBA, SRE, Devops and Architects are separate roles? It's mainly an artifact of the way we've broken up degree tracks, and the boundaries that each group is taught to stay inside, lest any particular group actually ends up culpable for a failure. Make fun of the "full-stack rockstar ninja" all you want, but the reality is that it is possible to have a functional understanding of all of these areas. It's just a matter of having the confidence and doing the legwork. To the extent that more of your people have a working knowledge of these domains, you'll not only have a better end product, but a much easier time getting stuff done. There's room for hyper-specialized expert consultants in each field, of course, but the myth of the myth of the full-stack developer exists primarily for political convenience. Most of this stuff is not any harder than the rest of it, and can be learned by anyone willing to sit down and learn it.

msla 7y ago
The phrases "functional understanding" and "working knowledge" are gigantic sucking tarpits. Before I got my current job, I felt confident in my knowledge of computer networking at the LAN level. I knew I wasn't going into the telecom world and I knew I didn't have the knowledge to debug BGP or ensure a CO was doing everything right, but LANs? Sure. No problem. I knew DHCP, Ethernet, TCP/IP, even stuff like PPP which is more niche now. Heck, I'd even passed a college course on the subject. OK... set up an ICMP server and make it useful. That's LAN, right? Certainly gonna be used on a LAN. I'm not saying it was hard. I'm saying that I'd never touched ICMP before except for ping and didn't know what the more advanced stuff even was. Did I have a "working knowledge" of basic networking? Did I have a "functional understanding" of how to get a building full of computers to talk to each other? It's always something. I thought I had a good, working knowledge of networking. Someone who'd actually done networking in a corporate setting would have disagreed, and pointed to a list of things I'd never touched because those things aren't useful in SoHo LANs and aren't theoretical enough for a classroom. Multiply that by a few dozen topic headings and watch people sink under the load.
- cookiecaper 7y ago
  Unless you got yourself into a situation where you were expected to set up a whole office with the same speed and expertise as a full-time network engineer based on some gross misrepresentation of your skillset, I don't see how this story is particularly relevant. Maybe it's a good cautionary tale about presuming that SoHo is the limit of networking? Technical topics are indeed both very deep and very broad. The level of sophistication and depth is how you choose your specialization, but that doesn't mean you're never allowed to learn anything else. You should learn enough about each field to know the shores when you're standing there, to be able to communicate with the "natives"/specialists, and to know when you're getting out of the shallow end. This expectation should exist for everyone: DBA, application developer, devops, network, whatever. They should all know the territory and be able to work together cohesively to identify the best place to take something down deep. Depending on the constraints of the project, leaving the shallows means either a) developing more proficiency directly and getting deeper yourself; or b) acknowledging that you need someone with more expertise in that area to take it from there while you go back to handle things in areas you know better. The thing we must avoid is "well I'm not a network engineer so I don't look at Cisco configs, sorry". That should be replaced with "well I'm not a network engineer, so I have no idea what's happening here, but it's still interesting, can I sit behind you and learn?"

quickthrower2 7y ago

Hell Yes. Break it down further: the front end demands that. You could split further into front end architecture, front end UI performance (DOM etc.), web performance (taking into account network etc.), tooling. Even getting NPM to play nice could become a full time expertise! The "developer". Can do anything that involves smashing at a keyboard! It's like calling a politician a "talker". Oh well you could do ground control for the next moon launch then, that's just a "talker".