The LeBron James of Programmers

How should Hyper Performers be Judged and Compensated? (How to Make the Case for a Raise)

I'm often asked questions about compensation by both employers and candidates, such as:

• What is a fair salary for this position?
• Why can't I find a higher salary?
• Why can't I find and attract top talent?
• What skills pay the most?
• How can I get a raise?

For many years, I have wondered why a great programmer (one who is 10x as productive as a poor programmer) doesn't make 10x the income.

There are a number of factors, as described in The Myth of the Bell Curve, but that only explains part of the discrepancy. Even if we agreed that a programmer is 3x as productive, are we willing to pay 3x more? Should we be willing to pay 5x more once you take into account the fixed overhead, such as health insurance, and indirect savings through making others more efficient?

I find that the missing piece is a shared understanding of how to measure the minimum skills required for the job. Because I think the question that dictates programmer salaries is, "Who is the least qualified programmer I can get to do the job?" In another post, I'll try to cover how low-rate programmers cost companies more, but the focus of this post is the hyper performer.

How Much is LeBron James worth as a Programmer?

The average NBA player's salary is about $5,000,000.

The lowest-paid NBA players, like poor Mario West, make about $25,000.

Kobe Bryant makes about $30,000,000 but his salary is an outlier; the top 10 players average about $20,000,000.

LeBron James, widely considered the best player in the world, makes a little less than $20,000,000. He could make more, but he agreed to a lower salary in order to keep the Miami Heat under the salary cap while attracting top teammates. Not to worry, his endorsements raise his total haul to around $60,000,000 per year.

I've been using all the zeroes in the preceding numbers, instead of abbreviations such as $25K or $20M, so you could appreciate the orders-of-magnitude difference in compensation.

Please note:

• The highest-paid players make about 1000x the salary of the lowest-paid players.

• The top 10 players (top 1.7% of 565 players) each make about 4x the average player and 800x the lowest-paid players.

• Even the lowest-paid players are all incredible athletes who have made the NBA. They are undoubtedly better than the vast majority of college and undrafted players who are not in the NBA, and perhaps better than players in other leagues throughout the world.

How much am I worth as a Basketball Player?

 

Instead of trying to evaluate my worth as a basketball player, in the aggregate sense, let's narrow it down to some specific metrics by which a basketball player can be evaluated, such as free-throw shooting.

How much am I worth as a Free-Throw Shooter?

 

Let's suppose that LeBron James and I are having a free-throw shooting contest (foul shots).

His career free-throw percentage is about 75%. Let's assume mine is about 25% (I can dream).

So, is LeBron worth only 3x me as a free-throw shooter? Perhaps.

Now, let's change it to a game situation, in which LeBron James earns 7.6 free throw attempts per game, because if they don't foul him, he is going to score anyway.

If I was in the NBA, and I played as many minutes and took as many shots as LeBron, I'd average zero free throw attempts per game, because no one would ever both fouling me ("He's open for a reason.") Let's be generous and assume I make 1 free-throw per game.

So, as a free-throw shooter, LeBron is worth at least 7.6x as me.

How much am I worth as a Three-Point Shooter or Slam Dunker?

 

Now let's imagine I have to make some three-point shots (about 23 feet away from the basket). With no defender, I might make 1 shot in 10 from the three-point line.  LeBron makes about 36.5% of his three-point attempts in a game situation, which is only 80th in the league!

Maybe I'm worth more than I thought.

Now, instead, let's imagine we are in a slam dunk contest. Granted, this isn't required in a game, but let's pretend it is a job requirement.

How many times, out of 100 attempts, will LeBron successfully slam dunk the basketball? I'd guess about 95% of the time, even when doing trick dunks, judging from this video.

I have never dunked a basketball on a 10-foot rim without using a trampoline. I will never be able to dunk a basketball, even if I get my knee repaired.

So, if dunking a basketball is part of the job requirement, LeBron James isn't just 100x or 1,000x more valuable. He is infinitely more valuable, because I simply can't do the job.

How Much is LeBron James worth as a Programmer?

Now, let's imagine we're in my house. LeBron won't stand a chance.

Can LeBron:

