We programmers have a strange sense of humor about naming our intangible creations. You really have to wonder what goes through non-techie heads as they run across the battlefield of one of our wars of technical ideology.  Think about how that grandmother down the street hears “Eunuchs versus windows” — it sounds like some kind of hate crime party game.

As a programmer who wants to build more cool things, I’d like to offer my opinion on the REST vs. SOAP debate (to the dismay of mothers everywhere).

For the uninitiated bystander, REST and SOAP are fairly similar ways of letting different applications, services, and devices share data with each other.  For a quick example, let’s assume you track your household shopping list on a piece of paper under a magnet on your fridge.  One day you drive to the supermarket and realize that your list is still stuck to the fridge.  You can either wing it or have someone next to the list relay it to you over the phone.  If your shopping list was online you could pull it up from your phone at the store, but you could also do a lot other interesting things like allowing different services to tell you how healthy your menu was, to group the list by aisle for quick navigation at your nearest location, or to find the brands that are on sale.  That’s a big part of what REST and SOAP do, they allow people to create tools and “mashups” that find new uses for (or meaning from) existing data.

Very briefly (and quite biased and oversimplified):

• SOAP enforces order at the cost of flexibility.
• REST permits chaos for the benefit of flexibility.

Still with me?  How about this:

• SOAP requests are verbose with a lot of formal syntax, always dealing with an HTTP POST.
• REST is stateless and operates just like the Web where resources are at /paths/like/this.

When passionate developers release an API there’s usually anticipation and curiosity about the kinds of third-party aftermarket that will develop.  Those suburbs of development can make or break a project.

A problem that I’ve seen quite a bit from various web services lately (I’m looking at you, Pingdom) is one where developers get excited about checking off the “Web API” feature request (or marketing bullet point), but it’s clear that nobody on the official development team actually tried to build a new tool with it.

I sat down tonight and thought about the API design blunders that give me the most grief.  Let’s see how well you do!

Have a Web API you want the world to use?

• Don’t make me log in and log out through the API.  You can tell who I am from my API key in the HTTP headers, and you can authenticate me by comparing a checksum you generate on-the-fly against the one I provide in the headers.  By enforcing an explicit login you’re requiring me to send at least 2-3 packets (login, action, logout or timeout) when I should be sending one.  Perhaps that’s fine for a desktop application that can maintain a persistent connection, but we live in the age of iPhones on cellular networks.  Why limit your reach?  Why punish my phone?
• Don’t make me use the Web API with the same login and password that I use to access the normal app or service.  I shouldn’t have to give away all my secrets just to share some info with another application.  Issue me an anonymous API Key and allow me to use a secret phrase for signing my packets that is specific to the API access.
• Don’t use SOAP just because it’s a more familiar buzzword.  There’s no need to be so formal unless it’s absolutely necessary.  Formality robs XML of its flexibility and platform agnosticism.  It makes it a pain to reuse my data if my new platform requires another library (or worse, custom code) to play dress up and talk SOAP.
• Don’t forget to provide examples!  Documentation is well and good, but a block of sample data is worth a dozen pages of explanation.

Do you have an abnormal affection for, or allergy to, a particular Web API?  I’d love to hear about it in the comments.

-Jeff

Your application framework may be like standing on the shoulders of a giant, but that giant is a beneficiary of an entire civilization, which is nested on the ground of the Earth, which itself is locked in orbit around the Sun, which itself is orbiting around the galaxy, which itself is still accelerating through the Universe after being ejected from an epochal Big Bang, which itself was probably the result of a collision in an even higher abstraction on our path to infinite regression.

I’m not saying that you’re insignificant — quite the opposite, I’m saying you’re fortunate; as much to be alive as to be a developer with all these great tools to build on.  A few years ago it would take an army of tie-sporting programmers chanting corporate songs in lockstep to produce an end result that a single coder can do from their bedroom today.

But as commercial developers we also have a problem.  It’s so addictive to work in these high levels of abstraction to rapidly change the world for our users that we often don’t see the ground moving beneath our feet.  The reality is our platforms are in motion too, and it’s a fallacy to imagine that our currently cushy abstraction will forever insulate us from having to go back to the drawing board.  But redesign we must.

So why change?  As the platforms we’ve chosen to build on evolve, more and more of the arcane glue between our ideas and tangibility is being done for us by the platform.

Here are a few examples:

• In Firefox, the browser-based spell checker adds spell checking to every text box in a web-based application.  That removes a huge burden from web developers who should never have had to deal with server-side spell checking in the first place.  There are clear benefits for the user too: they get consistent spell checking support that they don’t have to re-train for each application.  Their last name added to the dictionary on one site is reflected on every site.
• Again in Firefox, browser-based extensions can take over even more of the heavy and redundant functionality that shouldn’t be wasting developer time at the application level.  My favorite recent example is the WriteArea extension which adds an inline HTML editor to any <textarea>.  This cuts out a large chunk of the source code footprint (FCKeditor, and ironically TinyMCE, are both hefty); it reduces the amount of client-side script you’re requiring people to cache; and it also reduces complexity, especially on Ajax-enabled sites that may be popping up asynchronous edit windows on floating DIVs.
• Memcached is a distributed shared memory cache that can take over your home-brew caching layer.
• Syndicating application content as RSS is a great way to offload notifications to tools that are better suited for it, without overloading your users’ e-mail inboxes.
• PHP5 introduced SimpleXML; which while far from perfect, I’d take any day over the event-driven nonsense we were doing in PHP4.
• PHP6 will introduce native Unicode support (I’ll wait while the Java crowd stops laughing).  Right now we’re having to hack support together with the ‘mbstring’ extension and deal with side-effects in binary strings from libraries out of our control.
• I’ve been pleasantly surprised by my forays in to OSX and iPhone development land.  While XCode itself is no Eclipse, the Interface Builder puts the UI tools I’ve used in Java (Swing or RCP) to shame.  This abstracts the relationships between the code and the interface.
• Amazon’s elastic computing (EC2) and redundant storage (S3) services are game changers. Designing your application to take advantage of elastic computing and “unlimited” storage can remove your hardware-imposed scaling limits — at least until you’re successful enough the costs of doing it yourself are less imposing.

If you haven’t gone back to the drawing board in the past 12 to 24 months, chances are you’re wasting a lot of time on things that are already solved.

Sure, that sounds great in theory, but my community will turn into a com-mutiny!

If you have a sufficiently large user community around a project, you likely have your own subgroup that gets loud every time significant change is hinted at.  “We don’t want to have to retrain our entire team to do things a different way,” they say. “Small improvements are okay, but don’t go turning us upside down.”

It’s never a great feeling when you feel your project needs to diverge from the comfort zone of some of your most loyal users — most of whom helped you grow from nothing — but it’s more important that your project still exists with at least as much contagious enthusiasm in a year from now.  Hopefully more.

So where’s the “paradox”… Or was that a sensational headline?

I’ll make this real simple.  Let’s say you’re building applications on the LAMP stack.  PHP and MySQL are going to evolve with or without you.  Someday in the fairly soon future, Linux distributions will be standardizing on PHP6 and MySQL 6.  If your application doesn’t work in that environment, your users are going to have to maintain time capsules where it does work.  If their servers break, they’re going to have to spend extra time reverting a new server to old versions of everything.  That limits what they can do with their hardware.  They’re going to miss out on the other less-directly-tangible benefits of the platform: stability, security, maintainability.

