4 ms·

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 re

by 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.

by nstart 11y ago

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.