4 ms·

I think there are a number of major problems with the industry. Technology jumping based on anecdotal evidence of the efficacy of doing so. Jumping around so o

I think there are a number of major problems with the industry. Technology jumping based on anecdotal evidence of the efficacy of doing so. Jumping around so often precludes a lot of practitioners from gaining a deep experience and understanding with the tools they're working with. This may be the only industry I know where pertinent knowledge and experience matters little. The notion of "Full Stack Developers" gives the impression that one can be proficient top to bottom. What I find interesting about the label is full seems to usually be bounded on the lower end at a place much higher than a place where I would use the term full. This is one of the many areas in our industry where hubris is in play. Specialization is usually preferable for quality and scaling. Real world business continually drives the fast and cheap legs of the stool to be chosen by management. However, I think this grates against most practitioners who not only care about quality but would admit, the aspect of quality is one of the major reasons they are even in the field to begin with. There is a large natural tension at play here. I think it's this tension that Joe was articulating. It's seems to me the most satisfied folks in this field are the ones fortunate enough to be compensated for working within a bounded context where over time they can gain more and more experience and knowledge. This naturally leads to a growing confidence and a sense of control over the context with which they work.

adventured 7y ago
I've spent most of my adult life as as "full stack" developer, out of necessity: I build the whole banana on my own and typically work on projects on my own (about 3/4 of the last 20 years). I'm better at some aspects than others and I enjoy some aspects more than others, of course (and I offload/automate anywhere I can). From the late 1990s until five or six years ago, it was fairly easy to keep up with the latest interesting stuff in terms of full stack. Adjustments were modest year to year. At this point I've entirely given up trying to keep up with the very rapid fad switching that has been going on. Real full stack is now only possible if you freeze pretty strictly across the stack and don't try to keep up as the next fad rolls in for a given part of the stack. If you try to keep up with all the fads now, it'll burn you out (and most likely make you hate what you do as you realize how pointless the constant switching is). I've found - as you'd expect - that abandoning the stack rat race hasn't had any negative impact. Most of the latest fads are entirely unnecessary and bring nothing to the table that prior numerous solutions didn't already deliver toward building, launching and maintaining product.
- mtberatwork 7y ago
  This is the other side of the coin. A lot of folks in the industry, especially on the younger side, tend to believe they are operating at FAANG levels of data and complexities. What happens is that you get convoluted, over-engineered architectures and applications which really do nothing other than pad resumes. The next time you are listening to a talk or reading a blog entry that drones on about how complex their stack is, stop and think for a moment: "Do they really have traffic/MAU levels that merit this approach? Are they really operating on data that is PB scale or just a few GBs?" More often than not, the answer is an emphatic No ... or "Can this application be distilled down to a vanilla MVC app with a few cronjobs running?" Yes.
  - Mirioron 7y ago
    >What happens is that you get convoluted, over-engineered architectures and applications which really do nothing other than pad resumes. But padding resumes is one of those seemingly fundamental problems of any industry (or bureaucracy). Many poor decisions by (middle) management come down to padding resumes - when the consequences of bad decisions eventually happen said managers are gone. Hell, you could even argue that a lot of higher education is about padding your resume rather than learning skills. Unfortunately, it seems that we have to live with the added baggage of "padding resumes".
  - cercatrova 7y ago
    Maybe the point _is_ to pad resumes, ie Resume Driven Development. The incentives align for this to take place, as companies want to hire for the trendiest and newest technologies, simply as a way of virtue signaling that they're good, regardless of the efficacy of the new technologies. If I can job hop every few years while padding my resume, and get paid 30% more each time, for some N job hops, why wouldn't I? In this case, when you follow the incentives, you see why this happens. That the incentives of the business don't align exactly (stability, speed, efficiency to some regard) is inconsequential to the developer who wants to increase their value.
  - mtmalla 7y ago
    I will argue that some projects are definitely overly architectured simply for the sake of gaining experience in doing so. If everyone waited until they actually had Google scale problems to learn how to create scalable architecture, then only a small subset of people would have that skill. It is the initiative of doing so and ability to point at previous history of successfully completing such projects that give these people the opportunity to work on problems that actually require said complex solutions.

adventured 7y ago

I've spent most of my adult life as as "full stack" developer, out of necessity: I build the whole banana on my own and typically work on projects on my own (about 3/4 of the last 20 years). I'm better at some aspects than others and I enjoy some aspects more than others, of course (and I offload/automate anywhere I can). From the late 1990s until five or six years ago, it was fairly easy to keep up with the latest interesting stuff in terms of full stack. Adjustments were modest year to year. At this point I've entirely given up trying to keep up with the very rapid fad switching that has been going on. Real full stack is now only possible if you freeze pretty strictly across the stack and don't try to keep up as the next fad rolls in for a given part of the stack. If you try to keep up with all the fads now, it'll burn you out (and most likely make you hate what you do as you realize how pointless the constant switching is). I've found - as you'd expect - that abandoning the stack rat race hasn't had any negative impact. Most of the latest fads are entirely unnecessary and bring nothing to the table that prior numerous solutions didn't already deliver toward building, launching and maintaining product.

mtberatwork 7y ago
This is the other side of the coin. A lot of folks in the industry, especially on the younger side, tend to believe they are operating at FAANG levels of data and complexities. What happens is that you get convoluted, over-engineered architectures and applications which really do nothing other than pad resumes. The next time you are listening to a talk or reading a blog entry that drones on about how complex their stack is, stop and think for a moment: "Do they really have traffic/MAU levels that merit this approach? Are they really operating on data that is PB scale or just a few GBs?" More often than not, the answer is an emphatic No ... or "Can this application be distilled down to a vanilla MVC app with a few cronjobs running?" Yes.
- Mirioron 7y ago
  >What happens is that you get convoluted, over-engineered architectures and applications which really do nothing other than pad resumes. But padding resumes is one of those seemingly fundamental problems of any industry (or bureaucracy). Many poor decisions by (middle) management come down to padding resumes - when the consequences of bad decisions eventually happen said managers are gone. Hell, you could even argue that a lot of higher education is about padding your resume rather than learning skills. Unfortunately, it seems that we have to live with the added baggage of "padding resumes".
- cercatrova 7y ago
  Maybe the point _is_ to pad resumes, ie Resume Driven Development. The incentives align for this to take place, as companies want to hire for the trendiest and newest technologies, simply as a way of virtue signaling that they're good, regardless of the efficacy of the new technologies. If I can job hop every few years while padding my resume, and get paid 30% more each time, for some N job hops, why wouldn't I? In this case, when you follow the incentives, you see why this happens. That the incentives of the business don't align exactly (stability, speed, efficiency to some regard) is inconsequential to the developer who wants to increase their value.
- mtmalla 7y ago
  I will argue that some projects are definitely overly architectured simply for the sake of gaining experience in doing so. If everyone waited until they actually had Google scale problems to learn how to create scalable architecture, then only a small subset of people would have that skill. It is the initiative of doing so and ability to point at previous history of successfully completing such projects that give these people the opportunity to work on problems that actually require said complex solutions.