Even if your application simply works with new versions of your platform, you’re at the risk of your competition offloading grunt work to their platform and spending their time making their product and packaging better.

The paradox is that you’re going to have to change anyway, and it’s going to cost you far more energy to not change and maintain a time capsule than it’ll take you to embrace change and draw energy from your platform.

Rewriting a successful application can be daunting, but it’s also inspiring to know you’re working on something that people definitely will use because you’ve already proven the idea.  This time you’re informed by all the things that didn’t work out like planned, and you have the ability to turn the roughest spots into the improvements you’re the most proud of.

This is the “why”, but I need to sit down and write out my thoughts on the “how”.  The real dividends from a software rewrite come from sweeping away the scaffolding cruft of a first attempt and building from a stronger,cleaner, more maintainable foundation on the ideas that survived.  It’s also more important to design for changeability than around a concrete feature set.  Your first re-write shouldn’t sow the seeds of your second in another year or two.  I’ll definitely post a follow-up.

Before starting WGM, I used to be among the purist crowd who considered the ability to just “fire and forget” in development a major job perk (if not a requirement). I naively felt that projects started at their conceptual best, when you built from a blank slate, and I didn’t enjoy watching them degrade and get “boxed-in” through the endless concessions made during maintenance and marketing. Ideas were pure and reality was evil. Users was somehow a dirty word.

My reality at WGM, thankfully, has been much more practical; and my collaborative, iterative development eyes are wide open. There’s a powerful, unavoidably-magnetic sense of pride and ownership here that makes it impossible for us to just “fire and forget” anything.

I often find myself entranced by our hosted helpdesk servers. They’re running hundreds of copies of Cerb4 for customers who exist in this — as my past self would say — “messy real-world”. The same past self would gawk at the liability of hosting all this data, and whimper, “I just want to write code!”. After all, every design flaw and inefficiency is embarrassingly magnified on this scale… and yet, I love it!

It’s way too easy to forget how many inefficiencies you’re forgiven when you’re working on a scale of one copy on one machine. I’ve really found my way as a developer by honestly looking at what hasn’t worked, and still trying new things knowing they could very well dead-end, because it’s always a much stronger lesson than simply googling “the best way to _____” and blindly assuming someone else’s opinions or conclusions. Obviously it’s practical to do research, but that’s a far cry from letting something you “read somewhere” become your immutable opinion.

So, do yourself a favor and find a way to be responsible for hosting at least 100 copies of your own software for real users. Naturally, you can charge whatever you want, as long as you still end up with a population of at least 100. Take care to not oversell your hardware, because I’m assuming you do actually want to provide a useful service to people; and your brand is going to be in the gutter if things are completely unusable.

You’ll be getting paid to learn how to write better software. You’ll get the mindshare of being the application people choose because it doesn’t bog down or die when you have a mere 500,000 records in the database.

(If there’s any interest on this topic, I’d love to do a couple more posts about the things I do to benchmark and monitor my applications in our high-use hosting environments.)

I know too many talented and well-intentioned people who are professionally ineffective. Ineffective, because the result of their effort isn’t meaningful progress toward making tomorrow better than today.

(Measuring better is going to depend on the task at hand. For knowledge work, let’s say better means less repeating yesterday through mindless zombie motions today.)

Never-ending droplets

In some roles, emptying a bucket that will never stop filling up with accumulated droplets is the job description.

The ineffective way to handle these never-empty buckets is to just occasionally dump them in the sink.

It would be a lot more productive to dump these buckets into a garden. Our endless tedium could help produce useful resources — food, flowers, trees, fish-stocked ponds.

Conservation of the point

My point isn’t that you should run around hugging trees (but feel free!). Instead, every time you’re barraged with tedious tasks that have no end in sight, and you can’t automate them, find a way to build a garden out of them.

Instead of repetitively laboring through the same questions in phone calls and e-mail, treat them as a resource for constantly improving your documentation or website in ways you hadn’t originally thought of. Tomorrow those improvements will undoubtedly save everyone time.

Using the same example, you could also make a habit of asking each person who calls or e-mails a question of your own. You could tune your marketing without obnoxious and impersonal surveys.

You’ll start to perk up every time the phone rings.

“You should be ashamed of yourselves for charging for software built on free software!”

Hey Potential Customer Who Feels All Software Should Be Free,

I wanted to write you a quick note about your “free software stack” jab.

Libraries, frameworks, languages and operating systems are the prime candidates for being open-source software.  Hobbyists, professionals and students can all share in the building, maintenance and testing of those components.  Everyone can benefit from them for many purposes, and anyone can feed in donations of time, word-of-mouth or money to projects they want to see flourish.

Those open-source components are also used by commercial companies to build applications which are high-level and specialized.  The libraries, components and syntax of a particular programming language act as glue that binds high-level concepts and business logic together into tools.  Such tools are a unified front-end for the constituent components that would individually have little (or no) consumer value or appeal on their own.  Such tools also require a lot of ongoing business-related miscellanea (e.g. support, marketing, documentation) that many open-source programmers would rather live without.

Commercial software has a vested interest in the open-source software it depends on, and an unspoken moral responsibility to provide time, money, recognition, or energy to those projects when possible.  It’s an ecosystem.

It would be a much bigger warning sign to me (of inexperience or misplaced priorities) if a project was rolling its own XML parsing libraries, building its own database abstraction layer, or writing its own templating system, if those components weren’t at the core of that project’s purpose for existing.

Component projects that have philosophical reasons for only promoting free software have the option of releasing their work under licenses like the GPL, which requires derivative software to follow suit.  We use LGPL or BSD/MIT licensed components, where the authors put their work (for varying reasons) into the ecosystem between free and paid software.

Complaining about that is like saying all books should be the cost of their paper because words are free.  There’s a lot of value created by someone who gathers innovative, efficient ideas and technology into a ready-to-use format for your business.

I’m certainly not ashamed of where we fit into that.  You’re a random human being on planet Earth who came into contact with us because of what we’re doing.  Did you also spend the same amount of time looking for programming languages or templating engines?  I imagine you were looking for something a little more immediately usable.

Signed,
 - A dedicated team of talented people who are perpetually immersed in building charming solutions to all those nasty business problems which led you to our doorstep in the first place.

Putting your screencast on most video sharing sites will require you to use resolutions much smaller than full-screen, high-definition video. It’s a shame, but so are bandwidth costs.

You can still provide an incredibly useful screencast in a small video window with a few clever tricks. I’ve found CamStudio to be one of the best screen recorders for these requirements. It has an excellent “follow the mouse” scanning feature, which lets you provide a moving region of your full resolution screen based on what you’re pointing at with the mouse. It’s also free and incredibly easy to use.

For sharing videos, I’ve come to like Jumpcut more than YouTube due to their online video editing toolset, slightly better resolution and more liberal allowances on file size and video length.

What you need to screencast:

• CamStudio: http://www.camstudio.org/CamStudio20.exe
• A Jumpcut login (http://www.jumpcut.com/)
• The DivX codec (http://www.divx.com/divx/windows/download/index.php)
• A headset microphone
• Little enough sleep or enough caffeine to make yourself interesting

CamStudio Setup:

• Install CamStudio 2.0
• Run the application.
• Region->Fixed Region->640×480
• Options->Record Audio from Microphone
• Options->Enable Autopan, Autopan Options->Speed->Max
• Options->Video Options, DivX, Quality 90%, Configure, Home Theater Profile
• Options->Cursor Options, Show Cursor + Use Actual Cursor, Highlight Cursor + Size Halfsize + Circle + Color Yellow (RGB: 255,255,125)
• Options->Keyboard Shortcuts->Record/Pause (CTRL+ F12)

Recording a Video:

• Minimize everything on your desktop and open the application you want to talk about.
• Harmonize your Chi and attempt to channel every great speaker you’ve ever heard.
• Press the record button in CamStudio (or CTRL+F12).
• A region will appear, you can place this anywhere since it will follow you around automatically, but it’s best to place it near where you want to start talking (and where the mouse is).
• Once you place the region, you’re LIVE. Start gesturing wildly and explaining your actions as a running narrative to an empty room.
• After you’ve covered what you wanted to talk about, press CTRL+F12 to pause recording. Open CamStudio in your systray and stop the video by clicking the huge blue square button in the toolbar.
• If all goes well, your video will compress using DivX and pop up a preview that you can play. By default this .AVI file will be saved in your Program Files\CamStudio directory.

Uploading and Editing the Video with Jumpcut:

• Log into Jumpcut (http://www.jumpcut.com/)
• Click “Upload” in the top menu. Click the exorbitant green upload button. Select your video file from the appropriate directory.
• Depending on your upload speed, you may want to get some more coffee or take a polyphasic powernap.
• Once the clip is uploaded, click “Create” in the top menu. Choose “Open the Editor” at the bottom of the page. Maximize your browser if you haven’t already (some options like to hide at the bottom).
• On the right, set the dropdown to “Your Media->all your clips and photos(1)”. Drag your clip to the white frame at the bottom.
• Click “Titles” from the editing toolbar in the middle of the page. I prefer “A Scanner Darky”, but feel free to shop around. Enter your title text and click “Add”. Drag the orange title timing bar from the timeline toward the left until it’s about a half-inch long. You’ll want to experiment with this when previewing your video.
• Click the rewind button in the video preview area (to the left of the play button). This resets the video to the beginning. Click the play button and watch your video.
• Unless you have a healthy ego, or you’re oblivious about your faults, you’ll probably fall to morose depths of self-deprecation while watching the preview. Attempt to remember that you’re going to be harder on yourself than other people will be, unless you had too much caffeine or you’re just really bad at explaining things off the top of your head. If you’ve had 4 cups of coffee and you’re still falling asleep while listening to yourself, it’s probably time for “take two”.
• There are a lot of other fun toys in Jumpcut, but I’m not going to bother explaining them. Play around on your own time!
• Once you’re happy with the video, or at least have resigned to the fact your voice really does sound like that, hit the “Publish” button at the bottom of the page.
• Enter title, tags, visibility and click the “Publish” button.
• You have a video! Even if you chose to make this video private, you can still share the URL with people you trust with your fragile ego in the palm of their hands.
• You can embed this video on your website by clicking the “share” link under the video and copying the “embed” HTML. There are also several other provided options for distributing your video.

Feel free to provide a link to your video in the comments here!

I tilt my head back and let my eyes reassuringly trace the taut lifeline up to the tiny disc of blue sky, the size of a full moon, capping the vertical chamber. The sight sparks an anonymous memory, which flutters to dutifully provoke a faint aftertaste of life in the center of my chest. Never willful to leave anything unanswered, a familiar dream-like reality superimposes itself on my surroundings. It’s as if I’m standing in a subway tunnel, directly facing an oncoming car, while being pulled backwards strongly by something’s insistence that it’s the proper place for me to be. I twist my head to look over my right shoulder, but everything is dark and shapeless. The illusion melts. I find myself still inching downward, carnally addicted to the growing clarity of my thoughts; paternally insulating them from everything that only knows how to dampen and mute.

I pause to contemplate how I’m as equally dependent on the rope staying anchored from above as I am on my desire to not let go of it. While the only biofeedback I’ve received so far has promised that further down is better, I ask myself if I’m any more objective by now than an alcoholic whose bitter swill has grown sweeter with inebriation. I can’t help but smirk as I tell myself the outcome of a bitter poison is the same as a sweet one — that the only difference is the courtesy of a warning.

An electric pain echoes between my left middle finger and elbow. The bloodless knuckles of my left hand wish to inform me that they’ve noticed they’re the only members of our mutual congregation who are doing any struggling. My mouth opens in instinctive response to the mental image of my left hand turning the wheel of a giant faucet, which proffers a drop but promises a torrent.

It’s been a month since I made Remember The Milk (RTM) part of my daily life. At this point, I’d go through massive withdrawals if I had to “Forget The Milk”.

Tips:

• It’s not very obvious that you can edit multiple tasks at the same time by pressing ‘m‘. This is really useful, because I often find myself wanting to tag or schedule several related tasks to reduce repetitive keystrokes and mouse gestures.
• There is a huge list of advanced search options. You can convert any set of search results into a dynamic Smart List. For example, if you search for “dueBefore:tomorrow” you can create a list which will always show the current and overdue tasks for today. Just click the “Save” tab to the right of the results. This gives you a list you can work on until it’s empty, instead of the default lists which will always have future tasks at the bottom. It’s far more motivating to work toward an empty “to do” list!
• Make your lists “Getting Things Done” contexts like @Errands, @Home, @Office and @Study.
• Your lists sort on priority by default. If you change the sorting drop-down to due date it will still sort each date by priority. This makes it easy to spot the occasional high priority task that’s overdue, which you generally want to handle before today’s tasks.
• If you’re like me, it’s a hassle to try to find a specific browser tab when you have 100 tabs open across 15 Firefox windows. Try firing up RTM in a separate browser (IE, Opera, Safari). This makes it a lot easier to jump around the desktop taskbar throughout the day while being productive.

Surprises:

• I originally looked at RTM for the Twitter integration, but I find myself adding tasks through their web interface more often than I use the IM->Twitter->RTM functionality.
• We set up our entire team on RTM so we can share tasks, but with RTM is always reminding me about the next productive thing I should be doing I rarely find myself dwelling on what other people are doing.

Likes:

• Reoccurring tasks are my favorite feature. These help ensure I’m making constant progress on our business objectives (“reply to forum posts every weekday”, “reply to blog comments every weekday”, “assign project tasks every Monday”, “audit the backups every Sunday”), as well as the mundane household things I often overlook (“drag trash cans to curb every Thursday”, “make credit card payments every Friday”).
• The iPhone interface is very convenient, especially if you have context lists like @Errands.
• The flexibility on date entry is fantastic (e.g., “every other Thursday at 5pm”).
• Being able to send a single task to multiple contacts (without having to duplicate it) is a big time-saver.
• $25/yr for the Pro features is quite the bargain.

Peeves/Wishlist:

• It’s a little annoying that the current task remains checked after I save an edit. This forces me to habitually press ‘n‘ (select none) when maintaining my lists.
• I wish I could make my to-do & completed lists public so my contacts could see what I’m working on.
• It would be amazing if my contacts could be notified (by e-mail, Twitter) when I finish a particular task that they’re waiting on. That would be easy to pitch as the killer Pro feature.

If you aren’t using RTM yet, check it out!

Related reading:

• Lifehacker readers vote for Remember The Milk as the best web-based task manager.
• Remember The Milk now integrates with Gmail!

After my post “JIRA Is More Annoying Than Having to Eat Three Times A Day” was published yesterday, Jon Silvers from Atlassian (developers of JIRA) stopped by and left a friendly comment.

I’m incredibly impressed that my tongue-in-cheek critique came to his attention so quickly.

Hey Jon,

First, thanks for commenting! I’m glad you took my ranting in good spirits and left a gracious comment. I must not have put my karma into overdraft protection.

“Hm, there are lot of people who want to eat three times per day, even some that would be happy with one meal.”

Ouch! At the risk of sounding insensitive, I’m sure they also find the daily existential requirement of eating — and the neuroendocrinological punishments for not eating — profoundly annoying too. At least breathing is automatic, or we’d get absolutely nothing else done. I certainly can’t argue against the fact that we’re incredibly lucky in our selection and availability of food.

“My other first thought after reading this is whether you’re using filters to find only the issues relevant to you? [...] It’s not consumer software, it was never meant to be.”

Yeah, the customer-facing bit is really the key to our issues. We’re directing end-users to JIRA to submit their own feature requests and bug reports. For many of the reasons that JIRA is great for developers (e.g., specificity), it’s conversely daunting for our average end-user.

It would be great if we could really take a democratic community pulse on various feature requests to help us build each release roadmap. The voting feature does exist, but our experience has shown that only the most enthusiastic users will go through the trouble of logging in, reading all the open requests and voting on each task’s profile. Unfortunately, the demands on most people’s time necessitates community polling features that are more socially “Digg-like”.

As I mentioned in my post earlier, I did get the impression that a non-developer user community wasn’t intended to be directly served by JIRA’s interface; however, I’m sure we’re not alone in sending end-users to JIRA anyway. There isn’t a good alternative, beyond fielding every request personally in real-time, or transcribing requests from piles of e-mail. JIRA at least ensures busy developers won’t unintentionally ignore feedback.

“We are working interface improvements, with the knowledge that (A) lots of people really like JIRA as it is today and don’t want many changes and (B) others like you want to see change.”

We’re in both camps. As techie developers, we liked JIRA enough to buy it. As community-driven software designers, we feel JIRA needs an additional community-focused interface that streamlines the feedback process and allows user democracy to contribute to project decision-making.

I’d like to see distributed feedback from the community helping to elevate the great feature requests and showstopping bugs above the overwhelming majority of trivial or self-indulgent requests. That would save us a lot of time as developers, and it would display that we’re always listening (which encourages more feedback, and the cycle continues).

Here’s one of the features I’d headline if I was going to create a JIRA alternative:

Even when we aren’t expecting users to directly vote on tasks or add themselves as watchers, we need the ability to create a private waiting list per task. That list would allow us to add links to helpdesk tickets, forum posts or attach contact e-mail addresses. Once we’ve finished a given task, that waiting list tells us exactly who to ping. There are ways to currently hack this together using private comments on tasks, but the feature really should require that we’re notifying the waiting list before the task disappears.

“You might also want to discuss your pain points on our forums [...] or if you can stomach (pun intended) another JIRA, you can log issues and feature requests…”

Haha! I’ll do that. It’s certainly more efficient for you guys than implanting tracking devices in rogue bloggers (or, you know, following everyone’s RSS).

It’s great to see that you guys are so on top of feedback.

Up until I snapped a few minutes ago, I wasn’t sure anything could be more annoying than having to eat every day. After all, I’ve been told by close friends that I’d be a happier entity if I was simply a brain in a jar, left entirely to its own thoughts. I don’t disagree.

Tonight started out normally enough:

• I fired up JIRA for the thousandth time.
• I dug through the ever-shifting, free-for-all, trivial-showstopper, dupe-a-thon of a roadmap for the thousandth time.
• I wracked my brain trying to sort out the new bugs and wishlist items from ‘Unassigned‘ purgatory, which contains over a hundred tasks that aren’t either outright reject-worthy or important enough to schedule.

Except tonight, something cried out in my mind and asked Why are you reading every single thing AGAIN?

It’s pretty embarrassing when you don’t have a good answer for your own internal teleprompter. It must be something like catching yourself with your pants down. There really is no explanation.

I don’t think it’s entirely JIRA’s fault — but I do think I’ve realized we aren’t their target audience. We’d rather just play bouncer at the door of Club Development and decide which tasks are on the guest list, are too damn sexy to turn away, or have a $100 bill cleverly folded into their handshake. Instead, we have tasks sneaking in the side door, cloning themselves, and all simultaneously proclaiming themselves the most interesting thing in the room.

There’s no reason that a user of our software, clutching a precious scrap of feedback, should arrive at Fort JIRA and be put through the Mensa screening program before they can share. We should be rolling out the red carpet and carrying them to the suggestion box in a golden litter.

Perhaps JIRA wasn’t meant to be customer-facing – and that would explain quite a lot. But if I was going to adopt something for my own neurotic use I’d just keep writing out my ideas in magic marker on rolls of toilet paper (or as I like to call them, perforated Post-Its).

Simply stated, we need something that:

• Doesn’t require a customer login of any kind (but may test for humanness).
• Doesn’t feel the need to ask the customer for more than a block of textual feedback.
• Will bother looking for possible duplication when submitting bugs or ideas.
• Allows our developers to quickly tag, categorize, assign and prioritize suggestions on acceptance without requiring us to open each task’s freaking FaceBook profile.
• Lets us simply pile accepted tasks into “Doing now”, “Will do later”, “Probably will never do, but we don’t have the brass pendulums to say so”.
• Provides simple RSS for everything (e.g., new submissions, current assignments).

Maybe I’ll write it. (Then someone can rant about all the things it can’t do that JIRA can.)

Can anyone save me from the compulsive desire to write things from scratch? Let me know in the comments.

Robert Scoble recently stated why enterprise software isn’t sexy enough to cover on mainstream technology blogs.

He offers two arguments:

• The majority of tech blog readers will never be in the position to buy enterprise software.
• Stories about business software, due to a disconnect with their readership, don’t produce meaningful traffic for the blog’s advertisers.

He then asks what can be done to make business software sexy enough to talk about.

Here’s my take contribution to the discussion:

For the bloggers:

If a large software company is giving day-to-day end-users the cold shoulder to schmooze with the market’s decision makers, then they aren’t owed any organic word-of-mouth.

As Scoble points out, anecdotally (but my experience agrees), most workers on a company’s front lines will probably trend toward hating their current business software when asked. In fairness, I also doubt the majority of those workers are offering management a request for any specific alternatives.

This is one area where technology bloggers could be doing a valuable public service, by informing technology workers about the good ideas coming out of the business software market. Make people say “That is much better than the crap I have to use every day!”.

Even if these tech workers are disempowered, and feel their petitions to management are futile, the situation will never improve if the only discussion going on is paid for with multi-million dollar advertising budgets.

For the enterprise software developers:

Assuming for the moment that you want more organic word-of-mouth (and who doesn’t):

• Hire and empower enthusiastic developers who bring fresh perspectives to your problem domain. Look for developers who have first-hand experience as users of software like yours. These people are going to put more thought into the problem you’re trying to solve for people. If time is money, then efficiency is time. Time and money are sexy. 12 keystrokes for common functionality is not.

• Listen to your end-users. These are the people who have to use your application every day. You might think it’s more important to appease the people making the current buying decisions, but today’s helpdesk worker may very well be tomorrow’s influential startup founder. Technology enthusiasts like this attract a large following and they love to talk about what they’re discovering or using. Don’t outsource your suggestion box – let your actual developers connect with the end-users through online communities and feedback portals. Two-way communication is sexy. Megaphones, press releases and moats are not.

• Make an effort to adopt current technology. A lot of technology bloggers, developers and consumers would love to talk about a behemoth like you using some of the same tools that they are (maybe even some tools they wrote!). This doesn’t mean you have to offer an iPhone interface or rewrite everything in Ruby. There are plenty of opportunities for a big tech player like you to contribute to communal libraries which meet 90% of your needs already. Open source libraries and tools are sexy. Golf course nepotism is not.

• Be approachable for technology enthusiasts. Look at Sun Microsystems’ Startup Essentials and Amazon’s EC2/S3 web services. Those strategies build a relationship with non-captive users and let them figure out what you’re all about. Those people broadcast over blog, IM, text or a good old-fashioned chat over drinks. I trust what my peers tell me about you a lot more than I trust an advertising testimonial from the CEO of Megacorporation, Inc. Reaching out with downloadable demos and startup friendly options is sexy. Hiding your entry-level pricing and product demos is not.

You might want to hurry,  business software users are trying new things too.

I’ve been programming for about 16 years now.

I almost called this my “Most Important Programming Lessons”, but I consider writing software to involve far more than a mastery over programming arcana.

When I first discovered source code, I didn’t pick up a manual and start reading about data structures and flow control. That was a lucky decision for the current me, because the former me would probably have been overwhelmed and lost interest.

Instead, I kept myself entertained by making little changes to programs that I already knew worked. I’d do fun things, like surprising the gorilla in the QBasic game ‘Gorillas‘ by modifying his thrown bananas to explode like atomic weapons. The poor guy never saw it coming.

I was writing code for me.

Anytime I showed my latest tweaks to somebody they would laugh in appreciation — but then they would always come up with another idea to push things further. What if the bananas fragmented on their descent like a MIRV missile? What if the bananas became the hero and they threw gorillas? Ha! I was hooked.

I was dealing with feedback from people who became truly inspired only after seeing something working already.

Eventually, I figured out enough through my tinkering that I could face a blank screen and enter my first instructions to make the computer do something. Paint the screen red. Draw a box. Beep!

I would only make a couple small improvements before compulsively running the program again. Did I predict how things would behave, or was I about to be rewarded with something completely unexpected (and often hilarious)?

I was practicing iterative development.

As the years of experience piled on, and I worked through various programming gigs, I started to get overly-confident in my ability to think like the computer. I wrote code for longer stretches, at times making changes so vast that it was impossible to actually run the program for several days. I also started to preemptively add new features, and I delayed for longer periods between demonstrating the new changes to actual users. “It will be finished when my task list is finished!” I thought, naively.

My growing confidence in programming was undermining my ability to collaborate with non-programmers. I was also looking at projects as a checklist of disparate tasks, instead of a cohesive experience for the user.

One day, probably after completing yet another soulless project — with my team breathing a collective sigh of relief, as if being spared from an execution at 30 seconds before midnight — it finally dawned on me that things shouldn’t be this way. Things didn’t used to be this way.

I made a short list of things that detracted from the fun I had when starting out:

• We were writing projects that we didn’t need, and wouldn’t use, ourselves.
• Management, alone, was deciding the tools we used to solved our problems, usually because of executives who bought into vendor marketing at face value.
• Our project managers weren’t programmers, and they weren’t end-users, so they couldn’t effectively communicate with either side. Their project plans revolved around the least important party — the middleman.
• Our talents were being rented out at five times our compensation.
• We had no stake, or risk, in the success or failure of our work.

Shortly after this epiphany I quit my job as a complacent programmer. I co-founded a new software company where we established an ethos of:

• Writing software that we would use as much as our end-users.
• Talking directly with our end-users instead of using middlemen.
• Sharing ideas and changes as early as possible.
• Emphasizing that sales were votes of confidence in what we’re doing going forward, opposed to a payment that merely offset our past work.

Dozens of projects, half a dozen programming languages, and tens of thousands of hours of experience later, and I it turns out I learned my most important software writing lessons in those first tinkering days with QBasic.

Did you practice any of your favorite software development lessons well before you realized what you were doing? I’d love to hear about it in the comments!

Related reading:
http://www.extremeprogramming.org/
http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

Burnout.

It starts with the feeling you can overcome anything.
It’s reinforced when you overcome a swell of adversity.
It languishes when you thirst for more mountains to climb.
It roars into revival when your enthusiasm brings you to the truly insurmountable.
It laughs when you try.
It grows when you struggle.
It lays roots when you capitulate.
It wins when you’re left with want for nothing.

So what’s the trick to surviving the curse of having great potential and the stubborn perseverance to succeed at all costs?

Having an anchor.
Having a necessary distraction.
Having something that lends purpose to your tireless effort.
Having a goal that means more to you than a dream you plucked out of a hat.

Not leaving yourself enough rope to make a noose with.

The last card in the deck of virtues that you want to be left holding at the end of the game is the ability to dig in and tough out anything. Because you will use it. Repeatedly. Just because you can.

Boundless enthusiasm is best exercised in small passionate bursts.
It’s best if you embrace the spirit of “boundless” without looking for boundaries.

If we’re anything alike, you also use a wild tangle of web applications to manage your life or job. We all love web applications — they’re often inexpensive (if not free) and they allow us access our data from almost anywhere. If you have a modern cellphone then you’ve probably also felt the special magic of being able to access all your personal miscellanea from a tiny device that’s always with you.

The best part about having an endless sea of web applications is the ability to find something that fits your one specific need really well. You don’t need a monster application that tries to do everything and ends up doing nothing exceptionally well. However, without a single point of focus you become inundated in bookmarks to all your tools.

Luckily, a new breed of applications is being born from this ingenious epiphany: when you’re at your PC, your instant messenger (IM) is like your cellphone. It’s always with you. Suddenly, you can chat with your various web applications as if they were simply people on your buddy list. You no longer have to visit each site and log in. Your credentials become your instant messaging account.

One project that really understands this mentality is Twitter. If you’re not familiar with it, Twitter allows you to post quick updates about what you’re doing from a social website — but it really makes sense when you send updates from your IM or cellphone. These updates can be forwarded to your friends automatically in a way that’s almost telepathic.

Among many other things, two really interesting things have evolved from the simple idea that spawned Twitter:

First, ordinary people started following celebrities and quasi-celebrities in addition to their friends. While one’s first impulse is often how this is just an extension of reality shows, or a marketing scheme by these public figures, it’s actually something much more interesting in practice. You find yourself feeling like you’re intercepting the thought processes of people you admire. A lot of people already use Twitter: Authors of your favorite books, representative political figures, developers of your favorite applications, major news organizations, creators of your favorite television shows and so on. There’s obviously another long list of benefits for each celebrity.

Secondly, developers started to realize that their popular applications could also interact directly with their fans. Twitter already provides a communications platform that has a ton of existing users. This avoids the pitfall we come across in development where we’re asking users to adopt yet another discontinuous tool or process. Most people don’t want another tool. Anybody with an instant messenger account can communicate with Twitter and, by extension, communicate with some of their favorite applications.

I’ve found myself switching my digital life over to applications that understand this new “mashup” mindset. My current favorite example is “Remember the Milk”.

Remember the Milk (RTM) is a simple online task list. It has a clean interface and uses Ajax tastefully for its user interaction. Otherwise you’ve seen this kind of thing before: tasks, due dates, lists, yada, yada. What’s really special about RTM is the ability to remote control it through IM. Not only can you update and receive notifications about your own tasks, but you can also quickly send tasks to friends and co-workers who have an account with RTM and Twitter.

For my part, my usual suspects are my friends and co-workers at my software company. We often pass tasks back and forth through IM, e-mail and post-its. After several years, we’ve come to the conclusion that none of those options are very dependable. We’ve tried all kinds of task management software, but our busy workplace has the habit of refining out superfluous tools or steps. People simply stop using them. The one constant fixture in our business chatter is our instant messenger (namely, Google Talk).

Blending the useful combination of Twitter and Remember the Milk into our commonplace IM communication seems like the way to make this shared task tracking finally stick. Instead of telling each person something the moment it pops into my head, regardless of what either of us is doing, I can simply IM it off to RTM to be added to their task list. They then receive reminders by IM of their current tasks from the RTM contact. Nothing gets buried in the chat log or inbox. They don’t need to log into RTM daily to be reminded of tasks we’ve given each other.

My hope in writing this article is giving you something to forward to your usual suspects, who will then rush onward to make your mutual existences more painless and dependable.

If anyone has other mashups like this I’d love to hear about them.

Here’s the 5 minute rundown:

Sign up with Twitter

Visit https://twitter.com/signup

Feel free to follow my updates for future tips: http://twitter.com/jstanden

Integrate Twitter with IM

In Twitter: Settings->Phone & IM

Register your IM account and verify it as instructed.

Sign up with Remember the Milk

Visit http://www.rememberthemilk.com/signup/

Add your IM account to: Settings->Reminders->”I want to be reminded by”

Integrate R.T.M. with Twitter

Follow ‘rtm’ on Twitter: http://twitter.com/rtm

Visit: http://www.rememberthemilk.com/services/twitter/

Enter your Twitter username and follow the simple verification step. This page also contains a very neat list of commands for remote controlling your RTM account through through your IM account.

Done!

That’s it! If you have any questions or run into any trouble, I’d be happy to help in the comments.

Update: Lifehack has an excellent summary of using Twitter productively with a great list of examples.

Update #2: I found another great list of Twitter mashups on Digg from Jake Bouma, and this Big Juicy Guide to Twitter from Caroline Middlebrook.

Scanning through the November 2007 analytics for www.cerberusweb.com shows 34% of our traffic comes from Google search results. We’ve always had a strong “word of mouth” factor in our marketing, but sometimes we get a bit too proud of that and overlook the benefits of fresh traffic from paid advertising campaigns. To a proud software developer, paying for ads almost feels like prostitution.

In the past we’ve advertised with iNET Interactive (on Hotscripts.com and WebHostingTalk.com) and used Google’s AdWords. Both of those options brought in fresh clicks, but both also delivered a majority of their traffic with an incredibly high bounce rate (people leaving after a single page) and a very short time spent looking through our site (usually mere seconds). With our natural search results doing so well on Google we eventually abandoned AdWords.

Since we’ve just finished up a 9 month development marathon of getting our new 4.0 release into people’s hands, we’ve been taking a survey of our new media advertising options. Things have changed quite a bit in the past couple years.

I took a quick glance through the sites for Slashdot and Freshmeat since they tend to send us a lot of traffic. It looks like OSTG also removed the self-service advertising portal, though they joined up with the FeedBurner Ad Network.

I also took a look at how Merlin Mann served ads over at 43Folders, since his “Inbox Zero” philosophy has a lot of common themes with our web-based helpdesk software. He’s using Federated Media.

There seems to be a consolidation trend by blogs toward Federated Media and FeedBurner, along with a few niche and exclusive networks like The Deck. We definitely wanted to advertise to these blog readers who were already interested in productivity and group e-mail management.

Both Federated Media and FeedBurner offer self-serve, web-based advertising portals. You can log in, select your audience, upload your creatives, schedule the campaigns and pay through PayPal in a matter of minutes.

On Federated Media’s network we selected an initial audience of: 43Folders, TechCruch, Mashable and VentureBeat readers. Mashable was a long-shot, since it’s practically an anti-productivity site, but we felt a kinship with the spirit of mashing web applications. We mixed textual and leaderboard (728×90) graphical banners.

Photo by Somewhat Frank

FeedBurner offers you a choice of Networks and Channels, which group together subscribers and feeds, respectively, into simple packages like “Venture Capital” and “Digital Culture”. We chose to advertise to the Venture Capital and Entrepreneur networks. This gave us coverage on about 230 blogs, which was also useful for wide-scale brand exposure. We only ran textual ads with FeedBurner.

Our initial batch of ads went live the following morning. The campaign had a simple message to try out: “The biggest obstacle in replying to your daily e-mail shouldn’t be your inbox”.

We use Google Analytics to monitor traffic on our websites. Federated Media and FeedBurner also offer simple “click” statistics for your campaigns. It was easier to just follow along using their interfaces, since our primary mission was to figure out which audiences responded the best to our message and then throw our money behind those campaigns.

After two weeks, the top result with Federated Media was rather surprising. 43Folders did very well, as expected. Mashable and VentureBeat did abysmal, which wasn’t a big shock. But it was TechCrunch that was the undisputed champion in delivering high-quality eyeballs to our project website. It brought in more clicks than all the others combined and doubled, at a cost of about $2.66 per click. One sale buys us around 188 more clicks (in theory, since you can also buy run-of-site text ads for a week that don’t count impressions).

On the FeedBurner side, the Entrepreneur network had a decent click-through rate but very few impressions – reasonable, since it only counted for 15 blogs in the total coverage. The Venture Capital network, however, brought in far more clicks than all of our ads at Federated Media. The average cost-per-click was $3.52. One sale buys us around 142 more clicks – 75% of what TechCrunch delivers, but to a much bigger audience (230 blogs vs 1). That wide-scale branding is worth a small trade-off, and there is room in our future campaigns for both.

In the end, we decided to make TechCrunch, 43Folders and the Venture Capital network at FeedBurner the backbone of our new paid advertising campaigns. We’re anxious to continue exploring the various sites and channels provided by both networks.

I don’t really have anything bad to say about our experience with either. I found myself wishing FeedBurner would summarize clicks by the individual sites in each channel (it’s pretty obvious why they don’t). You can still infer the sources through Google Analytics. My only trivial complaint with Federated Media was their ad inventory has sold out on popular sites between our campaigns. I doubt people want to see even more ads on blogs, so the real answer is for both networks to continue growing and encompassing more blogs with topics we feel an affinity with.

It’s probably not the smartest business move to disclose where we’re finding success with our advertising — but it’s healthy for the blogging community as a whole to promote funding for those who are freely sharing knowledge and not holding back.

Naturally, not all businesses have a choice of whether or not they’re going to be funded or bootstrapped. Some business plans will always require major equipment, inventory, real-estate, licensing or other initial costs that simply cannot be paid for by actual customers voting with their wallets. A software company, on the other hand, simply requires a computer, a desire to constantly learn new things, a great idea, and the ability to spend most of your day (or night) staring into the embracing glow of a computer screen.

When you aren’t bootstrapping a software startup you usually have the funds available to pay people a competitive salary, grant stock options, or give them an environment that’s so engaging they’re willing to trade a bit of their paycheck to work on “the next big thing”. Everybody can still pay rent. There likely isn’t a founder sitting there thinking about how many sales it takes to keep the lights on (just how many sales it takes to bank a million). The downside is you can spend too much time having fun in “abstract business plan land” and burn through your funding without setting up the infrastructure required to generate a sustainable money train.

When you are bootstrapping a software startup you usually can’t avoid setting up the infrastructure for creating the money train, because you likely wouldn’t survive more than a few weeks without something in place early on. This organic growth is incredibly dependable as things mature because you always know people are willing to pay for your expertise or service. There is nothing hypothetical about the plan. You can feel the pulse of your business, and the merit of your ideas, by the flow of cash from customers into your business. However, many homegrown businesses don’t get off the ground (or out of the spare bedroom) because of the glaring catch-22 prescribed by “it takes money to make money”.

(I think I’ve pumped the maximum amount of sunshine into the bootstrapping side of the equation.)

My current software company was born in the second camp, initially funded by credit cards and a lot of founder-donated, unpaid overtime. We had no lack of late nights spent clicking away on keyboards, appeasing compilers and cursing out Internet Explorer. Yet, 6 years ago, we sold our first copy of our first product within 2 months of picking a name and writing the first line of code. (yes, it was a time of many “firsts”).

Ever since that first early sale, we’ve adopted a policy of rapid development and letting sales be the barometer of how well we were spending our time. If we weren’t responding to community feedback, or we ignored glaring problems to work on more glamorous ones, money would stop flowing in and we’d go bust — or at the least we’d be playing a game of “rent, ads, electricity, health insurance, DSL. Pick any two.” We’ve designed the company to maximize that constructive pressure, and it persists even six years later.

This seems like a rather common-sense revelation at a glance: “people pay you more when you’re doing your job better, and less when you aren’t”. But it’s not that simple, because it’s so easy to separate sales and development into two isolated groups that only work together when, and because, they have to.

It’s much more difficult to tie every single founder and partner to the cashflow of the business, so that development knows how to help sales to its job and vice-versa. We can dig into that collaboration in future blog posts. For now, let’s skip ahead to what to do when money starts trickling in.

Obviously, if you have $8,000/month in early sales you can’t mandate that Dwight the lead programmer makes $75,000/year and Jim in sales has a base salary of $40,000/year plus commission. (If you haven’t had your coffee yet, the explanation is that those numbers add up to at least $9,584/month and don’t even include business expenses or other payroll — the money just isn’t there).

You certainly don’t want to start keeping an I.O.U. from the company to the partners, to be paid back “when you make money”. That is important, and it warrants repeating: Do not set up I.O.U. salaries.

All that is going to happen with an I.O.U. salary is complacency, and inevitably a founder will leave and expect to cash out their accrued “overtime” balance. If the company isn’t producing money, nobody deserves anything at the current point. You can’t avoid that if someone is leaving and divesting stock/options, but don’t fall into that trap with salaries.

However, it’s certainly a good idea to know roughly what each person is contributing and how that should translate to a realistic target salary. The process of determining that should be transparent and candid, and involve all the partners. In our previous example, if sales balanced perfectly with payroll, Dwight would take a 65.2% split and Jim would take a 34.8% split. Those splits are distributions of profits, as you always have to pay business expenses first.

What I would advise for Dwight and Jim is this:

1. Set up a simple spreadsheet with three columns. The middle column would hold the target salaries, the column to the left would hold a scenario of “less than ideal” income, and the right column would be “bonus” income.

2. The top of the spreadsheet, above the salaries, would contain all the immutable expenses of the business, such as: rent, DSL, health insurance, ads and utilities. There should also be a miscellaneous category of historically-averaged discretionary spending (for books and snacks), and a “slack” category to ensure some profits are returning to the company every split. The slack can be used as a buffer during bad weeks, or as a war chest for investing (e.g., hiring new people, expanding, unexpected expenses or repairs, or literally investing in some asset).

By my plan, the amount distributed to the buffer is completely arbitrary and might change often or cease entirely after a specific amount is saved. It really depends on everyone’s comfort level, but you should strive to split as much of your early profits as possible.

If you chase the pot of gold at the end of the rainbow too long, you’re going to get there alone, in poor health, with less friends than you started with — if you get there at all.

3. Every Friday the gross income should plug into the top of the spreadsheet. It should then percolate through the expenses and buffer (which are represented by their weekly costs). The resulting remainder is the net profit. This is the amount you actually have available to pay everyone.

Set up the spreadsheet to use the middle column (salary targets) as percentages. These establish the proportions for the columns on either side. For example, the ideal salaries from the example above required $9,600 per month, which is about $2,240 per week.

If $1,500 of net profit comes in the door this week, Dwight gets $978 (65.2%) and Jim gets $522 (34.8%).

If $3,000 of net profit comes in the door this week, Dwight gets $1,956 (65.2%) and Jim gets $1,044 (34.8%).

The reason you set up 3 columns is so you can play “what if” with your income during the week (better or worse than the goal). Usually I have the current income in the left column until it passes the goal, and the right column is always set to an attainable bonus goal to give us something to constantly strive toward.

4. At some point, it’s no longer going to be realistic to split 100% of the profit between the partners. At our company we currently set this cap at 120% of our target salaries, as long as we have a good business use planned for the remainder (buying more ads, hiring more people, investing in more assets). We won’t cap splits if the only thing we can think of doing is creating a big pile of “buffer” money and then swimming around in it.

5. Re-balance the target salaries when you’re constantly passing them or when you add new partners.

As you can imagine, it takes a lot of trust and candor to set up a system like this, where everyone can plainly see how much the business values their input against everyone else. Target salaries should be established by the group and voted on. If you’re running a proper meritocracy (this is the software industry, after all!) it’s probably pretty clear to everyone already what is brought to the table in terms of time, experience and talent.

If you don’t think your group can handle individualized valuations, then just establish salaries per role. But leave yourself the option to reward all-stars. You can quickly rationalize to the naysayers that this person will make slightly more, but so will everyone else though their efforts at boosting the overall income. You don’t want to burn out an all-star any more than you want to constantly cater to a naysayer.

Having the burden of expenses clearly shouldered by (and apportioned to) the entire group also helps trim needless spending from the startup’s budget.

We’ve carried this system into our 6th year of business and adjusted it as new partners came on-board or our expenses grew. We’ve added payroll employees as expenses at the top of the spreadsheet. We’ve regularly gone through the expense categories as a group and looked for waste. This transparent system has focused everyone’s eyes on the bottom line — and we’re a leaner and more efficient company because of it.

If you’ve bootstrapped a startup with full-time partners, how did you decide to distribute cash before there was enough to go around?

First, the necessary disclaimer: I like risk — a lot. And chances are I don’t know you or your financial situation. My thoughts on investing should be considered entirely anecdotal. Nothing I say should be construed as financial advice that has you, or your best interests, in mind. I have no problem risking all my own money, but don’t weigh down my conscience by vicariously investing yours based solely on something you read online.

As a partner in an American LLC I’m responsible for my own tax planning. Tax, social security or Medicare are not withheld from my paycheck. Partners pay estimated taxes and self-employment taxes to cover what’s usually withheld by employee payroll.

Since I learned a lot of my business acumen from survival situations, I’ve developed a love for Opportunity Cost, and a hatred for not maximizing funds (like, say, paying for a year of car insurance in advance instead of investing the excess).

For the past couple years I’ve been lumping my personal tax savings in with my regular weekly investments. That means, while I’m responsibly setting aside enough money for taxes, I’m riskily throwing that money into the stock market to be potentially consumed by mass paranoia or emotional stock picking. It also establishes a terrible thing in investing — a deadline. I pay my full lump sum of taxes in April along with a penalty for not prepaying using estimates. That penalty is around 7%, but it’s capped at 7% of my total taxable income for the previous year. It’s a calculated risk.

Supposedly, capping the penalty to your previous year’s income is forgiveness for your inability to plan for unexpected raises or windfalls during the current year. According to the IRS, you should always estimate by paying at least as much as your taxes from the past year. That’s reasonable. If you don’t estimate enough, they tack on a penalty because you didn’t allow them to squander any of your hard-earned money before April 15th.

As a partner with a major material impact on my company, and a direct share of profits, I’ve been safe in assuming I’ll take home over 7% more for each year I spend building the business. So far things have been good and it’s been well over that.

So my entire game with investing taxes throughout the year is trying to beat a 7% return with enough extra profit to make the risk-taking worthwhile. In reality, since I make and invest more each year, the target is a bit less than the full 7% penalty. If I play it too safe, I’m not going to beat the market and I would have saved money by just paying my estimated taxes. If I play it too loose, I’ll lose some of my principal on top of still paying full taxes and penalties.

Just before the recent market dip this November I was running about 35% ROI for my entire portfolio (including gains on recent deposits). At the moment it’s about 25%, but that’s still plenty to make this risk worthwhile.

To take on this reasonable risk I’ve found myself coming back to a couple habits. I’m sure fragments of these habits were picked up from learning and reading over the years, and a lot of them are common sense. However, sometimes there’s a longer road to a common sense answer and a shorter road to a convoluted one (due to the convolution often being more fun/interesting/challenging). I don’t claim these tenets form some proven system, that it’s reproducible, or that it’s even unique. It’s just what I’ve found works for me.

1. I forget that the numbers in my portfolio represent cash-money dollars that I can buy things with.
   If I was constantly measuring gains or losses in HDTVs, Macbook Pros or new cars then I’d drive myself crazy and I’d start to get apprehensive. I remind myself that the swings, up and down, don’t matter until I actually pull my cash back out of the market. In long-term investing you can generally wait as long as it takes to get paid — or at least until you see a much better deal that can offset your losses. I still have to respect my Tax Day deadline.
2. I stay blissful when the market is panicking.
   I always know what I want to be buying. All my watch lists show the current price between the 52 week low and 52 week high, with the P/E ratio, growth rate, EPS estimates and volume following immediately. I get really familiar with my watch list stocks so I know the range they like to run around in, how they react to good/bad news, and if they’re commonly manipulated by big money before noteworthy events (*cough*, AAPL). I’m not trying to “time” my buys in the trading vs. investing sense — it’s just all about perspective when everyone else is emotional. I love to “stock up” from my wishlist during a good cathartic market dip. I plan to go long on all the things I buy. I’m holding many of those buys well beyond Tax Day.
3. I limit my lovin’ to 10 stocks at a time.
   One of my early mistakes in buying stocks was having so many “good” ideas that I was essentially running my own mutual fund. Any great picks I had were averaged out by the overwhelmingly mediocre ones. I had a really hard time staying ahead of the market while doing that. Today I limit myself to no more than 10 individual stocks at a time, which forces me to focus and properly capitalize those picks. I never have to worry about not having enough “oomph” behind a well-researched pick that pops, and if a stock really takes a beating I’m familiar enough with it to know whether to kick it to the curb or buy more at a discount. (Since it’s one of my privileged 10 I’m usually buying more when something temporarily drops.)
4. I focus on my overall market value (balance) more than my gains.
   Since my goal is accumulating money, for taxes and the freedom to do what I want in life, I try to stop myself from hyper-focusing on the gains of a specific stock or my portfolio as a whole. Because I deposit money into my brokerage account weekly I’m constantly pulling my total gain down slightly, but my balance (with gains and deposits) is constantly going up. That doesn’t mean I ignore stocks that are going down, or that I don’t cull stocks with bloated gains, it just means I stop pretending my game is trying to hit 200% on AAPL or 50% on the whole portfolio. I’d have to start employing counterproductive tricks to keep overall gains that high. By watching the balance I don’t lose perspective of the big picture during a dip.
5. I compete with and against friends.
   I find it much easier to adhere to my rules when I’m constructively competing against friends who have their own investing methodologies. Some of my excessive love affair with risk is tempered by looking at what more moderate (or even risk-adverse) friends are doing, and how well it’s working out for them. It’s also really encouraging when my strategy hits higher highs without having lower lows. Despite the benefits of camaraderie, it wouldn’t be nearly as much fun if we all tried to do the same thing — but a little overlap on a stock pick where two of our strategies meet is a lot of fun.
6. I “double down” when the market forces irrational losses.
   If a stock I’ve done my homework on starts dropping, rather than trying to sell my positions for a better entry point later, I find myself just buying more. This is often referred to as pyramid buying, because you start with a smaller position to test the waters and you buy increasingly more as you’re more confident the bottom of a crashing stock is near. This is a really risky tactic, and it’s something I only do when I’m completely convinced the market is being irrational and applying market or industry paranoia to a specific stock that doesn’t deserve it. Some people appropriately call this strategy “trying to catch a falling pencil” (a lesson I only had to learn once in elementary school). I try to keep in mind that the perceived stock price and the value of a company are often two completely different things — but over enough time they generally come back into harmonization and complement each other.
7. I enjoy myself.
   Managing my stocks this closely would probably feel like a part-time job I had to do each morning if it wasn’t such a fun game. “Down days” require a completely different strategy than “up days”. Each of my 10 stocks in this portfolio feel like a chess piece that is benefiting from, or defending against, specific events. The picks work together, and often I’ll watch as one or two pick up the slack while the others are getting beat up. Some days everybody except one or two is having a party, and they tell the down stocks “Don’t worry, we’ve got ya covered! You saved our ass last time.”