Monthly Archives: July 2012

Advice From A JUG Leader II – Debate Breakdown

Posted on by
12

It’s been a week since I posted “Advice From A JUG Leader – Learn a Different Language” and it seems to have ruffled at least a few feathers in the Java community.  As the article has been re-posted and bounced around on Twitter, I have had some opportunity to interact with some members of the Java community who have strong feelings about the content.  None have called for my death, and the debate has been almost entirely polite thus far.

I think and sincerely hope that the Java community understands that the impetus for writing this article was an observation that many in the Java community are simply not aware of the trends in the industry, and by the time those trends become standards it is too late.  These are the people that, if the train does come, never heard it approaching.  My purpose is not to predict or encourage the demise of Java, as that should not and will not happen.  The Java community is deeply loyal to Java, perhaps even to a fault, and I hope these articles serve as a wake-up call that the most important loyalty should be to your career as a software professional and to neither an employer or language.

I have noticed from these mini-debates is that defenders of Java, at least in my interactions so far, seem to primarily be highly experienced developers that perhaps have the most invested in Java.  As I mentioned in my original article, I don’t expect known Java experts to feel any changes.  At least a few of the comments seem to come off as rants against youth (“go play your Xbox“?) and start-up culture and not a defense of the language’s health itself.  I haven’t seen the younger generation of Java pros, but I know they are out there.  I don’t seem to see Java enthusiasts attacking faults in the alternative languages or praising Java for a superior feature set.

Some comments seem to admit that Java has some shortcomings just like other languages, but it’s what we have for now.  That is good enough for some people – particularly those that have been in Java for a long time – but not good enough for many developers who want to work with the best available.    The arguments so far have been, in no particular order:

Argument #1 – Don’t Use Alternative Languages Because The Languages are Unproven, and/or Only Start-ups Use Alternative Languages

“And, don’t forget, 70% of startups will fail within the first ten years. So, I’m not inclined to base my decisions on the faulty and unproven ability of start-ups to make sound business decisions for themselves.” – Comment from TSS reader, click for full context

Some of the languages are more proven than others obviously, but we can’t ignore the fairly regular news regarding established firms transitioning to alternative languages and platforms or taking a polyglot approach. I would hardly call companies like Twitter, YouTube, foursquare, LinkedIn and Google immature start-ups at this point.  If you are going to argue that there are plenty of other shops that use Java, we all know that.  The point is some start-ups (those most apt to use these alternative languages) have made bad decisions (as have large firms), but to call the languages themselves ‘unproven’ at this point would not be accurate.  No guilt by association here.

Businesses don’t make decisions, people do.  I don’t think we should fall into the trap of lumping together the decisions made inside of some start-ups as any proof of language relevance at this point.  When a host of start-ups fail due to their language choice alone, that conversation can be had.

If you were around back in the late nineties there were a lot of technology start-ups with funny sounding dot-com names.  Many of these companies were using a three or four year-old programming language called Java.  They could not have predicted that Java would grow to be as popular as it is today.

Note:  Python is older and Ruby is about the same age as Java, Scala has been around for 9 years, Clojure for 5 years.

Argument #2 – If You’re Bored With Java, That Is No Reason To Branch Out

“Becoming “bored or frustrated with Java” is a pretty poor excuse for branching out. As a professional, I’m not paid to feel entertained and broadened in my horizons. I’m paid to get things done as efficiently and as well as I possibly can… Go home and play your Xbox to relieve boredom. Don’t make your employer pay for yet another language learning curve so that you feel less bored and frustrated.” – Comment from TSS reader, click for full context

Simply being bored with Java could be enough for someone to look for other alternatives.  I think the bigger issue is that technologists who pay attention to developments in other languages are envious of the features that other languages provide.  Today, I feel that a smaller percentage of the Java community explore alternative languages based either on less curiosity or less opportunity.  As the Java community at large is exposed to these other languages more and more, I would expect you will see many more defectors.  The early adopters of Java were the most curious C++ or C developers who were looking for something different and stumbled on Java, and the most curious of Java pros stumbled on these other languages over the past few years.

