4 ms·

One coworker posted this a while back and I just dismissed it as someone afraid of something that they can't handle. While I understand the point.. I'm also a

One coworker posted this a while back and I just dismissed it as someone afraid of something that they can't handle. While I understand the point.. I'm also a dev and I love "DevOps". Aren't we all doing this because we love problem solving? How is this not just another problem to tackle? I love having to figure how to automate mundane tasks (again.. this is just code.. not much different than we write elsewhere) to make sure I don't have to manage any systems manually. /rant

zippy786 11y ago
Don't you see tight coupling between two components/roles which may be bad ? Of course, for management it's less money they have to pay so they will always prefer a one man doing everything scenario.
- mattkrea 11y ago
  I see that I can't trust what is the traditional IT department to understand how my application works so I strongly prefer shipping Docker containers or using something like Elastic Beanstalk if that is not available.
nstart 11y ago
It's actually a complex debate. We as developers naturally gravitate to a role like this because it's in our nature to believe that we can solve all the tech related problems. And all other problems, we believe can be solved with tech and therefore we believe we can solve everything. Ok. That's an exaggeration but there's quite a large shred of reality in that statement. Being fullstack/devops/<insert fancy term> satisfies that craving to jump on to new problems that we developers have. And that CAN be a problem. It isn't necessarily always a problem. But think about it. How many of us prefer jumping up to try working on a brand new project. Shiny stuff everywhere. And then everything gets abandoned at the grind and polish stage. The enthusiasm is gone. We crave the next new problem that we can use as an excuse for jumping away from the grind we are in. I think what the author is trying to get across is that this new "devops" culture is creating a large number of developers who don't have deep knowledge of anything. Ask a developer (myself included) to evaluate a set of JS frameworks for a particular project which has somewhat specific requirements. Behind most answers (this is based on observation, myself included again) the primary argument will be the developer's preference; not an objective breakdown of what is most suited for the task. We might not see too much of this on HN (I think. I see a lot of intelligent debates here which I learn from all the time) but on a larger scale developers are becoming half baked. And that's basically the other side of what you pointed out. Problem solving, learning new things is a lot of fun (discovering and configuring vagrant and docker for the first time was incredibly fun). But it possible that the full stack role is churning out people with broad but just somewhat in depth knowledge. Tough call. Question is, is somewhat deep deep enough for most everything?
- eropple 11y ago
  > I think what the author is trying to get across is that this new "devops" culture is creating a large number of developers who don't have deep knowledge of anything. I dunno about that. My experience has been more that a team may need one person who's both wide and deep (T-shaped, or maybe just "rectangular"), but the companies I run across generally seem to hire younger developers who do have one or two core competencies--I-shaped, if not just dot-shaped and hoping to train them up.
- mattkrea 11y ago
  I can agree with that. Though on the other end of things.. I have a friend that is very into how some languages are optimized for various tasks and he'll mention to me that X language does something with their loops for speed, etc. I don't have that same low level knowledge of the languages (not as low-level at least; I have some) but at the end of the day X language is slower than those that I prefer for the type of work we do (APIs mostly) so I don't care that X language does all these things internally.. and I don't need to know because it doesn't matter to us (nor our employer) in the end. So my--hate to use a buzz phrase here but it's appropriate--'get shit done' style tends to work for me and our company because evaluating tools comes down to "does a framework or tool accomplish what we need without too much overhead". Is this the type of deep knowledge you were talking about?
  - nstart 11y ago
    Yep. The question was, is the "I can analyze and tell you if I can use this tool to get work done" knowledge deep enough for most work? Or is it essential that if you are a front end dev to at least have an in depth knowledge to analyze, explain, and predict where a JS framework will shine over another and where it's pitfalls will lie. Knowing those pitfalls is also important because someday, it will bite. I remember not knowing about the pitfalls of python and default parameters being permanently set if given or passed a mutable argument. That bit me hard. I really don't know where the line lies honestly.
