Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.cornell.edu

Post reply on HN
Print view View original

71–80 of 354 posts

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

#71

Post by tamimio »

This is known to everyone who worked with these corpo drones, that language is just to look smart and give the optics of being knowledgeable and professional, and it doesn’t end there, I also personally add to that anyone who jumps into XYZ bandwagon trend that are being used by popular silicon valley companies, like open office environment, scrum useless meetings, the forced harmony, daycare level team activities, among many more.

And you can get the gist of that company or people during the interview actually.

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

#72

Post by gavmor »

domga wrote: post #66
antonymoose wrote: post #58

Earlier quoted context omitted.

Wildly controversial! I look at OOP Patterns as standards and practices. The same way we have building codes for staircases the framing of walls and electrical installations to prevent injury or collapse or fire. Sure, you can dodge a lot of design pattern paradigms and still make a working application that makes money. You can also invent your own system when building your house and maybe nothing bad will happen. Th…

A decent chunk of OOP patterns was due to lack of language features, notably passing and returning functions

A lot of patterns have become frameworks, or language features, yes. It's just paving cowpaths.

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

#74

Post by duped »

CGMthrowaway wrote: post #43
rdevilla wrote: post #16

I suspect this is why formal languages exist; as a sieve to keep the hordes of fools at bay, and a system for turning bullshit into parse errors. We are undoing much of this progress by now insisting everything be expressed in natural language for a machine to translate on our behalf, like a tour guide. The natives will continue to speak amongst themselves in their mother tongue.

>a sieve to keep the hordes of fools at bay Corporate speak as a signalling mechanism is only effective among the "clueless" in the Gervais model. If any CEO tried to talk 1:1 to a competent board member that way, they would lose all credibility. Once you've operated at a certain level you get it >a system for turning bullshit into parse errors. This is the (cynical version of) the framing I tend to hold about corpor…

> Which is not to be read as a necessarily "bad" thing

I (and many others) read it as "dishonesty"

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

#75

Post by sillywabbit »

RobotToaster wrote: post #18

To analyse the impact of this study I recommend that we set up an interdepartmental committee with fairly broad terms of reference so that at the end of the day we'll be in the position to think through the various implications and arrive at a decision based on long-term considerations rather than rush prematurely into precipitate and possibly ill-conceived action which might well have unforeseen repercussions.

Rushing prematurely into precipitate does sound pretty dangerous.

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

#76

Post by layer8 »

domga wrote: post #66
antonymoose wrote: post #58

Earlier quoted context omitted.

Wildly controversial! I look at OOP Patterns as standards and practices. The same way we have building codes for staircases the framing of walls and electrical installations to prevent injury or collapse or fire. Sure, you can dodge a lot of design pattern paradigms and still make a working application that makes money. You can also invent your own system when building your house and maybe nothing bad will happen. Th…

A decent chunk of OOP patterns was due to lack of language features, notably passing and returning functions

Since a single-method object easily serves the role of such a function, that’s simply not true. Looking at the 23 GoF patterns, I can’t identify any that would be obviated by having first-class functions (or lambdas, as many OO languages nowadays have). Some of the patterns can employ first-class functions (e.g. an observer could be just a callback function reference), but the pattern as such remains.

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

#77

Post by scott_w »

irishcoffee wrote: post #70
domga wrote: post #66

Earlier quoted context omitted.

A decent chunk of OOP patterns was due to lack of language features, notably passing and returning functions

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

I recall a lot of this comes from Java 5/6 where I think passing function pointers around was difficult, if not impossible. Back in those days, I had many a conversation with a friend who would ask "can Python do pattern/feature X?" to which I'd respond "it doesn't need to."

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

#78

Post by encom »

VorpalWay wrote: post #42
eucyclos wrote: post #35

I thought tfa would say seeking synergy is a sign one is struggling with ones own deliverables so one tries to add value elsewhere in the organization. Is synergy really such a poorly defined term that it's synonymous with corporate bullshit?

Yes. (There are other phrases too that should be red flags such as "strategizing", but "synergy" is probably the poster child).

>other phrases

"Pipeline". I hate this so much. At a previous job, it was used so much by management it became a meme on the production floor. When asked how many units had been sold, there was always a big number in the pipeline, when the real actual number was zero.

It's a non-commitment word. Whatever is talked about may or may not happen or exist. Maybe it's ignorance or a straight up lie to shut up the people on the floor, but "pipeline" works maybe once or twice and then everyone is onto your bullshit.

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

#79

Post by ndriscoll »

irishcoffee wrote: post #70
domga wrote: post #66

Earlier quoted context omitted.

A decent chunk of OOP patterns was due to lack of language features, notably passing and returning functions

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 everywhere.

In a decent language with functional programming and generics support a lot of GoF patterns can be directly encoded as a simple type signature where you receive, return, or both some function, so there's not really much else to say about them. Like half of the behavioral patterns become variations of the interpreter pattern.

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

#80

Post by throwway120385 »

antonymoose wrote: post #58
alcasa wrote: 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.

Wildly controversial! I look at OOP Patterns as standards and practices. The same way we have building codes for staircases the framing of walls and electrical installations to prevent injury or collapse or fire. Sure, you can dodge a lot of design pattern paradigms and still make a working application that makes money. You can also invent your own system when building your house and maybe nothing bad will happen. Th…

Design Patterns is more like the Human Factors and Ergonomics Handbook.

You can have your building engineered, in which case building walls out of 2x6's 16 inches on center is not off the table, but neither is a mortise and tenon timber frame with partition walls. In that paradigm, the code tries not to be descriptive of an exact technique but only gives you criteria to satisfy. For example you could run all of your electrical wiring on the outside of the walls or on the outside of the building, and you could use ramps instead of staircases. It only talks about ingress and egress for fire safety, and it explains how you're supposed to encase wires, or if wires are not encased it describes the way the wiring must be sheathed to protect the occupants.

You can heat your house entirely with an open fire, and the code speaks to how to do that safely. So it's unlike "design patterns" in a lot of ways in that the code tries to accommodate the kinds of buildings we try to build and the ways in which we modify buildings because that's easier than saying "these are all the allowed ways of building an entry staircase." Design Patterns are more in the latter category.

Post reply on HN