1- They don’t think of themselves as rock stars.

Arrogance is perhaps a key requirement in being an entrepreneur, but overconfidence will drain your cash pool faster than hookers and blow.

2- They have a proven track record of multiple shipped products.

You don’t want a hotshot kid out of school, you want a seasoned professional, preferably one who knows how to write applications for the industry you’re trying to reach.

3- They care more about frameworks than plumbing.

Unless you’re trying to design a complex new mathematical algorithm (in which case you should probably be partnering with a university research lab), you want someone who can grasp a system rather than a method. If this guy ends up in deep technical discussions about the optimal way of implementing a sort, you’ve got the wrong guy.

4- They’re not willing to work for free

Risk management and strategic thinking is key to long-term project viability. If you have someone willing to work for equity, they’re willing to take risks with your payment processing gateway just as easily as they’re taking a risk on you.

5- They believe in development process and best practices to speed up their work.

The last thing you want is someone who’s trying to reinvent the wheel. Mind you, this also likely means that the first two weeks or so of development you’ll see a lot of development support tools get set up and used before code actually starts, but that’ll give you time to get your documentation in order.

6- They have a positive attitude.

If someone bitches, they’re looking to blame themselves. Instead, you want them to identify their concern as a problem they can solve.

7- They get uncomfortable when you ask about their social life.

’cause, well, currently it’s still socially odd to prefer coding on a saturday night.

8- You don’t want Alphabet/Acronym soup in their technical skills.

Lots of languages means little depth in each, and depth = speed. Pick a serverside language (PHP, .Net, Ruby, etc), pick a database (MySQL, SQLServer, Postgres, etc), and pick a frontend (Flex, Mootools, JQuery, etc). Focus on that. If a dev has only a few languages this does not mean they’re stupid- it means they know how to focus.

9- They’re involved in the community.

Speaking, attending, whatever, you need to make sure their technical skills don’t stagnate, and that they’re willing to accept ideas from outside.

10- You respect them

Respect means you are willing to listen when they tell you you’re full of it, and that’s key in a partnership. You’re not looking for a monkey you can put in a corner who can bang out some code- you’re looking for a partner who’ll act as a technical sounding board.

So now I have this question: What makes for a rockstar business partner?

I have had no small number of conversations with my boss about the nature of Work-Life balance. Today’s everyday wisdom says that you have to keep both your personal and professional life properly segregated if you want to lead a happy life, and yet work continues to raise it’s ugly head once I leave the office. Case and point: I’ve been in the office most of the weekend trying to complete some tasks that I was unable to complete during the week, and even now I’m having a hard time even thinking about them in such a way that I can complete them and finally go home. Frustrated, I flipped back over to my browser and read my RSS feeds to clear my head, an came across an article on multitasking that allowed me to frame the problem in a way that made some sense: It’s not the work-life balance that I need to deal with, it’s the work-work balance.

The author in the article makes a reference to something called "dual task interference", which in a nutshell means that the brain cannot really do more than one thing at a time. You can switch between different tasks fairly rapidly, but according to research (citations for which I have yet to find, apparently there was a study at Stanford) doing so dramatically reduces your mental capacity for both tasks. You end up not firing on all cylinders when you’re trying to accomplish more than one thing at once.

Lets take this into the office space: Let’s say you, like myself, are a developer who sits on an open floor. It’s easy for others to walk up to you and ask questions, and depending on where you sit on the team you could be pulled into a variety of meetings haphazardly scheduled throughout the day with breaks of intermittent length. You have neither door, cube walls, nor some way of shielding yourself from the rest of the world (except for maybe headphones). Now from a management and collaboration standpoint this environment is great: All the resources are readily available to each other, you can have impromptu discussions if you hit a roadblock or if something interesting comes up, and questions can be directly posed rather than sent (and forgotten) via email. Personally I love these environments because I’m very extroverted, and it feels like I’m working at a party, which given the conclusion presented here means I’m probably one of the worst offenders.