• Write a Jenkins script?
• Configure SVN and train the team on best practices?
• Create a re-usable component?

I'm sure he is a smart guy who can do many things, but he presumably less of a programmer than Michael Jordan was a baseball player. (MJ made about $5/hour as a baseball player.)

How Much is a Great Programmer Worth?

 

So what are the factors that typically determine the low and high end of a programmer's salary?

The following are examples of things that cause downward pressure in your value as a programmer:

• Low level of skill required (basic HTML, or template work)
• Lots of repeat work required but not highly original (i.e., programming banner ads)
• High number of qualified applicants relative to job openings
• Easily outsourced or off-shored to lower wage markets
• Low-paying industry, because people think it is glamorous (fashion, sports, etc.)
• Low-paying because industry is not profitable (non-profits, dying businesses)
• Low-paying due to lack of capital (start-ups, mom & pop shops)
• Low paying due to poor stock market, IPO, or VC interest
• Cyclical or boom-bust downturn (2000 Tech crash, 2008 Recession)
• Dying technology with glut of existing programmers competing for declining number of roles.
• The geographical market pays little (college towns, etc.) due to low cost of living, etc.

The following are examples of things that cause upward pressure in your value as a programmer:

• High level of specialized skill required (quant, enterprise architecture, big data)
• Highly original or creative work (award-winning advertising or game design)
• Low number of qualified applicants relative to job openings
• Harder to outsource or off-shore due to time constraints, security restrictions, or high degree of communication required
• Historically high-paying industry (finance, etc.)
• High-paying because industry is highly profitable (pharma, energy)
• High-paying due to stock options (Facebook, Google, etc.)
• New technology with shortage of existing programmers (iOS, Objective C, HTML5)
• Booming market due to IPO and VC interest
• The geographical market pays more (such as NYC) but business and living expenses tend to be much higher.

 

Are you Worth 10x Other Programmers?

The definition of "what you are worth" in a financial transaction is, "How much is a willing employer offering to pay you?"

You are highly unlikely to command 10x the salary of a "good enough" programmer, almost regardless of your skill.

Here are some things you can point out to your employer to help make your case that you are worth 2x or 3x what they are paying other programmers, but you'll be lucky to be paid 25% more.

If you are 10x as productive as other programmers, you'll probably be paid no more than 2x their salary.

Bruce's Law:

For each 100% improvement in productivity over other programmers, you are paid only 10% more in salary. LeBron James earns 4x the average NBA player's salary, and you are not LeBron James.


May these Odds be Ever in Your Favor:

• You can perform some critical programming in time for a deadline that others can't meet
• You have a unique skill that other programmers simply don't have
• You can fix and debug things 10x faster due to your superior architecture skills, reusable components, and debugging skills
• You raise the level of all the developers, and make the team more productive
• You shorten time to market
• You shorten the QA cycle and let them hire fewer QA staff
• You wear multiple hats, so they don't have to hire other programmers to do those roles

All of the above pale in comparison to the one reason that give you the most leverage:

• You have another job offer and are willing to walk away

Conclusion

There's an old saying, "You don't get what you're worth, you get what you negotiate." I'll cover some of the non-salary points for negotiation in another post.

When negotiating, remember:

• If job satisfaction is important to you, don't make it all about the money
• Software development is a team sport. LeBron James didn't win any championships by himself
• Work to improve yourself every day
• Make your teammates better
• Learn what your employer values

Best of luck in all your career pursuits.

Be sure to comment, like, share, or follow this blog, and check out the other posts on the right-hand side.

Of Snowstorms and Software Development

Explaining Software Development in terms of Snow

This winter has been brutal in the US. Record snowfalls, the Polar Vortex, crazy ice storms. I love analogies, because I think they can help non-technical people understand technical concepts. So what can snowstorms teach us about software development? More importantly, how can we use these analogies to explain these issues to non-developers?

How To Shovel a Driveway

