DEV Community


Discussion on: Why Older People Struggle In Programming Jobs

brianmcbride profile image
Brian McBride

Thanks for the thoughtful counter reply.

Yeah, I started off by saying I don't know you. And my ignorance is huge in that regard. I don't mean to offend or imply anything. I was sharing opinions based on what I heard (and even that is suspect as I am not best best empath myself!)

I think I hear, basically, all this shit has existed and now you've done it enough times, you don't want to deal with it. I totally agree with you. I did the opposite, instead of sliding back into developer-only, I moved to a company where I could be in charge to make the change. I still make many mistakes and probably cause some of the issues you mentioned, but I'm trying :)

For me, I'm living life with the analogy that we all walk on our side of the road, even if we are going the same direction. I'm responsible for my side, you are responsible for yours. We can't make others do better, we can't make them not have a crappy culture. All we can do is represent the culture we want.

So, again, I don't know you, and your counter-responses are well articulated. So I'll just reflect that from an outsider, it read a bit like a "bitch session" :)

And speaking of bitch sessions. I totally agree with you on hooks. Functional components could be faster in some benchmarks (Maybe?). At least I thought I remembered that. But, I suspect that early on, "Pure" functional components didn't have all that hook state management code in there.

The ONLY argument about functional components and hooks that I have heard of is "you don't have to deal with the 'this' keyword". Now we have useEffect, useMemo, useState, useContext, blah, blah, blah... Not only that, but front end developers are starting to put more and more app-wide state into their hooks or API calls that don't cancel out properly. So I guess Facebook thought to abstract it all away was better? I can see some of the arguments... but now there are new problems. So now Facebook has to create Recoil.js (basically Hookstate.js... sigh) to offer better performance as useContext sort of sucks at scale. I personally keep wondering why we just don't make Observables part of the ecma standard so we can use libs like RxJs even more efficiently. I mean, RxJs can make a state engine in a few lines of code and has way better operators for events.

I can definitely bitch and complain :) Next week I have a big tech talk on why GraphQL is leading us back into building monoliths (which is fine if you intended that) and the problems that will impose at the enterprise scale. It is so true developers keep repeating the mistakes instead of learning from the past.

Thread Thread
bytebodger profile image
Adam Nathaniel Davis Author

If you're ever bored and wanna read more longwinded stuff, check out some of my other articles. I've written a lot about JS's class hatred - and its fascination with all things functional.

And to your point, I will never quite understand the irrational fear that many devs have over the this keyword. When I first started using anonymous functions and arrow functions, I found those constructs to be far more counterintuitive than any problems associated with this. But I've heard from numerous JS devs who, for whatever, seem to have some kinda mental block when it comes to this.