

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&#x27;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&#x27;s invested in Continuous Delivery, and they use Subversion for source control. They have a team of about 20 people, all who are &#x27;Senior UI developers&#x27; yet no one uses TDD. But they are offering a lot of money, and most likely I&#x27;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.