Let’s take a look at this from the perspective of interference: Every time someone asks you a question, you’re distracted from your task, and your brain is trying to both not forget where you left off the task while also coming up with an answer. Every time you see an email popup come up, you’re distracted. Every time a coworker IM’s you, or you have to start prepping for a meeting in 15 minutes, or something that’s important to someone else needs to get done your mind starts splitting itself and you get, to put a fine point on it, stupid. The very act of creating an environment conducive to collaboration guarantees that your employees aren’t working at their peak capacity.

There are aggravating factors as well: Do you have your IM client running? How about new email notification? Do you have an automated process in your brain that loads up your RSS reader every half hour? SMS? Weather warnings? Twitter? A low battery beep on your cell phone? All of these will similarly distract you, and chances are that anyone working at a computer these days has no less than 2, maybe 4 things occupying their attention at any given point in time.

On top of that, we developers have to construct systems that requires quite a bit of mental capacity, and having a question fielded by another team member on a different topic right when we’re in the middle of something is much like wiping a magnet across a disk drive: You have to get back into your code, remember where you were, reconstruct the logical process you were following and then pick up where you left off. For small tasks this isn’t much of a problem, but if your application is particularly complicated…. well, speaking for myself it takes anywhere from 10-30 minutes to reconstruct where I was, assuming another interruption or meeting doesn’t come along.

The natural conclusion of this is that it is in the best interest for yourself as a developer, your company, your clients and practically everyone on your team that you cut out as many distractions as possible. Yes, the current generation is all about being instantly and constantly connected, but to actually accomplish something you have to let it all go. Turn off your IM client, schedule certain periods of time when you check email rather than leaving it open, block out time during the day when you simply refuse to attend meetings, and be ready to ask a coworker to bring his question back at another time.

In short, learn how to Singletask, to focus exclusively on what’s in front of you.

The only thing that seems to be tying all these things together on a consistent basis is speed. Contribution needs to be fast, results have to be instant, and if something doesn’t catch our attention within our rapidly diminishing attention span, the audience moves on to the next best thing. Things with real staying power are growing fewer and fewer, and the last thing that seems to have any kind of tenacity is reputation.

Let’s face it: Employers, clients, friends and colleagues will search for our names online, and an even sightly determined sleuth will be able to uncover a substantial amount of our history. As a result we each have to be very careful about managing our online activity, and in particular our professional reputation; Even the slightest negative comment found in a search result will raise unwanted eyebrows, and raised eyebrows mean lost interviews, bids, and job opportunities.

To that end, I’ve tried to list a few rules and guidelines that I follow. I’m hardly perfect at them, and there are exceptions for each, yet overall they are things that I’ve learned that are absolute must-haves in order to properly manage your reputation as a developer.

Rule #1: Don’t misrepresent your skills.

The first and foremost rule is not to lie about what you’re capable of. This can often be tricky, because skill and competence are largely subjective in nature, and the title “Developer” can span anything from a college dropout with a PHP tutorial and an Ego to a 15 year assembly veteran who knows how to read a core dump.

This rule is especially hard to follow when you’re a junior level developer, trying to break into an industry, or a freelancer short on paying projects. As the bills start piling up the pressure to enhance a resume increases, and there are many ways of spinning a phrase to make it say one thing but mean something completely different.

Consider the consequence: You’ve engaged in some creative embellishment and finally landed a gig. You start working, and your lack of skill comes to light. Now not only have you lost your paycheck, but you have also demonstrated that you’re wholly untrustworthy and left a sour taste in your employers’ mouth. This then begins to cascade: You may be asked about it in interviews, they might do some background checking, someone might make an idle comment on a blog or in a discussion at a local professional group and suddenly you’re working at McDonald’s just to make ends meet.

In contrast, honesty about your skills will properly frame your employers’ expectations, and give them a good sense of how to compare you against other candidates. You will definitely lose some opportunities, but now these opportunities will either have been outside your skill set (with all the issues listed above), or for a boss who’s expectations aren’t in line with the project scope (whom you probably didn’t want to work for anyway).

Rule #2: Credit where credit is due.

If you write code, you deserve credit for it. If someone else wrote it, they deserve credit for it. This is not rocket science, and falls neatly under the Golden Rule. Even so, it is very easy to take full credit for a particular body of work, especially if you were the sole developer on the project.