How many times has this happened in your software development career? You are given an incomplete specification, or no specification, and asked to just start programming something. Or, you are asked to start some inefficient process (say, deploying some software by hand) because it will be faster than doing it the "right" way. (I'll talk about "The Right Way" in a future blog post.)

Or you've been asked to work on a single feature for a single project, knowing that it is (or should be) identical to the same feature in another project. But the software teams are divided by project, not by feature. For example, in pharmaceutical software development, there is often a team dedicated to a particular (prescription!) drug, with redundant development being done across teams.

How can you explain to management what they need to know about software development, when they don't recognize the things you take for granted (code re-use, automation, etc.) as valid and relevant?

I like to use the snowy driveway analogy.

Suppose your manager says, "Please, shovel the driveway."

Here are the things you should ask in snow-terms (and business terms):

• Is it even snowing yet? (Is there anything to do yet?)
• Do I have a shovel? (Do I have the necessary tools?)
• When is the snow starting? (When does the first requirement come in?)
• How long will it be snowing? (How long will requirements continue to come in?)
• How much snow do we expect? (What is the scope?)
• What is the reliability of the weather report? (Do we have an accurate spec?)
• Do we have enough shovelers? (Who else do we need on the team?)
• Should we get a snowplow? (What equipment do we need to buy?)
• Should we hire a plowing company? (Should we hire a contractor or outsource it?)
• Am I physically capable of shoveling? (Do we have the talent and staff to do this?)

On it's face, this technique seems juvenile if not ludicrous. But stick with me.

You have to remember that salespeople, project managers, and non-technical managers don't speak geek. How can I be so sure? Because the only thing more ludicrous than my analogy is the requests you get as a software developer to "shovel the driveway" without knowing answers to any of the above questions. And you're being asked to do things that are counterproductive by people who don't understand how and why their requests are counterproductive.

And one of the major goals of this blog is to help get you outside of your geek braincase and help you understand how non-developers think and communicate. This is the key to your professional satisfaction, productivity, and career advancement.

How Not to Shovel a Driveway

Here are some typical requests, and how you might reply.

Manager: I know that everything isn't ready, but please start on the project with the information you have.

You: I can certainly start some basic prep work, but it probably won't save any time. It would be better for me to work on another project while we wait for the spec to be defined a bit further. I can work with the project manager on that.

Manager: We need to get started on this project so we don't fall behind, and because Mary (Mary is always evil) will have my head on a stick if we don't start on it this week.

You: Well, I'll do what I can to help move the project along, but I want you to understand that it won't save any time. It is as if you are asking me to start shoveling a driveway while it is still snowing. I can shovel the entire driveway, but since more snow is still falling, the driveway is still going to be covered again. I'll have put in work now, with very little to show for it. And, I'll still need to shovel the whole driveway again later.

Manager: That can't possibly be true. What is the easiest thing for you to implement in module XYZ?

You: Any design you reasonably come up with is going to take the same amount of time to implement. What takes extra time is if the design changes. The best thing for me to do is work with Mary to agree on the spec. There is no benefit to starting on something that is not defined and/or highly likely to change.

Manager: Mary is out this week, please just get started.

You: Okay, now that you understand the situation, I feel much better that we had this conversation and know that I'm on the task you want me to be on.

Free Advice: Don't remind your manager s/he is uninformed. S/he understood the decision is inefficient, at best, but doesn't want to admit it to you and has a different agenda. S/he will use the same analogy to Mary's face later, because you gave her/him a talking point that Mary can understand. Your career will advance much faster if you see yourself as the student when it comes to office politics, and not the teacher. If you don't take my free advice, take your manager's free advice. Programmers are used to highlighting the important points to each other, such as, "You need to use this compiler flag or it will fail." Non-developers just speak English and expect you to read between the lines, which you're probably not very good at.

Always, be sure to check yourself. Are you just being combative or lazy?

Is it true that your snowy driveway analogy holds?

If the snow is already deep, then maybe you could take a pass now and get ahead on some of the work. If you wait, maybe the snow would be so deep you have to shovel twice anyway. Or, you can take this time to do research, so you can ask intelligent questions later.

Don't take the snow analogy too far. You can affect the weather! Instead of complaining about the snow, work towards solutions. Don't use the analogies as an excuse to shut down conversation. Use them as a path towards a shared understanding.

The Nor'Easter

For those who don't know about Nor'Easters, they are swirling snowstorms shaped like the Milky Way.

The relevant characteristic of a Nor'Easter is that they contain heavy bands of intermittent snow, interspersed with lulls in which the storm appears to have passed.

Here is how to use this analogy in business:

Manager: Now that we are done with that major push, we have time to work on this huge backlog of work.

You: Sorry, but I think this project is like a Nor'Easter. I think we are in a temporary lull after a ferocious period, but the storm is still there, and we will be hit by periodic waves of snow every three weeks for the next quarter.

Of course, this analogy fails if the other person doesn't know how a Nor'Easter works, so you may need to explain, or use a different approach.

The sneaky part of the analogy is that you've subtly introduced the concept of a recurring storm, which your manager can understand without any knowledge of software development.

You've taken the focus off the geek-speak, and given them a mental image of something they can grasp onto.

How do you drive that home?

Consider naming each of your projects after some weather-related event, and add a photo (in this case of a Nor'Easter) to the project home page. Once your manager sees the photo, s/he'll understand intuitively.

Tech Debt

Tech Debt is one of the most important concepts in all of software development.

Here is how to explain it in terms of snow:

Tech debt is like when you don't shovel your driveway, but you drive the car over it. That snow seems to be "out of the way," and you don't need to deal with it any more, right?

Wrong! That snow will turn to ice, and someone will undoubtedly slip and fall on it. When/if you decide to deal with it, it is much harder to scrape off the ground because it has been compacted and re-frozen. It is 100X easier to deal with by shoveling before driving the car over the snow.

Now let me give you the software developer's definition of Tech Debt:

"If I don't refactor this module, then the code will be brittle, and we'll have to spend more time in QA, and the software won't be as robust or performant."

Which one do you think your manager is going to relate to?

So try this:

"I can take a shortcut today, but it is going to cost us dearly in the near future. Any perceived benefit is just an illusion. It is like driving over snow in your driveway instead of shoveling the snow first. The part you drive over is going to be hazardous and hard to deal with later. Please authorize me to head off this problem today, and it will pay itself back 10x within a week."

Forecasting and The Weather Report

How many times have you been asked to estimate a project without being given any details?

Manager: We need you to build an advertising site for this new cell phone our client is promoting.

You: Okay, do we have any details?

Manager: No, we just need to know how long it would take to do a micro-site.

You: Well, I can give you a better weather forecast if I know the city, the latitude/longitude, and the season. At this point, I don't even know the planet we're talking about.

Manager: Just assume it is like every other project we do.

You: Okay, I can give you the typical highs and lows. These sorts of projects usually take two weeks to spec and three weeks to develop. But, I don't know if there is going to be a freak snowstorm that dumps ice on the unsuspecting Southeast. When the storm hit Atlanta, a typical 45-minute drive took 7 hours.

Manager: You made your point, but I just want to know what is typical.

You: Okay, thanks. I just feel obligated to meet my promises and my deadlines. As long as you understand this is just a ballpark estimate that will need to be revisited when I have more specifics, I'm happy to do everything I can to help approximate the work. Is there someone I can work with to get more specifics?

Manager: Thanks, I'll let you know.

Conclusion

We've covered a lot of territory here.

Some take-aways

• Look for creative non-technical ways to relate technical concepts.

• Use visual images to relate concepts. Most people think visually.

• You've made your point, now keep your mouth shut. Non-programmers can only keep from strangling each other because their communication is built on a foundation of ambiguity that allows them to constantly save face or leave room for interpretation.

• People in glass igloos shouldn't throw snowballs. Recognize that communication is a two-way street. Stop chalking it up to your manager's failure to understand your brilliance and expertise.

• Make a snowman in the shape of your manager and watch him/her melt . Do not run it over with your car. It will only be harder to clean up later.

Happy Coding! Be sure to check out the other posts on the right-hand side. And like/share this article if you found it useful.

Top Ten Non-Technical Skills Software Developers Need

Why aren't I Rich Yet? (Part 1 of N)

 

Developers are often really good at logic, structures, software development, etc., and often not as good at other skills that are widely praised and highly valued by non-programmers.

This is the first of several posts on this topic in which I'll try to help programmers understand why their careers and compensation might not be advancing as fast as those of co-workers they consider not as smart, indispensable, or productive as they perceive themselves to be.

1. Reliability/Punctuality

Whoever said "90% of life is just showing up" perhaps underestimated. Programmers need to understand that they get more credit for showing up early than for staying late. If your business opens at 9:00 am, show up at 8:55. Don't stroll in at 9:45 just because the first meeting isn't until 10 am.

Programmers tend to be the last to arrive and the last to leave, and often work many hours at home, at night, and on weekends. Sorry, but you get almost no credit for those things in your boss's mind. To the contrary, they interpret it as you being lazy, undisciplined, and inefficient in the use of your time.

I'm not saying those things are true, but you have to recognize that as the perception.

Programmers are often seen as flaky if they are hot and cold. One week, they may kick ass, and then next week they may be largely AWOL or burnt out. This happens especially with contractors who have to juggle multiple clients. I'll leave an in-depth discussion of this issue for a future post. Suffice to say, employers don't care what else you have going on. They want you 100% available for their task. Within an organization, you'll see the same phenomenon. If two project managers want you working on their project, they tend to underestimate the time you have to spend on another project.

2. Written and Verbal Communication

Learn to speak at a level non-technical people can understand. Hint: Ask questions, and say things at a much less technical and detailed level than you'd like (that will be the subject of a future post).

You need to be able to tone down the geek-speak in order to communicate with others along their wavelength, emphasizing a) what they can understand; and b) what matters to them.