Argument #3 – The Assumption That Most or All Of These Alternative Languages Will Be Dead In 5-10 Years

“If I’m off learning optional languages, I’m falling short of what I get paid to do. What’s more, I may have decided to do some development in one of the latest and greatest languages that, in a few years, will fall by the wayside, and now I’ve left my employer with a bunch of projects that will have to be re-written into a language that is currently active and supported.” – Comment from TSS reader, click for full context

Many of the early adopters of Java, as I mentioned in my article, have already been exploring some of these alternative languages for some time now.  Often they were not initially paid to do so.  Could some of these languages be dead in 5-10 years?  Sure.  Most of the languages I’m thinking of when I talk about alternative languages are already 5 years old, and some much older.  Even the young Ruby/Rails combo has been around for over 5 years.

Did people make the same assumption about Java back in the late nineties?

Argument #4 – Look At The Evidence That These Alternative Languages Are Not Being Adopted/Used/Sought After

Some defenders of Java have been pointing me to various statistics as proof that these alternative languages are not being used, not being sought after by employers, or not being adopted.  I would cede that none of the current crop are even close to Java in terms of popularity today.  I was sent to this link from Networkworld.com that says Java developers are the “most difficult tech pros to land, followed by mobile developers“.  I wonder where the demand for mobile developers was three years ago?  Would mobile development be a valuable skill to learn at this point?

As a recruiter, I’m also having a bit of a harder time finding Java developers now.  One of the main reasons for that is pretty simple – a lot of the people that I know that used to do Java work aren’t interested in doing Java work any more.  Over the years I’ve met a fair amount of experienced Java developers that were dying to get a job doing mobile work, Ruby work, Scala work, etc., but I’m not finding too many Ruby or Scala programmers with five years out of school looking for their first Java job.  Maybe it’s just me, but I don’t see that…ever.

Another link was given to the Tiobe Index, which is pretty widely used to highlight trends of language popularity.  It is based on search engine hits.  All indexes like this have some obvious flaws.  If you read Tiobe’s Definition, the phrase “Java programming is dead” will actually improve Java’s position in the rankings. So absorb these ratings with that in mind.  They measure chatter, which could be positive or negative.

Tiobe Index July 12

Tiobe Programming Community Index for July 2012

Well, the takeaway from this graphic, for me anyway, would be that Java dropped significantly and Objective-C seems to be gaining popularity dramatically.  But this could be some anomaly in a given month.

Tiobe Long Term Trend

Tiobe PCI 10 Year Trend

“Java has slid only recently and barely while the much touted JVM languages aren’t even on the radar” – Comment from Dzone.com reader, click for full context

The green line that is Java seems to be trending downward on a fairly regular basis since ’02.  I’m not sure I’d refer to a 10 year decline as ‘recent’ in the technology industry.  Again, I don’t think the Tiobe index is the ultimate indicator, but I wouldn’t point someone to this statistic to support an argument that Java is healthy.

Objective-C wasn’t listed in 1997, was ranked #46 in 2007, and now stands at #3 on the index.  If you had picked up Objective-C a few years ago, say in ’07 when it was not entirely popular, you would probably be doing well today as the demand for iOS work is quite high and the supply of developers is quite low.  In ’97, Java was #5 – one spot behind VB and two spots behind COBOL.

Conclusion

The arguments against learning a new language or using a new language in production were probably the same back in the late nineties when Java was still new.  People surely came to the defense of C and C++ saying that we didn’t need a new language then.  It’s progress and subsequent resistance to change, and in the technology industry change can sneak up on you pretty quickly if you aren’t paying attention.

I feel that many in the Java community may not be paying close attention. 

If you were a C++ programmer messing around with applets back in ’96, you’ve already been through this transition once.  What I’m hearing now from experienced folks is that these alternative languages are for start-ups, “Trix are for kids!“.  I know quite a few gray haired former Java developers that are getting paid to write code in other languages now, and I think they would tell you that the alternative language market isn’t just for kids.  Were you using Java in a start-up back in the day – were you one of the kids?

