There was a time when I would have said "Stick it out, give things a chance."

That was then and this is now.

I've been where you are. What the "senior" did is unacceptable. Pulling your commits is marginally justifiable, if he IMMEDIATELY issues his design plan document. Deleting your (presumably private) branches is not.

Get out of there. As soon as possible.

You made the mistake so many make.

You came straight from school to your first job and took it upon yourself to change how the company works.

Nobody cares if your suggestions are good or not, they just see a still green behind the ears graduate who thinks he knows better than everyone before him.

Of course you'll be met with resistance and looked down upon.

So that was why you're in the situation you're in right now.

Your senior either understood you know more than him and views you as a danger to his position or he thinks you're an immature, know it all hack who can't write correct code.

You have two options:

Confront or submit.

If you confront ask why your work was deleted and escalate to superiors if you can prove it was replaced by inferior code.

Be prepared for backlash up to the point that you want to or are forced to look for a new job.

If you submit, just do your tasks and bite your tongue if you have an idea how to optimize the company.

It's not your place until asked to do so, given a position with that responsibility or have your own company that you can run exactly the way you want it to...

Being a new member of a team, especially being fresh out of college, makes it difficult for your voice to be heard. This is something I have struggled with and, even as a senior developer, still struggle with.

I have worked as small start ups, medium sized companies, and Fortune 500 companies. One thing I will tell you right now is that the larger and older a company is, the more resistant to change they will be.

Right now I'm a senior engineer at a large enterprise (I won't say which one) and trying to get anything done is like pulling teeth. When I signed up they said I'd be working on their new platform, which no one told me was also five years old. The age of the platform would have been fine had they kept it up to date, but because they made poor technology decisions and had a bunch of developers who generally had no idea how the modern world of software worked, they created this massive junk yard of horrible code that is next to impossible to maintain.

One of the main reasons they hired me was because I've been known to shake things up, modernize, and get things done, which is what, during the interview, they said they wanted.

Why am I saying all this? Basically I'm using it as a teaching point. Making any changes to existing processes or technologies in an environment where those things didn't exist is a constant uphill battle. Eventually, I was able to start to get some changes implemented and I've kept up the momentum and will eventually be pioneering the next generation of their software. Here's how I got there:

1. You have to prove yourself to the team. Make sure that your team members and managers see you as a useful and productive member of the team. This will help them build trust that you know what you're talking about.




2. Find some concrete examples of things that you see that are wrong and could be done better. Investigate these things and gather as many metrics as you can. Business people and managers are easy to convince when you use easy-to-understand graphs and numbers that relate to savings time and money.




3. Getting other team members on board will go a long way to helping your cause. You can't do this alone, so try to convince your colleagues because the more buy-in you have from them the easier it will be.




4. Don't try to change everything overnight. It won't happen, so make a bunch of small changes in the right direction and keep up the momentum and it will start like an avalanche.

Good luck to you!

Long term advice: if you decide to stay in the job then change will only happen in proportion to the amount the team respects you.

Short term advice: pick your battles and try to get other people to fight them for you. If you do this successfully you will build respect. You may have squandered a lot of respect by not doing this successfully.

Some rules of thumb for picking your battles:

1. Anything adversarial should go directly through your boss. Do not directly criticise or complain about colleagues in front of other colleagues. Your boss is the the person who directly controls your senior colleague so speaking to anyone else about adversarial issues is pointless (and potentially dangerous, if they are friends with senior).


2. You can suggest improvements to anyone but try to do this in a non-confrontational manner. Be prepared to drop suggestions if people aren't buying it. You also want to try and suggest the same improvement as few times as possible. For example, it is ok to say "we could use github for this" every time there is a new project/problem but it is not ok to tell Dave Anonymous "github would be really good for your project" then proceed to tell Dave's colleagues how good github would be for Dave after he has already indicated that he isn't interested. Dave will be annoyed and maybe never respect you again. The trick here is working out the right time/situation/person to put forward your suggestion and restricting yourself to one time/situation/person per idea.

