68 karma · joined July 12, 2012
I took a leap of faith from Mountain View and landed in Kochi.
Read the story: https://www.indiehackers.com/edit-article/@arunaugustine/my-long-journey-from-quitting-silicon-valley-to-getting-our-first-paid-customer-aeda7e0cb9
I wrote an article recently about my leap of faith and four pivots. The link is in my bio.
Perhaps, begin again.
For me recognizing that the count on the left is simply new items I discover out of possible 560 was part of the fun aspect of this surprisingly simple but engaging game
Does a duck, walks like a duck and talks like a duck, because it is a duck (being) ?
OR
Is a duck, a duck because it walks like a duck and talks like a duck (doing) ?
Then I read it the second time.
And the "chautauqua" (what the author calls the philosophical discussions) blew my mind!
I have read the book 3x so far, and the insights keep deepening.
So a new approach I am trying is the "GPU Pipeline of side projects". First, I choose to trim my list of side projects to a few important ones (4 is a number I like, so four). I work on them in a parallel pipelined fashion. So I have one that's more advanced, one that is being setup, one that is being fleshed out, one still in ideation phase (you get the idea).
Secondly, I realize that when building things, the novelty can come from "recursing down to the details". For example, setup a AWS pipeline for code deployment would mean, learning how to setup an Ec2 deployment, then a Chef or Puppet instance, then easy config management of them, best way to document our setup (gitbook etc) and so on.... So if we use our boundless curiosity, which is both a strength and a weakness, to look a little deeper, we will find enough novelty to keep going even in a "single" project.
What I realized is that one single project is like a LISP S-Expression. (project). You (eval project), and it returns (list sub-project1 sub-project2 interesting-research3 wonderful-idea4) All you have to do is keep eval'uating the sub-expressions till you hit an "atom" of truth to share with the world.
Makefiles I presume, will be hard to write by hand when:
1. Your project code base is large 2. It take large amount of time or very powerful machines to build sub-modules (V8 for e.g in chromium) so, you don't want to do it all the time 3. Conditional inclusion of sub-modules (for iOS vs Android if you have two separate set of files etc) 4. Sub-modules are pulled in from 3rd parties into your code base
Of course, that would introduce some privileged nodes, but if anyone can create such a node, as part of protocol and be part of this data routing network, isn't that still a distributed egalitarian network?
This problem and the proposed solution involves new ideas and changes across the boundaries of that layers of abstraction, so it would be hard to digest in a single sitting. Unless of course all this was synthesized in your own head :)
My guess is you would need need a more agile version of the Douglas Engelbart's "Mother Of All Demos", a functional prototype that shows everything works together in synergy to create more than a sum of the parts.
The best case would be if all the components of the puzzle are independently valuable, like Musk's SpaceX model.
Similarly for the startup lessons. A deeper (albeit painful) introspection into the mistakes made would make this a valuable post for others.
- I wonder if there is a systematic procedure than can enumerate the fixed properties for algorithms. I guess this is the hard part in formal verification theory.