1. Cleanup the Desktop.

There are two main things I’ve found really helpful to eliminate distractions on my desktop:

1. Archive every file that is not a part of my current task.
   I put these files in a subfolder called ‘file’, which is then subdivided into the folders ‘notes’, ‘pix’, ‘projects’, and ‘misc’.
2. Get a clean dark wallpaper. The key here was finding a aesthetically pleasing wallpaper that I don’t find distracting.

Rethinking my desktop has allowed me to easily find files that are related to my current task, and eliminates the clutter of the dozens of other items that used to be on my desktop.

2. Rethink the dock and learn to love Spotlight.

I used to be guilty of dock clutter. Every application I’ve ever used would be in my dock, irregardless of if I’ve used it in the last hour, day, week, or even month. I think I may even have had iMovie and Garage Band in my dock (two programs that come installed by default on OS X, which I’ve never even used!).

To clean up this area of my computer, first I needed a way to easily start programs that I was going to remove from my dock. (Turns out Spotlight is a great tool for that. More on spotlight, below). Then, I removed all items from the dock that were not vital to my workflow on a daily basis.

Here’s what’s left: Chrome, TextEdit, Gmail, Adium, Terminal, Activity Monitor.

Spotlight is a nifty feature of OS X that allows me to easily search my mac for any program, folder, or any other document. It’s stupid-simple to use: Just press Apple-Space and type the name of the item you want to find. (Also worth checking out: QuickSilver) I’ve found it to be a more-than-adequate replacement for having so many applications in my dock.

3. Minimize the menu bar.

This is an area that should be relatively easy to clean up. To reduce distraction, I removed all items that were not vital to my workflow. Here’s what’s left: Wifi, Battery life, Clock, Spotlight.

4. Learn to love keyboard shortcuts.

I’m a big fan of using keyboard shortcuts to manage all the application windows I’ve got open. To configure this feature, open up your system preferences, click ‘keyboard’, and configure your keyboard shortcuts.

The big to-do with keyboard shortcuts is to build a mental map of the most valuable shortcuts and actually work them into your work flow. I can’t do that for you, but I can recommend some of my favorite shortcuts:

• Alt-Tab to switch between application windows.
• Apple-Space to invoke Spotlight
• F10 to show all windows
• F11 to show Desktop
• F12 to launch Dashboard
• Apple-H to hide current program
• Apple-M to minimize current program

5. Check out Fluid.

Fluid is a great app for turning any web site you commonly use into a desktop application. In my opinion, this allows much greater workflow management because I can manage the new application separately than all my other browser tabs. Read more about Fluid here.

How about you?

What are your favorite keyboard shortcuts? Workflow management techniques? What used to slow you down, and what saves you time now? Please post a comment via Intense Debate, below:

Figure A: Ambient Data-Porn @ Ignighter

Years ago, when I ran a web hosting company, I remember I’d hooked up my home computer to chime with a ringing cash-register when the site made a sale, and to play a less pleasant buzzing sound when someone emailed a complaint.

Nowadays, I’m more serious about collecting and reporting data on my product. Figure A, above, is the trends viewer we use at Ignighter. It’s nothing more than a regular pc with a web browser displaying some charts on updates every few minutes with latest site usage data, that we put in a prominent location. Pie charts, line graphs, and segmented data, oh my!

It’s ambient, it’s visceral, and it’s useful because it allows impromptu team chats about trends in site usage during the day.

And I think that’s a big win.

Bottom line:
Data is only useful for driving decisions when it’s relevant, easy to understand, and all around you. Make it stupid easy to see trends in your product.

He’s a physicist by calling, so it shouldn’t have been a surprise, given the context, when he quoted the founder of classical physics, Sir Isaac Newton:

If I have seen further it is only by standing on the shoulders of giants.

~Sir Isaac Newton

That got me thinking. My grandfather was a pilot in the air force. He lived through the Great Depression. He ran a gas station in his later years. He had to work very very hard. My father worked years and years as a programmer and then a graduate student to get his PhD and, even then, it took him a decade to get his own team and make a name for his work.

Taking a look at my peers in the startup world and what they’re working on, it is clear to me that the business landscape has changed so much since the days of my parents and grandparents. Startups like Foodzie, DailyBurn, Devver, EventVue, Occipital, Retel, and Next Big Sound are creating massive disruption in their respective industries. In some cases, they are creating new distribution channels or even entirely new products. And, many of them are in their twenties and thirties! How is that possible?

They are standing on the shoulders of giants, of our forefathers. People like Linus Trovalds, the creator of Linux. Some are built upon the backs of hundreds of open source programmers, who write and refine languages like PHP or Ruby. Or, on Sun Microsystems., or the work at DARPA, or at Bell Labs. All of these projects created more value than they captured. And, all of those disruptive startups are dependent upon commoditized electricity, hardware, data storage, and internet access, among many many other things.

It’s truly amazing to take a look back and reflect on all of the things that had to’ve happened in order for the tech landscape to look the way it does today.