My purpose in writing these posts is to make a certain element of the Java community aware of what is out there, and that in my opinion now is an opportune time based on external market forces to explore other languages.  This is not an attack on Java as a language or on the people that choose to write in Java.  I’ve dedicated much of the past 12 years to the Java community and I don’t intend to change that now.  I expect that I will be involved with Java professionals for several years, helping them to find jobs and scheduling great events for my JUG.  I chose to change the focus of my business beyond Java, and my suggestion to Java professionals would be to at least consider and research doing the same.

About these ads

Advice From A JUG Leader – Learn A Different Language

Posted on by
15

The cry of “Java is Dead” has been heard for many years now, yet Java still continues to be among the most used languages/ecosystems.  I am not here to declare that Java is dead (it isn’t and won’t be anytime soon). My opinion, if you haven’t already heard:

Java developers, it’s time to learn something else

First, a little background as basis for my opinions:
I founded the Philadelphia Area Java Users’ Group in March 2000, and for the past 12 years I have served as ‘JUGmaster’. Professionally, I have been a technology recruiter focused on (you guessed it) helping Philadelphia area software companies to hire Java talent since early 1999. I started a new recruiting firm in January that is not focused on Java, and I’m taking searches for mostly Java, Python, Ruby, Scala, Clojure, and mobile talent. This was a natural progression for me, as a portion of my candidate network had already transitioned to other technologies.

I launched Philly JUG based on a recommendation from a candidate, who learned that the old group was dormant. Philly JUG grew from 30 to over 1300 members and we have been recognized twice by Sun as a Top JUG worldwide. This JUG is non-commercial (no product demos, no sales or recruiting activity directed to the group), entirely sponsor-funded, and I have had great success in attracting top Java minds to present for us.

The early signs

After several years of 100% Java-specific presentations at our meetings, I started to notice that an element of the membership requested topics that were not specifically Java EE or SE. I served as the sole judge of what content was appropriate (with requested input from some members), and I allowed the group to stray a bit from our standard fare. First was Practical JRuby back in ’06, but since that was ‘still Java’ there was no controversy. Groovy and Grails in ’08 wasn’t going to raise any eyebrows either. Then in ’09, we had consecutive non-Java meetings – Scala for Jarheads followed by Clojure and the Robot Apocalypse (exact dates for said apocalypse have been redacted). Obviously there is commonality with the JVM, but it was becoming readily apparent that some members of the group were less interested in simply hearing about JSP, EJB, Java ME or whatever the Java vendor universe might be promoting at the time.

I noticed that the members that sought these other topics and attended these alternative meetings were my unofficial advisory committee over the years – the members I called first to ask opinions about topics. These people were the thought leadership of the group. Many of them were early adopters of Java as well.

It was apparent that many of the better Java engineers I knew were choosing to broaden their horizons with new languages, which prompted me to write “Become a Better Java Programmer – Learn Something Else“. That ’09 article served to demonstrate that by learning another language, you should become a better overall engineer and your Java skills should improve just based on some new approaches. Today I go a step farther in my advice for the Java community, and simply say ‘Learn Something Else‘.

To be clear, the reason I make this suggestion is not because I feel Java as a language is going to die off, or that all companies will stop using Java in the near future. Java will obviously be around for many years to come, and the JVM itself will certainly continue to be a valued resource for developers. The reason I advise you to learn something else is that I strongly believe that the marketability of developers that only code in Java will diminish noticeably in the next few years, and the relevance and adoption of Java in new projects will decline. Known Java experts who are at the top few percent probably won’t see decreased demand, but the vast majority of the Java talent pool undoubtedly will.

The writing on the wall

I think at this point the writing on the wall is getting a bit too obvious to ignore, and you have two forces acting concurrently. First, there is a tangible groundswell of support for other languages. A month doesn’t seem to go by that we don’t hear about a new language being released, or read that a company transitioned from Java to another option. Much of this innovation is by former Java enthusiasts, who are often taking the best elements of Java and adding features that were often desired by the Java community but couldn’t get through the process for inclusion.  Java has been lauded for its stability, and the price Java pays for that stability is slowed innovation.

