Monday, October 30, 2000

Developer Career Tip #0021---Setting your hourly billing rate

Developer Career Tips #0021

Setting your hourly billing rate

In my September 21st Developer Career Tip entitled "Consulting---Getting Started" I discussed how to get started with Independent Contracting and Consulting work. Let's assume for the moment that you've found someone who wants to hire you--the next major step to take is to determine how much to charge them.

There are many schools of thought on what newcomers to the consulting business should charge their clients.

One theory (to which I do NOT subscribe) is to offer to do the job for a rate that reflects your relative inexperience. While I think it's important to be honest and "up front" with your prospective client about your consulting experience, I think it's a BAD idea to charge a "below market rate" to get your foot in the door. In my opinion, doing so sends a subtle message to your client that, just as your rates are below par, maybe your work is also. If you believe that your skills and services are worthy of selling, then you must also take the tact that they are worthy of being paid for at the market rate.

In some cases, you may not have the option of setting your own rate. In many of my consulting jobs, the client tells me what they are willing to pay for my services. Of course, I'm free to make a counter offer, or even to walk away, but a lot of the 'guess work' is taken away when the client states the rate up front. In actuality, most times I'll accept the rate---most times clients have a strong feel for the current market rate and are willing to pay it for experienced consultants and developers.

On the other hand, suppose the client asks you to name your rate? How then do you establish what to charge your client?

I've seen consultants do this in a number of ways.

One way is to join an association of computer consultants. One such association is the Independent Computer Consultants Association (ICCA).

Membership in an organization like the ICCA has many benefits, one of which is the ability to ask other members what rates they are charging in your area. You can then use this as the basis for your billing rate.

You can also find out what your competition is charging, and use that as the basis for your own billing rate. I know of a consultant whose husband (and billing manager) on a quarterly basis calls consulting firms in her area to find out what they are charging per hour for contract programming in Visual Basic or Access. This market research can help you establish your own billing rate.

Another way is to perform some mathematical calculations to determine your optimal billing rate. This method, in addition to helping you set your billing rate, also forces you to make some assumptions about the nature of your lifestyle and business as an Independent Contractor or Consultant. For instance, you'll need to answer questions such as: will you be working 40 hours per week, 50, 60 or more? Will you be taking time off for a vacation, if so, how many? Will you be contributing to a Simplified Employee Pension Plan? How much do you hope to 'clear' after taxes?

I'll be illustrating this method in next week's tip.

Monday, October 23, 2000

Developer Career Tip #0020---Before you take a course…

Developer Career Tips #0020

Before you take a course…

I discussed getting up to speed with a new programming language several months ago, and I thought I would follow up on that theme by relating to you the experience an associate of mine had a few weeks ago with a formal training class he took at a Microsoft Certified Technical Education Center (CTEC).

My associate, let's call him "Jim", is a Visual Basic expert, and he had spent some time learning Java on his own. He decided to spend a week in a Java fundamentals class being offered by a CTEC with whom he had taken several enjoyable Visual Basic classes. Jim had always been impressed by the instructors at this CTEC--historically, in addition to teaching the material, they were also senior developers and consultants who were able to bring their real-world experience to the classroom.

For the Java class however, Jim was a bit disappointed. Although the instructor was knowledgeable about the subject matter, he readily admitted that he had no professional Java development experience. This lack of real-world experience became apparent when many of Jim's questions about real-world issues of speed, style and deployment went unanswered. All in all, Jim came out of the class not knowing much more than when he went in. As a professional developer, Jim wanted to come out of the class with some professional tips and guidelines, and that's not what he received. Still, I think Jim got what he deserved.

I chided Jim for failing to heed the 4-step checklist I run through prior to taking any formal classes. For your reference, here it is:

1. Know your expectations. Jim took a Java fundamentals course and he probably should have been in an advanced course. Beginning level courses are more easily staffed by instructors lacking in real world experience.

