3 ms·

It's not just about that role, it's more about the interface between the people responsible for running the code and the people responsible for writing it, and

It's not just about that role, it's more about the interface between the people responsible for running the code and the people responsible for writing it, and to what degree each should be able to do the other's job. Just throwing shit over the wall isn't any good either.

toomuchtodo 10y ago
If you need to do backend and front end ("full stack"), know devops, know cloud primitives, know database fundamentals, know document storage (Elasticsearch), what are you going to actually be good at? Not much. You can't have both depth and breadth of knowledge, unless you're doing unhuman levels of cocaine and never sleeping.
- draw_down 10y ago
  Of course, I was just speaking to why this is happening, not my grand scheme for how this should all work. Personally I would ideally like to just commit code and be done with it. Being on-call sucks.
- cmdrfred 10y ago
  I think you can be good at all those things, just not at 23.
  - flukus 10y ago
    Even if you're good at all those things, can you imagine keeping up in all those areas?
- majewsky 10y ago
  There is a remarkable difference between "knowing Elasticsearch" and being able to debug it when shit hits the fan in the middle of the night.
stonogo 10y ago
This is a common answer which presumes that all businesses are development companies, or that they are development companies which are legally allowed this interplay between the programming team and the production team. There are places (places with a lot of money on the line) that do not fall into these categories, and yet the solutions are not so different. I'm just intrigued by the level of effort Silicon Valley is willing to exert to avoid recognizing this -- or even admitting that it's possible.
- draw_down 10y ago
  Hmm, OK. Yeah, if you legally have to separate the two roles then I guess you'd do that. There still needs to be some sort of interface, though, that's all I am saying. For example, in places I've worked there was a "definition of done" where in order to have a new service be taken on by ops, it had to meet certain criteria so that the people running all these services had some common basis for diagnosing and running them. You don't want 100 different ways of calling a healthcheck on a service. You want service nodes to be able to handle a hard shutdown without data loss, maybe. Stuff like that

toomuchtodo 10y ago

If you need to do backend and front end ("full stack"), know devops, know cloud primitives, know database fundamentals, know document storage (Elasticsearch), what are you going to actually be good at? Not much. You can't have both depth and breadth of knowledge, unless you're doing unhuman levels of cocaine and never sleeping.

draw_down 10y ago
Of course, I was just speaking to why this is happening, not my grand scheme for how this should all work. Personally I would ideally like to just commit code and be done with it. Being on-call sucks.
cmdrfred 10y ago
I think you can be good at all those things, just not at 23.
- flukus 10y ago
  Even if you're good at all those things, can you imagine keeping up in all those areas?
majewsky 10y ago
There is a remarkable difference between "knowing Elasticsearch" and being able to debug it when shit hits the fan in the middle of the night.

stonogo 10y ago

This is a common answer which presumes that all businesses are development companies, or that they are development companies which are legally allowed this interplay between the programming team and the production team. There are places (places with a lot of money on the line) that do not fall into these categories, and yet the solutions are not so different. I'm just intrigued by the level of effort Silicon Valley is willing to exert to avoid recognizing this -- or even admitting that it's possible.

draw_down 10y ago
Hmm, OK. Yeah, if you legally have to separate the two roles then I guess you'd do that. There still needs to be some sort of interface, though, that's all I am saying. For example, in places I've worked there was a "definition of done" where in order to have a new service be taken on by ops, it had to meet certain criteria so that the people running all these services had some common basis for diagnosing and running them. You don't want 100 different ways of calling a healthcheck on a service. You want service nodes to be able to handle a hard shutdown without data loss, maybe. Stuff like that