I’m slowly working my way through the new site – changing providers and blogging software has proven both easier and more difficult than I had originally planned. Unfortunately I have also had things made more difficult by an extensive travel schedule for the past few weeks (and extending into next week).
I am hoping to get a chunk of time to address these issues during the next few days and get back to regular posts in a week or so.
Sorry!
… and hopefully most of the content is here somewhere. I’ll be updating it over the next week to get everything back in order. I’ll also be working on recreating my template one more time for Wordpress this time.
I’ll write more about my switch over tomorrow.
According to the IEEE, the number of software developers is decreasing worldwide. Why do I think this is a “good” thing? Because the US Bureau of Labor Statistics projects the demand for software developers to grow by over 30 percent, one of the fastest projected growth rates.
So with a shrinking labor pool and increased demand, the job prospects for software developers looks good (at least in the longer term). Hopefully that means that some of the younger generation coming up through school will see this and view the field as a viable career option, reversing the downward trend of enrollment in Computer Science (and Engineering). There is some evidence this may be occurring, as for the first time in almost 6 years, enrollment in Computer Science has increased.
I’m hoping this continues, since this influx of new talent and ideas is critical to continue advancing and shaping our field in the future.
Besides, I enjoy writing software, and I’d like to continue doing it for a while…
Imagine that you have a pressing need to hire a top-notch software developer. You contact all your friends and colleagues to put out the word. You call up a couple of recruiters and put an ad on a couple of websites. You canvas some relevant conferences.
Soon you have a pile of resumes. Depending on your company and how much advertising you’ve done, you might have thousands of resumes. So you sit down to run through them, rapidly discarding the vast majority until you find one with those magical three words, “Open Source Experience”. BAM. Search over, move on, right?
Looking around the web, it seems accepted that job seekers should participate in open-source projects because it will help them get a job. The theory is that by participating, you make a portfolio of your work available to any prospective employer, so they can verify your technical aptitude. It also seems to be the prevailing wisdom that only the “best of the best” participate in open-source projects (as it is supposed to be a meritocracy).
While I can’t speak to the general quality of open-source developers versus the average developer, I can speak to the value of an employer being able to look at your portfolio of work. While I am certainly not the first person to suggest this, it bears repeating so that people do not fall into the trap of placing too much value on it.
I will not review your work on an open source project.
Having source code available bears no relevance to the hiring process. Remember that I have thousands of resumes. Most of the time I won’t even read the entire RESUME, much less go look at the source control history of some open-source project on the web to determine what code is yours and evaluate it.
I am interested in your experience. Whether you gave the code away or not generally does not matter as much as whether the code you wrote is relevant to the position I am hiring for, and I should be able to determine that from your resume.
I might check to verify that you actually committed code to the stated project. I might even go so far as to see what parts you worked on. But that is no different than me calling up a former employer to verify that you worked there. By the time I do these things, I’m already interested in hiring you. I’ve probably already interviewed you and determined you are a good fit for the position.
If I want to see what kind of code you write, I’ll ask you to write some code as part of the interview, and if I ask you to write some code, you can bet I’ll ask the other candidates to solve the same problem. This way I can compare and contrast everyone’s strengths and weaknesses from a common starting point.
So, essentially, my advice on whether to contribute to open-source projects is this. If you want to contribute to open-source projects, please do so. The networking and development skills you gain will be invaluable in finding a job. The best way to become good at something is to practice, so learn how to read code, learn to fix bugs, develop new features, respond to complaints. All these things are valuable skills you can gain by working on open-source projects.
Just don’t expect your open-source experience to magically open any doors for you. Proprietary-source developers are all learning the same thing. You still need to demonstrate all the same intangible qualities and experience that companies look for to set a candidate apart. If you can’t even be bothered to show me why you would be a good candidate, why should I be bothered to find out if you are or not?
Its that time of year again. The time when employees everywhere are forced to justify their existence to management, and talk about all the great things they have done for the company. So, in honor of the occasion (and since I’m still recovering from my whirlwind few weeks of travel), I want to point you to this commentary on performance reviews. Even after all these years (it was first published in 1993), the accuracy of the commentary still hits home.
So, here’s to another day spent filling out useless forms and identifying “accomplishments” suitable for presenting my work in the appropriate context to upper management, and for everyone else going through the same charade, good luck.
Matt Asay posed a suggestion today on CNet.com that our healthcare problems here in the US could be solved by “Open Source”. He points out that the current information architecture is designed to handle the needs of the insurance and collection agencies, not the doctors and patients. Essentially, the systems handle billing, not patient care.
So the solution is easy, right? Have the open source community create a system for free that handles the patient data for the doctors, efficiency improves and everyone wins!
Trust me, if the solution were that easy, it would have been done already. There are a number of movements to digitize patient records and test results and otherwise bring the medical profession into the digital age, but still, as was pointed out in the article, only 34% of these records are transmitted electronically.
To give you an idea of a common problem, suppose that a hospital created a digital records system that would allow patient data, test results, care instructions and anything else you might need to be stored electronically. A doctor goes to see a patient and takes his patient history and symptoms, discusses treatment and care and decides which tests to order.
Answer these questions and you begin to have a solution (and it is only a beginning, I make no claim to even understand the full context of the issue)., but nowhere in these questions is there a problem with proprietary solutions. Doctors and nurses don’t care if the source code is available. They just want it to work with them, not against them. Open source in software is simply a non-issue. Smart folks are out there working on the real problems right now, and they are making progress. Let’s not confuse the issue by demanding they release the source code under a belief that if we simply make the software open, it will solve everything.
How do you decide when its time to change projects, companies, jobs? How do you decide to move from software development to management or back again? I have one simple test – persistent boredom.
After much experience I have learned that persistent boredom is the single best predictor that it is time for a change. The problem is that boredom can be comfortable. Boredom is predictable. It can be relied on in a crisis, and it keeps the paychecks coming in. But boredom forces you to remain still.
If you seek out new experiences and new opportunities, you cannot be bored. If you are not stretching yourself or your abilities you are not growing, you are not moving. In essence you become bored. Most problems with a job seem to stem from this boredom.
A bit of boredom is natural. We all have lulls where things aren’t as exciting as they could be. I tend to have a hard-time with the post-release lull where everyone coasts for a few days while we re-engage with our customer about the next release. But that is a temporary boredom, and during that time I am actively working to alleviate it. The boredom I am talking about is a persistent state. When I enter into that prolonged apathy, I know it is time for a change.
How many of you have ever commented on a manager’s lack of technical ability and/or knowledge? I’d wager that most of us have been astonished at least once in our careers by the technical incompetence of someone in charge of a technical project. A manager who doesn’t understand what “compile” means, who can’t grasp the concept of “automated testing”. Someone who doesn’t understand the domain of their employees.
It is difficult to work for someone like that. It can be difficult trusting their judgment when you know that they can’t grasp the simplest functions of your day-to-day job. Now, before you think this is another internet rant about clueless managers, let me ask you a question:
Can you have a conversation with your customers in their domain?
If you write financial software, can you sit down and talk with the financial analysts who use their software, without requiring the use of a “domain expert” to translate for you? If you can’t, you should consider learning how.
Too often we focus on learning our domain. We learn all the neat tricks in our chosen language. We become experts in the quirks of automated memory management. We learn about the differences between allocating on the stack versus on the heap.
Honestly though, when was the last time a successful release hinged on some arcane development trick that only 10 people in the world know about?
Every software release hinges on the ability of that software to solve some pressing need of its customers. And unless you are selling software and services to other software developers, those customers do not care about the software development domain. They care about the financial services domain. They care about the medical domain. They care about the cellular phone domain.
Become a domain expert. Learn to talk to your customers so you can anticipate their needs before they do. Don’t be content to be just an expert developer, strive to be more, so that the next time a customer calls you, you don’t become that clueless manager, asking what exactly it means to compile your software.
Most developers I know have wondered what it would take for them to “cut the ties” and go out on their own, but inevitably are ill-prepared to deal with the change. The biggest problem most of them have is calculating their costs. Too often they charge rates that are simply a patchwork of guesses and hopeful wishing that they are competitive. They can’t understand why they aren’t making as much money as they should be.
If you just want a ballpark figure, a rule of thumb to get you started would be to take your take-home pay rate and multiply it by 2.5. Calculating your take-home pay rate is simple:
PayRate = DesiredAnnualSalary / PaidHoursPerYear
How many paid hours are there in a year? If you assume a standard 52 week year with a 40 hour work week you get a total of 2080 hours (more or less – it is actually missing a day or two depending on the year, but its good enough).
PaidHoursPerYear = 2080 hrs/yr
So a good estimate of your hourly-rate would be:
BallparkHourlyRate = PayRate*2.5
Using these two calculations, if you wanted to make $60k/yr, you would have a pay-rate of $28.84/hour, and an hourly rate of roughly $72.10/hr.
Of course, that rate is only useful as an estimate. What you really need to do is calculate a rate based on your own circumstances. To do that, you need to account for much more.
The first thing we need to change is the number of hours in a year. When you determine your pay-rate you include all of your paid time-off. When you calculate your hourly rate, you do not. This means that we need to remove all the vacation and holiday time from our hours in a year.
WorkingHours = PaidHours – VacationHours – HolidayHours
If you assume a 10 holiday year and 4 weeks of vacation, you would get the following number of working hours per year:
WorkingHours = 2080 hrs/yr – 80 hours – 160 hours = 1840 hrs/year
However, not everything you do during a day is “billable”, which is the number we really need. So our final calculation reduces the number of working hours by the amount of time spent on “overhead” – tasks that cannot be billed but are still necessary:
BillableHours = WorkingHours – OverheadTime
Overhead time can range anywhere from 20% to 50% of the time. I usually use a 25% overhead rate.
OverheadTime = .25 * WorkingHours
Now that we know how many hours we can bill for in a year, we need to determine how much total money we need to make to cover all our costs. Of course, our major cost will be our salary. We will also be responsible for the employer portion of Social Security taxes and Medicare, along with any state taxes (for simplicity, we will combine these into a single number). We should also include any retirement benefits we may have to pay, and the cost of insurance:
AnnualSalaryCosts = DesiredAnnualSalary + EmployerTaxes + RetirementBenefit + EmployerInsuranceCost
Currently, Medicare costs 1.45% of the salary and Social Security costs 6.2% of the salary (Social security has an income cap, but I am ignoring the cap to keep it simple). State taxes will depend on your state, so I am going to ignore them:
EmployerTaxes = .0145 * DesiredAnnualSalary+ .062*DesiredAnnualSalary
Insurance costs can vary greatly, so I am just going to use a rule of thumb that says it will be about 25% of the annual salary:
EmployerInsuranceCost = .25 * DesiredAnnualSalary
Finally, we can use a fairly standard 6% matching program as our retirement benefit:
RetirementBenefit = .06 * DesiredAnnualSalary
If we combine all these different numbers and assumption, we get the following equation:
AnnualSalaryCosts = 1.3271 * DesiredAnnualSalary
You may have noticed that the multiplier used to calculate the salary costs is a little over half the multiplier we used to create our ballpark estimate. So what else do we need to account for to determine our total costs?
There are 3 major areas left to consider. The first is equipment. This means computers, software licenses, etc. The second is facilities. This means the cost of renting an office, keeping the lights on, the water running, and the internet surfing. The final major component is the profit. This is the money that goes back into the company to build and expand it and keep it running. Adding these final items into our cost calculation gives us the following:
AnnualCost = AnnualSalaryCosts + AnnualEquipmentCost + AnnualFacilityCost
TotalAnnualCost = AnnualCost + Profit
Profit is usually some percentage of the annual cost. A modest profit would be 10%, but a 20% profit is not unreasonable. For a single person, the facility costs can run from about $500 a month up to as much as $1000 or more. The equipment costs will obviously vary depending on your needs, but I usually assume about $3000 a year. That covers a new computer every few years and license costs for any needed software.
Now that we know what our total costs are, and how many billable hours we have, we can calculate a much more accurate hourly rate:
HourlyRate = TotalAnnualCost/BillableHours
Using our example salary of $60K/yr and the assumptions list above (with a $500 monthly office cost), we can calculate our actual hourly rate to be
HourlyRate = 101409 / 1472 = $68.89/hr
Of course, I would round that number up to a nice and even $70/hr and use that as a basis for all my calculations. If I needed to know how much I should bid for some project, I would first estimate what I need to do and how long it will take me, then multiply that by my hourly rate. If I was making a commercial piece of software, I would use that development cost to help guide how I set its price. If I combine that information with sales forecasts, i can get an idea of whether I will even be able to break even on the project.
Knowing your true hourly rate is essential to determining how to price yourself and your skills. Even if you are working for a company it is worthwhile to calculate it simply to have an idea of what your time is actually worth. Plus you’ll know how much to ask for the next time a friend calls up asking for technical support.
I am often surprised at how difficult it can be to give other people your money. Too many sales departments in companies providing business services seem to be under the unfortunate impression that their software/service is *so* compelling, that it can dictate the terms of the conversation. They erect barriers so they can control the sale process and prevent simple comparisons. By controlling the terms and content of the sales and marketing process, they believe that they can maximize the sale. Of course, they all claim to do this to ensure that their potential customers “understand” their choices and “select the option that provides the best value”.
Unfortunately, I have yet to encounter a piece of software or a business-related service that is so compelling that I will not walk away from it if I cannot control the terms of the sales process. As someone who is frequently asked to make purchasing decisions, I have dealt with a wide spectrum of approaches to sales and have discovered a number of common barriers that will almost immediately cause me to look elsewhere.
I have found that companies that use these barriers generally do so because of a lack of confidence in their product. They usually have a number of close competitors and they are afraid of making the process transparent because they believe it will give their competitors an edge. This may be true, but it is not my problem. All it indicates to me is that your product or service is not as compelling as you want me to believe. If it was, you wouldn’t be worried about your competitors because your product or service would stand on its own merits, and a product or service that can do that is always the best option.