The second contributing factor is that Java has simply lost much of its luster and magic over the past few years. The Sun acquisition was a major factor, as Oracle is viewed as entirely profit-driven, ‘big corporate’, and less focused on community-building than Sun was with Java. The Java community, in turn, is naturally less interested in helping to improve Java under Oracle.  Giving away code or time to Oracle is like ‘working for the man‘ to the Java community.   Oracle deciding to run JavaOne alongside Oracle OpenWorld may have been an omen. Failures such as JavaFX and the inability to keep up with feature demand have not helped either.

My suggestion to learn something else is also rooted in simple economic principles.  I have seen the demand for engineers with certain skills (Ruby, and dare I say JavaScript are good examples) increasing quickly and dramatically, and the low supply of talent in these markets makes it an opportune time to make a move.  It reminds me of the late 90′s when you could earn six-figures if you could spell J-A-V-A.  Some companies are now even willing to teach good Java pros a new language on the job – what is better than getting paid to learn?  The gap in supply and demand for Java was severe years ago, but it seems the supply has caught up recently.  Java development also seems to be a skill that, in my experience, is shipped offshore a bit more than some other languages.

Still don’t see it?  Remember those early Java adopters, the thought leaders I mentioned?  Many of them are still around Java, but they aren’t writing Java code anymore.  They have come to appreciate the features of some of these other offerings, and are either bored or frustrated with Java.  As this set of converts continue to use and evangelize alternative languages in production, they will influence more junior developers who I expect will follow their lead.  The flow of Java developers to other languages will continue to grow, and there is still time to take advantage of the supply shortage in alternative language markets.

Java will never die.  However, the relevance and influence of Java tomorrow is certainly questionable, the marketability of ‘pure’ Java developers will decline, and the market for talent in alternative languages is too strong for proactive career-minded talent to ignore.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.

Stop Crapping on Startups

Posted on by
9

Michael O. Church recently wrote a thought provoking blog post, “Don’t Waste Your Time in Crappy Startup Jobs“, and the author clearly put a lot of thought into writing the piece.  Based on the comments and the retweets, it appears the article hit home for quite a few people.  I think the article’s title might sway a reader’s interpretation a bit, or readers may simply see it as ‘Don’t Waste Your Time in a Startup’.  I’m sure that wasn’t the intent of the article, but based on some of the comments, that sentiment seems to be the takeaway for many.

The crux of the article is a list of seven misconceptions that the author chooses to dispel one by one.  I’d like to take each of them and see if these are truly problems with start-ups, problems with the engineering industry, or even problems with expectations.  (Mr. Church’s excerpts are in red, my comments follow)

1. A startup will make you rich. True, for founders, whose equity shares are measured in points. Not true for most employees, who are offered dimes or pennies.”

First, I don’t think most engineers that join startups are expecting to get rich these days, and even founders aren’t all expecting to get rich.  If you had written this in 1999, I’d agree this is a common misconception.  Most employees in my experience see stock options or equity grants as ‘lottery tickets’, that they realize probably won’t pay off – but they also understand that you simply can’t win if you don’t play.

“Moreover, raises and bonuses are very uncommon in startups. It’s typical for high performers to be making the same salary after 3 years as they earned when they started. (What happens to low performers, and to high performers who fail politically? They get fired, often with no warning or severance.) “

I don’t see bonuses or raises as uncommon in the start-ups I’ve worked with.  My current client list includes a handful of startups that all offer bonus, and historically I’ve seen employees getting raises and bonuses from startups that are on par with some of my larger clients.  And low performers being fired without warning or severance?  Is that a startup problem specifically?  Low performers or people who ‘fail politically’ are fired in any sized company, the only difference may be severance.  Again, this is not a ‘crappy startup problem’.

2. The “actual” valuation is several times the official one. “In truth, startup employees should value equity and options at about one-fourth the valuation that VCs will give it. If they’re giving up $25,000 per year in salary, they should only do so in exchange for $100,000 per year (at current valuation) in equity.”