Ideally you don't want to spend any time criticising or fighting with your "senior" colleague but there are some times when this is unavoidable. e.g. if your colleague is deleting your work. In all of these cases you need to go to your boss with a clear outline of the problem and what you would like to change.

In the case of deleted work you could say "X is deleting my work without talking to me. Please could we have a meeting with you, me and X to agree on some kind of framework for version control (replace version control with whatever you think would help). I'm sorry to bring this to you but I haven't been able to find a solution with person X." Do make sure that you have already tried speaking to X before your boss. Also make sure that you have a tangible example of work deleted. Perhaps you don't have the code itself (since it was deleted) but you should be able to describe how long the code was and what it did.

"Because of him being the only developer in the team for more than a year, no one challenged his opinions and ideas on how processes should work."

That is exactly what happened to me at work, and that's happened not only in programming, but also in every field work. (I'm not programming, but I have the same situation as yours.)

I don't say my senior (same situation with your senior) is bad at all. Sometimes I give some advice/opinion/critic, but she rejected it, she won't discuss it and find out the best way to solve the problem.

But my condition is worse than you. Basically I know, I already lose the war before it even started.

Well, if you are looking for the answer, maybe it only has two options:

1. Brace yourself, and accept the condition, considering if you need (have) to keep your job. I believe karma is real.




2. You could resign and find another job. I mean, why would you live in a place that makes you unhappy, right?

And sometimes, the truth will reveal itself. I mean it's better for you to focus on yourself, use your energy and your time to develop your ability and skills rather than think about them, ignore close-minded people like your senior (also mine).

And the meaning of "the truth will reveal itself" - who knows, five years later your senior will be stuck at a low-grade job and you got into a higher-level job at a different company. Who knows, right?

Do you currently have the great luck of working in an industry where there's plenty of work.

Right now you should be working for a company where either a) you love your job or b) you are learning every single day (which will help with a) in the long term). I can see no reason whatsoever for you to remain at this job.

Do the job the best way you can regardless of circumstance

You were hired for your skills and expertise. The fact that a "senior" engineer doesn't recognise that isn't your fault.

The way I see it you have three options:

Option 1: Leave

This situation raises numerous red flags. A small development team entirely controlled by one inexperienced leader, no consultation on process, poor standards and quality control, etc.. You could well be better off elsewhere.

Only choose this option if you feel you can't make it work otherwise. Leaving during probation can look bad on a resume. You will need to explain it and see yourself well in all future interviews.

Option 2: Submit

Lower your own standards to fit in with the team. You're new; don't rock the boat. He does have another year's experience compared to you. Clearly he knows more; just sit there and learn from the master of all things programming.

Don't choose this option. You're better than that.

Option 3: Try to improve the situation

This is what you were hired to do. Do the job to the best of your ability despite adversity. You have said that direct confrontation didn't work and your concerns were dismissed. You need evidence to support yourself. Some things you could try:

Ask to document the current development process.

"I'm having trouble getting my head around our development process. If you explain it to me I'll document it for the next new starter." There is no reasonable cause to reject such a request. Best case, you will discover the process isn't as bad as you thought. More likely case is you can use this to identify special deficiencies or problems you can improve. Worst case, your request gets rejected, see Option 1.

Present Solutions, not Problems

Write up formal documentation for what process you want to change. Make notes of specific problems the team has had that this process with resolve in the future. You know an off-hand suggestion to change will be dismissed, and don't give them that chance. Present the team leader and management with a well researched and documented approach to solve problems. Now you aren't the new kid causing issues; you are the solution to problems they already had.

Be polite and don't start fights

You need to be the bigger person in this situation. Show yourself as rational and willing to listen. If an idea gets shot down, accept it and move on. When the problems inevitably reoccur you can bring it up then. You don't want to be seen as a troublemaker; earn their represent through your behaviour even if you can't change their minds.

Often times the best programmers are the ones with the humility to admit when they're wrong and that don't need to hide behind layers of bullshit to cover up for not knowing something