Notes for Non-technical Founders Looking for Technical Co-founders

Jotted down after the N-th time I had to answer this. Probably partially applicable to technical founders who are just getting into the nubznz game.

In general

(... ok, maybe just in South-East Asia.)

• Read everything on google's page 1 for "non-technical cofounder", and page 1 for "why startups die" and you should be good to go.
• This is a website for matching co-founders (hopefully) https://www.cofounderslab.com/
• startupjobs.asia has billions of non-techs looking for tech-co-founders. Check it out to see what you're up against.
• Be super proactive in seeking first-hand, local-market advice, from recent non-technical founders who have bootstrapped their software operations via outsourcing. Ask everyone you know if they know someone, who might be willing to have a chat with you about their experiences.

In Malaysia

• https://www.facebook.com/groups/wckljobs/ <- you can post in detail about what you're looking for in a co-founder here. Non-detailed posts will probably be ignored due to the volume of non-technical founders looking for technical founders.
• https://www.facebook.com/groups/webcamp/ <- this is the parent group of the jobs group. No job postings here. But a lot of meetups between developers and designers are in this circle.
• MaGiC - has some funding. Headed by some chick who sold a company to WalMart.
• If you're raising funds, get ready to meet dingdongs at every corner. It's a bit of a bubble right now. dingdongs = inexperienced investors; it's a bit of a bubble right now. Not a good thing.

Bootstrapping: Coding a Web App

Your options are basically a bunch of scripting language platforms which have enough community support to be reliable. Ruby, Python, PHP, JavaScript are all viable candidates. Ruby is a bit of a mess (I'm doing that now), and PHP has a lower barrier to entry.

Second. You don't want to be writing things from scratch, so again a community supported framework within the chosen language would be necessary. Ruby -> Rails, PHP -> CakePHP, for example.

A Case for PHP

If you're planning on hiring in KL, you're probably in a better spot with PHP because KL is quite behind the curve on Ruby (supply of skilled labour).

For your own first-timer development infrastructure, EasyPHP and CakePHP might be the way to go, for Windows users. PHP is also (arguably) the closest relative (in this bracket) to ALGOL, which is the ancestor of stuff like Visual Basic which you may have used before, if you have done much work in Microsoft Excel.

A Case for Ruby

Globally, the Ruby language and the Rails rapid development framework, have the greatest community support in this bracket. If you have the luxury of time, then consider learning this stack instead.

A Case for Python

If your core product or service relies heavily (read: is how you make money) on crunching a lot of numbers fast, say a statistical analysis or mathematically algorithmic product/service, then Python is a good place to start. This is because Python has a high degree of adoption among the scientific (and thus finance) communities, with a lot of common/basic/popular mathematical libraries that can crunch numbers fast. You'll figure out the details of how this works later, but for now just look in this direction.

A Case for JavaScript

If your core product or service relies heavily on user-interface design, then you probably want to start with JavaScript, as you'll need it to get prototype user-interfaces up and running for web or mobile applications. JavaScript can also be used on the server-side to write infrastructural software, so consider that a bonus.

other hubris...

Personally, I've been interested since 2008 in a pattern that seems to occur all over the place. This would be in the "grand-unified market-clearing social-network," problem. Analytics wise you just need lists of "stuff I have," and "stuff I want," - the rest is analytics ops work. Every market can be modeled like that. Just my 2sen.

Lost in Stupid Parentheses

Ruby:

A subroutine is invoked by calling it name with parentheses around its arguments; parentheses can be ommitted, except when you want to pass the subroutine's output to another subroutine within the same expression, unless your first subroutine has arity-0; however you should cato canways use parentheses around arguments, except in instances frowned upon by the community-maintained style guide, such as in a DSL.

oCAML/Haskell:

Fuck all the parentheses.

In any event we're still all lost...

Extended Ruby hate

(I kid):

**Too Many Ways To Do Anything**

- See the Wiki book's page on Ruby: on literals (particularly Arrays and Hashes), and function calls.

- Sigils. Too much Perl here for me.

- Two types of closures, one of which reacts to "return" like a block (in C) and the other like a function (in C). [C just used, as a common example.]

1. Ruby wasn't initially designed to have closures.

2. Methods on classes, are designed in the OOP sense, as interfaces to objects.

3. Proc class objects are "procedures", behaving like blocks of code in parentheses, which at the time of their definition will "close over" the values of variables used in their definition ("at interpretation time"), and which may be defined with free variables so that varied input can later be passed to the Proc class object resulting in varied output. However with regards to the "return" keyword called inside a Proc class object ("at runtime"), a Proc class object behaves like a block of code, and control will be passed not to the nearest assignee of the Proc class object, but to the caller of the nearest surrounding function. Also, it behaves like a block of code in the sense that extra variables assigned in the Proc class object's scope ("at runtime") in the form of extranuous arguments, are simply ignored if the Proc class object's number of free variables ("at interpretation time") were lesser than the number of arguments passed into the Proc class object ("at runtime").

Proc class objects can be called explicitly, or implicitly. Explicitly, you call Proc.new, and do stuff with the new Proc class object. Implicitly, there are times when you simple apply the syntactic sugar x {:some_block}, and it creates a Proc class object accessible only to x.

4. The "lambda" keyword, recently introduced, produces closures that are like the anonymous functions of many other languages. Extra arguments passed in ("at runtime") which don't fit into the free variable schema ("at interpretation time") will throw an error. "Return" called inside a lambda simply terminates execution flow of code in the lambda, and passes a value to the assigner of the lambda's value. [bonus: ->(){} syntax]

At some point I'd like to open up Ruby's AST and see how these implementations are related under the hood.

Growing pains, I suppose, just like Python, and PHP, and... Javascript? Or is the latter actually the stablest of the lot now? I don't know, but I'll find out.

Education. My Favourite Thing.

Let's Kill the College Major

This article came up in a forum. My comment:

Relatedly, I spent 50% of my undergraduate figuring out why university syllabi in the US are as un-MECE as they are. Back to OP tho,

Short version: one needs to take a means->ends approach to this.

ActivityX can be "an academic program", "a time of private study", or anything else.

1) if the objective of activityX is to (a) train people to question their assumptions, and the assumptions of the world around them [philosophical driver], (b) figure out what they're going to specialise in later in life [self-discovery driver], then no-majors is the way to go; everyone should be a generalist;

