Alex Payne

The structural and core part of the issue gets muddled due to poor education/know-how among engineers (partly due to excellent marketing by VCs). See below an excerpt from Alex Payne's article at https://al3x.net/2013/05/23/letter-to-a-young-programmer.html

"
...
As a VC at a top-tier Sand Hill Road firm told me during a pitch several years ago when describing a conceptual feature in Simple that would let users easily and regularly donate a portion of their savings to charity, “let’s not waste time on that stuff; we’re here to make money”
...
".

There are a breed of VC's who project themselves as if their sole purpose in life is to help entrepreneurs realize their dreams and that there is a higher purpose for their VC avatar. Some believe it and mean it, and some pretend (It is important to keep up the pretenses in this business lest you get shunned by all starry-eyed entrepreneurs who come to valley to change the world). VC's exist to help their investors make money. They have a fiduciary duty to do so. When you are giving away a good part of your life (sleep, money) in pursuit of a dream, and getting into a financial transaction with VCs to do so; It is vital for you to understand how they operate, how they make decisions, are incentivized to behave, and also be cognizant of their true (ulterior?) motives. VC's are a vital part of the startup eco-system. I am not against them or how they operate. They are smart enough to be politically right and make themselves desirable…

Node is an asynchronous programming framework bundled with a largely async library. If you have 40 cores on your system, you would presumably run 40 instances of node for a CPU intensive webserver(using multinode etc). So the event handler won't get stuck as long as there are available cores.

What about a single core system? Well I guess a threaded/multi-process solution would time slice the fibonacci requests between two threads so that both requests are served in 10 seconds, instead of one request in 5 seconds and the next one in 10 seconds like the node.js solution. Does not sound much better.

If you have done any kind of systems programming, you would know that availability of asynchronous I/O is a life saver, and can simplify your locking model greatly. 90% of the issues you face when building such systems is that some module deep inside grabbed a lock and issued a blocking I/O request and now the rest of the system is bottle necked behind it. Node.js is basically trying to eliminate the possibility of the existence of such a module. This complicates the issue of I/O calls, but simplifies locking in the sense that you don't really need all those locks in your system. In node.js of course there are no locks. The complexity moves from reasoning about locks to reasoning about correctly handling I/O calls and responses. IMO, this is the correct place to move the complexity to, because locks are simply an abstraction the programmer built. When debugging the system, we have…

I recently tried Natural Stress Relief (NSR) meditation per Alex Payne's suggestion (http://al3x.net/2010/09/07/startup-health.html). The technique requires carving out around twenty minutes for meditation twice a day (morning and evening). Even with a schedule as flexible as mine (i.e., extremely flexible), I found this virtually impossible to maintain; forty minutes a day may not sound like much, but it is, especially since it has to happen at specific times (before meals, not before bed, etc.). For example, I work much better if I eat within 30 minutes of waking; since (according to NSR) you're not supposed to eat before meditating, that leaves almost no slack in my morning schedule. It's also incredibly easy to forget to meditate until an hour before you have to be somewhere, and then you have to (say) shower, dress, eat, and meditate in order to keep up with the program. (Actually, per the eating rule, you would have to meditate and then shower & eat. And possibly be late to your thing.) And you know how hackers operate on the Maker's Schedule? For me, meditation became one of those things that breaks big chunks of time in two. Not good.

NSR emphasizes the importance of doing two sessions every day. After a couple of weeks on the program, I found that the stress of scheduling the meditation, combined with the stress of missing the occasional session (and hence, horror of horrors, not following the program), completely overwhelmed any stress-relieving benefits from the…

A bit off topic, but I'm wondering if anyone has any ideas about how to remember to do something like this?

In specific, I mean as it relates to information management. E.g., a lot of things are solved problems for me, like using todo apps for todos, and some sort of "Everything bucket"[0] system for searching for information (per the link, I use the file system for this).

But things like this, things you want to try and implement, but unlike a todo, you have to wait for the right moment (i.e., use this technique to address a bad habit at the right moment), I can't figure out a way to use to technology to remember to do them.

(I'm aware some people don't like to use technology to solve these kinds of problems, but for me personally, technology has been tremendously effective in solving these problems when a system can be adapted to the problem. I'm just not sure what the system should be for this type of information.)

I've actually been thinking about this problem literally for over a decade, the first app I ever made was designed to address it[1]. This app is no longer maintained, because it didn't get enough users to be worth maintaining. Maybe an app like this is the right solution, and there's just not enough people who think it's a problem worth solving to support the continued development of a software solution? I'm not sure.

[0]: https://www.al3x.net/blog/2009/01/31/the-case-against-everything-buckets

[1]: https://1percenter.com/review/

In the context of views that are potentially odious but are tolerated in technology, it's perhaps worth noting that two of the instigators of this decision [1, 2] are respectively an avowed communist [3] and a socialist who serves on the board of a magazine that literally takes its name from the people who brought us the Reign of Terror [4]. Should they be barred from speaking at conferences because people might feel "unsafe" in the presence of someone who holds such views? Or should we learn to leave politics at the door, and be willing to listen to tech talks even from people whose politics we find repulsive? I for one endorse the latter view. Strange Loop is entitled to its decision, but I find it both craven and sad.

[1]: https://twitter.com/steveklabnik/status/606219754513264640

[2]: https://al3x.net/2015/06/04/wouldn't-censorship-be-exciting.html

[3]: http://blog.steveklabnik.com/posts/2011-12-15-marx-anarchism-and-web-standards

[4]: https://al3x.net/2015/03/03/jacobin.html

Corroborates a piece posted a few days ago on HN: http://al3x.net/2012/02/29/how-not-to-sell-software-in-2012.html

Point #2 on the list: "Don’t make it hard for me to try your software. If I can’t play with a trial version or sandbox immediately, I’m moving on."

Another piece of constructive criticism: promotional codes. I can't find the article now, but it argued lucidly that promotional codes are an obstacle to user sign-up: they prompt people away from the page to search for a discount/benefit instead of engaging a user immediately in the service. If the Shoplocket author is lurking about - might be worth setting up A/B testing to figure out whether the Beta Promo code is worth placing so prominently on the front page.

Other than that, looks great. Embedding seems like a smarter way to get connected with your audience than a stand-alone store. Best of luck!