For example, saying “We need a RAID array” is not helpful. You need to say, “If we don't invest in a more reliable disk, our business will be adversely affected when it crashes.” Better yet, add, "Here are three quotes from reputable vendors for the hardware we need. I think we should go with Vendor A for $2,500 when we have the budget for it. I think this will be critical by May, so I'll remind you in April. If we don't deal with it by June, it will likely cost us $50K in lost productivity and downtime, so it is wise to invest in it now."

Learn to write intelligibly. I've worked with many programmers who can't spell, even when English is their first language. It is simply not acceptable to mix up “too” and “two,” especially when your email will be read by non-native speakers who don't understand English homophones and are easily thrown off track by typos.

For example, suppose I wrote, "Test the Reporting module too," but meant for the person to test the second Reporting module ("module two") thoroughly. It might lead the tester to test the Reporting module "too" (i.e.,  superficially, in addition to the other modules).

Or imagine that I am working with a tester on Module A and Module B, but I confuse them in an email. A native speaker will usually detect the error from context and request clarification. For several reasons, a non-native speaker will tend to just take the instructions at face value, and end up testing the wrong module.

There is also a huge need to learn to make a competent PowerPoint, which requires both verbal and sometimes graphic communication.

3. Understand Schedules and Time Estimates

Your job as a developer is not to program software. Your job is to help the business make a profit by publishing software in a timely manner. 'Tis better to deliver adequate software on time than to blow through deadlines like a case of Red Bull.