I usually advise candidates that they may want to weigh any equity simply as a chance to receive some additional compensation, and I’d generally advise them not to accept any offer that won’t afford them to live a lifestyle that makes them comfortable.  If you can’t afford a 25K pay cut, don’t take one.

3. If you join a startup early, you’re a shoe-in for executive positions. 

Again, I just don’t think engineers are this naive today to believe this, or at least not the people I know.

“Not so. In fact, one of the best ways not to get a leadership position in a startup is to be there early.”

I’d love to see if any actual scientific evidence exists to back this claim up, but I wouldn’t know where to find it.  For every engineer you can name that did not get a leadership spot, I’m sure someone else can name one that did.  Again, in my experience I generally see that engineers who join early on are rewarded with leadership roles that they are qualified to do.  Being the first or second engineering hire at a startup doesn’t automatically give you the qualifications to be CTO, and if you expect you should be CTO/VP just because you were an early hire you probably need to rethink why you are joining the company.

“Startups often involve, for engineers, very long hours, rapidly changing requirements, and tight deadlines, which means the quality of the code they write is generally very poor in comparison to what they’d be able to produce in saner conditions. It’s not that they’re bad at their jobs, but that it’s almost impossible to produce quality software under those kinds of deadlines.”

True on hours, deadlines, requirements, and perhaps the code could be better in ideal conditions.  I hear anecdotes all the time from engineers at large companies telling me how much free time they have with their highly reasonable deadlines and fully developed requirements being written in stone.  Wait…no I don’t!  Again, not a ‘crappy startup problem’ – it’s the nature of the software game overall, just a bit amplified.

“It may have been a heroic effort to build such a powerful system in so little time, but from an outside perspective, it becomes an embarrassment. It doesn’t make the case for a high-level position.”

From an outside perspective, companies that may hire these engineers down the road will most likely respect the experience those engineers had in building the product under less than ideal conditions.  Most hiring managers from outside firms won’t know whether the product was some epic flop anyway.

“Once the company is rich and the social-climbing mentality (of always wanting “better” people) sets in, the programmers will be replaced with more experienced engineers brought in to ‘scale our infrastructure’… The old engineers probably won’t be fired, but they’ll be sidelined, and more and more people will be hired above them.”

Well that was depressing.  I’d say, more likely, once the product is built and the company can hire more engineers, the developers that were there in the beginning now have accomplished their goal and will make the choice to move on.  The mentality of this type of engineer is to build something, but they may not want to maintain it.  Once that excitement is gone for this type of engineer, they will go voluntarily.

“Frankly put, being a J.A.P. (“Just A Programmer”) in a startup is usually a shitty deal. Unless the company makes unusual cultural efforts to respect engineering talent (as Google and Facebook have) it will devolve into the sort of place where people doing hard things (i.e. software engineers) get the blame and the people who are good at marketing themselves advance.”

Is J.A.P. a great deal at other companies?  There are plenty of established companies that don’t pay engineers great salaries, and work them long hours.  I think the key point is the cultural efforts to respect engineering talent.  My clients tend to love and respect their engineers, which is why I disagree with many of these stereotypes.

4. In startups, there’s no boss. This one’s patently absurd, but often repeated. Those who champion startups often say that one who goes and “works for a company” ends up slaving away for “a boss” or “working for The Man”, whereas startups are a path to autonomy and financial freedom.”

No boss?  I must admit, in my 15 years of tech recruiting I’ve never heard this one before.  Who are these people that you are talking to?  I’d say startups are a potential path to financial freedom, whereas working for an established company (with no ‘lottery tickets’) is probably not going to get you to early retirement.

“People who really don’t want to have “a boss” should not be looking into VC-funded startups. There are great, ethical venture capitalists who wouldn’t go within a million miles of the extortive shenanigans I’ve described above. It’s probably true that most are. Even still, the power relationship between a founder and investor is far more lopsided than that between a typical employee and manager. No manager can legally disrupt an employee’s career outside of one firm; but venture capitalists can (and sometimes do) block people from being fundable.”

