May 24, 2010

A simple exercise management lifehack

If I’m working at a computer all day on a regular basis I find it necessary to plan an exercise schedule. If I don’t I feel awful about not exercising and it becomes a distraction. I’m inspired by this description of novelist Haruki Murakami’s daily schedule while writing a novel:

I mesmerize myself to reach a deeper state of mind. But to hold to such repetition for so long — six months to a year — requires a good amount of mental and physical strength. In that sense, writing a long novel is like survival training. Physical strength is as necessary as artistic sensitivity.

I like to have a sense of how close I am to reaching a destination so I use a simple accounting tool to keep track of how much I exercise. Here’s what you do: take a clean sheet of paper and write the month on the top line along with a goal of how many exercises you want to aim for. Skip a line then write an exercise per line. 

It looks like this:

May (goal: 10 exercises)

1 Mile Running

30+ Pushups

Make a tick mark every time you complete a set of an exercise. Keep the paper and a pen on your desk or somewhere you can see it everyday. Review at the end of the month and customize as necessary. 

May 18, 2010

Lessons from the Appointment Reminder Launch

Patrick McKenzie recently launched a new product called Appointment Reminder. Actually, it’s just a demo but this was done intentionally. Let me explain.

There is a “lean startup” movement that includes a concept called the MVP, or minimum viable product. The MVP is the first “product” (in quotes because it doesn’t actually need to be a working application as you’d expect for a software product) that you show potential customers with the intention of gathering feedback to determine what to do next. The key is to spend the least amount of your resources (time, money, etc) until you are sure you have a product worth investing in. The main thing you want to find out with the MVP is if there is a market need for your product.

The Appointment Reminder MVP consists of a website and a demo that will call you (your phone will ring) to give you a taste of what the service will be like. Patrick mentioned on Twitter that he started getting messages from people who couldn’t find the “Sign up” button. The thing is, you can’t sign up yet because the product isn’t finished. It’s a great sign though and it perfectly illustrates how the MVP can be used to gauge market demand. It can also be used for getting product feedback or collecting emails.  

The lesson is that I had previously thought that the MVP should be a finished, minimal product with core features. Now I realize it’s value is in what you can learn with it, not what it does. I had seen the same lesson illustrated in Dropbox Startup Lessons Learned but it didn’t sink in completely until I saw Patrick’s MVP. 

May 17, 2010

Some other blogs by software developers that I like

I like Marco’s blog. He’s the lead developer of Tumblr. I ask myself why I like it and I’m not really sure. Sometimes the posts are pretty random and don’t have anything to do with software. The thing is, I don’t really care and I still like it. It’s proof that a good blog can go off topic sometimes. I conclude that it’s okay to go off topic as long as you keep your main focus central.

Another blog I like is Patrick McKenzie’s blog. He’s a software developer that worked for a large company as a Japanese Salaryman. This means he was working sixty to eighty hour weeks and frequently sleeping at a hotel near his work on long days. He spent close to one hundred days sleeping at the hotel in a typical year. Anyway, Patrick started an online business (a Bingo software application) on five hours a week. In April of 2010 he switched to working on his business full time. Interesting story, interesting blog.

May 14, 2010

New iPhone App Coming May 18th

I’m about to release a new iPhone app on May 18th. I made this one in about a month which is the time frame I was aiming for. Given the hit-based nature of the App Store, I would rather create three apps in three months than one app in three months. With three apps in the store I can evaluate which idea is doing best and focus on it or just make another app.

The inspiration for my new app, Song Library Scanner, is the fact that the music playlists on the iPod and iPhone suck for telling you about what you listened to or rated recently. There is a My Top Rated playlist but it doesn’t show you the ratings. There is a Recently Played playlist but it doesn’t show when you played the songs. There is Top 25 Most Played playlist but it doesn’t give you the play count. 

The data in the playlists that you’d want to share is missing. The real purpose of Song Library Scanner is to find the songs that you’d want to share (recently played, most played, rated 5 stars, etc) and let you tell your friends about them. After you find the songs you can post a message on Facebook. Your friends can see what great music you’ve found.