You are expected, as a programmer, to be able to estimate accurately how long something will take. Learning this skill is a long and sordid tale, which I'll take up in future blog posts. The first step is to admit you have a problem. If the software is late, stop looking around for others to blame, and realize you have the power to improve the time estimates and affect the schedule moving forward.

4. Understand Budgets and Cost Tradeoffs 

Understand bang-for-the-buck calculations and understand the business value attributable to any software decision you undertake. What is the cost of extra QA, of being late to market, of hiring the wrong developer for the wrong role?

Don't spend time writing something by hand that can be better obtained off the shelf for less (and faster). Don't be afraid to hire an expert in the short-term that will get the product to market faster and make the company money in the longer term.

And when architecting a solution, don't neglect the ongoing cost of supporting that product. For example, if you are generating huge amounts of video traffic that is costing the company $100K/month to serve, you may need to revisit your bandwidth calculations. Can you get by with lower-bandwidth video that will cost the company much less each month? If you don't understand your bandwidth, server, hosting, and hardware costs, then you should ask someone in the company who does.

5. Patience

Developers tend to be smart and impatient. Businesses tend to make decisions over months and years. Developers tend to want it done today. Are you working in a start-up or a large conglomerate? Is there a big IT dept and a formal process for server deployments? Align your expectations with the reality of the business.

