Paul Graham had a great article on Lisp. In his view, Lisp programmers love Lisp because it offers extremely powerful features in a way that other programming languages don't. Those who don't understand Lisp are (rightly) skeptical. Their thought process goes something like, "I don't need these features, and I do my work just fine". In other words, they don't know what they're missing out on, and so it appears useless to them.

I've found this pattern of human thinking to repeat itself in countless places in my life. From politics to programming and everything in between, systems look like unusable chaos when you don't understand it and have not been able to derive a controlled benefit from it. Once you learn how to use it, everything falls into place, and you immediately see how blind others are to the system as you now understand it (the curse of knowledge).

Working with people effectively is a skill, and one as rare as competent programming. And when you don't know how to do it, it looks useless or arbitrary.

The problem is there's no easy way to know which things will actually make you more productive and which won't. Will switching to lisp make me more productive or will it just mean I have to re-write 30 libraries from scratch that aren't written in lisp? Will that productivity multiply as I hire more people or will the fact that it's hard to find lisp programmers mean my options to expand will be limited? Does lisp work well on large teams or does the fact that it's typeless and every programmer makes their own DSL macros mean that it's actually harder to share knowledge?

Will switching from framework X to framework Y really increase my productivity? Is it a matter of not understanding how Y is so much more efficient to build thing than X or is it just hyperbole/marketing/cult. Switching to different product management software, different game engine, different 3d software, different wiki system, etc etc .. How can I know. If I believed everyone I'd be switching every week.

For Lisp in particular, you're probably right about many of the tradeoffs. You won't benefit from a large ecosystem, you won't find as many job candidates (albeit likely a higher quality of average candidate), and it's probably not the best language for large decentralized teams that need to coordinate development (although, what language is?).

The lack of knowing you reference is exactly what I'm riffing on here. There are people who have leveraged Lisp features to huge benefit, and there's just no easy way to explain those features to people who don't use Lisp. "There's no way to say it in that language". To outsiders then, Lisp looks like a back-patting cult with no tangible benefits and yet an air of elitism. Similarly, those with "people skills" can't always explain the mental framework and skills they've built up to make themselves excellent at working with other people, but they can easily recognize those skills in another.

EDIT: Here's the article. http://www.paulgraham.com/avg.html

The whole thing is well worth the read, but for what I'm talking about here, you could skip down to read about the Blub paradox.

When I see someone who is a virtuoso of that I have a lot of respect.

This is an extraordinarily myopic view of business. Most firms do not create new tech; all firms (including tech startups) need individuals capable of selling, winning over the faith of others (recruiting), and who have an eye for creating business processes and operations for delivery, support, and so on. To watch engineers attempt to do all these things on their own is also a comedy.

This idea reminds me of things developers say to disparage anyone who operates on a higher abstraction layer than they do (e.g. Rust sucks cause it's not C. Ruby sucks cause it's for beginners. Salesforce sucks cause it's not real programming.)

Maybe 1/4 of people who want to be non-technical co-founders really bring something to the table.

It is a black comedy to see how many salesmen could not sell, how many recruiters cannot recruit, how many businesses recruit people at great expense to lose them because they use them in a boneheaded way, etc.

I've seen many people who think they are working at a high abstraction level while they are really ignoring a large number of inconvenient truths.

Given that so many businesses need web sites that are a variation on a theme I wonder why there isn't an accelerator that has a captive dev shop that is highly productive making e-commerce sites that are variations of a theme based on a fixed framework.

I'm continually amazed by the number of recruiters I work with who lack the communication skills needed to do their jobs in an environment where everybody's increasingly picky. You'd think they'd step up, considering it can mean the difference between a $30k year and a $200k one, but most of them continually choose low-effort, low-reward paths. It doesn't make that much of a difference to me whether any one recruiter can land me a role. I'll get one eventually. But it matters to the tune of $X0k to them. Boggles my mind.

I need to start coming up with filters to weed the grifters out. Spending 10+ hours on a homework assignment only to find something important wasn't communicated is getting old.

There is a common trope that developers lack social skills and business understanding and need a "people person" to "handle the business side." This is basically why almost every technical person at big companies is beholden to PMs (who may not even have any technical background) who get paid just as much, if not more, to write word documents, make powerpoints, and tell you what to do. And while it's true that a lot of developers have bad social skills, I'm willing to guess most developers who want to start a company and raise VC money don't fit that stereotype.

So maybe it's non-technical cofounders implementing a vicious cycle of grifting off the technical people, I think it's more likely it's just due to the fact that we have pervasive negative stereotypes surrounding technical people's ability to do non-technical things.

It’s not that technical founders don’t have people skills: they don’t have the time. Going full bore into product development only to be interrupted by a potential customer asking about pricing plans is a big time suck, but it’s vital if you are actually building a real business.

Wild speculation: It is the founders that have developed a deep understanding of both computers and people that are likely to be successful. These two domains are very deep and take a long time to learn well (say twenty years at a minimum). Studies suggest that generally people focus on one or the other (men generally focus on understanding things and women focus on understanding people). Find those people who did both at a young age and give them some resources to run a business and they might do very well. As Paul Graham said somewhere, these types of people are only likely to want to start a business as mundane as "make file backups really easy and reliable" if they will be very successful and that success will let them hang out and work with similar people.

Programmers tend to want to hack and not care about sales/marketing/everything else.

It turns out that doing "sales/marketing/everything else" is of significant value when building a business.

Well look, I already told you! I deal with the goddamn customers so the engineers don't have to! I have people skills! I am good at dealing with people! Can't you understand that? What the hell is wrong with you people?

@pkaye are you modeling a person who has poor people skills?

Its just a line from an old movie Office Space.

Have you seen Office Space?

But when a good part of your company involves marketing, blogging, content marketing, qualifying leads, talking to potential customers, supporting customers, dealing with advertising, going to conferences (where your target customer is,) that’s a huge amount of “non-technical” work that has to get done. Many technical founders consider a non-technical founder as somehow “less important” that the tech, but it’s definitely is the opposite. All the great tech in the world doesn’t mean jack if you can’t sell it.

> Many technical founders consider a non-technical founder as somehow “less important” that the tech, but it’s definitely is the opposite. All the great tech in the world doesn’t mean jack if you can’t sell it.

And all the marketing skills in the world don't mean jack if you have nothing to sell.

A technical founder who can create a product and market it with average efficiency can still be successful, unlike a non-technical sales guru with no product.

So I'd say the technical person is till the more important one.

P.S We're also ignoring the fact that many technical founders are also great at marketing themselves. Unlike a non-technical one, who isn't technical by definition.

The only flow in the logic for me in the multi-founder scenario is that if the other person is non-technical, they are automatically considered sales etc... by default. So you can get anyone who is not technical and meet the model; regardless of their skills. It's harder to prove someone is not good at sales vs a technical person (more relevant in younger founders).

The only argument I can think of against what I just said is that the other person is not heads down building so they have more time to acquire those skills.

I would think that sales would be easier to measure than tech because successful salespeople have a track record with dollar amounts sold.

I’ve seen people do really well at sales within one organisation completely fail in another.

Dollar amounts between salespeople are really only comparable within a given company and maybe not even then taking into account different territories, product lines and times.

Agreed. Sales in big companies is also extremely different than sales in startups. Hard to measure how much of the sales is happening because of big company X being your employer (carrying the weight of the process).