2. Know your vendor. Jim took a Sun Java course at a Microsoft Certified Technical Education Center. Jim should have asked himself why a CTEC would be offering a Sun Java class to begin with--if he had done some checking, he would have found that the course he attended was the first Sun Java course the CTEC had ever given. Although this fact alone did not cause Jim's disappointment, it was a contributing factor.

3. Know your instructor. You have the right to know in advance who will be teaching the course, and what their background is. Prior to taking any course, call the vendor and ask for the credentials of the instructor. Ask how many times they taught the class. Ask what real-world experience the instructor possesses. If real-world experience is important to you, and the instructor has none, then you can either find another vendor or wait for a class with another instructor.

4. Know the curriculum. In addition to obtaining information about the instructor, ask for a detailed outline of the course. You should also ask if ALL of the material in the outline will be covered (some instructors 'drop' material). You can also ask to examine the course materials ahead of time, and perhaps even sit in on a session of the class for a few hours (if it's a multi-day class, choose a day other than the first day to get a better gauge of the class pace and activity)

Following my checklist is a great way to avoid surprises and to get the value for your training money that you deserve.

Monday, October 16, 2000

Developer Career Tip #0019---Communication skills--don't overlook them

Developer Career Tips #0019

Communication skills--don't overlook them

Success in the Computer field is not just a matter of having solid programming or analysis skills, but also requires good communication skills. Many hopeful programmers downplay the importance of communication skills, but I can assure you that even if you are not the world's greatest programmer, if you foster and hone your communication skills, both verbal and written, there's a good job waiting for you somewhere.

As an example, let me talk about ' Bob'. I was working for an organization that was just beginning to realize the importance of the end user in the Systems Development process (unfortunately, we had just developed several far-from-stellar applications where we had neglected that important piece of the puzzle), and we badly needed to turn our department's reputation around. What we really needed was someone who could sit down with a user, determine and gather their requirements, and do so in a non-threatening manner.

At the time, we had an opening for a programmer, and we had a large number of applicants. A group of us eventually interviewed Bob, and although his resume included work with C and Unix, it was obvious during the interview that Bob's strengths were not in those areas. However, something that came through very strongly in the interview was that Bob's communications skills. Whenever we asked Bob a question, his eyes were attentive and focused on the questioner--and he answered each and every question thoughtfully and completely. At times, Bob would repeat the question before answering--just to clarify that was he was answering was he had been asked. And he frequently sought the opportunity to pose questions of us. We had allocated about a half hour for Bob's interview and we wound up talking to him for over an hour.

A couple of days after the interview, we received a letter from Bob thanking us for the opportunity to interview with the company. Despite the fact that Bob had not taken any written notes during the interview, he amazed us by remembering minute details of the hour long interview (including everyone's name).

Our decision to hire Bob was not a unanimous one---other candidates possessed stronger programming skills, but in the end what got him the job was his ability to communicate better than the other candidates.

Bob's strengths and weaknesses became very obvious in the first few weeks of his employment. His C and Unix skills were weak---and he did become better in those areas. But something he never needed help with was evident the first time he sat down with an end user---he was able to speak with every member of our end user community as if the two of them had been great friends their entire lives.

Bob wound up doing very little programming---in actuality, he spent most of his time performing analysis, determining user requirements, and in end user training and presentations to management.

Shortly after we hired Bob, I asked him what was his secret. Were those great communication skills something he had been born with?

Bob's answer didn't surprise me. He told me that he realized very quickly in his career that if we going to make it in IT, he would need to concentrate on his communication skills. He told me he worked each and every day on his communication skills---making eye contact, listening, really listening, to people, concentrating on what others said, clarifying their statements or questions, and in thoughtful answers and replies. And he told me he practiced writing each day as well.

Four years later, those great communication skills were rewarded when Bob was promoted to Vice President of IT for our company. You need look no further than Bob for proof of the importance of good communication skills in your IT career.

Monday, October 9, 2000

Developer Career Tip #0018---Is it time to learn C#?

Developer Career Tips #0018

Is it time to learn C#?

For those of you not familiar with C#, Microsoft, in June, announced C# as the 'replacement' for J++ in the next version of its Visual Studio Suite, which will be released sometime in 2001.

Those of you who read my Careers tip last week in which I discussed Visual Basic and Java salaries may be wondering whether C# is a language that you should learn?

The answer is not a simple one, for a number of reasons.

First, C# has not officially been released yet, and won't be until the next version of Visual Studio is released sometime in 2001. You can download a beta version from the Microsoft Web Site if you wish

and there is some preliminary documentation available from Microsoft as well

Second, at this point, there aren't many jobs calling for a knowledge of C#. I maintain a web page devoted to C# at

and if you check out some of the links that maintain job sections, you'll see that there are few jobs asking for a knowledge of C# (not surprising, since the product has not been released yet).

Third, and perhaps most importantly, the importance of the C# language in the grand scheme of things to me is cloudy at best. For instance, is C# a replacement for J++, a replacement for C++, or a possible competitor to Java?

If you read Microsoft's announcement concerning C#, Microsoft plainly states that their intention is to bring Rapid Application Development to the C++ programming community. In light of the advice I give to my students to learn Visual Basic (for its ease of use and marketability) and then, if possible, Java, for its hardware portability, C# just doesn't fit into that picture.

On the other hand, many analysts believe that Microsoft is positioning C# as a competitor to Java---in which case the picture changes a bit. If C# somehow manages to cut into the Java market, then learning C# isn't a bad idea. And being the first person on the block to know a suddenly popular language is a great place to be.

However, I think it's way too early to make that investment of time and energy. Learning C# at this point will be difficult for most people. Your options to learn C# are pretty limited---use the Microsoft documentation to learn the language, or purchase one of the few books on C# available on the market. And if learning this way is not your cup of tea, other options are virtually non-existent--as best as I can tell there are no formal classes on C# being offered.

The bottom line is that you should wait and see what becomes of C#--if it looks like a winner at this time next year, there will still be plenty of time to get up to speed and to enter the potentially lucrative C# programming pool.

Monday, October 2, 2000

Developer Career Tip #0017---Visual Basic Programmer's Journal Salary Survey released…

Developer Career Tips #0017

Visual Basic Programmer's Journal Salary Survey released…

In my opinion, the best Visual Basic publication is the Visual Basic Programmer's Journal. I recommend it highly to my Visual Basic students as a source of great information on Visual Basic development. According to the latest figures released from Magazine Retailer, the Visual Basic Programmer's Journal has the highest paid circulation sales numbers, and is the largest paid magazine in the world devoted to Windows development. Because of this, I place a lot of trust in their bi-annual salary survey, the Fall version of which was recently released. You can view it yourself at:

According to the Fall Survey, Visual Basic developers earn an average base salary of $65,500 per year. Be careful when reader the survey yourself, as the survey factors in extra pay such as bonuses and profit sharing, raising that average to $75,500 in total compensation.

Some highlights of the survey:

Developers in San Francisco and New York earn much more than the average compensation--but bear in mind that the cost of living is much higher there.

Experience pays off. The average salary for developers with less than one year's experience is $43,140--for developer's with 6-8 year's experience is $74,539. That's quite a difference, but if you've been reading my tips, this shouldn't surprise you.

Microsoft Certifications are beginning to carry some weight---Microsoft Certified Professionals (MCP's) and Microsoft Certified Solutions Developers (MCSD's) made substantially more than those without a Certification. Definitely something to consider!

VB skills alone are fine and will pay well--but those developers who marry their VB skills with another hot technology such as Java or XML do much better. In fact, VB Developers who know XML earn about $10,000 more than the average Visual Basic developer.

Not surprisingly (to me anyway), at the top of the pay scale are Independent Consultants. Independent Consulting will be one of several recurring themes of my tips.

In case you're wondering how VB stacks up against Java, here is a link to a first-ever Java Salary Survey by the publishers of Visual Basic Programmer's Journal.

I think the results will bear out what I tell my students---learn Visual Basic, then turn your attention to Java as a second language (and based on the salary survey, it looks like you should add XML to that mix also).