Co-worker sabotaging/undoing my work [closed]
Clash Royale CLAN TAG#URR8PPP
Context:
I just got hired as a software developer in a team which has freshly transitioned from networking to development. Before me they hired another developer a year ago who has been since then given a senior role. He is the only other developer by background in that team. This senior developer and I have graduated from the same college and program as well, and this is also our both first job, the only difference being he graduated from college before me, being older than me. I am saying this to explain how much of a difference he and I have in professional experience.
Our manager is not technical, and therefore he is one of those "I care about how much money did it save the company."
Problem:
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. When I joined the team, I saw a team not using Git/GitHub correctly or straight up not using it, no documentation, pushing code directly to production boxes, no collaboration, and manual if some testing. (Things are not that bad. The team is learning, and they realized they aren't following the best practices.)
When I joined, as in any other team, I started putting my ideas forward, but I am always met with a condescending response ("Do you even know insert given topic") by this senior developer. The rest of the team and manager just side with the senior. When I asked them why, the conversation went somewhat like this:
Me: Why do you think this is okay?
Team & manager: He is senior and he knows more.
Me: Why do you think he knows more?
Team & manager: Dude, he uses Linux as his development environment, and he knows a lot.
(That Linux comment actually happened.)
So, I decided to stop getting myself insulted and just do my own thing until maybe more developers are hired and/or we get a technical manager. However, recently I was told to collaborate with this senior on a project, and as usual he denied my ideas...which was okay. I decided to play by his rules (not worth my time) until I recently saw my branches and commits being deleted because he had something else in his plan, which was not communicated to anyone.
I am still on probation and don't want to cause a drama, but it's getting hard not to.
software-industry software-development
closed as off-topic by gnat, solarflare, OldPadawan, Jenny D, JimmyB Feb 25 at 14:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – gnat, OldPadawan, Jenny D, JimmyB
|
show 7 more comments
Context:
I just got hired as a software developer in a team which has freshly transitioned from networking to development. Before me they hired another developer a year ago who has been since then given a senior role. He is the only other developer by background in that team. This senior developer and I have graduated from the same college and program as well, and this is also our both first job, the only difference being he graduated from college before me, being older than me. I am saying this to explain how much of a difference he and I have in professional experience.
Our manager is not technical, and therefore he is one of those "I care about how much money did it save the company."
Problem:
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. When I joined the team, I saw a team not using Git/GitHub correctly or straight up not using it, no documentation, pushing code directly to production boxes, no collaboration, and manual if some testing. (Things are not that bad. The team is learning, and they realized they aren't following the best practices.)
When I joined, as in any other team, I started putting my ideas forward, but I am always met with a condescending response ("Do you even know insert given topic") by this senior developer. The rest of the team and manager just side with the senior. When I asked them why, the conversation went somewhat like this:
Me: Why do you think this is okay?
Team & manager: He is senior and he knows more.
Me: Why do you think he knows more?
Team & manager: Dude, he uses Linux as his development environment, and he knows a lot.
(That Linux comment actually happened.)
So, I decided to stop getting myself insulted and just do my own thing until maybe more developers are hired and/or we get a technical manager. However, recently I was told to collaborate with this senior on a project, and as usual he denied my ideas...which was okay. I decided to play by his rules (not worth my time) until I recently saw my branches and commits being deleted because he had something else in his plan, which was not communicated to anyone.
I am still on probation and don't want to cause a drama, but it's getting hard not to.
software-industry software-development
closed as off-topic by gnat, solarflare, OldPadawan, Jenny D, JimmyB Feb 25 at 14:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – gnat, OldPadawan, Jenny D, JimmyB
36
How do you become a senior developer with 1 year of experience? That alone sounds like a red flag.
– Joe W
Feb 25 at 0:33
18
You are catching close votes. I am inclined to agree with them. What is your goal? Can you state it clearly? Otherwise this is just a rant.
– bruglesco
Feb 25 at 1:42
7
The answers you have so far are speculative; please formulate a direct question. It will make it just a bit more clear. :) I'll also add a little note here that you shouldn't need the manager to be technical to understand that you can contribute new ideas the senior lead hasn't; that strikes me as somewhat odd.
– person27
Feb 25 at 5:34
1
See similar question - I think the advice is also quite relevant: workplace.stackexchange.com/questions/40352/…
– ForOhFor
Feb 25 at 8:30
7
Not really an answer, but a relevant footnote: "sabotaging" implies intent to harm you (professionally). While I agree with the majority here that the senior's behavior is unacceptable; I strongly urge you not to call it sabotage when you talk to your employer. This suggests that you're taking it personally and elevates it from a professional conflict to a personal one; which can detract from your professional argument.
– Flater
Feb 25 at 8:48
|
show 7 more comments
Context:
I just got hired as a software developer in a team which has freshly transitioned from networking to development. Before me they hired another developer a year ago who has been since then given a senior role. He is the only other developer by background in that team. This senior developer and I have graduated from the same college and program as well, and this is also our both first job, the only difference being he graduated from college before me, being older than me. I am saying this to explain how much of a difference he and I have in professional experience.
Our manager is not technical, and therefore he is one of those "I care about how much money did it save the company."
Problem:
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. When I joined the team, I saw a team not using Git/GitHub correctly or straight up not using it, no documentation, pushing code directly to production boxes, no collaboration, and manual if some testing. (Things are not that bad. The team is learning, and they realized they aren't following the best practices.)
When I joined, as in any other team, I started putting my ideas forward, but I am always met with a condescending response ("Do you even know insert given topic") by this senior developer. The rest of the team and manager just side with the senior. When I asked them why, the conversation went somewhat like this:
Me: Why do you think this is okay?
Team & manager: He is senior and he knows more.
Me: Why do you think he knows more?
Team & manager: Dude, he uses Linux as his development environment, and he knows a lot.
(That Linux comment actually happened.)
So, I decided to stop getting myself insulted and just do my own thing until maybe more developers are hired and/or we get a technical manager. However, recently I was told to collaborate with this senior on a project, and as usual he denied my ideas...which was okay. I decided to play by his rules (not worth my time) until I recently saw my branches and commits being deleted because he had something else in his plan, which was not communicated to anyone.
I am still on probation and don't want to cause a drama, but it's getting hard not to.
software-industry software-development
Context:
I just got hired as a software developer in a team which has freshly transitioned from networking to development. Before me they hired another developer a year ago who has been since then given a senior role. He is the only other developer by background in that team. This senior developer and I have graduated from the same college and program as well, and this is also our both first job, the only difference being he graduated from college before me, being older than me. I am saying this to explain how much of a difference he and I have in professional experience.
Our manager is not technical, and therefore he is one of those "I care about how much money did it save the company."
Problem:
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. When I joined the team, I saw a team not using Git/GitHub correctly or straight up not using it, no documentation, pushing code directly to production boxes, no collaboration, and manual if some testing. (Things are not that bad. The team is learning, and they realized they aren't following the best practices.)
When I joined, as in any other team, I started putting my ideas forward, but I am always met with a condescending response ("Do you even know insert given topic") by this senior developer. The rest of the team and manager just side with the senior. When I asked them why, the conversation went somewhat like this:
Me: Why do you think this is okay?
Team & manager: He is senior and he knows more.
Me: Why do you think he knows more?
Team & manager: Dude, he uses Linux as his development environment, and he knows a lot.
(That Linux comment actually happened.)
So, I decided to stop getting myself insulted and just do my own thing until maybe more developers are hired and/or we get a technical manager. However, recently I was told to collaborate with this senior on a project, and as usual he denied my ideas...which was okay. I decided to play by his rules (not worth my time) until I recently saw my branches and commits being deleted because he had something else in his plan, which was not communicated to anyone.
I am still on probation and don't want to cause a drama, but it's getting hard not to.
software-industry software-development
software-industry software-development
edited Feb 25 at 13:50
yoozer8
4,17643056
4,17643056
asked Feb 24 at 21:11
RandomDevManRandomDevMan
139123
139123
closed as off-topic by gnat, solarflare, OldPadawan, Jenny D, JimmyB Feb 25 at 14:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – gnat, OldPadawan, Jenny D, JimmyB
closed as off-topic by gnat, solarflare, OldPadawan, Jenny D, JimmyB Feb 25 at 14:41
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions require a goal that we can address. Rather than explaining the difficulties of your situation, explain what you want to do to make it better. For more information, see this meta post." – gnat, OldPadawan, Jenny D, JimmyB
36
How do you become a senior developer with 1 year of experience? That alone sounds like a red flag.
– Joe W
Feb 25 at 0:33
18
You are catching close votes. I am inclined to agree with them. What is your goal? Can you state it clearly? Otherwise this is just a rant.
– bruglesco
Feb 25 at 1:42
7
The answers you have so far are speculative; please formulate a direct question. It will make it just a bit more clear. :) I'll also add a little note here that you shouldn't need the manager to be technical to understand that you can contribute new ideas the senior lead hasn't; that strikes me as somewhat odd.
– person27
Feb 25 at 5:34
1
See similar question - I think the advice is also quite relevant: workplace.stackexchange.com/questions/40352/…
– ForOhFor
Feb 25 at 8:30
7
Not really an answer, but a relevant footnote: "sabotaging" implies intent to harm you (professionally). While I agree with the majority here that the senior's behavior is unacceptable; I strongly urge you not to call it sabotage when you talk to your employer. This suggests that you're taking it personally and elevates it from a professional conflict to a personal one; which can detract from your professional argument.
– Flater
Feb 25 at 8:48
|
show 7 more comments
36
How do you become a senior developer with 1 year of experience? That alone sounds like a red flag.
– Joe W
Feb 25 at 0:33
18
You are catching close votes. I am inclined to agree with them. What is your goal? Can you state it clearly? Otherwise this is just a rant.
– bruglesco
Feb 25 at 1:42
7
The answers you have so far are speculative; please formulate a direct question. It will make it just a bit more clear. :) I'll also add a little note here that you shouldn't need the manager to be technical to understand that you can contribute new ideas the senior lead hasn't; that strikes me as somewhat odd.
– person27
Feb 25 at 5:34
1
See similar question - I think the advice is also quite relevant: workplace.stackexchange.com/questions/40352/…
– ForOhFor
Feb 25 at 8:30
7
Not really an answer, but a relevant footnote: "sabotaging" implies intent to harm you (professionally). While I agree with the majority here that the senior's behavior is unacceptable; I strongly urge you not to call it sabotage when you talk to your employer. This suggests that you're taking it personally and elevates it from a professional conflict to a personal one; which can detract from your professional argument.
– Flater
Feb 25 at 8:48
36
36
How do you become a senior developer with 1 year of experience? That alone sounds like a red flag.
– Joe W
Feb 25 at 0:33
How do you become a senior developer with 1 year of experience? That alone sounds like a red flag.
– Joe W
Feb 25 at 0:33
18
18
You are catching close votes. I am inclined to agree with them. What is your goal? Can you state it clearly? Otherwise this is just a rant.
– bruglesco
Feb 25 at 1:42
You are catching close votes. I am inclined to agree with them. What is your goal? Can you state it clearly? Otherwise this is just a rant.
– bruglesco
Feb 25 at 1:42
7
7
The answers you have so far are speculative; please formulate a direct question. It will make it just a bit more clear. :) I'll also add a little note here that you shouldn't need the manager to be technical to understand that you can contribute new ideas the senior lead hasn't; that strikes me as somewhat odd.
– person27
Feb 25 at 5:34
The answers you have so far are speculative; please formulate a direct question. It will make it just a bit more clear. :) I'll also add a little note here that you shouldn't need the manager to be technical to understand that you can contribute new ideas the senior lead hasn't; that strikes me as somewhat odd.
– person27
Feb 25 at 5:34
1
1
See similar question - I think the advice is also quite relevant: workplace.stackexchange.com/questions/40352/…
– ForOhFor
Feb 25 at 8:30
See similar question - I think the advice is also quite relevant: workplace.stackexchange.com/questions/40352/…
– ForOhFor
Feb 25 at 8:30
7
7
Not really an answer, but a relevant footnote: "sabotaging" implies intent to harm you (professionally). While I agree with the majority here that the senior's behavior is unacceptable; I strongly urge you not to call it sabotage when you talk to your employer. This suggests that you're taking it personally and elevates it from a professional conflict to a personal one; which can detract from your professional argument.
– Flater
Feb 25 at 8:48
Not really an answer, but a relevant footnote: "sabotaging" implies intent to harm you (professionally). While I agree with the majority here that the senior's behavior is unacceptable; I strongly urge you not to call it sabotage when you talk to your employer. This suggests that you're taking it personally and elevates it from a professional conflict to a personal one; which can detract from your professional argument.
– Flater
Feb 25 at 8:48
|
show 7 more comments
9 Answers
9
active
oldest
votes
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.
18
The way that "senior" is behaving made me want to write the same thing about getting out. I worked with one guy and it was an absolute dream - we discussed, put forward ideas : some of mine got accepted, some weren't... but *all were looked at as to how they "fit" and how they worked towards the future... Plus 1 from me, said it better than I could.
– Solar Mike
Feb 24 at 21:22
4
He has 100% trust from everybody, and your current level is apparently quite low, even less than the benefit of the doubt. . Also doesn't sound like he's open to ideas that are not his own, too the point of how code style stuff is done. You have everything against you. Get out.
– Fabio
Feb 25 at 7:24
add a comment |
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...
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
Feb 26 at 6:27
add a comment |
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:
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.
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.
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.
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!
add a comment |
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.
I think leaving during probation period is still better explainable with "it was not a good fit" than leaving shortly after probation. The probation period isn't only there to access the employee, but also the employer. (In case OP wants out ASAP). This may be culture dependend though.
– Rhayene
Feb 25 at 12:38
add a comment |
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:
- 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).
- 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.
add a comment |
"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:
Brace yourself, and accept the condition, considering if you need (have) to keep your job. I believe karma is real.
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?
add a comment |
"which was not communicated to anyone"
- anyone, or you?
He's not gained this trust because he hides what he's doing, or because he doesn't deliver. I would suggest that it's just you he doesn't feel the need to explain things to YOU - which leaves you in the dark in multiple different ways.
IF you plan to stay there, then the solution is to improve communication in your team; find out why he thinks you were so wrong, and explain to him that unless he communicates plans with you, you will never be productive.
It sounds like he's new to managing teams and projects; but is a much trusted member of the company. Attempting to push him down will only backfire, and you never know maybe his reasoning will make sense.
add a comment |
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
6
I don't disagree with the sentiment, but I'm not sure how it can be considered an answer. It would be helpful if you could flesh this out into something that provides an action that can be taken, or other solution to the situation.
– Booga Roo
Feb 25 at 6:45
add a comment |
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.
add a comment |
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
18
The way that "senior" is behaving made me want to write the same thing about getting out. I worked with one guy and it was an absolute dream - we discussed, put forward ideas : some of mine got accepted, some weren't... but *all were looked at as to how they "fit" and how they worked towards the future... Plus 1 from me, said it better than I could.
– Solar Mike
Feb 24 at 21:22
4
He has 100% trust from everybody, and your current level is apparently quite low, even less than the benefit of the doubt. . Also doesn't sound like he's open to ideas that are not his own, too the point of how code style stuff is done. You have everything against you. Get out.
– Fabio
Feb 25 at 7:24
add a comment |
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.
18
The way that "senior" is behaving made me want to write the same thing about getting out. I worked with one guy and it was an absolute dream - we discussed, put forward ideas : some of mine got accepted, some weren't... but *all were looked at as to how they "fit" and how they worked towards the future... Plus 1 from me, said it better than I could.
– Solar Mike
Feb 24 at 21:22
4
He has 100% trust from everybody, and your current level is apparently quite low, even less than the benefit of the doubt. . Also doesn't sound like he's open to ideas that are not his own, too the point of how code style stuff is done. You have everything against you. Get out.
– Fabio
Feb 25 at 7:24
add a comment |
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.
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.
answered Feb 24 at 21:18
John R. StrohmJohn R. Strohm
6,01722125
6,01722125
18
The way that "senior" is behaving made me want to write the same thing about getting out. I worked with one guy and it was an absolute dream - we discussed, put forward ideas : some of mine got accepted, some weren't... but *all were looked at as to how they "fit" and how they worked towards the future... Plus 1 from me, said it better than I could.
– Solar Mike
Feb 24 at 21:22
4
He has 100% trust from everybody, and your current level is apparently quite low, even less than the benefit of the doubt. . Also doesn't sound like he's open to ideas that are not his own, too the point of how code style stuff is done. You have everything against you. Get out.
– Fabio
Feb 25 at 7:24
add a comment |
18
The way that "senior" is behaving made me want to write the same thing about getting out. I worked with one guy and it was an absolute dream - we discussed, put forward ideas : some of mine got accepted, some weren't... but *all were looked at as to how they "fit" and how they worked towards the future... Plus 1 from me, said it better than I could.
– Solar Mike
Feb 24 at 21:22
4
He has 100% trust from everybody, and your current level is apparently quite low, even less than the benefit of the doubt. . Also doesn't sound like he's open to ideas that are not his own, too the point of how code style stuff is done. You have everything against you. Get out.
– Fabio
Feb 25 at 7:24
18
18
The way that "senior" is behaving made me want to write the same thing about getting out. I worked with one guy and it was an absolute dream - we discussed, put forward ideas : some of mine got accepted, some weren't... but *all were looked at as to how they "fit" and how they worked towards the future... Plus 1 from me, said it better than I could.
– Solar Mike
Feb 24 at 21:22
The way that "senior" is behaving made me want to write the same thing about getting out. I worked with one guy and it was an absolute dream - we discussed, put forward ideas : some of mine got accepted, some weren't... but *all were looked at as to how they "fit" and how they worked towards the future... Plus 1 from me, said it better than I could.
– Solar Mike
Feb 24 at 21:22
4
4
He has 100% trust from everybody, and your current level is apparently quite low, even less than the benefit of the doubt. . Also doesn't sound like he's open to ideas that are not his own, too the point of how code style stuff is done. You have everything against you. Get out.
– Fabio
Feb 25 at 7:24
He has 100% trust from everybody, and your current level is apparently quite low, even less than the benefit of the doubt. . Also doesn't sound like he's open to ideas that are not his own, too the point of how code style stuff is done. You have everything against you. Get out.
– Fabio
Feb 25 at 7:24
add a comment |
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...
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
Feb 26 at 6:27
add a comment |
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...
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
Feb 26 at 6:27
add a comment |
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...
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...
edited Feb 25 at 8:32
answered Feb 24 at 23:28
DigitalBlade969DigitalBlade969
1
1
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
Feb 26 at 6:27
add a comment |
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
Feb 26 at 6:27
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
Feb 26 at 6:27
Comments are not for extended discussion; this conversation has been moved to chat.
– Snow♦
Feb 26 at 6:27
add a comment |
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:
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.
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.
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.
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!
add a comment |
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:
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.
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.
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.
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!
add a comment |
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:
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.
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.
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.
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!
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:
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.
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.
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.
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!
edited Feb 25 at 12:03
Peter Mortensen
57747
57747
answered Feb 25 at 6:13
Shadow1349Shadow1349
911
911
add a comment |
add a comment |
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.
I think leaving during probation period is still better explainable with "it was not a good fit" than leaving shortly after probation. The probation period isn't only there to access the employee, but also the employer. (In case OP wants out ASAP). This may be culture dependend though.
– Rhayene
Feb 25 at 12:38
add a comment |
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.
I think leaving during probation period is still better explainable with "it was not a good fit" than leaving shortly after probation. The probation period isn't only there to access the employee, but also the employer. (In case OP wants out ASAP). This may be culture dependend though.
– Rhayene
Feb 25 at 12:38
add a comment |
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.
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.
edited Feb 25 at 12:03
Peter Mortensen
57747
57747
answered Feb 25 at 5:40
linksassinlinksassin
1304
1304
I think leaving during probation period is still better explainable with "it was not a good fit" than leaving shortly after probation. The probation period isn't only there to access the employee, but also the employer. (In case OP wants out ASAP). This may be culture dependend though.
– Rhayene
Feb 25 at 12:38
add a comment |
I think leaving during probation period is still better explainable with "it was not a good fit" than leaving shortly after probation. The probation period isn't only there to access the employee, but also the employer. (In case OP wants out ASAP). This may be culture dependend though.
– Rhayene
Feb 25 at 12:38
I think leaving during probation period is still better explainable with "it was not a good fit" than leaving shortly after probation. The probation period isn't only there to access the employee, but also the employer. (In case OP wants out ASAP). This may be culture dependend though.
– Rhayene
Feb 25 at 12:38
I think leaving during probation period is still better explainable with "it was not a good fit" than leaving shortly after probation. The probation period isn't only there to access the employee, but also the employer. (In case OP wants out ASAP). This may be culture dependend though.
– Rhayene
Feb 25 at 12:38
add a comment |
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:
- 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).
- 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.
add a comment |
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:
- 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).
- 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.
add a comment |
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:
- 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).
- 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.
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:
- 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).
- 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.
answered Feb 25 at 10:08
P. HopkinsonP. Hopkinson
86418
86418
add a comment |
add a comment |
"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:
Brace yourself, and accept the condition, considering if you need (have) to keep your job. I believe karma is real.
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?
add a comment |
"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:
Brace yourself, and accept the condition, considering if you need (have) to keep your job. I believe karma is real.
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?
add a comment |
"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:
Brace yourself, and accept the condition, considering if you need (have) to keep your job. I believe karma is real.
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?
"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:
Brace yourself, and accept the condition, considering if you need (have) to keep your job. I believe karma is real.
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?
edited Feb 25 at 12:03
Peter Mortensen
57747
57747
answered Feb 25 at 4:37
RPPRPP
192
192
add a comment |
add a comment |
"which was not communicated to anyone"
- anyone, or you?
He's not gained this trust because he hides what he's doing, or because he doesn't deliver. I would suggest that it's just you he doesn't feel the need to explain things to YOU - which leaves you in the dark in multiple different ways.
IF you plan to stay there, then the solution is to improve communication in your team; find out why he thinks you were so wrong, and explain to him that unless he communicates plans with you, you will never be productive.
It sounds like he's new to managing teams and projects; but is a much trusted member of the company. Attempting to push him down will only backfire, and you never know maybe his reasoning will make sense.
add a comment |
"which was not communicated to anyone"
- anyone, or you?
He's not gained this trust because he hides what he's doing, or because he doesn't deliver. I would suggest that it's just you he doesn't feel the need to explain things to YOU - which leaves you in the dark in multiple different ways.
IF you plan to stay there, then the solution is to improve communication in your team; find out why he thinks you were so wrong, and explain to him that unless he communicates plans with you, you will never be productive.
It sounds like he's new to managing teams and projects; but is a much trusted member of the company. Attempting to push him down will only backfire, and you never know maybe his reasoning will make sense.
add a comment |
"which was not communicated to anyone"
- anyone, or you?
He's not gained this trust because he hides what he's doing, or because he doesn't deliver. I would suggest that it's just you he doesn't feel the need to explain things to YOU - which leaves you in the dark in multiple different ways.
IF you plan to stay there, then the solution is to improve communication in your team; find out why he thinks you were so wrong, and explain to him that unless he communicates plans with you, you will never be productive.
It sounds like he's new to managing teams and projects; but is a much trusted member of the company. Attempting to push him down will only backfire, and you never know maybe his reasoning will make sense.
"which was not communicated to anyone"
- anyone, or you?
He's not gained this trust because he hides what he's doing, or because he doesn't deliver. I would suggest that it's just you he doesn't feel the need to explain things to YOU - which leaves you in the dark in multiple different ways.
IF you plan to stay there, then the solution is to improve communication in your team; find out why he thinks you were so wrong, and explain to him that unless he communicates plans with you, you will never be productive.
It sounds like he's new to managing teams and projects; but is a much trusted member of the company. Attempting to push him down will only backfire, and you never know maybe his reasoning will make sense.
answered Feb 25 at 14:16
UKMonkeyUKMonkey
2,526616
2,526616
add a comment |
add a comment |
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
6
I don't disagree with the sentiment, but I'm not sure how it can be considered an answer. It would be helpful if you could flesh this out into something that provides an action that can be taken, or other solution to the situation.
– Booga Roo
Feb 25 at 6:45
add a comment |
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
6
I don't disagree with the sentiment, but I'm not sure how it can be considered an answer. It would be helpful if you could flesh this out into something that provides an action that can be taken, or other solution to the situation.
– Booga Roo
Feb 25 at 6:45
add a comment |
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
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
answered Feb 25 at 2:44
robertmainrobertmain
231
231
6
I don't disagree with the sentiment, but I'm not sure how it can be considered an answer. It would be helpful if you could flesh this out into something that provides an action that can be taken, or other solution to the situation.
– Booga Roo
Feb 25 at 6:45
add a comment |
6
I don't disagree with the sentiment, but I'm not sure how it can be considered an answer. It would be helpful if you could flesh this out into something that provides an action that can be taken, or other solution to the situation.
– Booga Roo
Feb 25 at 6:45
6
6
I don't disagree with the sentiment, but I'm not sure how it can be considered an answer. It would be helpful if you could flesh this out into something that provides an action that can be taken, or other solution to the situation.
– Booga Roo
Feb 25 at 6:45
I don't disagree with the sentiment, but I'm not sure how it can be considered an answer. It would be helpful if you could flesh this out into something that provides an action that can be taken, or other solution to the situation.
– Booga Roo
Feb 25 at 6:45
add a comment |
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.
add a comment |
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.
add a comment |
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 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.
answered Feb 25 at 3:16
bnielandbnieland
2214
2214
add a comment |
add a comment |
36
How do you become a senior developer with 1 year of experience? That alone sounds like a red flag.
– Joe W
Feb 25 at 0:33
18
You are catching close votes. I am inclined to agree with them. What is your goal? Can you state it clearly? Otherwise this is just a rant.
– bruglesco
Feb 25 at 1:42
7
The answers you have so far are speculative; please formulate a direct question. It will make it just a bit more clear. :) I'll also add a little note here that you shouldn't need the manager to be technical to understand that you can contribute new ideas the senior lead hasn't; that strikes me as somewhat odd.
– person27
Feb 25 at 5:34
1
See similar question - I think the advice is also quite relevant: workplace.stackexchange.com/questions/40352/…
– ForOhFor
Feb 25 at 8:30
7
Not really an answer, but a relevant footnote: "sabotaging" implies intent to harm you (professionally). While I agree with the majority here that the senior's behavior is unacceptable; I strongly urge you not to call it sabotage when you talk to your employer. This suggests that you're taking it personally and elevates it from a professional conflict to a personal one; which can detract from your professional argument.
– Flater
Feb 25 at 8:48