Before I sign, can I see your codebase?

Changing employers is always a hard decision to make. Whatever the reason is you found that new opportunity that caught your attention: money, fame, need for a new challenge. There are plenty of jobs in the sea, certainly as a developer, and it’s hard to find that one true job. You don’t want to end up in a job which has the same drawbacks as your previous gig. If you take the leap you want it to be worthwhile on all areas: financial, job satisfaction, etc. Although the financial aspect is an important part of the decision making it’s not the holy grail. For me even more important is job satisfaction. In every job interview they’re telling you they have state of the art ASP.Net Turbo 3000 code running on their Windows 2099 machines. But as we all know there is code and there is code.

To be able to make a good decision, the first thing you do is gathering intel. Asking around with friends, former colleague’s, friends from friends and so on about the company you’re about to sign for. If all those signs are positive and the pay is good (I’ve been told it should be minimum 10% more then you’re current wage), you could ask to meet the team you’re going to become a part of. I don’t believe in first contact, certainly not at a job interview because everybody is going to be at his best. You will see your future manager for about 2 to 3 hours and he will be looking for people so he will show his most charming side. Your future team mates don’t know you so they’ll act like the nicest people you’ve ever worked with because they don’t know you. If you sign the contract you’re going to spend more than 8 hours per day with these people, only then you will really get to know them. Worst case scenario if the first encounter with the team was a bad one, I would be reluctant to sign. But this is hardly ever the case.

So on what grounds should your decision be based? I’ve never done this before but I was discussing this topic with some people and it suddenly struck me. They can offer you double the wage you are earning today but if you have to work your way through the next big ball of mud you’re nog going to have a lot of fun at your new job. Unless you’re looking for a real challenge. But how do you make a distinction between a challenge and professional suicide? The best way to get to know how a company works and what the quality of the codebase is: ask if you can quickly see some codefiles and if they could shortly draw how their application is architected. You’ll get a crash course in how the company works and which of the statements the recruiter or manager made about the software methodology they’re currently following are really true. It will be enlightning because you’ll not be jumping into an abyss, you’ll have a better understanding of the risk you are taking. Of course there is always risk involved but calculated risk is in my opinion a part of an exciting life!

Employers can also learn something from this: If you have a neat codebase or some really cool continuous integration system show it to your future employees. It’s certainly an extra plus when trying to convince someone to sign for your company.