Tag Archives: advice

It’s always about the money

I was asked an interesting question today regarding which job should someone go for. The options in question were for a “boring” product, but with a good team, and for an “interesting” product, but for rubbish pay and the possibility of a full time job after a period of a few months.

As far as I’m concerned the above scenario really only has one choice, but in the conversation that followed it was pointed out that there are a few students out there who are unsure what path they should take when it comes to accepting Software Engineering job offers out of university. What I’m providing here is an expanded version of the advice I gave today. Caveat Emptor and all that.

Lets look at product first. I’ve worked on a product that, in its original incarnation, was a putrid, rotting corpse that sucked the very life from your soul. This was due to the hideous way it had been barfed into existence and the ridiculous choices that had been made in terms of architecture, language and structure. It quite literally broke two consultants while we were doing the analysis.

That exact same product, rewritten, re-architected and generally done properly was actually quite nice to work on. As a product it was as boring as hell, but as a job I had more fun there than I did on my next job which was, in theory at least, a much more “interesting” product.

As far as product (or service, or whatever you’re being employed to program) goes you really only care if it’s something sensible that’s going to continue making the company money (and therefore allow you to continue being paid), and that it doesn’t do something that you find morally reprehensible. You may also find, as I did when working in London, that your morals become somewhat malleable as the salaries increase.

So product is much less important the technology. Make sure it’s the technology you want to be working with. If the code has been around for any length of time, it’s going to be a steaming pile of crap. Deal with it. If it’s new code you’ll be involved in turning the nice new codebase into the steaming pile of crap that it’s destined to be. Such is the nature of most development houses. Either way you’ll have some days where you get to write little gems of code that make you proud, and others where you’re having to bludgeon some hack into the code just to make the damn thing work. May as well be swearing at a technology stack that you enjoy and doesn’t fight you back.

Team is also very important. You need to work with these people day in, day out. If the team is comprised of people that cause violent thoughts due to their behaviour and nature then walk away. In generally moving jobs every 2 years in IT isn’t going to raise any eyebrows, but can you really tolerate these people for that length of time?

So you’ve narrowed it down to a shortlist of things you are happy to work on, using technology you want to use, with people who won’t cause you to go postal. I’m going to assume you’ve already weeded out places that are too far away, or are otherwise impractical. You’re now left with the final thing: money.

Pro tip: up to a certain value, it’s always about the money.

If you’re stuck, go with the company that will pay you more. Money may not buy you happiness, but it sure as hell helps mitigate a lot of stress. Not having to worry about your next pay check, being able to afford treats, holidays away, shiny new kit, all these things can make life much easier.

Now you’ve made your choice, if you find yourself kind of wishing you hadn’t picked that place, strike it from the shortlist, start again.

Oh, and as an aside, anything that you’ve been promised is worthless unless you’ve got it in writing. Something in writing trumps vague verbal promises every single time.