Know what I'm talking about? I've gotten it when iterating quickly on something I know how to do, or something I almost know how to do. It's addictive and energizing, and the only thing that makes coding for long hours possible. Perhaps this is "flow."
I think I should keep track somehow of what causes this state. Today it was writing "hello world" using a couple of new technologies, and in that sense, it sounds quite flowy: surfing on the edge of my abilities.
It brings up a lot of questions, though:
- how can I cause this flow more?
- why don't I get it more often already? (I think it is because I am often trying things that are too hard.)
- will it bring me lasting job satisfaction to aim for more flow? (instead of whatever it is that I'm aiming for now, which is "doing what needs to get done", I guess. I think the answer to this question is yes.)
- will I keep learning if I aim for more flow? (I think the answer to this question is "yes, and stop asking so many worried questions.")
Programmers out there, do you know what I'm talking about? And non-programmers, do you get the same thing?
Monday, August 2, 2010
Sunday, August 1, 2010
New Android App: One Photo Every Minute
It's an app that takes one photo every minute. Or every 5 seconds, or 10 minutes, or whatever. Wow! Imagine the possibilities!
(EDIT: it's unpublished from the market now because it crashed a lot.)
And it was a surprising pain! Some tips that might spare you some pain:
- don't try to use the camera without a preview. It might work, but I feel like some of the developers might have been assuming a preview. (all example usages of the camera, in docs and ApiDemos include a preview.) At any rate, using a preview surface gives you a couple of callbacks that make it easy to manage the camera resources.
- you might get cryptic crashes or ANR's. I don't feel confident that One Photo Every Minute is 100% crash free, even on the Nexus One I was testing it on. This is awful.
Some general thoughts:
- At work, on servers, we use Guice and dependency-inject everything. I tried to do the same here, and it was way overkill. You can, and should, easily bang out a couple thousand lines of code without doing any DI. (this means most of your code won't be unit-testable. I'm okay with that. No, this doesn't scale well.) Maybe I'll get into specific issues later.
- Model-view-controller is a nice pattern. This might be the app where I most specifically understood how it works, because I created classes called Model and Controller, and I designated the MainActivity class (plus the xml layout) as the view. Totally great idea.
- Learn one or two things at once. In this app, I tried to learn three (MVC, manual dependency injection, and Android camera apps). That will just frustrate you.
- Launch as soon as possible. Especially if you're fed up with the project. After you launch a functional product, if it's just a hobby (and if it's free), you can stop working on it at any time. Before you launch, if you give up, you've just wasted a lot of work. You can always add features later.
- It's amazing the difference between a free hobby app and a paid or corporate app. If Google or whoever launches a thing with a minor flaw, people jump all over it, sometimes nastily. (I know; I've worked on Chrome.) But when you release a free Android app, even if it crashes all the time, people are very friendly, even offering help and support! The feeling I get is "I know you're trying your best. I appreciate it." It's wonderful.
(EDIT: it's unpublished from the market now because it crashed a lot.)
And it was a surprising pain! Some tips that might spare you some pain:
- don't try to use the camera without a preview. It might work, but I feel like some of the developers might have been assuming a preview. (all example usages of the camera, in docs and ApiDemos include a preview.) At any rate, using a preview surface gives you a couple of callbacks that make it easy to manage the camera resources.
- you might get cryptic crashes or ANR's. I don't feel confident that One Photo Every Minute is 100% crash free, even on the Nexus One I was testing it on. This is awful.
Some general thoughts:
- At work, on servers, we use Guice and dependency-inject everything. I tried to do the same here, and it was way overkill. You can, and should, easily bang out a couple thousand lines of code without doing any DI. (this means most of your code won't be unit-testable. I'm okay with that. No, this doesn't scale well.) Maybe I'll get into specific issues later.
- Model-view-controller is a nice pattern. This might be the app where I most specifically understood how it works, because I created classes called Model and Controller, and I designated the MainActivity class (plus the xml layout) as the view. Totally great idea.
- Learn one or two things at once. In this app, I tried to learn three (MVC, manual dependency injection, and Android camera apps). That will just frustrate you.
- Launch as soon as possible. Especially if you're fed up with the project. After you launch a functional product, if it's just a hobby (and if it's free), you can stop working on it at any time. Before you launch, if you give up, you've just wasted a lot of work. You can always add features later.
- It's amazing the difference between a free hobby app and a paid or corporate app. If Google or whoever launches a thing with a minor flaw, people jump all over it, sometimes nastily. (I know; I've worked on Chrome.) But when you release a free Android app, even if it crashes all the time, people are very friendly, even offering help and support! The feeling I get is "I know you're trying your best. I appreciate it." It's wonderful.
Subscribe to:
Posts (Atom)