How did we get from having ‘no boss’ to extortion by VC’s and managers?  A manager disrupting an employee’s career outside of one firm???  WTF?  Lemme guess...the author had a very bad experience?

5. Engineers at startups will be “changing the world”. With some exceptions, startups are generally not vehicles for world-changing visions. Startups need to think about earning revenue within the existing world, not ‘changing humanity as we know it’.”

This might work on a small subset of 22 year old kids, but I think most people know they aren’t going to change the world.

“…but people should understand that their chances of individually effecting global change, even at a startup, are very small.”

The likelihood of ANYONE effecting global change is incredibly small at a startup, and probably just as small at a large company.  Again, this isn’t a ‘crappy startup problem’.

6. If you work at a startup, you can be a founder next time around. 

Why not?  No, seriously – why not?  Working at a startup doesn’t exclude you from being a founder next time, does it?

“What I’ve said so far is that it’s usually a sh*tty deal to be an employee at a startup: you’re taking high risk and low compensation for a job that (probably) won’t make you rich, lead to an executive position, bring great autonomy, or change the world.”

If you assume there is high risk and low compensation for every startup job, I’d agree.  Jobs with established companies don’t always pay well, rarely make you rich or lead to an exec position, and almost never allow you to change the world.  If that is how you define a crappy job, all jobs are crappy.

7. You’ll learn more in a startup. This last one can be true; I disagree with the contention that it’s always true. Companies tend to regress to the mean as they get bigger, so the outliers on both sides are startups. And there are things that can be learned in the best small companies when they are small that can’t be learned anywhere else. In other words, there are learning opportunities that are very hard to come by outside of a startup.”

So you won’t necessarily learn more in a startup, but there are unique opportunities to learning in a startup.  This sounds like a feature, not a bug.  Are there unique opportunities in larger companies to learn things that you can’t learn anywhere but in the larger company?  Perhaps.

“Startups are generally too busy fighting fires, marketing themselves, and expanding to have time to worry about whether their employees are learning.”

Fighting fires is a great metaphor here.  Do you know the best practice for fighting fires?  It’s actually fighting fires.  Of course, there is danger in that, but engineers learn much more by being in those environments than they do in a completely comfortable setting.  It’s not about a company that can afford (both time and money) to send you to a training seminar, it’s about learning on the startup job how to build something under tough conditions.

CONCLUSION

In conclusion, the problem with Mr. Church’s article isn’t that startup jobs are crappy.  It’s that the author feels that many people may have certain unrealistic expectations about startup jobs.  It assumes that all startups work you to death and pay you nothing, and that simply isn’t the case.  It’s a stereotypical assumption, and it’s dangerous one.

If you take any job and expect that you will absolutely:

1 – get rich
2 – become an executive
3 – have no boss
4 – change the world
5 – found a company within x years
6 – learn more than everyone else

then I can assure you that you will be VERY disappointed, no matter the size or age of your new employer.  I sense that people have more realistic expectations than Mr. Church gives them credit for, and the people I know in 2012 certainly do.  A more appropriate title for his article would have been ‘Don’t Join a Startup with 1998 Expectations’.

If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful.  You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.

Geek Independents

Posted on by
4

The decision to become an independent consultant in the software world is not something to be taken lightly.  Although the work you will be doing on the job is probably very similar if not identical to what you have done as an employee, you really need to conduct an honest and thorough self-examination to determine if you are cut out for the demands of running a successful consulting business.

After years of working with many independent consultants to help them find gigs, and in many cases serving as counsel for engineers considering the transition from employee to independent, I have compiled a list of traits that are necessary in order to thrive in today’s marketplace.  Conveniently for me, the necessary traits are often associated with body parts (which helps with extended metaphors, bad puns, etc.) – so I give you “What it Takes to Be an Independent Consultant From Head to Toe (but not necessarily in that order)”.

