Ask HN: Switching Jobs

[bttf]

I recently received a job offer for UI work with Javascript, which I absolutely love to do. They are offering me a boatload more than what I am currently paid (almost more than half). Right now, my current job involves a lot of C#, Powershell and Bash scripting which I don't exactly love. The conflict is, at my current job, we are heavily invested in TDD and Continuous Integration. We virtualize all our testing environments, and have a CI server running continuously giving us feedback. This is part of the job that I love; we are shipping almost every week (which is impressive for the type of product we produce). On the other hand, at the new job, no one uses TDD, no one's invested in Continuous Delivery, and they use Subversion for source control. They have a team of about 20 people, all who are 'Senior UI developers' yet no one uses TDD. But they are offering a lot of money, and most likely I'd end up as a junior position, so I doubt I could take the evangelical role. I am searching for advice.

[RogerL]

My advice is that it is time to interview them. Why do they do what they do, what are their pain points, are they open to trying X to fix pain point Y, and so on. Interviewing is a two way street, and it may just be how you ended up wording your question, but I don't get the sense that you really know the answers to any of those questions. None of us can really answer that part for you.

My other advice is that if you are early in your career, it doesn't hurt to be exposed to different practices. Even if you ultimately decide that they should have used CI and such, you will see another approach which may perfectly apply to some job in the future. (Almost) No job is perfect - there will be a mix of interesting/dull work, great/bad practices, too many meetings or not enough communication, and so on. If it doesn't see like you'd be miserable there, why not go on over, build your UI/Javascript chops, and build it into your next job?

[arink]

You don't need to preach. Use the workflow that makes you the most productive, mention what you're doing to others, and roll with what happens.

As a personal example, I'm not sure anybody had heard of or used Jenkins when I arrived. We now have an automated build, multiple levels of testing, static analysis, etc. I installed it and did some initial configuration, but others took on the majority of the work because they bought into it.

Couple other thoughts

- For CI, mention it to the team, have examples to back up where it helped, and offer to set it up. Shouldn't take too long and it'll pay back as soon as you catch some busted code (yours or theirs)

- While Subversion may not be as highly regarded as Git, it works just fine. So I wouldn't consider that a negative, just a different tool.

[FurrBall]

A 50% pay increase? Go for the money.

Don't hold onto your preferred practices so strongly that you forfeit your own market value.

[goofygrin]

Some people -- myself included -- think TDD is not a good way to develop software. And I use SVN and TFS... I've tried git and frankly I want to solve problems, not introduce more with my source control provider. I want something that "just works" and git just isn't it (and repeated branching/merging has NEVER worked well in the long run IMO).

CI... all for it, must have IMO.

Remember, just because you think how you do your job is the "only way" you're not always right :) And I'd say a weekly release cycle sounds like a griiiiind.

(Edit, I run a team of 10-11 and have to work with developers from interns to senior with 10+ years of experience... so it's not like I'm just cowboy coding all in a vacuum... and we're reasonably successful at what we do :D)

[caw]

I'd go for it if the team is good. With 20 senior people, that's a lot of possible mentors and people to learn stuff from. The money is obviously good, and it's the thing you want to be working on.

You can evangelize once you're there. Or, you'll find out that what they're doing is actually best for the environment they have. I seem to remember SVN handles larger repos better.

Don't work about being "junior." I joined my employer as new college graduate, and still was able to influence some changes in my environment. However, I still use RCS for some scenarios because it works best in my environment.

[mchannon]

You need to decide if you're the sort who'd rather serve in heaven or rule in hell (the analogy works both for work environment and salary).

There's also the third option- seek out a better position with even more pay.

[wikwocket]

Look at it this way: what is more likely, that you could help the new company get started with TDD and CI, or that your current company would give you a 50% raise and let you work with technology that you love?

Consider all the dimensions, including the point mchannon made that you can always look for additional companies to work for if this new one doesn't seem like the best fit, but if you think you will be happier at the new firm, consider switching.

[abawany]

Don't forget the "if it's too good to be true..." aspect as well. Sometimes companies throw money at people to trap them in dysfunctional environments. If you got the feeling that the people at the new company will embrace good practices, then what arink says makes a lot of sense. However, if they instead actively shut you down for "wasting time with non essential activities", then you will end up being pretty unhappy.

[thifm]

You can be evangelical in all positions -- make sure you do a respectable work wherever you are and people will respect you and your opinions. If the job looks better, go for it!

This is time to use your intuition, not to be rational. If you stay rational you will never change jobs because your brain can invent and pretend that your current job is the best and the opposite is the worse.