serge2k 11y ago
The problem I have with DevOps boils down to 2 things. 1. It's really just a dumb buzzword. 2. I really don't like companies dumping more work on devs for the same pay and using a buzzword to justify it. Oh here, you get a pager now because we're DEVOPS! Hire a god damn support staff. That said, letting people form little kingdoms and toss up walls so that people just end up getting bound up in bureaucracy is also terrible.

zippy786 11y ago

Don't you see tight coupling between two components/roles which may be bad ? Of course, for management it's less money they have to pay so they will always prefer a one man doing everything scenario.

mattkrea 11y ago
I see that I can't trust what is the traditional IT department to understand how my application works so I strongly prefer shipping Docker containers or using something like Elastic Beanstalk if that is not available.

nstart 11y ago

It's actually a complex debate. We as developers naturally gravitate to a role like this because it's in our nature to believe that we can solve all the tech related problems. And all other problems, we believe can be solved with tech and therefore we believe we can solve everything. Ok. That's an exaggeration but there's quite a large shred of reality in that statement. Being fullstack/devops/<insert fancy term> satisfies that craving to jump on to new problems that we developers have. And that CAN be a problem. It isn't necessarily always a problem. But think about it. How many of us prefer jumping up to try working on a brand new project. Shiny stuff everywhere. And then everything gets abandoned at the grind and polish stage. The enthusiasm is gone. We crave the next new problem that we can use as an excuse for jumping away from the grind we are in. I think what the author is trying to get across is that this new "devops" culture is creating a large number of developers who don't have deep knowledge of anything. Ask a developer (myself included) to evaluate a set of JS frameworks for a particular project which has somewhat specific requirements. Behind most answers (this is based on observation, myself included again) the primary argument will be the developer's preference; not an objective breakdown of what is most suited for the task. We might not see too much of this on HN (I think. I see a lot of intelligent debates here which I learn from all the time) but on a larger scale developers are becoming half baked. And that's basically the other side of what you pointed out. Problem solving, learning new things is a lot of fun (discovering and configuring vagrant and docker for the first time was incredibly fun). But it possible that the full stack role is churning out people with broad but just somewhat in depth knowledge. Tough call. Question is, is somewhat deep deep enough for most everything?

eropple 11y ago
> I think what the author is trying to get across is that this new "devops" culture is creating a large number of developers who don't have deep knowledge of anything. I dunno about that. My experience has been more that a team may need one person who's both wide and deep (T-shaped, or maybe just "rectangular"), but the companies I run across generally seem to hire younger developers who do have one or two core competencies--I-shaped, if not just dot-shaped and hoping to train them up.
mattkrea 11y ago
I can agree with that. Though on the other end of things.. I have a friend that is very into how some languages are optimized for various tasks and he'll mention to me that X language does something with their loops for speed, etc. I don't have that same low level knowledge of the languages (not as low-level at least; I have some) but at the end of the day X language is slower than those that I prefer for the type of work we do (APIs mostly) so I don't care that X language does all these things internally.. and I don't need to know because it doesn't matter to us (nor our employer) in the end. So my--hate to use a buzz phrase here but it's appropriate--'get shit done' style tends to work for me and our company because evaluating tools comes down to "does a framework or tool accomplish what we need without too much overhead". Is this the type of deep knowledge you were talking about?
- nstart 11y ago
  Yep. The question was, is the "I can analyze and tell you if I can use this tool to get work done" knowledge deep enough for most work? Or is it essential that if you are a front end dev to at least have an in depth knowledge to analyze, explain, and predict where a JS framework will shine over another and where it's pitfalls will lie. Knowing those pitfalls is also important because someday, it will bite. I remember not knowing about the pitfalls of python and default parameters being permanently set if given or passed a mutable argument. That bit me hard. I really don't know where the line lies honestly.

serge2k 11y ago

The problem I have with DevOps boils down to 2 things. 1. It's really just a dumb buzzword. 2. I really don't like companies dumping more work on devs for the same pay and using a buzzword to justify it. Oh here, you get a pager now because we're DEVOPS! Hire a god damn support staff. That said, letting people form little kingdoms and toss up walls so that people just end up getting bound up in bureaucracy is also terrible.