akg's comments

I think what makes one great in craft is deeply caring about the craft. It's not just a means to an end, it is something one truly feels passionate about. When one has that visceral calling for something, I think they find ways to get better at what they do. The greatest attribute of humans is that they adapt and learn.

I know several people who could be great programmers, in terms of the ability to solve complex problems, but they do not care enough about their code to do so; which is fine, they find passion elsewhere.

Programming is not for everyone, but I do think that it can be learned over time with patience, passion, and practice.

Simply beautiful! I love how advances in technology (like the ability to view these fractal patterns) allows us to expand art as well as our understanding of the world around us.

Right, but I think Mark's point was that great companies can also be built slowly. These may not be the "best" companies but great one's can be built brick-by-brick. I feel that most startup founders today strive for a large funding round before focusing on building a solid business foundation.

For some businesses, it is not possible to create value until you have a large amount of capital in-hand (e.g., Aerospace, Automobiles) but for most it is and we shouldn't lose sight of that. People solve problems, not money; and it is unlikely that a large pile of cash will be the solution to your problems if you don't first start with a good business model.

I believe GMail already does the chat <-> email conversation quite seamlessly

It's like PG says in his essay,"The Island Test":

"The notebook and pen are professional equipment, as it were. Though actually there is something druglike about them, in the sense that their main purpose is to make me feel better. I hardly ever go back and read stuff I write down in notebooks. It's just that if I can't write things down, worrying about remembering one idea gets in the way of having the next. Pen and paper wick ideas."

Although, I find that most of the time I toss-and-turn b/c my mind is continuously thinking about solving some problem at hand. It's 3am and I should go to bed, otherwise I'll be a zombie at the office tomorrow, but there is this problem that I have to stop thinking about first. Creativity doesn't really follow the same schedules as "business hours"; I would suggest that if you can, stay awake thinking/working/doing until you can't anymore.

Would be really awesome to see a write up about what powers all this on the back end.

Awesome! It would be really cool to see an overhaul of current research papers to be more suited in digital form. A static PDF with words just doesn't do justice when you can enrich research and content with animations and interactivity. Heres an excellent example: http://worrydream.com/ScientificCommunicationAsSequentialArt...

How did they get her to the hospital if she needed to be upside-down the entire time?

I don't think I prefer scalability and low-latency over a high-quality of people discussing things I care about. The focus should be on community, not handling a large number of users.

Interestingly there seems to be a recent trend of not being a slave to your email, twitter, FB, etc. I suppose people are starting to realize that urgent things don't necessarily come from these mediums and as much as we have come to rely on them, they provide us with more noise than useful data.

I've been trying to check email twice daily at scheduled times and respond to emails in "batch" instead of as they come in. It's definitely increased the number of "concentrated" hours I put into a task.

Congrats on a tremendous technical feat!

Any advantage of using a full-scale FS over something like git-annex (http://git-annex.branchable.com/)?

This list is inevitable I think for anyone who is trying to ship or has some sort of deadline. The most important thing I find in maintaining large code bases is to vigilantly keep the broken window theory in mind (http://en.wikipedia.org/wiki/Broken_windows_theory). It takes some discipline to actually go back and fix things that are broken, but it does help to avoid longer term software rot.

No codebase is perfect at any single given point in time, but when you see a broken window, fix it.

http://pragprog.com/the-pragmatic-programmer/extracts/softwa...

I remember looking at Yahoo Pipes back in 2007, but perhaps the timing was not right for it back then. Now as the Web is getting more and more ubiquitous and the need for services to talk to each other grows, an approach like this could very well take off.

A live-demo would be nice to see. It's hard to gauge how to use the app and the descriptions in the help screen are far too long for anyone to read carefully IMO.

Excellent story. I think people in general overestimate the time they have available to do things and underestimate the time it takes to actually do it; which inevitibly leads to situations where you think you can make up for "lost" time by sprinting forward, tomorrow. The most valuable lesson I learned about productivity is that small actions, done now, can lead to huge productivity gains tomorrow. The hard part of course is to subconsciously justify to yourself that those small actions are actually making significant progress towards your end goal. It's important not to get discouraged and keep charging ahead.

What's more insidious are those "busy working" tasks that can consume your day where you actually feel productive, but haven't made any real progress towards where you want to be.

There's an excellent TED talk by Daniel Goldstein about the present and future self; highly recommended: http://www.ted.com/talks/daniel_goldstein_the_battle_between...

The book "Architectural Geometry" http://www.amazon.com/gp/product/193449304X/103-2668819-9693... is a fantastic read with plenty of nice geometric insights.

Some excellent advice from Chris Dixon on the chicken and egg problem: http://cdixon.org/2009/08/25/six-strategies-for-overcoming-c...

and also by Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000054.html

I found a nice introduction to lock-free data-structures here: http://www.cse.yorku.ca/~ruppert/papers/lfll.pdf

It is restricted to linked-lists but has some nice take-aways and worth the read.

Problem and Solution number 42 is a genius way to help the less fortunate. I do hope that the more metropolitan cities adopt that in their transit systems.

There seems to be a pretty common message for many of the rules here that encourage trial-and-error and re-doing things. I think that is just brilliant advice for innovation in general not just story writing. Not being afraid to fail and trying things again and again truly leads to amazing results.