This is perhaps the hardest rule to give proper shape to, because while we all appreciate the work of developers whose libraries make our jobs easier, it’s difficult to figure out exactly when to show that appreciation. Do I send an email thanking that developer? Do I put his name in the documentation? Do I blog about it?

I personally err on the side of being reciprocal. Whenever I take or receive credit for something, I make sure to note everyone who’s made a substantial contribution. This doesn’t always work- for instance I can’t go into too much detail on my recent work on HP Print Studio, both because of client agreements and internal policy (As much as I’d like to), and you might have similar restrictions.

Rule #3: Own up to your mistakes.

Risk is an everpresent part of projects. The risk of not meeting the launch date, the risk of hiring the right skill set, the risk of a client that won’t pay their bills or the risk of your project manager being suddenly hit by a bus. Many of these are not under our control, and yet even for those there are ways of mitigating the damage, usually involving project contingency time and exit clauses.

From a developer’s perspective, the three risk factors are (broadly speaking) the risk of not having the right resources on the project, the risk of improper time estimates, and the risk of development mistakes (frequently referred to as bugs). The first of these is largely an issue of staffing, so doesn’t affect us directly. The other two however are factors of our skill as developers, and can frequently be subject to errors of judgement.

The second to last thing a project needs to deal with when the pressure is on is a long, extended blame game that wastes everyone’s time. The last thing a project needs is a lurking mistake that’ll blow up in everyone’s faces just because someone didn’t have the guts to raise a red flag.

If you screw up, admit it. That way everyone is up to date, can plan for the extra time, and though you might lose some face (though you’ll gain some points for being honest) in the long run it is far preferable to the alternative.

Rule #4: Ask for help.

One of the hardest things for a technologist is to admit that we don’t know how to to do something. We’re asked to complete projects of staggering complexity, and after a while adopt a sense of infallibility that lends itself towards making extravagant promises. This pride cometh before the fall, as sooner or later we make extravagant promises in spite of having no clue of how to implement a request, and a single broken promise can derail an entire project.

We are usually the first to know whether our promises have landed us in hot water, and the hardest thing to do once this realization hits is to ask someone else for help. I for one am far more likely to pull ridiculous hours than admit that someone else might be better qualified to solve a problem, and the resulting billing mayhem has to be dealt with by someone.

Here’s a secret: People like to feel important, and asking someone else for help is doing exactly that. What for you is a pretty tight situation is to them a casual request that makes them feel good about themselves, and that goodwill may even get you some pro-bono help. It could be that they have that one remaining piece of information you need to get the job done, or maybe they can point you at the shape of the solution so that you can fill in the blanks. Alternatively if they don’t have an answer, they might know someone who does.

One cautionary note: There is a fine difference between asking someone for help and relying on them.

Rule #5: Respect your team

Lets face it, we’re an independent bunch, especially those of us who are freelancers. The teams we work on don’t usually include a full complement of project contributors, and it’s often that we have to take on the duties of other Developers, Information Architects, Designers, Testing and in some cases even Account and Project Managers. Yet even when we’re burning the candle at both ends and the other team members aren’t available, we have to remember that we do not work in a vacuum, and there are others whom we can rely on.

Everyone has their part, and each specialization is there to support and complement the goals of the project. While it might be tempting to assume that you can take on the duties of a Designer, chances are he has experience, nuanced training and a method of thought that you simply cannot compete with.

Lets take the case of Design vs. Development as a case study, because for flash developers like myself this is one of the blurriest lines. Here, a designer has set a vision for a particular project, and you are asked to implement it. In the course of development it turns out that there are several pages/screens that have not been accommodated for, but you can easily extrapolate something from the existing comps and maybe add a bit of personal flair. If you do so without the designer’s input, you are bypassing him altogether and effectively telling him you can do his job. If instead you inform him of the oversight and ask him whether you should do that, you’re deferring authority to him and acknowledging his place and responsibility on the team. In short you’ve just turned a potentially volatile situation into a team bonding experience.

That about sums it up. I’ll probably keep this list updated as I encounter more things, but these five should get you off on good footing. Remember, your reputation is as valuable as your paycheck, because in the long run that’s what will define where, what, and how you work.