Sometimes, in technology, it’s easy to focus on the negatives that are associated with things that aren’t working. I know I curse AT&T every time my iPhone fails. And I poke fun at the Microsoft Windows machines running IE6 that my buddies in corporate America have to use every day. But, on the other hand, you have to respect what those companies have done to grow the technology sector.

Life in tech today is pretty great. The internet is very much a meritocracy, and the barrier to creating a company has probably never been lower.

Take some time and reflect on all the things that had to go right to get you where you are today.

As a student of all things start-ups, I’ve noticed lately that many software developers have a horribly boring habit of rambling. And, as an engineer, I understand the premium put on being exact. On communicating every last detail, and getting every angle of a problem across.

But, man. Some people, they just don’t notice when the eyes in the room start glazing over.

As a profession, engineers are widely heralded as being comprised primarily of introverts. But, somehow we suck at delivering short, well-timed, and accurate answers. It really seems that being concise is just not in our nature as engineers.

But, it has to be. Because it shows credibility and professionalism. And, your co-workers will be appreciate it.

Next time you’re in a meeting, and you’re given the talking stick, try the following. Take a deep breath. Think about the context of the discussion. Think about what you know about the person who is asking you the question. If you know the answer, position it clearly and summarize it concisely in 2 or 3 sentences or less. Don’t worry about being 100% exact. People will ask follow-up questions if they need to. If you don’t know the answer, it’s okay to just simply state that you’ll get back to them.

As a developer, you speak the language of systems. You walk in the specific and precise languages of database, of code, of specifications. Your primary currencies are exact specifications and knowledge. Your job is to translate requirements into specifications, and instruct your system how to precisely and simultaneously execute both the requests of the user and the business.

Your business partner speaks the languages of marketing, operations, and their currency is relationships. Their primary concern is branding, and building the relationships, networks, and strategy of your company.

The two positions could not be more different in terms of language or means. But they are united in a common goal: That of building a product. It is their job to define the problem of your market, both of your job’s to define to solution to said problem, and your job to build the solution. Nevertheless, that does not make the hand-off of specifications, or the delivery of information from one party to another much easier to navigate.

There is a language barrier between software developers and businesspersons.

Though I’ve discovered that the only true ways to navigate this language barrier is through process and experience, I have come up with a few best practices for both parties.

Best Practices, Navigating the communication barrier:

Learn to walk in both worlds. Developers, spend some time understanding your market at a more-than-trivial level. If your niche is gambling, you should understand the primary motivation of the gambler is to have fun and win money. If your niche is dating, you should understand the primary motivation of your user is to create relationships (probably sexual ones). Understand what sets your product apart from all of the other gambling, dating, or otherwise competing apps, out there on the web. I’d also encourage you to explain often, at a high level, how your system works.

Build common ground. Cite specific examples of miscommunications in the past (without laying blame), and lessons learned from them.

Provide context into what you are trying to accomplish or communicate. When I’m trying to push forward a specific initiative, it is helpful to provide context into where the initiative came from, why it’s important, and where it fits into a timeline. Then, translate that into what it means for the business, the amount of time it will take, how high a priority I think it should be.

Let the data drive decisions. I’ve had quite a few times in which I’ve disagreed with a partner about how a featured should be implemented. In this case, I try to let the data (which has been gathered from our analytics software or usability tests), not ego, drive the decision-making process.

Clearly narrate the trade-offs involved in any decision. A lot of times, building feature x means feature y needs to be cut. I’ve found it infinitely easier to present these decisions in biz-speak than in dev-speak.

Establish a specific common goal. Many times this is implicitly obvious. Often times, it is not. I always restate my goal at the end of a conversation or meeting.

Clear up ambiguity by asking specific questions. A lot of times, the mandate I’ll hear from the business is ‘build feature x’, so that it does x and y, and looks like z. There is often much assumed about x, y, and z. Is x an AJAX feature? What is the UX like when you press the button in y?

In sum, these are the best practices I’ve found for navigating the language barrier between developer & businessperson. What has worked best for you?

Please do not reply to this email. Replies to this email will not be responded to or read. To contact us, jump through hoop x, y, or z.

Let me get this straight: You expect me to read your email, but you will not read mine if I reply? Morever, you expect me to hunt down your contact information by poking around on your website?

There are few things more insulting to me as a user of a web service than a service that sends an email from donotreply@companyname.com. This email address serves to discourage a two-way dialogue with a client base by discouraging easy communication.

It’s 2009. A dialogue with users is important. Their pain points today is your competitors’ advantages tomorrow.

Here’s a novel idea: Respect your users’ privacy and they will respect your brand.

My ‘Webservice Email Bill of Rights’, written in plain-speak, below:
- Respond to users who reply to your emails.
- Concisely state the information you wish to communicate. Subject lines should be less than 5 words. The primary paragraph of your body should be no more than 2 sentences.
- Do not share my email address unless you tell me you are doing so. If you do so, disclose that on your signup form. Do not hide this information in fine print.
- Provide a Privacy Policy, written in plain-speak, not lawyer-speak.
- Provide a clear unsubscribe link. Bonus points if I don’t have to sign in to modify my subscription.
- Provide a “view this email online link”.
- Make it clear what emails I am going to receive from you upon subscription.
- Allow me to easily customize which types of email I receive from you (if you send more than one email type).
- If you have a document attached to your email, put it into a format that is open, free, and quick to open. (hint: no MS Office)

