It saddens me that people advocating mainstream technologies describe "smart programmers" as unable to ship or make pragmatic choices. There is absolutely no evidence of that. To me it just sounds like sore losers talking. I've never met anyone voicing that critic who had actually tried both approaches.

In my opinion, average-level programmers on critical projects with deadlines will quickly cripple your team's ability to deliver due to technical debt, and throwing 3x more of those easy-to-hire/fire men at it won't solve the issue.

I've chosen such an "esoteric" technology for my startup, because we had ambitious technical objectives, and it proved extremely beneficial - we would never have been able to deliver a system so robust so quickly with mainstream technologies (which I know because I've used those, so I'm in a position to make an informed comparison).

There are legitimate uses of both established and cutting-edge technologies, but from what I've seen the people who fiercely advocate mainstream technologies are more often reluctant to leave their comfort zone than making pragmatic, informed choices.

You'll sometimes see Python people use not the word "smart", but the word "clever", with bad connotations. "Clever" programming, in this context, means valuing line/character count or showing off unusual algorithms or language tricks only the "clever" programmer knows, at the expense of clarity and maintainability.

So, for example, the mundane way to square a number in Python would be:

    def square(n):
        return n**2

The "clever" way would be:

    from itertools import count, ifilter, islice
    s = lambda n: sum(islice(ifilter(lambda n: n % 2, count()), n))

The first one was clear, readable, easy to understand and maintain. The second one is tricky to read, requires some thought to work out what it's doing, and is written to show off knowledge of a slightly-obscure algorithm and the way to implement it in Python.

It's an interesting problem. I always strive to write clear code, but clear and obvious code for me could be confusing, weird and "clever" to others.

I joined a .NET shop two and a half years ago. At the time they were targeting the 2.0 runtime, so one of the first things I did was to include LinqBridge for all the Where, Select, etc IEnumerable extension methods. I'm used to functional programming so that kind of stuff is what I use all the time. Not everyone was familiar with it and got clearly confused, but they picked up quickly, saw the utility, and today everyone is onboard.

So, I think there are two sides to it. Of course overengineering without considering understandability and maintainability should be avoided. But you shouldn't shun or even forbid language features because you don't understand them. I know of places where async/await are banned because the programmers cannot be bothered to learn how to use it. That's not what I think the programming profession should be about. C# regularly gets new language features, and I make sure to pick them up and use the ones I find useful. If someone thinks we shouldn't use some feature, I'm happy to have that discussion, and I will abide to what my team agrees to, but the reason better not be "because I don't understand this feature"!

What you call "clever" seems more like "complicated".

Yes, but there are people -- I've encountered them! -- who look on this as a way to show how "clever" they are, and consider it a good thing.

It's like Perl golf take to an extreme.

