Live data from Hacker News

Workers who love ‘synergizing paradigms’ might be bad at their jobs

news.cornell.edu

111–120 of 354 posts

Re: Workers who love ‘synergizing paradigms’ might be bad at their jobs

#111
post #61
post #21

Earlier quoted context omitted.

Maybe controversial, but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS.

OOP pattern were useful for people stuck in a pure OOP language (say Java 1.4) And needed to make something understandable. Today, when many languages, including Java, have reasonable functional programming support, a large percentage of the patterns are over complicated. Just look at the list, and see how many can be replaced with less boilerplate by passing a function, doing some currying, or both.

That doesn't replace the pattern, it just does the pattern by a different name. Design Patterns was never about OOP - the publisher added OO to the title because that was the fad at the time, but the patterns happen in other systems as well, they are just implemented differently.

Re: Workers who love ‘synergizing paradigms’ might be bad at their jobs

#112
post #67
post #55

"synergistic leadership" or "growth-hacking paradigms" are, in my opinion, what my teenage son refers to as "brain rot". I don't know where these people come from who make up these terms, or what childhood trauma has done this to them, but I absolutely cannot tolerate any of it, it makes my skin crawl.

It's a bit better: They are forms of obfuscation and lowering information in a channel. They are designed for environments where being clear is very risky. In certain organizations, you are better off being unclear than asking for approval or consensus on a tricky decision: You produce an incomprehensible, vague mess of a message, and avoid argument, as argument in those places leads to paralysis. Now, does this mean…

There’s also a compounding effect. Even though they tend to be a bit hand-wavy, you can use the words synergy or paradigm in a sentence and still have it confer some kind of meaning. However as soon as you utter the phrase “synergistic paradigm” you are obviously and completely full of shit.

Also a lot of corporate jargon does have specific connotations for skilled communicators to send a message that is seemingly polite but is actually saying something controversial that is picked up only by those in the room savvy enough to understand. In skilled hands it’s very useful, in unskilled hands it’s complete gibberish. In many ways that’s a feature as the clueless cargo-culters quickly out themselves, and then the smart leaders can use that knowledge to route around them or deploy them in non-harmful ways. All without any overt confrontation ever taking place.

Re: Workers who love ‘synergizing paradigms’ might be bad at their jobs

#113
post #49

Earlier quoted context omitted.

When applied without thinking about why. Yes. Except dependency injection. I really can’t imagine why you’d ever not use that. I suppose it’s possible to overuse, but you’d still have better code than without. Certainly more testable code.

Because code becomes harder to understand. With direct dependencies, if you are trying to understand some code that calls some function and what it does exactly isn't completely obvious, you can press a button to go to it, understand it, and come back. With dependency injection it depends on what is going to be inserted during runtime, so you can't.

If you can press a button to understand what is going on, "it’s possible to overuse" most definitely applies. Dependency injection, as the name implies, is for dealing with dependencies — things that you cannot observe until runtime.

Hence the benefit to testing; allowing you to inject a deterministic implementation while under test.

Re: Workers who love ‘synergizing paradigms’ might be bad at their jobs

#114

Earlier quoted context omitted.

Are you referring to function pointers? I believe C has allowed passing and returning functions from... the jump, no?

Not just function pointers. E.g. in Scala: def addX(x: Int): Function[Int,Int] = { y => x+y } addX(5) then returns a function that adds 5. So closures, which are equivalent to objects (behind the scenes, the compiler needs to allocate a structure to remember that 5 and know the "member function" to call to do the plus), and usually more straightforward. Once you get used to doing this, you realize it's useful everywh…

Pardon my ignorance, isn't that a lambda in c++?

Re: Workers who love ‘synergizing paradigms’ might be bad at their jobs

#115
post #21

Earlier quoted context omitted.

Maybe controversial, but I believe a lot of OOP/Clean Code patterns are the software equivalent of corporate BS.

I agree. Mostly they are copes for lack of first-class functions and multiple dispatch. Go through GoF and you will see this is the case for 80% of the patterns. OOP has no firm theoretical foundation, unlike FP which is rooted in the formalisms of mathematics.

Ok, I'm in an argumentative mood, and I think this is more true than not.

The first theoretical foundation of OOP is structural induction. If you design a class such that (1) the constructor enforces an invariant and (2) every public method maintains that invariant, then by induction it holds all the time. The access modifiers on methods help formalise and enforce that. You can do something similar in a functional language, or even in C if you're disciplined (especially with pointers), but it was an explicit design goal of the C++/Java/C# strand of OOP to anchor that in the language.

The second theoretical foundation is subtyping or Liskov substitution, a bit of simple category theory - which gets you things like contravariance on return types and various calculi depending on how your generics work. Unfortunately the C++ people decided to implement the idea with subclassing which turned out to be a mess, whereas interface subtyping gets you what you probably wanted in the first place, and still gives you formalisms like Array[T] = T (or even X[T] = T and X[_] that acts as a (side-effectful) function (T => void) but composes with a Consumer to get the type system right [1].

Whether most Java/OOP programmers realise the second point is another question.

[1] https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

Re: Workers who love ‘synergizing paradigms’ might be bad at their jobs

#117
'The results revealed a troubling paradox. Workers who were more susceptible to corporate BS rated their supervisors as more charismatic and “visionary,” but also displayed lower scores on a portion of the study that tested analytic thinking, cognitive reflection and fluid intelligence. Those more receptive to corporate BS also scored significantly worse on a test of effective workplace decision-making.

The study found that being more receptive to corporate bullshit was also positively linked to job satisfaction and feeling inspired by company mission statements. Moreover, those who were more likely to fall for corporate BS were also more likely to spread it.'

How is this a paradox?

Re: Workers who love ‘synergizing paradigms’ might be bad at their jobs

#118
If anyone wants a chuckle, I vibe-coded an endless supply of "synergizing paradigm" terms as a slideshow for a fake corporation. It's fun to put on in the background on a tv somewhere to see if anyone notices.

https://brightpath-global-solutions.com/

Edit: repo link: https://github.com/chronick/global-business-solutions

Re: Workers who love ‘synergizing paradigms’ might be bad at their jobs

#119

If anyone wants a chuckle, I vibe-coded an endless supply of "synergizing paradigm" terms as a slideshow for a fake corporation. It's fun to put on in the background on a tv somewhere to see if anyone notices. https://brightpath-global-solutions.com/ Edit: repo link: https://github.com/chronick/global-business-solutions

A delightful update to https://m.youtube.com/watch?v=RXJKdh1KZ0w
Post reply on HN