2) if the objective of activityX is to (a) equip people to get jobs [bottom-up economic driver] (b) create skilled labour for industries [top-down economic driver], then majors are definitely the way to go; in fact there should be minimal or zero general education in the syllabus, specialisation would be best.

3) if the objective of activityX is a bit more J (as in P vs J), and intending to create super-hero quality folks who have both 1) and 2), then heck... you're super, right? Do'em both in four years total.

And that's pretty much what the education industry looks like. The last time I checked circa 2003, there were 3000 registered tertiary organisations in the US. 100-200 made it to a list of "top rankings". The schools in the "top 20 colleges / top 20 universities" consider the others dross, and the schools in the "top 5 / top 5" consider all the others dross. It really is quite the rat race.

I went to a top-20 liberal arts college, and the top students gunning for (2) above would triple major (physics, economics, math) and got get $60,000/year jobs in investment banking - but they knew they weren't in these schools for the liberal arts program - they were there because they were on scholarship.

I was on scholarship too, but I was a type-(1) specialist, so after figuring out the economic drivers of the college syllabi, and deciding that there was nothing I could do to fix it, I spent the next two years finishing a major in philosophy (easiest damn B in the house) and funnelling all my resources into independent study of information science in the library. (My home country has shitty libraries, so I figured I'd make the most of it while I could.)

AI and Nukes

Buzzfeeds all over the world picked up on Musk's tweet.

"... potentially more dangerous than nukes..."

Why else would AI be interesting? It's everyman's chance to contribute to the total and complete redundancy of the human genome. It only happens once every epoch or so, you know.

Praps a reason a HAL-esque AI future works for me, is that I already entertain the thought that tossing idealists on the pyre is efficient.

"Is it working?"

So a bloke asked if my profiles on Internet dating apps attract attention, and offered to find me a date. Believe* it or not, these profiles are not primarily there to get me dates. These profiles are works of art - and art is entertaining. I'm quite happy to admit that they are bad art, if anyone feels that way.

Writing is an experiment in representation. It is one of many crafts. Through craft, we allow ourselves to discover patterns that are not immediately obvious without work. (Craft is work.) That's why putting up profiles is entertaining. That's why publishing on social media, is interesting. That's why going for job interviews, is interesting.

Maybe that's why so many women on the Internet (and elsewhere) wear so much make-up. I wonder how many are actually banking on social media as a channel for love and relationships (probably a large fraction, and I'd like to know the exact number).

(*It's much more fun to just meet people IRL, which is where I prefer to go shopping for relationships whenever I can afford it - and I haven't really been able to afford it in years - my sum expenditure there has probably been under $100 almost two years. "Other" work, has been rather consuming. :) )