51 grey beard here. Let me complain about the younguns. So much of what's out there today is, or is based on "solutions" created to solve problems that don't really exist. Rather than try to understand something so many engineers created "frameworks" to implement what was already there. Like 90% of current web stacks are just that. But new engineers are trained on that stuff and think it's the only way. That frustrates the hell out of me.
I share this frustration, but I think the root cause of the frustration is the difference between what I feel should be important, and what actually is important to people.
Getting great reliable software delivered quickly, which is easy to maintain and change, should be the goal, I feel. But if that’s the case, why do people invent problems to find solutions to, why do people spend multiple days a week in Scrum meetings, etc.?
But looking at everyone involved and their actual incentives:
- For a consultant, the objective is to maximize the billable hours.
- For the employee, to get modern skills on their CV.
- For the junior programmer, there is a more level playing field with the seniors when tech is used that’s new and nobody knows, vs. tech the seniors know well and they don’t.
- For the manager or owner of a product company, they want less stress having to make decisions and as long as the product makes money who cares if the software could be delivered 50% or 70% faster?
The psychological aspect of consultants and even employees trying to play a game with billable hours aside, a lot of developers of all ages genuinely feel using frameworks to do the exact same thing one can achieve with far less hubbub is a good thing, and they have trouble defending it. It's a cargo cult by all standards.
Many of us are living this now. If it's not the chasing of new frameworks, it is old frameworks no longer being actively supported, or key features never being developed. Then it turns out something like vanilla HTML + JS can do the job just fine, but you need to update everything to vanilla to make it uniform.
I think the issue is the batteries included approach taken nowadays.
Many developers nowadays seem to expect to be able to just wire things together without actual writing much algorithmic code. And the solutions have catered to that.
Those of us that are older lament the idea of using frameworks to increase our productivity, but still being more than glorified middle-men.
Why reinvent the wheel? I’ve seen “architects” who didn’t think they needed Entity Framework and went about solving the same problems (mostly around change tracking) very badly. Give me a widely supported framework any day over a badly written unsupported in house solution.
Sometime frameworks are a real help, sometime using it is just making thing bloated and it's hard-linking the future to someone who have the knowledge of the framework.
I would much rather “hard link” the future to a publicly available documented framework than one that a single person who thought their problem was a special snowflake wrote.
Which is why I've been paid good money to both maintain and bring up to speed old RoR applications that were so out of date you had to manually patch the C libraries just to get it working.
This attitude is common, that these frameworks are not, themselves, dependencies to be managed and protected from.
In medium and large organizations, manager pay and influence is mostly related to the number of employees managed and the size of their budget. Managers maximizing these two variables explains a lot of behavior that seems unreasonable to employees.
As a consultant, I try to reduce my billable hours as much as possible, then charge an appropriate amount for the value I have created, not the time spent, and this leaves me more time for more clients or leisure.
I can't speak to the prevalence of this mentality, but it rings true for my consultancy. The idea of maximizing hours is absurd. We do everything we can to minimize hours, thus maximizing value to the client. That's how we keep our clients happy, and make room for more business.
I sort of know what you are saying. Being dealing with so-called "server-side rendering" v.s. "static generated" recently, and these feel old / boring. It has been 15 years and mostly the same thing reinvented.
However, it is not a negatively thing. We may be able to setup IIS / Apache with Squid two decades ago to do similar things. The bar to do it now is much lower, and the tooling to help achieve that is much better overall (there are some not-so-great: Figma is a great design tool, but it doesn't translate to code directly unlike Dreamweaver / Borland VCL / Visual Basic, but I heard Framer is doing good on that front). That is part of the reason why there are so much more participation of labor in this industry: it is more graphical and easier to do (even terminal tools, largely do the similar things, are much more graphical nowadays!).
My company has a tech stack consisting of all the latest and greatest devops/tooling/cloud services, and an old timer like me wonders if that could have been just implemented as one C++ binary running somewhere.
Seeing all the JavaScript kiddies rediscover the speed and UX benefits of not using massive front-end JavaScript libraries to display simple web pages in the last few months has been alternatively hilarious and frustrating to me.
I feel it never really was about denying how effective plain web pages are but rather that faced with the choice of a wonderful DX with just JS, and a more difficult day to day with a mix of both, we picked the first. Sometimes at the expense of the end user, yaddi yaddi yadda, etc.
Good solutions for the "have your cake and eat it" scenario with exceptionally good DX are just now reaching some maturity.
There’s a legit issue in there, but us old’ns might have to own up to some of the problems we’ve caused (or even just failed to solve) and the legacy we’re leaving. ;) I’m mostly joking, but I honestly don’t think this is a young vs old issue, I think it’s a byproduct of happening to live through the time when the internet took over the earth right while programming exploded as a career. The amount of choice, complexity, scale, and expectation in software today is so much higher than it was 20 years ago.
Putting together a decent web app today that is competitive with what’s out there and doing it in a reasonable amount of time is something that just requires frameworks and library mashing. Even though I can fully empathize with your comment, from experience, and even though my beard is almost as grey, piling stuff I don’t understand together from yarn or npm is exactly how I start a new web app. My job recently switched from web to hardware, and the workflow changed dramatically into writing and scrutinizing every line of code, and complied instruction even. But even still in the hardware company there is an overwhelming sea of choice and complexity and an army of young and old programmers all borrowing and reusing code at all times, with everyone just treading water and understanding only the tiniest sliver of it all.
I think we have no choice but to embrace the fact that it’s no longer possible to avoid swimming in 90% code you can’t control or understand, and figure out how to better manage it and encourage people to snorkel under the surface whenever they can. I don’t think we should blame it on the kids though, they’re just trying to get by the same way we did, but in a different world than we had. The good ones will still shine through and be amazing, and the rest can learn their mistakes the long way just like we did when we were young and obstinate.
I definitely had some fears about it, and there are things I miss about web, but it was easier than I expected. I was reasonably prepared though, and it wasn’t as big a jump as my comment above might have made it sound, since I was doing C++ and video game programming before doing web dev, and my hardware job is centered around graphics and is still mostly software work.
If you're talking about web applications then I tend to disagree. The SaaS paradigm and the UI living in a browser are relatively new ideas that are still maturing. I don't think there is a lot of good "what was already there" and we're just seeing the evolution of tooling for this ecosystem, not completely decoupled from the evolution of the large companies that rely on this tooling. Not sure it's worth getting frustrated about... I tend to just stay away from it because I prefer to work in areas that are less fluid. And sure, sometimes there's just Not Invented Here syndrome and let's reinvent the wheel instead of using existing wheels. Nothing new about that either, it's always been like that.
All that said, the principles of how everything works are unchanged. People that only learn to use a framework are just not good software developers. People that understand the principles can work in any framework. This has always been true and is still true. There's a shortage of people that really know their sh*t and there's always been as well. That's great... I'll never run out of work (I might run out of motivation ;) ).
I once had an experience where I asked a younger developer why they didn't use cookies for a solution they were using JWT's for. Their answer? They didn't know how to use cookies.
I was bemused, their solution worked just fine, it's just all the extra infra needed when compared to cookies, which would have solved the problem just fine.
I'm in my mid-40's and I would apply that observation to scrum (and software dev in general). What I tend to see are a lot of very earnest people who are legitimately trying and the behaviors often associated with scrum are what they've been taught works.
Truly understanding what goes into successful software dev takes years of work and is more craft than algorithm, so I can understand the challenges.
The only thing I hate more than the ckusterfuck of the modern front end ecosystem is coming behind an “Architect” who doesn’t think they need them and reinventing the wheel badly.
