The Silver Bullet Syndrome by Hadi Hariri
HTML-код
- Опубликовано: 11 сен 2024
- Subscribe to Devoxx on RUclips @ bit.ly/devoxx-...
Like Devoxx on Facebook @ / devoxxcom
Follow Devoxx on Twitter @ / devoxx
We love our silver bullets don’t we? Constantly chasing the dream that the next big thing will solve all our past problems. It doesn’t matter if it’s a language, framework, platform or library, we’re out there chasing it. Why? Well because it’s going to solve our needs, it’s going to solve the business needs. Well supposedly it will. And how much is it going to cost? Not that much, especially if we’re not the ones paying the bills. It’s about time we look at the hard facts and ask those difficult questions. Are we really looking for a silver bullet? Why are we constantly riding the technology bandwagon? Where is the churn going to take us? And at what cost?
You can always tell when a presentation is good and the subject is good. Just like great and stable methodology (engineering practices), it's timeless. I just found this remarkable presentation and watched it in July of 2023. This presentation is 7 years old and IT'S STILL SPOT ON and more applicable than ever! Thank you, Hadi Hariri. This should be required viewing for everyone (including the managers, users, and analysts) in the world of software because the fundamentals never change and neither do the ramifications.
The trouble is that the moment a technology (X) is stable, magazine writers and bloggers start producing articles asking "Is X dead?".
Been a dev for 25 years now, fantastic talk, hit the nail right on the head. It's really about finding the way to add value and writing good maintainable code to provide that value.
One of the best videos I've seen in the last 5 years
The content and insights shared in the video have stood the test of time, which is truly impressive. I really enjoyed watching it. Kudos to Hadi for creating such timeless content that continues to resonate with viewers even after all these years!
I think we adapt and adopt technologies based on our needs. The idea of certain approaches coming into and going out of "fashion" or popular trend seems like a symptom that we don't really understand our options and want to fit our problems around somep opular framework, rather than trying to choose the appropriate tool for our needs.
I absolutely agree though that we should be focused on talent and ability to learn, rather than "do you know this framework?". The problem with the job market for developers is it's completely framework/language-driven and the poeple hiring seem to want someone that knows a framework instead of someone that has the capacity to learn the framework.
Funny... When I say similar things around, I get to be "Crazy C++ guy who rants about new stuff"... It's good to know that you are not the insane guy, time to time :)
43:30 "Does it impact ARE pay?" should be, "Does it impact OUR pay?"
Great Presentation. Thankyou. Nail firmly hit on head.
Marvellous analysis of software development world.
mehmet ali kipcak no. just talking to the filterbubble - there is no analysis of anything in this talk
There is a V 2.0 of this talk. It’s a lot better.
This talk is so true, just compare it with current situation of our tech world 🌍 we have now kotlin for everything let's see where it goes
I like most of the conclusions stated about long-term, business, tech+ the 2 above !
Still the day JAVA is in the same pool with stability .... there is something wrong with the Java world, most likely it's not Java any more. JAVA = Good idea, poor realization + Too big to fail as of Today. It's not evolving, but constantly building-on-top. Getting bigger and bigger, sloppier and sloppier.
ps: I agree that javascript is worse in stability and maintainability, but still Java doesn't look better in its targeted area. Too bad for the good JVM idea years back, ahead of its time.
ps2: Also I don't understand, nor appreciate the show put in modern presentations. Are we there to talk tech or to watch one man stand show.
ps3: Feel free to disagree with my opinion, reality remains what it is.
this talk is ment to be ar least midly entertaining, and at most a relativistic approach to sweet talk us into the the tranquility, that the assurance entails, that wen dont need to worry about anything fundamentally new coming along, changing the way we go about our craft of programming, by only showing us examples of hyped technologies, that promised to be game changers, but actually didnt quite deliver, while deliberately ignoring or quickly brushing over actual disruptive technology changes.
Guess what? The examples are well selected to infer the proposition the talker wanted to conclude all along, and which the audience probably wanted him to arrive at.
been a dev for 15 years, I did not like this talk. It oversimplifies too much, and doesnt contain any meaningful proposition at all. At the beginning there is a disclaimer I should have taken more serious,but I didnt because the disclaimer itself was promising at least an entertaining talk.
But I was wrong. It is just the ssme ole "there is nothing on earth that could be done to improve programming substantially, yadayadayada" - of course with the usual disclaimer that we all should still learn new things anyway...
To me it just looks like the java/javascript community is just trapped into a mindset, without knowing it, like a fish knows nothing about the water it swims in.
Most stuff on npm or in javaland might actually be overhyped bullshit, but that same line of reasoning is also used, e.g. in this talk, to wipe away proven technologies and concepts, that were improved over decades, and resulted in theories, languages and tools like Elm, Haskell, Erlang, Lean, Rust .... that actually are - emperically provable - better in terms of programmer productivity, maintainability, performance, stability and correctness, than classic, imperative languages and the (poor) tooling around that.
Now functional programming seems hard, but with the goal in mind to write better programs, I would argue, that is actually easier to accomplish.
Now I have personal experience working in a mixed OO/FP shop, I found that many OO coders just read some headlines until they feel informed enough to have the feeling that they basically understand what it is about FP, that makes it special, and they might even be able to use some FP jargon convincingly, but they never ever work throuh lambda calculus, programming with recursion and learning some scheme, lisp or Haskell.
Instead they try to write webservice or go on codingame.com, and actually just write in the same thinking pattern that they are used to, only now they think, they actaully did FP and "get it".
Which leads to guys like this one, who just mentions FP, because he and probably most of his audience think that it is just like every other framework, and they already know it wouldnt be a game changer.
But if that were actually true, why not stick with assembler? Or manual memory management? Why use IDEs?
These things THEY ARE GAMECHANGERS, get it in your minds, SOME TECHNOLOGIES ACTUALLY ARE GAME CHANGERS.
Functional programming with e.g. Haskell, or maybe some derivatives of it like Elm, Purescript, Idris, Agda, F*, Lean, ... are or will be absolute game changers, they will literally change the way we do programming for an important share of developers and industries.
Actual game changers are often those that the current generation of programmers refuse to adapt or take seariously.
React os NOT a game changer, it is a ridiculous piece of technologie, trying to implement ideas decades old, in a language that is not equiped well for that task. And even facebook cannot do anything about that, they cannot defy the basic rules of math and logic and neither of the cognitive abilites of the brain.
basically, If the current generation of mainstream developers dont fight it, it is not a game changer.
One indicator for over hyped non game changers is btw wether the product has a website with a .io domain ;)
Mainstream developers often have good reason to fight a "game changer" technology that they distrust as a fad, because sometimes they are just that. There is a real cost in becoming invested in technologies that come and go, and lose support.
So how do we make a distinction between game-changing technologies and fads? I do not think it is hard, and it is not risky. Just WAIT. See if that technology sticks around for more than a few years. See if it becomes a sustainable change being borrowed, adapted, and evolved in other frameworks and products. Developers did not lose their job because they didn't switch from a console editor to the very first IDE. Nor did Java developers lose their jobs for failing to learn functional programming in 2010. But if a Java developer has failed to discern functional programming as more than a trend in the past 8 years, that's their own fault.