very recent mixergy interview with their founder: http://mixergy.com/runkeeper-jason-jacobs-interview/
4,550 karma · joined January 27, 2009
also, plans are useless but planning is invaluable; that helps with actual success, not so sure about getting funded.
Only a fraction of a CPU is active during a given time period (eg if no floating point arithmetic is needed); and we don't use all the muscles in our body most of the time either. That's a bit different from what the pop-psy authors meant though.
I've noticed that computer science research/development in Europe tends to be more theory-based, as if the goal is to create a little world where everything makes sense; like the courtly protocols of a medieval sovereign. I'm thinking Dijkstra (who wanted a respectable profession), German academics I've known, and strikingly in some French papers and software I've come across.
Whereas work in the States seems to be more outcome-based and pragmatic. There's Edison, BASIC and Microsoft, and also Ethernet (which is deliberately non-deterministic.)
Of course these are just statistical patterns, and every individual person will exhibit both tendencies.
So, my theory is that, culturally, not having a sovereign or a court gave people the freedom to do whatever works, without it looking elegant. But it's also scarier to live that way - hence, religion.
Is Korean really that much more efficient than English, or is that word a label?
The instructors started to teach her after 949 tries - 949 tries, of watching this poor woman fail! - then she did learn, and got it on the 11th try after that. Teaching her was frustrating to them, I think mainly because they weren't really teaching her about driving, but a subset of civil administration and technology concepts, such as "regulations" and "emergency light".
The tragedy is that she could not afford "Middle school", despite dreaming of it so painfully that taking the driving test daily became a joyous wish fulfillment of attending school... an attitude of which the stereotypical student is too invisibly wealthy to properly conceive.
Aside: I saw a guide dog on a sweltering day in peak summer last year in Melbourne. It was clearly very uncomfortable, licking its lips. But it was also clear there was no chance it would let down its owner. It was touching to see such faithfulness; now I often donate to the guide dogs.
But in the other two cases, the answers are not immediate, which was the thrust of the statement to which I objected - it's quoted above, and includes "instant gratification", "answered immediately" and "almost any question". We're not there yet, we've only got the easy stuff. Wolfram|Alpha is an attempt to go a bit deeper, and it's also part of Google's mission.
Apart from reference questions (like dictionary meanings, map look up, programming syntax, wikipedia), we are an awfully long way from this.
I also had liked being the one and only - but that's ego, not business.
He also mentions users' "favorite features" (it's well known that we don't like having to change our behaviour, even for the better); and "“critical” features" (sometimes they aren't actually necessary; and sometimes, as Joel says, "everyone uses a different 20%" - Linus has also said this). An example of the latter, and as people have said here, is when really do need to customize a default behaviour.
Love Joel's linked comment on bootstrapping: So you sell "simple" as if it were this wonderful thing, when, coincidentally, it's the only thing you have the resources to produce. http://www.joelonsoftware.com/items/2006/12/09.html
I take a walk and observe nature, the smallness of myself and how little control I have over the rest of the world - yet everything keeps going. Go to a cafe, go to the supermarket - even a DVD is good for a change in a sense of place. Making progress on 'unimportant' side-projects is very encouraging. Making progress on little utilities (like bash techniques) is very satisfying, and even marginally justifiable. Make time to do things that you think are really cool. Credit yourself for each little step of progress you do make, by comparing with where you were before that step - you did that! (when focussed on the big, distant goal, it's easy to not notice the progress that we do make. But the journey of 10,000 miles is made of steps.)
> When no code word is given, you may use an alternative code word that floats along among trusted users. There is no way to apply for this code. Try your friends-of-friends network. Remember that this code and the mechanism itself will change if abused. http://c2.com/cgi/wiki?MoreAboutCodes
I just checked what you said, and the above seems to be (now?) the exception, and most pages do supply the code. A surprise to me, good to know, thanks!
Reading it reminds me of a mailing list archive of intelligent discussion. Haphazard, sequential, with links only at times. There are very insightful thoughts tucked away in there, but it takes a lot of reading and tracing to find them - and then you can't find them again without going through the same process. It's abysmal, labyrinthal, like some of my prototype projects.
What's the simplest thing that could possibly work? http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.htm...
A few years back, I wanted to buy stock in a software company, because I was in the software business, knew something about it, and owning stock would result in me learning more, which would benefit me doubly. Out of Sun and Adobe, and choose Sun (still love java); but after I placed the order, I realized that Sun wasn't a software company. It didn't draw significant revenue from software. I tried to change the order to Adobe, but it was too late.
I sold it years later, for half. I don't regret the loss (it's the stockmarket after all), but I do regret mistaking Sun for a software company.
1. I always find it exciting to see something happen because of my code. It's very basic, like a child playing with blocks. Graphics code is especially good for this; and there's also javascript that creates a webpage; or simply printing something on the screen (terminal/console). Combine a few steps together, and you can have something cool, even though it's simple.
2. breaking tasks down is how you "get to the point of being able to attack something". This "divide-and-conquer" is crucial - absolutely crucial - throughout all computer science (and every other complex activity). This is not a skill you should expect to automatically have perfectly mastered, but it's one you already have the beginnings of and that you can practice to improve it. For a start, you could look at any task (of any kind), and ask yourself how it could be broken down into simpler steps - often, it will be obvious to you. Now, break down one of those subtasks again, and keep going until you have a task that you are 100% sure you can do. Then focus on that one task to the exclusion of the rest of it. This is difficult. Try to pretend that the original task and all the other subtasks and sub-subtasks etc don't exist; and when you have solved this one task, observe that you've made progress and congratulate yourself. Only after this little celebration of real progress should you go on to the next step.
If you want to hit a bird on the wing, you must have all your will in
focus, you must not be thinking about yourself, and equally, you
must not be thinking about your neighbor: you must be living in your
eye on that bird. Every achievement is a bird on the wing.
But be warned: there always be things that are too complex for you, and that you'll have to break them down. The skill of breaking things down is essential.
I think it's a neat idea. Technically easy, but some of the best ideas are. I'm not using OhLife, but I coded a version (mainly to see if Google apps could be used to make a webapp, but also because people were concerned about privacy - the script's in the above thread); and I've been using it for the past week or so. I keep a paper journal anyway, so it's not really necessary for me on that score.
I'm mostly interested in the effect of their idea of being reminded of a previous entry. I think a week isn't long enough to tell; but so far a positive is that it shows I've made progress. It's reminded me of things I wanted to do (or problems I wanted to solve), that I have now done (or solved). So I'm using it partly as a technical journal.
Otherwise it would be a good investment.
You need information to make these decisions. I like Steve Blank's idea that your startup is a process for finding answers to questions, like here's my idea, I think these people will need it - do they? Try to get this information as early as possible - before version 1.0, before version 0.1, before any version, before any planning or design. Some questions will require a version 0.1 to find the answer.
So, try to formulate the specific questions, that if you had factual answers to them, it would be obvious to you whether to stick/pivot/quit. Then work at obtaining those facts (instead of at "keep pushing forward".) Some of them, by their nature, might take a long time or a lot of work to obtain; but because they are concrete, specific and factual, it's easier for you to decide whether it's worth finding the answer or not. Or, just by thinking in these terms, a brilliant short-cut for getting this information might come to you. [Note: I haven't actually talked to customers, which his approach says to; but I have researched my questions in other ways, which was very revealing.]
Some startups also have engineering questions, is this technologically feasible, can I get this to work? A similar approach applies, where you try to solve the bare essence of the problem first; customers can't tell you about this aspect. [Note: I do this all the time; unfortunately the basic "is it usable?" question can require a substantial prototype - a lot of work]
re "practice framing": I find that asking the question is very helpful for clarity - and then defining the key nouns in it.
Of course, programming jobs do exist where you do the same thing over and over again. And there's a threshold of skill required before you can automate some classes of things; and you also need a clear understanding of the task, to see precisely which aspects are mechanical, and which aspects are configurable. It pretty quickly gets into compsci research. And sometimes it's not worth the effort (it can take a lot of effort.)
But if you've ever called a method twice, instead of writing the code twice, then you have done some of it.
I feel that your question "start to make sense" suggests your thinking is all-or-nothing. Does no aspect of programming make sense to you - or do some "trivial" aspects make sense but they "don't count"? Does a print statement make sense to you, to some extent? Does a loop make sense to you? There's a continuum of mastery. If you only acknowledge perfect and complete mastery as "mastery", then you won't feel any satisfaction in mastery of one small bit of it. And without the confidence and encouragement of that success, it's very hard to be motivated to continue. (oh yeah, plus, of course, it's impossible to have perfect and complete mastery of programming anyway, for Turing's reason.)
Lamenting the bad is less effective than embracing the good. As in life.