(admittedly, some of my co-workers and I have been known to golf our interview questions into ridiculous one-liners, but we do it for amusement value, not because we'd ever write production code that way)

It's a reaction to the Perl community, which whom Python once competed. Perl programmers absolutely loved writing very clever "one liner" programs (look up Perl Golf). Python programmers therefore took pride in writing code that wasn't "clever."

It is somewhat multifaceted.

First, I have yet to see a wave of mainstream technology that lasted more than 2 seasons. Bonus points if it truly solved a problem that businesses have. (Note that this is distinct from solving programmer's problems.)

Looking at my children in the corner playing pbskids, I am struck by how much more productive designers were with Flash and related technologies than they have yet to become with any of the current technologies.

Second, I have yet to be involved with a major "mainstream" technology choice that did not crash and burn terribly. These choices have often ended in public disaster for companies. It has truly become amusing.

Now, does this mean you can't make it work? Of course not. But, with the numbers as they are, realize that even at 1% or less... you actually aren't that unique in the world. But your experience still doesn't scale.

(And I realize this last criticism can relate to me, as well. This is why I won't personally stone wall any choices. I do ask pointed questions about when we will get to focusing on customer's value. So long as we are answering that, I just don't care on the technology anymore.)

> First, I have yet to see a wave of mainstream technology that lasted more than 2 seasons.

Is technology codename for web framework now? How about C, C++, Java, the JVM, Unix, OpenGL, Directx, Windows, .NET, Python? Aren't they also considered technologies?

This is precisely why it's such horrible word. How to compare C++, Unix, OpenGL, MS SQL Server, and TCP? Those all are thrown in the same bucket by calling them "technologies".

I'm torn. At face value, fair point. However, each of those has had a rocky road to success. At best.

Oddly, the one that has had the most success is objective c and swift. And that is successful because it is the only game in that town. Despite people trying to make other technologies work.

Compared with how many places failed by picking the new hotness. This definitely includes Java. It took a while before server side became a hit.

Actually I would count the skills you describe as "smarter." The fact that we don't all assume this is a sign something is wrong. Maybe it lies in that I don't remember too much emphasis in CS education on legibility and maintainability, beyond some token "practicum" classes that focused just as much on the many other "practical" topics like version control, working together, unit testing, etc.

The best programmer I ever worked with had an incredible ability to produce straightforward, simple code, that could have been written by "any fool" ... if "any fool" had gotten incredibly lucky. His code looked so obvious in retrospect, like anybody could do it. He made the difficult look easy. I call that very smart, and you desperately want brilliant people like that.

The programmers I've worked with that were traditionally "brilliant" in the sense of quickly coming up with "clever" but hard to maintain solutions only count in the middle of the pack, and I dreaded working with their code. Their code was more likely to not last as long and be thrown away in a refactor.

So I learned to aspire to be more like the first than the latter. And in doing so I saw just how damned hard it is to create simple looking "any fool could do it" solutions to hard or even medium problems. So many times I thought something was clear, but it was not to others. So many times I only finally thought of the architecture that would make it possible to write it simply and legibly after many iterations through other designs that generated much more complex "clever" code. It made me gain incredible respect for the amount of smarts and experience it takes to generate simple, easy, boring code that anyone can easily read and pick up.

Those are some good points. Sometimes, though, you come across some new tricks (perhaps not that new, but anyway) that you really wish your coworkers would get on board with.

E.g. - Our current big project at work uses a lot of Javascript. My coworkers are primarily die-hard Java developers (I know Java, but I don't "live" there...). As Douglas Crockford said in a presentation "[those people] will go to their graves, never knowing how miserable they were".

Rather than writing a bunch of classes with one meaningful method ("Executioner", anyone?), I would rather use FP / higher order functions techniques (e.g. - partial function application, such as in Ramda.js). Also, the idea of anything approaching metaprogramming is very scary to them, rather than pasting in many copies of the same stuff with minor variations. Perhaps it's ("custom") abstraction in general that is scary, since so little is documented in most industry standard practice code.

At what point do you ask your coworkers to realize that the eighties are over, and [static] OOP is not the one true hammer of sole best practice any more???

Further aside: it's funny that in popular use, "abstract" means "unintelligible", but in math, it means "well defined shorthand", for the purposes of making bigger problems approachable, at all.

If you think abstract is bad - wait until you see what civil engineers think 'concrete' is!

Oh, I agree that trying to write Java in JavaScript is frustrating. To be fair, JavaScript is a language that cries out for some kind of structure to be imposed upon it.

Sure. Good luck getting the unwilling to follow the structure, though.

I mean, it depends on the structure. Maybe a crummy one was chosen in your case. The fact that individual shops are rolling their own or choosing their own structure means on average they have a poorer one than a language that picks good defaults to begin with. But you have to pick something, or you'll have 6 developers doing 6 different things and nobody will be able to read anything

There is an old parable about that:

https://blog.oxplot.com/i-saw-what-he-meant/

Oh, that's wonderful, thanks for posting it! That parable says precisely what I was trying to say, but more succinctly and beautifully

Usually, though, there is a continuum between the "code a well known and well understood problem quickly and maintainably" and "figure out the math/algorithms to do do it in a new way". If you can stay closer to the latter, that is a competitive edge too. (Provided you don't bungle the basic stuff in its pursuit). I remember this thread from a few days back when I asked about Mathematica:

https://news.ycombinator.com/item?id=12473688

A relevant section from PG's How to make Wealth [1] essay:

"Use difficulty as a guide not just in selecting the overall aim of your company, but also at decision points along the way. At Viaweb one of our rules of thumb was run upstairs. Suppose you are a little, nimble guy being chased by a big, fat, bully. You open a door and find yourself in a staircase. Do you go up or down? I say up. The bully can probably run downstairs as fast as you can. Going upstairs his bulk will be more of a disadvantage. Running upstairs is hard for you but even harder for him.

What this meant in practice was that we deliberately sought hard problems. If there were two features we could add to our software, both equally valuable in proportion to their difficulty, we'd always take the harder one. Not just because it was more valuable, but because it was harder. We delighted in forcing bigger, slower competitors to follow us over difficult ground. Like guerillas, startups prefer the difficult terrain of the mountains, where the troops of the central government can't follow. I can remember times when we were just exhausted after wrestling all day with some horrible technical problem. And I'd be delighted, because something that was hard for us would be impossible for our competitors."

[1] http://paulgraham.com/wealth.html

The one thing I've learnt is that often a "dumb" programmer with domain expertise is far more useful than a smart programmer without. While the smart programmer might be able to implement a clever optimization or spot a subtle bug in some corner case, the domain expert will point out that your perfectly optimized, bug free code is built on entirely incorrect premises.

>To the contrary, programmers with the ability to deliver and iterate working code quickly is what is needed -- and especially without overengineering, or inadvertently creating huge future technical debt due to inexperience.

That requires smarter programmers.

It's just not the kind of smart that correlates with knowing technical trivia or being able to write out a binary tree algo on a whiteboard.

There's a cultural prejudice against overengineering in the python community whereas in the Java community (possibly Scala too) there is something of a cultural prejudice in favor of overengineering.

I think what you're looking for is wisdom, not smarts.

I call it smart vs clever.

If you're doing a bunch of "clever" things in your code, you or your co-workers are going to hate it when you have to come back and figure it all out again later.

Smart developers can make the difficult look simple.