I can present a company that avoids all three.

Ready... fire... aim!

Perhaps of some interest: https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

I've seen people put things into software for no other reason than it's cool and they wanted to try it. I didn't realize that was known as cargo cult programming. My understanding of that term was that it referred to people copying code and data structures into software without knowing what they were for.

It's both.


The Goddamned Consultants are the worst with the cargo cult crap, and we've got someone high-up egging them on...

Me, I'd be a lot happier if people would stop arguing over what is the best framework du jour, stop neglecting a working stack just because it isn't trendy, roll up their sleeves and start taking some responsibility.

Peh.

As a recovering Node.js/Javascript developer, that resonates with me greatly.

Javascript can burn in hell. In fact, it's what keeps the brimstone hot.
I'd rather code in Perl

I was coding in Perl some 35 years ago. I would be BBSing on my 300 bps modem and my sister would pick up the phone and scream at me to get off the line ... what appeared on the screen I have to assume is parseable Perl code.

I'm not a fan of Perl, as several folks here know. I prefer my code to look legible.

(But then why, you may wonder, would I prefer to code in C++ if that's true?
It's complicated).

When using a scripting language, I'm fond of Python.

Some of the Rails programming I got into recently was pleasant enough.

JavaScript? Eh... I could take it or leave it. I don't have a problem with the language itself, per se, but I could see if you had to work with it across different browser environments where those different environments might make it annoying.

Java? That's a language encouraging a sort of broken mechanic with more broken-ness on top of a broken idea. It's so seductive, especially when you have things like Eclipse that makes it almost a visual language with its point-and-clickness (and, seriously, I do like that feature in the IDE), but when you have to do something large with it, and everything looks like objects just for fucking objects' sake, you want to just get something the fuck done, but it actively gets in the way, insisting you try to think like it, rather than like a human being.

cutting-edge while billing way more hours than otherwise would have
been required to complete a project.

Ding ding, winner winner chicken dinner.

Their architectural approach is "build a big huge webservice module deployed to a separate machine" for a small bugfix that should have involved writing a new .class or two and wiring them into the existing execution flow.

"Job security", I guess.

Software engineering consultants are mostly process focused, and significantly less focused on specific frameworks. The glut of frameworks and APIs today is due entirely to a breed of employee known as the "serial entrepreneur."
These guys are known for hopping from start-up to start-up, each time working with relatively recent (or inventing entirely new) technologies because it's the latest, greatest thing. They've never read Mythical Man-Month, and so are completely unaware that a silver bullet doesn't exist; or, they simply don't believe it, and are hellbent on trying to invent one anyway.

The result is a pile of mostly identical feature sets in otherwise wildly incompatible tools or languages, requiring otherwise responsible engineers to become generalists and forcing them to learn whole *classes* of technologies instead of settling down and focusing on a small set of orthogonal and portable tools. They decry vociferously how one should not reinvent the wheel, hypocritically ignoring that they did exactly that months to years ago when they spawned their niche of the open source community. (It also ignores the fact that I cannot remember when I last observed wagon wheels on a Mazda RX-7, but I digress; that's a rant for another time.)

Meanwhile, after they've bounced from their current place of employment, these serial entrepreneurs leave the husk of their flagship projects for the rest of the "responsible engineers" to maintain in their absence, devoid of documentation, crushed under the weight of schedules now coming due, and with the routine conflagration of operations infrastructure one tends to get with underspecified, immature technologies applied at scale to real-world problems.
My previous employment actually took measurements: 75% of our 12-man team's time was spent actively dealing with ops-related issues; only 20% remained for productive work. (The remaining 5% were spent in meetings and the like.)

More succinctly: beware the rockstar coder. They're dangerous, and have a propensity to build products to sell companies, not to satisfy customer demand.

What did I read recently? "Python where you can, C++ where you must."

Probably not a bad rule of thumb, although it sounds a trifle simplistic.

I don't know if I'd want to use either for web development.

2017-06-13 12:24 from fleeb @uncnsrd

Probably not a bad rule of thumb, although it sounds a trifle
simplistic.

I'm sure a highly paid consultant said it.

Most likely.

What did I read recently? "Python where you can, C++ where you must."

How about "use the language and framework the rest of the system is written in, unless you've got an extremely compelling reason to change that."