6. Managing Stress, Sleep, and Tempers

It is not acceptable to be snippy with co-workers because you pulled an all-nighter. You are expected to manage your behavior even when you are sick and tired, and even if you are overdue for a smoke break. If you can't behave, then send a polite email calling in sick. If you can't manage the stress of the industry you are in--advertising has notoriously high stress and tight deadlines--then try a different industry.

Take care of yourself physically. You need to get adequate sleep, food, exercise, etc. You need to shower, shave, and dress appropriately. Showing up unshaven in T-shirts and torn jeans just doesn't cut it. Grow up. Get some sun. Wear a decent pair of slacks.

7. Talk to people Outside your Dept

Be sure to talk to people in customer support, marketing, sales, and business development. Understand their needs and frustrations. Establish a relationship so that everything isn't adversarial.

Reach out to other departments to find out how you can help advance the business's interests. Here is an easy line to use as your fallback: "What is the most important thing I can do as the developer to help you in meeting the company's goals?"

The answer will often be that they need demos, sales sheets, predictable schedules, etc.

It is your responsibility as a developer to help the business, not just program software. You can't do that if you don't understand the business. Ask to go to a trade show, sales call, sales meeting, etc. You'll learn a huge amount.

Bonus: It feels great to see people actually using and benefitting from your software.

8. Handle Feedback and Criticism

Be open to feedback, and don't take criticism personally. We all make mistakes. Own up to yours, and work to fix the issue.

The major challenge is when someone criticizes you for something that you think is unimportant or not your fault. For example, if someone says, "Your code has a bug," you'll probably agree and fix it happily. But if someone says, "We need you to spend more time with the product manager and then write the spec," your initial reaction is probably going to be, "That's his job, not mine, so screw that."

Try to hear it in a different way. Maybe your boss is really saying, "You have expertise that no one else has, and the project manager really isn't capable of writing specs without you." It is high praise that appears to be negative feedback or criticism that you didn't do the task earlier. If you treat it as punishment, it is a missed opportunity. If you are doing the other things on this list, it will help your boss see you as someone who can willingly handle new tasks and responsibilities. That's how you get a bigger raise.

When in doubt, treat it like you are a baseball pitcher. The umpire will call some balls and some strikes. You'll give up some hits and make some strikeouts. There will be some fielding errors by your teammates. No one else expects perfection of you. They do expect you to take feedback professionally and adjust accordingly.

9. Take Ownership without being Territorial

Don't wait for someone else to move the project along. You weren't hired to be a cog in a wheel. If you see something that needs attention, bring the necessary attention to it. For example, if you are supposed to fix one dialog box, and you notice all the dialog boxes have the same problem, consider fixing them all (or at least raise the issue at the next meeting).

And don't be territorial - nothing is so tiresome as a defensive and territorial programmer.

10. Think Beyond your Current Assignment or Own Project

Suppose you are being asked to optimize a software product, and you realize that another software product (outside your assignment) has the same issue. Bring it to someone's attention. Example, when using Product A, customers have complained that the popup blocker prevents the “Save File” dialog box from appearing. Chances are, the same thing occurs in Product B. In an ideal world, the code would be centralized and could be fixed for both products at once, but if not, bring it to the attention of the Product B team. Maybe they already fixed it, or maybe they can implement your fix in their product.

Conversely, when someone from an outside team brings something to your attention that might affect your project, be open to it. See items 8 and 9.

Conclusion

 

You are a smart person and a great programmer. If you are not getting ahead in your career, it is because you are being measured against other metrics where you are weaker.

These tend to be the softer, emotional-intelligence skills, such as collaboration, consensus building, active listening, etc.

It took you many years to master programming.

The sooner you start working on these other skills, the sooner you'll see the beneficial impact on your career path.

Good luck!

Be sure to like, share, comment, follow, etc. And check out the other fine blog posts on the right-hand-side of this page, such as: Top Ten Things you Should Learn from Your Job Search and  Twenty-three Evergreen Developer Skills that will Keep you Employed Forever...