What would you add? What are the most common email faux paux’s you see in your inbox?

The World Without Us

It’s not often that I read a book that truly humbles me to the bone. That’s why I’d like to recommend The World Without Us by Alan Weisman .

The book begins with a narrative that details the massive cities, transportation, and communication networks, that have been built by human civilization. Then, it moves into the timeline on how they would begin to erode if humanity, for some reason, just vanished.

It’s an interesting thought experiment. What if maintenance on everything around us, our cars, our houses, our sewage systems, our power plants, our roadways, just … stopped? What if?

Click through to http://www.worldwithoutus.com/ to learn more.

One of my favorite ways to block out background noise is to put on a set of headphones and fire up iTunes, Pandora, or Grooveshark.

I’ve long wondered why the two activities fit so well together. The music I’m listening to can impact my energy level, level of focus, productivity , and sometimes even my passion for the project I’m working for. Perhaps, music is just a great way to cancel out background noise, allowing increased focus. Or, maybe music stimulates the same logic or mathematics-oriented areas of the brain that coding does. Skills like pattern-recognition, inference, and abstraction are common both to both. I’m no psychologist, but my own empirical observation has shown a heavy overlap between the programmers I know and friends who count seeing or making live music as a hobby. Maybe it’s self-selecting, but I think there may be a shared set of innate qualities between the two populations.

Or, perhaps as an engineer I am simply doomed to attempt to vigorously try to reverse-engineer everything I come into contact with. Though the practical merits of listening to music while I code are clear to me, I’d never realized how similar the process of writing a computer program is to writing a piece of music: Galghamon, a stackoverflow.com commenter who studied both music theory and composition, notes:

Musical notation is a lot like a system spec: There are varying amounts of information present, from which you have to make educated guesses about what was intended. Composing music on paper is a lot like writing a system specification. The more you spell out what you want (using all the notational elements available), the more faithful to your ideas the final performance of the piece will be. But just as you can have coders that ignore some of the specs, you’ll have some musicians that will improve on the piece by ignoring certain instructions and providing their own interpretation. Sometimes this works, sometimes it doesn’t.
Writing code is a lot like playing music: you interpret the instructions of others, internalize them, interpret them, until you can deliver a performance. There’s no clear right or wrong with either, just degrees of faithfulness to the original thought or intent, but there’s a goal in both (even improvisations follow a certain style and direction). How well that performance was executed is left for others to judge (audience, users), except when your playing or programming for your own pleasure.
Debugging and testing is a lot like hearing your a composition played for the first time – there are often wrong pitches in the notation, simple notational errors, but sometimes you can tell that something just isn’t working right in an ensemble, so you have analyze the problem and look at why this is. You can do trial runs with users/audiences to see what their reaction is.
[ Click through to read the whole thread ]

So there you have it. Some musical pieces can be engineered or reverse engineered, the same as how us hackers can engineer a website, program, or video game.

But anyway, I’ve digressed.

After a chat with a close friend about music and code, I’ve come up with three themes I consistently see in good coding music:

1. Fast Paced.
2. Instrumental, without lyrics.
3. Heavy on melody and rhythm

Genres like classical, jambands, and electronica fit right within these themes. But, basically, I’ve found that anything instrumental (primarily, without the spoken word) works.

Some of my favorite artists for coding:

• Classical:
  • Bach,
    
  • Mozart
    
  • Beethoven
    
• Jamband:
  • Lotus
    
  • Explosions in the Sky
    
  • STS9
    
• Electronic:
  • Cut Copy
    
  • Radiohead
    

Do you see any parallels between music and code? What are they? What do you listen to to help you focus?

• Ponder This [FLASH] – Woody Harrelsons poetry about community and leadership
• Andrew Hyde – 3 Simple Blogging Tips [TEXT] – Advice for those who are just getting started blogging
• Aurora Borealis [PIC] – Breathtaking
• WIRED – Gone Forever, What does it really take to disappear? [TEXT] – Stories of ordinary present-day Americans who’ve decided to leave their whole life behind, for reasons legitimate or sometimes not so legitimate, and create a whole new identity.

dfib8u9my6

What it is. (from Rescuetime.com):

Personal time management software. Get the focus you need to get things done!

Features. (also from Rescuetime.com):

- Automagical app & site tracking (with no data entry!)
- Beautiful time & attention reports for managers only
– goals, alerts, and blocking

I discovered them a few months back. It’s been a fantastic way to introduce a feedback loop into my work that allows me to see where I’m wasting time, when I’m most productive, and when I’m somewhere in between. For example, I’ve learned I have a bad habit of checking facebook, email, and twitter throughout the day. Using their blocking feature, I am able to block those services whilst in delivery mode.

Their interface is smooth. Their widget works fine. I’m pretty happy with their service..

Some data pron, to follow:

Check them out at Rescuetime.com.