I’m also trying out a feedback form on the app site to make it easier to get feature requests, comments, etc. It’s powered by Wufoo in case you’re curious. The app is going to be free with ads. I’ve got at least one month worth of ideas about how to make the app better but I want to see what people think before I add anything. 

May 12, 2010

Going to the extreme points

Here’s a long term strategy I use to figure out what I should be doing.

When I made my first iPhone app it took about three months to do all the design, graphics and programming. I was aiming to make something quickly and three months seemed quick.

Next I decided that what I would really like to do is make a music game that I could add music to every few months. It took about four months to finish the first release. I was aiming to make something that wouldn’t take long but my definition of long was still around eight to twelve months.

In retrospect, three to four months is a long time to spend on one app. That is now my extreme point for development time. To experiment, I’m going to go in the opposite direction and make an app in a week. A week probably means a few weeks if I include making the icon, testing, surprises, improving the design, etc but that’s fine too. A month is still much shorter than three or four months. 

When I’m done with that app I’ll have established two reference points in my mind: shortest development time and longest development time. With that information I can determine which strategy works best and I’ll know the direction to go in next.

May 10, 2010

“As a rule, the experienced designer does not begin with some preconceived idea. Rather, the idea is (or should be) the result of careful observation, and the design a product of the idea.”

—

Paul Rand, A Designer’s Art

I think about this a lot before I start a project. I don’t want to limit myself to what I already know. Before I made Sunburst Fly I had never done any audio programming or made anything close to a game. I try to approach a project with a clean slate so I can let my imagination go anywhere. I want it to feel like I can do anything even though I may not actually know how to do it. I do however think about practical constraints or key elements I want to incorporate. Those are the foundation of the idea.

May 7, 2010

Emotional guidance and walking away from code

Working with a complex piece of code can lead to moments of difficulty. The brain may start sending signals to back off or quit. I equate this moment to one that happens when lifting weights, which is when your muscles can’t take anymore. They have been exhausted. With code the brain has been frustrated.

This is a great place to be because it means you have pushed yourself to the limit. When I reach this point while writing code I need to step away from the computer and think about the problem on a more abstract level. I start thinking of new ways to approach the problem. I might realize I need to research or read up on something or sketch something out. The answer usually arrives soon after that. It’s like lifting weights. The muscles build up over time.

May 5, 2010

How do you choose the right people to work with?

I submitted the question in the title to Chris MacAskill, the co-founder of SmugMug, during a live Mixergy interview. 

Chris started by saying they have always focused on passion. The primary thing they look for is that the person cares about what the company is doing. He described the purpose of Smug Mug, which is a place to store and share your life photos like wedding pictures, baby pictures, travel photos and more. These things are part of your legacy he said.

After explaining the importance of passion, Chris went on to say that as the company grew they started to higher people that had a particular skill. For example, at some point they needed a Javascript expert so they hired one. These people may not necessarily have been passionate about photos but could contribute to the mission of the company.

To sum up, look for people with passion at the beginning. Once you have a strong core focus on hiring for specific skills.

May 3, 2010

Feedback as an analytic

I have a theory that you should work on the thing that will give you the most high quality feedback. This doesn’t necessarily mean that all the feedback will be positive. However, if people care enough about something to tell you about it then you just might be working on an important problem.  

How do you decide what to work on next?

April 30, 2010

Momentum and a tip from Hemingway

Momentum is one of the keys of finishing a software project, especially one that you are doing by yourself. 

One common thing that disrupts my flow is realizing that I need to go back to the drawing board to sketch out a feature in more detail. Usually it’s something that seems minor when looking at an overview of the project but needs clarification before it can be programmed. I keep a notebook on my desk for this situation to draw out exactly what the feature will be and how it will work. This clears up the mental block and lets me go back to programming. It’s a back and forth process between design and development. Designer-developer Shaun Inman described it as a conversation between design and development that goes on when he is making something. I believe it was in this episode of the Pipeline.

