Don't Ask for a Raise - Find a New Job

I read a lot of hand-wringing about asking for a raise.

The most important thing you need to understand is that your supervisor probably cannot get you a raise. It's just not possible.

Your boss gets at most one time a year to influence your pay - your review. At that time, your manager can ask for a good raise, or not a good raise. That's about it. There is usually a pool of money that has to cover all the raises in the group - if you get a huge raise, it means everyone else gets a tiny one. That's hard to justify, no matter how good you are.

And as any parent knows, if you have three kids, you can't buy one ice-cream cone. You must buy three. Similarly with big raises - if you get one, everyone else will want one. For a supervisor, there is a strong tendency to be seen as fair.

So asking your manager for a big raise is usually not worth it. He or she simply can't deliver a big raise, most of the time.

Instead, find a new position that pays what you are aiming for, and apply. That is the best way to get a raise in pay.

When a new position is being staffed, the salary rate is not set yet. At that time a manager actually has far more ability to get you more money. The position will have been approved with a range of available salaries. For an entry level computer science grad in Colorado right now, that might be a range of $65K - $80K.

If you are making much less than the top end of that range, you will have a better chance of getting a rise in pay by switching to the new position and coming in at a higher rate.

Measuring Tests

At first, it is easy to add tests. When there are no tests, start covering your most important functionality.

And as bugs are found and fixed, new tests are added. (Every bug should generate at least one new test - the one that proves it has been fixed.)

After testing has reached a more advanced stage, there are tools that can show you what code remains untested. Then you can craft specific tests to excersize that code. By measuring the code base, you can ensure that all of your code is tested.

A Word of Warning

Testing is wonderful and necessary. Reaching 100% test coverage on a code base (or getting close to it) is a great feeling. Such code is really much better tested than code with no tests, or few tests.

But it does not guarantee that the code is bug free. Bugs are sneaky things - they can be in tests as well as the code, and they can depend on input data that the tests don’t attempt to use.

Adding Testing to Untested Project

If your project is currently untested, you should start adding tests. Here’s how to do it in three steps:

1. Put your code in a repository (git or subversion, for example).
2. Install Jenkins or some other continuous integration server.
3. Write your first test.

Making it Work

The most important factor in making testing work is that the management and senior developers have to make the commitment to only allow tested code to enter the code base. All new code changes must come with testing to support them.

If a programmer is assigned to add a feature to the code, then he or she must also develop tests for that feature. The development of the test code must be considered an integral part of the task. It is not an afterthought - it is central.

Only by submitting test code with the code changes can the programmer demonstrate the correctness of the proposed changes. The programming culture must change so that it is no longer acceptable to merge work based on just the programmer’s say-so. Work must be demonstrated to be correct - demonstrated like a mathematical proof.

Incrementalism

A key to a successful strategy is incrementalism.

A large software package has a lot of code to test. It may take months or years to fully test a complex package. It may never be fully tested.

But it is possible to add some tests, for some commonly-used functionality, today. And, over time, you will find that it is possible to quickly spin up a useful set of tests. Over time, they will improve.

Life After Testing

Life on an untested software project is hardly worth living. Programmers are always scared that disaster will strike. They don’t feel confident in their product, and they are correct in their lack of confidence. Without through testing, there is no reason to be sure that their software is working correctly.

After testing is implemented, everything changes. Programmers can sleep easy. Although bugs may still leak through the test process, at least all the easy bugs are caught/ And as new bugs are encountered, the tests are improved. Over time, the test suite becomes quite skilled at catching bugs.

Why You Should Test Your Software

Automated software testing is so normal, so ordinary, and has been around so long, that I sometimes forget that a lot of places don’t do it.

If you are in a software group that does not do automated testing, then I have a suggestion for you: start testing today.

What is Testing?

Testing means automated tests which exercise the code base.

Tests are simply programs that run other programs, to make sure they handle different inputs in the correct way.

Human-based testing is better than no testing, but if that is what you are doing, you need to start adding automated testing. Today.

Why Test?

Each software product is one-of-a-kind. If there was another piece of software that did what you needed, then you would use it. So if you are writing software, it is one-of-a-kind software. It is software that has never been written before and is like no other software in the world.

It is unique.

It is also very complex. If it were simple, you would be able to use general purpose software that already exists. If you can achieve your goals with a spreadsheet, a word processor, or some other piece of off the shelf software, then you would not be developing software.

Therefore if you are developing software, you are solving a complex problem, in a unique way.

Of course you need to test it!