The Stomach – Obviously it takes some guts to leave a steady job and take the plunge into independent work. You need to have confidence that your skills will be in demand by clients, and that you will be able to reach your target audience (hiring managers) either through your own network or via agents/recruiters that you can trust. It also helps to understand that sometimes independents will be ‘between gigs’ – many indies appreciate the ability to take a week or two off before starting a new assignment, but if not carefully choreographed the beauty of an independent’s flexibility can become an undesirable period of unemployment. Being able to digest some weeks without a paycheck is a necessity, even if it never actually happens to you.

The Teeth – Chances are you’ll be asked to cut your teeth on some new technology on every gig. Never expect to be using the same set of languages, tools, databases, operating systems, etc. on every project. The ability to learn new technologies quickly and ‘on the fly’ is essential to your success as an independent. Ask the client what tools you should brush up on a couple weeks before the project starts, and do a little research to hit the ground stumbling if not running.  Invest additional time to keep up with trends and learn new tricks that may be valuable on future gigs.

The Head - We’ll assume you have the head for technology – if not, please stop reading this now and get back to your work! In addition to knowing your way around code, you’ve got to at last have some mind for business. Most tend to leave the tax and legal stuff for the professionals (a decent accountant and lawyer will save you time – good ones might save you jail time!). You also need to have at least some idea of the numbers behind independent work. What do I need as an hourly rate to maintain or improve my lifestyle? Did I factor in some costs that I may not have worried about as a salaried employee (insurance, mileage, parking, taxes)? How much time can I afford to take off without hurting my bottom line?

The Legs – Finding a great gig can take quite a bit of legwork, especially if you decide to go it alone and not use an agent. Even with an agent it can take some time and effort to secure a project, so be prepared to take the search for new assignments just as seriously as the job itself. Be organized in your search, reach out to past clients and touch base with an agent you know and trust. Finding a five year or even two year project is extremely rare, and many gigs are in the six month range.  Thankfully, your job search activities should only happen a couple/few times a year at most.

The Feet – Unless you can find telecommuting positions, independents may have to be more open to locations that may be less than ideal from a commuting perspective. It is always better in the long term to take the project 40 miles away that offers a new marketable skill over the Cobol gig next door. Openness to a bit longer ride will surely enhance your ability to stay utilized/paid.

The Heart – You are the sole representative of your company, so you need to make every interview and client interaction a positive experience even if you don’t get the gig. Walking out of/canceling interviews, leaving assignments without proper notice, or presenting yourself as negative or unfriendly can get you a reputation with both hiring managers and agents, and that will hurt your chances of securing future work. Don’t burn any bridges! Show some love to your clients and they’ll keep you coming back for more work.

The Nose – Getting stuck on a doomed project will happen to almost every independent during their career, but having a nose to smell out rotten gigs will save lots of headaches. Ask the right questions in interviews to learn as much as possible about the team, management, customers, and expectations for delivery.  Then decide if you have a chance to be successful.

The Elbows – Rubbing elbows with fellow software professionals and staying in touch with old contacts should keep you off the bench, and tools like Twitter and LinkedIn make it that much easier to keep connected. Foster relationships with other independents that could potentially find you work when necessary.  If you are active in some open source communities, developing personal relationships with other committers and contributors could lead to referrals.

The Ears and Mouth – The ability to listen to and understand your clients’ requirements is perhaps the most important skill required to be successful as an independent. At the rates you are being paid, there is little margin for error. Get a good req and ask the necessary questions to be sure you are clear as to what is expected and when it needs to be delivered.

The Face - Many successful independents have a reputation in the community as having deep expertise in one certain subject, or while others are regarded as great and well-rounded engineers.  How did they achieve that notoriety?  Independent consultants often choose to be very conscious of their ‘brand’ and to proactively take time to help build and maintain that identity.  Blogging, authoring books or articles, presenting at conferences and user groups, or simply being seen at certain industry events are ways to keep your face out there for potential customers to see.

Do you have the necessary traits to run a successful independent consulting business?

Note:  If this content sounds remotely familiar, I originally wrote parts of this article for a newsletter in 2008.  I made several edits and updates for this posting.