Sketching features in more detail is a way to regain momentum but there is also a way to maintain momentum. Knowing what you will work on the next day is one of the keys to this. After I’ve defined enough of the design of a project I can go into development mode and start coding. A significant project will be a multi-day effort so it’s necessary to use some type of planning document. At a minimum, I have a basic design document that lists the main features. I’ll pick one to work on and then I sometimes use a sticky note (virtual or real) to track smaller milestones I need to accomplish. The sticky note is particularly useful when I’m in the middle of coding something that I need to continue the next day. I simply write down exactly what it is (for example, right now my sticky note says “Print the selected songs in the UILabel”) and the next day I know what to start working on. The project rolls along.

Hemingway found it useful to know in advance what he would work on tomorrow too. John Gruber shared in an interview that he uses a similar technique to write Daring Fireball:

Ernest Hemingway said this:

You write until you come to a place where you still have your juice and know what will happen next and you stop and try to live through until the next day when you hit it again.

He was talking about writing books, but I find his advice perfectly apt for what I’m doing with Daring Fireball. Without having a boss or editor, I could do anything at the start of the day. Leaving off the day before with something specific in mind for what to do next is an enormous aid to getting going.

April 28, 2010

Learning to program advice

Every once in a while I see that someone has asked a question like “how do I learn to program?” or “how do I start?” or “what books should I get?” This is my answer to those questions.

My first bit of advice would be to use Wikipedia and Google to read about technologies. For example, maybe you’ve been hearing the term “Ruby on Rails” a lot. When I was starting out, I didn’t know what it was either but the more I read about it the better I understood it. After doing this type of research it becomes a habit to look up something quickly when you are curious about it. Pretty soon you’ll be able to categorize different technologies by what they do (ie. Ruby on Rails and Django are web development frameworks) which will give you a sense of control.

The real question you want to answer though is “what do I want to make?” Once you can answer that you’ll know what type of technology you need. Choose the best one and start building it using whatever resources are available. Later I’d look for other good resources like online communities, experts, books, documentation, etc.

April 26, 2010

How to choose programming technologies to learn

An important aspect of programming is choosing what technologies to learn. Besides knowing what you want to build there are many other factors that are wise to consider before diving in.

One way to make a decision is to see what programming jobs are available now. Looking at a few job boards (Ars Technica, StackOverflow, 37signals) will give you a quick snap shot of what languages and skill sets are in demand now.

Another useful way to think about this is to consider what technology is up and coming. The best example I can think of for this is HTML5. It could potentially replace or be an alternative to Flash which is a big deal since Flash is used on so many web pages right now. It may not be in demand now but there is a good chance it will be in the future.

The portability of a technology is also worth thinking about. Things like OpenGL, which run on the iPhone and on Android give the programmer more options because they are not limited to one platform. 

April 24, 2010

Trusting Intuition

Basketball players must trust their instincts to be successful. At the same time they need to be able to accept advice from a coach and integrate it into the game if the team is to be successful.

Like the basketball player making choices on the court you must deal with situations from moment to moment. It’s not possible to be successful with only the strategy that the coach has chosen. At the highest level great individual skill combines with great strategy to produce excellent results.

April 23, 2010

“Reaching for the new is tilting at windmills; the goal ought not to be what is new (original), but what is good.”

— Paul Rand, “Design Form and Chaos”

April 21, 2010

Index card and scissors as a design tool

So far, the apps that I’ve released have been designed to be paid apps and they both have paid upgrades.

As an experiment, I want to shift directions and make my next app free and ad supported. This will be a good opportunity to test out iAds once they are available and it also means that my design process changes. 

To start off, I have to design the screen layout to include an ad. I have a basic idea in my head of what the app will do (give stats about the user’s iTunes library) so I have a collection of elements I’ll need (buttons, labels, etc).

What I did to help me lay everything out is I took a notecard and cut it up into pieces that I can arrange. For example,  I have one piece that is roughly the size of a typical mobile ad and another that is the size of a standard button. This technique made it possible to quickly try out different layouts and screen sets. I’m going to incorporate what I learned into the UI.

Page 2 of 3



By Michael Rakowski