So without really having any insight about what's up here, I have two pieces of advice.
Ask a lot of questions to understand why he thinks what he thinks. The job is not to explain to him why he's wrong; the job is to ask enough questions that you understand why he's reached some specific conclusion.
And focus on getting things done. Forward progress tends to get everyone aligned and give you something specific to talk about that's productive. If in the "blah blah blah" he's telling you 'this will never work' then you have proof positive that he's wrong. Great. If in the "blah blah blah" he's telling you that your solution is not re-entrant and it's going to crash then you are going to find out he's right.
This should be a checklist of possibilities to consider anytime there is office conflict.
To be fair to the soothsayers, you could find out you're wrong about reentrancy after the code is in production for two years and some records in the database start having garbage sporadically.
There are some categories of problems where results are king, and some where humility is wiser.
It's just so hard to advise here without knowing more about OP and the senior colleague. (That should be the title of the novel "OP and the Senior Colleague.")
And be careful how you use your language, just some points that got my attention:
- "who thinks he's my manager" -- You don't really know what he thinks.
- "like he knows everything(in reality he doesn't..." -- You don't really know what he knows.
- "He can't understand simple logic" -- I'm sure he can understand "simple" logic.
- "he acts like I don't know anything" -- People act differently, but you are the one who gives meaning to their actions. If you don't like him, everything he does might seem bad to you.
EDIT: Formatting
> "who thinks he's my manager" -- You don't really know what he thinks.
You're taking common turns of phrase and interpreting them literally. Saying someone "thinks X" usually just means that they "behave as if they think X". The same goes for the rest of your corrections.
I think you’re right in that people usually intend “thinks X” to mean “behaves as if they think X.” But what I typically try to do is to share behaviors that make it harder to interact and to work on that. It’s pretty rare that I care that someone “thinks they know everything,” but more common that “they did not spend time listening to my idea and made a judgement without all the info I could share.”
The latter helps me try to create situations where I can share info to inform their decision. Yadda yadda yadda.
Everything is new, but everything is old. And around and around it goes. The funny thing about history is that as much as we move forward, so much of our reality is just a repeating pattern of the past.
Nobody knows anything and we're all just making it up as we go along. For my wealth of knowledge and experience, which is considerable, there is still so much I don't know. There's still so much you don't know and there's still so much this junior developer doesn't know. But we all have something to teach and something to learn. History has shown though that the more junior you are, the less likely you are to be aware of how much you don't know and the bravado of youth is still very much in play. There's a reason the phrase "I wish I was still young enough to know everything" was coined.
Of course, it doesn't help to tarnish everyone with the same brush. There are those who bring genuine insight, but they are so few that it's a shock when they do. It's not unheard of, but I'd be surprised if this junior programmer has any clue what goes on in the heads of his colleagues and is projecting their thoughts based on a complete lack of awareness of a much larger context in their heads than in his own.
Communication is the key to resolving this issue. Nothing more.
That's not to say there aren't those who are manipulative and untrustworthy, there are many of those too - with plenty of ego to overcome or sidestep. It's something to be cautious of, but not everyone is as they first appear - especially in an industry where social skills aren't exactly a strong suit.
I've never had so many things make so much more sense to me now, than at any point I was ever given advice in the past.
I've also been through a little bit of management training... The Arbinger Institute books (been through 2) have been pretty good in this regard too. "Leadership and Self Deception: Getting Out of The Box" as well as "The Outward Mindset"
You can't know that for sure.
If, for example, someone is constantly making claims that are factually incorrect, and they are very confident and arrogant in the way they assert these claims. If they are always (factually incorrectly) telling others they're wrong about topics. If they always have to give their view on a topics, even if it's not necessary. In cases like those, it's pretty fair to say they talk like (the OPs actual phrasing) they know everything when they don't.
> - "He can't understand simple logic" -- I'm sure he can understand "simple" logic.
On the basis of what? Plenty of people can't understand simple logic, just like plenty of people have problems with basic maths.
The trick is to deploy massive empathy for him and know that he's displaying sure signs of insecurity.
I'm sure he knows that you know he was laid off. He also is intimidated that you're smarter than he is. But this is life, you'll be continually surrounded by folks that don't know their place and struggle when confronted with "threats" like yourself.
Walk in his shoes for a day and if you feel like it start asking about his past life, his past teams and experiences. Find out about his home life, does he have kids, did he watch Game of Thrones last night?
Don't take people like this seriously, just know that they're hurting inside when their behavior makes zero sense to you.
This is what I do and it works!
Finally know that when you dig deeper, you'll uncover that his actions have nothing to do with you.
To be clear, I'm not saying that the problem is entirely yours, but in most communication problems, the blame lies with both parties. I'd suggest involving a third party (another colleague) in your conversations and allow them to moderate the discussion.
In my experience a third party can quickly see where the communication is breaking down, even when it's not apparent to the two people attempting to communicate.
My former lead got promoted to his position because he was literally the only guy who knew the language they wanted to use. He knew very little about the language and technology but took to the position because he obviously likes status.
The end result is him having "7+ years of experience with <pretty obscure language>", but he didn't even know some of the basics of it. On top of that he has this unfortunate defect/defense mechanism where anything he doesn't understand is automatically bad; even things that anyone versed in the domain would say are better than his homegrown solutions. You end up noticing this a lot, because there is a disproportionate amount of things he doesn't understand.
To put this into perspective: His solutions always involved some kind of raw string interpolation for SQL, even though there were plenty of flexible, good libraries that could safely abstract away issues with SQL query handling. If you asked him about it he'd say it "was hard to use" or some other useless thing.
I stopped working with him even before he left our company and even after we've parted ways I hear stories through the grapevine about people who thought he was a great, experienced developer and how they worked on a project with him and saw the truth.
Sometimes, people really just are garbage developers who somehow skated through on merits they didn't have.
So the best thing to do in those situations is exactly that - show a little patience. Work with him. In time you will either earn his respect (remember it does have to work both ways) or in the worst case you'd have gained enough experience handling him that you'd be ready to progress to your next role as a senior engineer. Perhaps even both. Plus in the process he might even surprise you by demonstrating that he's not so useless after all and in fact his blindspots aren't an inability to grasp simple logic but rather just gaps in knowledge for one specific framework amongst a wealthier repertoire of skills that you are yet to discover.
This is a little like the problems hiring managers face when trying to separate out those who are confident but lack skill and those who are confident because they are skilled. Or even telling apart people who are confident because they think they know what they're doing from those who do know. So maybe think about this as improving your none-technical career building skills?
Lately I started to review much more code than I write. And what I can tell you is that is very easy to fall into the trap of thinking that something is obvious when you spend a lot of time within specific domain, codebase, or technology. If someone can't immediately tell what some straight piece of code does it usually says the code could be simpler or more idiomatic rather then they are ignorant.
While I'm not necessarily saying something's wrong with your code I wouldn't assume he's in the wrong or that he's stupid.
Besides I think it's pretty normal to ask authors about their code when you work with it.
> I am a bit hesitant to work with him because I think he is not very competent and when he do not understands anything, he will simply complain to my manager that its my fault and my manager, being his friend, will listen to him.
Has it ever happened? Don't overthink it, just do your job and provide help to colleagues when needed.
I want to emphasize that this is senior level thinking.
Code needs to be able to be understood by not only the best and worst on your current team, but also for the engineers you hire in X years that may not ask the right questions to the correct people or when the people who wrote it are no longer there.
Unfortunately it's not that uncommon, it happened to me before. The problem becomes worse when the people around (bosses, etc) have no technical knowledge whatsoever, and rely only on job titles to decide who should be in charge of what, and who to trust.
I've seen code written by a senior developer who writes
if some-predicate
// left blank.
else
// do something
end if
That'd be something pretty silly to do. But sadly I've seen enough bad code that this would not surprise me.
It could be a convention to maintain semantic consistency in the predicate so you don't have to randomly flip your brain each time you encounter a new conditional statement.
Ask around. Could at least be a funny story behind it. The great not not of 2014.
Semantically you're not saying "if X is true" you're saying "if X doesn't happen". It's a subtle difference and this format draws attention to it for the Next Developer.
It's also a stub where you can add logging or similar along the normal path without touching the conditional and risking introducing bugs by accident.
Depending on the language or runtime the empty clause will likely be factored out by the optimizer so there's no cost for extra readability and flexibility.
if(!some-predicate)
Maybe it's because you have to do the negation mentally.
But more ideally, it should be done with polymorphism or similar rather than using if..else.
This is almost never the case. Please don't assume people don't know what they're doing, especially to such an extent. I would actually recommend attributing expertise and wisdom to their decisions until proven otherwise.
This particular construct is not a lack of understanding but often used to improve readability, transition code that may be in that block in the past or future, denote the normal vs exception branch, and several other scenarios. Did you ever ask why this person wrote it this way?
One must remember that code is not a paint and a canvas for you to feel like an artist but a documentation for for Next Developer to comprehend. One must write it like a book or some sort of navigation manual, drawing attention of the reader to the important parts and guiding them through intricacies of the requirements and logic.
if ((a and b) or (a and c and not d)) and not e)
orderSubmitted = a and b
orderValid = a and c and not d
orderNotYetFulfilled = (orderSubmitted or orderValid) and not e
if not orderNotYetFulfilled {
# code here
}
The raw de Morgan's transform is only necessary if it's a performance optimization, and in 2019 the conditions for that to be an issue are very, very precise.
There shouldn't be much in-between in 2019 where writing the clauses out this way will have a materially negative impact on one's code, and it should have a generally very positive one.
return (x && y) || (a && b) && !(c != d) //pseudo example of complex condition
Or write a bunch of macros given that if you're on embedded 99.999% probability you're writing C.
https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
>> 'In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."'
I've met plenty of people like that. To tell you the truth, it was SO BAD that had I not seen it with my own eyes, I would have difficulties believing that people can be so incredibly incompetent.
I've also met "experienced" people, coming from the best "elite" schools in France (I'm french), that were unable to code their way out a paper bag, but were somehow working in programming or technical team roles. It's always stunning when you meet people who come from high studies, that involve quite a lot of programming, but who know NOTHING, how can they pass the exams is a real question, that puts in resious doubt the value of those schools. Two such people (technical managers) were fired for gross incompetence (after having us lose plenty of time & money). Unfortunately, many others (at various levels) managed to stick around and made things HARD for everybody else.
But the worst is when those people are also JERKS (or worse), as in the OP example. I've suffered A LOT because of that, as have my coworkers. And working as a contractor makes it super hard to get rid of them (though I managed it in one case).
Either way, focus on establishing your relationship with your manager. The manager assigns you tasks, not the senior colleague. If you disagree with your colleagues input, follow up with the manager to make sure your approach is correct.
Also, see if other colleagues are having similar problems (if your team is larger). If you are correct, you will probably find everybody on the team is simply ignoring them.
1) Leave ASAP
2) Take this as an opportunity to learn something which is really common with (senior) SW developers
I am not gonna tell you that (2) is easy. It's actually extremely hard, it can get even harder than what you think right now. However, time-box your learning experience: how long before you leave? how long before you have a nervous breakdown? In the meantime, try to learn as much as possible about communication with this difficult colleague. Some resources you might want to use are
- Nonviolent Communication: A Language of Life
- Getting to Yes: Negotiating an agreement without giving in
- Difficult Conversations: How to Discuss What Matters Most
Then you can follow any other advice given here, like talk to your manager, etc. However, be cautious there, especially when talking about someone that has already some sort of power.
Also, beware that even after you have mastered all the great communication skills you want, etc., you might still not get what you want. It takes a lot of effort, trial and error, and patience. At a certain point, if you see it's not worth, in the worst case, you've learnt something.
First, I would have to figure out what he was asking. Then from there (through a series of probing questions presented in a casual conversation style) I would get to what he actually wanted to accomplish. This was often cloaked in secrecy, mostly because he didn't realize that details are important. Finally I would get to what he actually needed.
So I would ignore what he said he wanted, give him what he needed, but dress it up in a way so that it looked like it was what he wanted. I can't tell you how much better of a solutions provider and communicator I've become out of that ordeal.
If all other factors properly calculated, the current job position is worth it, keep it, take it as a learning experience... otherwise leave.
But beware. Companies and people are complex, it is part of your job to deal with situations as above. If you always run away from problems like this, you won't improve and grow.
Also, don't have the expectations that you will manage to fix this problem tomorrow by some magic comment from HN. The only person that can: 1. handle this, 2. fix this. Is you. Maybe read books on communication and people problems. But the final attitude comes from you. Take responsibility for it.
And this might take time. But once you manage to handle this situation, you will have grown. I'm sure.
Also a side note: it could be that he's good, but you don't like him for some weird reason. I've seen much more developers fighting over this way. Most of people nowadays have a great deal of problem of dealing with authority and try to bend the universe in their head to make sure that they are the victim of the senior+friend from manager.
How to Win Friends and Influence People by Dale Carnegie is still a timeless classic that provides an immediate and permanent buff to self-awareness and social navigation.
Remember that when a company wants to keep someone, they will tolerate no end of ridiculous behavior. When they don't care or want someone out, they tolerate nothing, or invent things not to tolerate.
There is a personality type who cherry picks easy problems from other peoples queues and then front runs the news of solving them. They create a race to the bottom environment where to survive in the org, people start competing to claim credit for insignificant problems and create pressure to neglect the valuable and hard ones. It also creates "turf," instead of collaboration.
There is a lot of advice that will say, "things are dynamic, be yourself, be authentic, collaborate," but what advice really means is, "no, the situation isn't changing, we're not making the jerk accountable, you are the bottom dog."
A manager who lets this happen is also encouraging it. Maybe the culture is such that it doesn't matter, and the jerk has protection higher in the chain, but the effects are clear.
In principle, you can always ask a manager to clarify roles and rules. In conversations, you can always ask that colleague for clarification of principles, e.g. "thanks for the insight, and while I balance it with other priorities, to be clear, do I have a reporting relationship to you, or has your manager given you direct accountability for this work?" In practice, this can alienate people by asserting your interest and forcing a decision, and they may resent you for it.
If they do, find a new job, there are better places.
These people are the worst. I wonder what inspires people to waste their time like this instead of learning to do things the right way and making a real contribution. Low self esteem and bad morals?
Instead, you could phrase these concerns like:
"Hey, I've been having a bit of a frustrating time working with X. For someone of his experience, I thought he would be familiar with some of the simpler parts of our work, like Y. But in practice he has needed assistance there. It feels like he has been slowing the team down, rather than speeding it up.
I also feel like his attitude isn't the most productive. When we were discussing issue Z the other day, he was very insistent about an issue where he ended up being incorrect, and wasting a lot of the team's time.
I feel like this colleague is used to working in an area where he is very experienced, and isn't used to this sort of project. Maybe you could talk to him about it? It's hard for me to bring this up since he's so much more experienced than me. As it is, I feel like I would get more work done if I wasn't working together with him."
In six months everything will have changed.
Also, read "The Prince" if the really want to know how to survive office politics.
What this will do is to allow the existing communication pattern to be accepted as a norm and it will be extremely difficult to change in the future. Instead, with a little explicit pushback the OP can express his confusion/dismay at other dude's behavior, set the boundaries and nip this in the bud. Literally, just interrupt him mid-sentence and say - Listen, something's been bothering me. I really don't understand why you are talking down to me. I don't like it and I find it inappropriate.
But as others have said, you clearly have a communication problem, because you both think the other one is an idiot :)
My only regret in hindsight is not just ignoring them.
Things do move so quickly in the workplace that it won't be long till he or you is gone or some other circumstance comes up.
I don't think it's always in your interests to confront problem people. Just nod, pretend to listen then do whatever you want.
Pragmatism man, that's were it's at.
Given the circumstances -- OP being new to the company and the other person being "friend of manager" -- I would say it would be really difficult for OP to pull off a push back. The advice to put your head down and smile can work wonders when used at right occasion (which I feel like this is one).
See if you can tell the story from your colleague's perspective. Perhaps it might go something like this: "There's this one junior employee who seems to speak as if he knows everything, but in fact his fundamentals are lacking, so all I can do is set them straight as quickly as I can."
The rest of it sounds simply like arrogance. Simply said, it is quite common in software world. To me, it worked couple of times to say that "I know", but it depends on exact personalities involved. Be careful to not underestimate him just because he is arrogant and annoying.
Also, what does "act like manager" means? Is he assigning you tasks and checking time sheets? Bossing you around?
Awesome! Mission accomplished!
You may believe you are smarter than him and a better developer and even a better human being... it doesn't matter because you work somewhere that allows some nepotism and are willing to continue to pay "Senior" developers who aren't that good.
If you like the job/company, suck it up and just ignore this person whenever you can (kill them with kindness and patience when you can't) while improving your position through adding value and doing your job better than can be ignored.
If you don't like it, then keep that resume shiny and make sure you do a little more vetting of your employers in the future.
Be humble, be quiet, listen and learn.
I’ve been doing this $a_long_time and every time I start a new job I act like a junior, no nothing developer until I get both the political and technical lay of the land.
Perhaps I am salty because I am in the same situation as the OP, albeit with a little bit more experience.
I have one of these senior developers in my current team, who has about 10 years of experience. He consistently tries of evade code reviews, probably because a good part of whatever he writes is mind boggling gibberish (dead simple things like proper handling of database connections are not done). Most of the features he has developed are buggy incoherent messes that require debugging every other week. He might might be the most brilliant developer in this hemisphere, but the code he writes and the design decision makes it seem like might be a mentally disabled chimp. He the second oldest guy in the team after me, but he isn't able to answer literally any question related to whatever we've built. Worse, he doesn't admit that he doesn't know it, instead he spouts bullshit which is misleading or outright wrong and waste hours of others time.
Even the other so-called senior developers aren't any better, most of them do the bare minimum to keep things working. The situation is so bad my manager has started assigning the bulk of the development/deployment work to me and 2 other devs, since nobody else seems to care about anything at all.
So yeah, we don't know what situation OP is in (he might be at fault too), but outright dismissing his complaints based on his lack of experience isn't exactly right.
I don't know what your work situation is, but when you start referring to coworkers with language like this, it immediately makes me wonder if the issue is with you, not the person you are referring to.
If your code reviews feature this kind of vitriol, I'd probably avoid them, too.
I think that might also come with experience. I do the best I can within the political, business, and technical constraints of the company, keep my resume updated, and watch money appear in my account twice a month.
My job is solely a method of supporting myself.
Someone told me a long time ago.
“Either change your environment or change your environment”
> “Either change your environment or change your environment”
Atleast we agree on this, I've given up on this job, looking for new one. Perhaps the next one won't be so bad.
Don't go through your life like this. Here is what to do:
- make sure your logic is sound
- present your case
- be kind in your demeanor but confident in your position (until proven otherwise)
Nothing else matters.
If it is only the kind of hierarchical conflict that rise in day to day conversation and doesn't actually interfere with work, you should give it little attention. Stand your ground with arguments and reason, and if some fails that means he was right in the first place to criticise and you can use the opportunity to be a better professional.
But if he is actively hindering you unfairly you have to do something about it smartly. Can't really advise as to what specifically, but talking to other people, finding other coworkers with the same problem is a good start. And also maintaining good relations with his superiors is a nice idea too. Because if this is the case it is likely he is doing this to other people or other coworkers will notice this unfair relation.
In any case, harsh positions are good opportunities to be a better professional and grow in social skills, if you so choose to see this as an opportunity for self improvement.
There is a wide range of discussions with your manager about another employee between work dynamic and friend bashing. It's initially concerning that you are unaware of this, but it is part of learned working in a political environment.
You want to objectively present one objective thing to your manager about your troublesome colleague at a time. This is the opposite of saying that you want the troublesome colleague fired and more asking that your manager find a way to coach him and you to work together, and specifically, to look out for your trouble situations.
I'd start with "senior colleague is making manager type demands or judgements from me and I need direction on how to prioritize your [manager's] requests over his."
The next 1:1 I'd bring up, we had a disagreement about x logical piece, and went with x, my idea had merit, how can I help push my idea forward next time.
The other jr developer actually had a nervous breakdown due to the bullying and had to go on medical leave and the sr. developer eventually quit before he got exposed and went to another company doing the same thing (I know ppl there)
My advice in these situations is to stand up for yourself, DOCUMENT what you are doing and even any back and forth between you two (emails). If it's really bad maybe even set him up to fail by not bailing him out constantly. I was able to get the guy under control by threatening to not hold his hand on certain tasks that he had to complete under deadline, unless he changed his attitude
Second... when you are explaining code, unless it is `1+1` don't assume that it's simple logic. I've seen people freak out seeing code like this.
Object
.entries(obj)
.filter(([k,v]) => /foo\-/.test(k))
.reduce(([k,v], o) => ({...o, [k]: v}))
Third... if, and that's a big IF you are right... be considerate in your communications.
You may or may be able to not work with someone... but if you're a junior, and they're a senior.. they may not be your direct manager, but they are senior and may have a more critical understanding of a project and the company as a whole.
In 25 years in software development... I've met literally one person that was too arrogant for me to actually work with and one that was actually too ignorant for me to work with. This is out of hundreds of people I've interacted with in the workplace regularly.
Reflecting back on it. In most cases, the issue was me.
Object
.entries(obj)
.filter(([k,v]) => /^foo\-/.test(k))
.reduce((o, [k,v]) => ({...o, [k]: v}), {})If you have overlap in your work with him where you are forced to defer to his decision-making for whatever reason, then just make your dissent known (and documented in email or something like a public meeting).
If the issue is purely attitude and doesn't actually affect your work and he's not making decisions that directly affect you, then this really isn't a big deal. You can just listen and shut up and say thanks for his input and ignore him. You won't always mesh with everyone at work, that's just a part of life. And if he's not directly affecting you that's the absolute best case scenario if you don't really get along with someone.
If whatever he's doing actually affects work, you can also strategically bring this up to a higher up and raise concern by saying something like "[x] is saying we need to do this, and I know he has more experience than me, but I feel strongly that the project/company would be better off doing this instead..." and explain it and make sure you are humble when doing so and acknowledge that there may be other business reasons why they haven't chosen that path that you might not be aware/privy to.
But it really sounds like he's just annoying you with his attitude so I would simply ignore it and not let it get to you. Let your work speak for itself or try to befriend him since he's friends with the manager (if you want to play office politics).
I could tell such a person that I'm busy and have no time for a conversation. Without explaining him what his personal traits bothers me. I would say something like "I need to work now, have no time to chat, sorry, maybe next time".
If it is unacceptable for some reason, I would tell it without words, by playing a role of busy person with his mind on something else, honestly trying to be nice but having no spare mental capacity to do it good. At the same time I'll try to aviod to show him any emotion, because it may reinforce his behaviour. Just imagine that there are a lot of things going on your mind, you are thinking right now some complex thoughts that are not related to the conversation with this guy, and the conversation doesn't really prevent you from thinking, despite you are trying (not very hard) to be nice.
A few months of such a one way conversations and he will find something else to teach.
The problem is, it can go in reverse. You can have a senior dev whose really good, but has incredibly poor people skills and thinks they can solve everything and gets extremely irritated when you struggle on something. Not everyone knows the latest stuff and its often better to sit down and help them through their struggles rather than let it fester. They will respect you a lot more if you approach it in a neutral matter rather than just bad mouthing them on hacker news.
From the way you respond to comments that only support your position, it sounds like you've made up your mind.
However, one of the hardest things I had to learn in the professional world was active communication. Making every effort to let people know what I was doing and explaining, in detail, what I had concerns about. Sure, it takes a lot of time, but it helps immensely.
A) 'his previous team laid him off' <- obviously some issue
B) 'he's a friend of my manager' <- why he was not fully laid off
2) I have been in your shoes, or similar a few times. Often they have been assigned as my boss. I have also been in the opposite where the junior thought they knew more, but that is a different story.
I see 3 possible paths:
1) Expose him as a fake - this will require you to enlist a senior person whom others respect. Most likely from the group he left.
2) Leave - this can be to another company or to the group he came from. They would be sympathetic to your cause, and if HR is not run by idiots, turn up a red flag to a problem.
3) Suck it up - I did this once, not again.
* They don't tell them what they mean by lead and
* They don't tell the team that they have a new leader
Yet another example of just how bad telepathy is for communication, and we should probably stop trying to use it.
I would advise scheduling a short meeting with the 'real' manager and saying that you're having difficulty understanding how best to collaborate with XYZ. Mention that you don't know if XYZ has the mandate to override decisions made by manager and shit will be made clear _real_ fast to both of you.
> I am junior and new in this company!
If you are young, it is quite easy and quick and sometimes deserved to think you don't know. He is being nice or projecting his own youth experience on you, where he learned very slowly and knew nothing at the start.
It you teach him or correct him, he will dismiss it and call it young person's folly.
It will take some time to get him to understand your competency level. And when you do there is no gain to be had.
I don't have advice beyond that.
Don't reveal that you don't think he doesn't know much.
I run a free mentoring service and I’d be happy to talk 1:1 live. It’s technically for managers, but feel free to sign up anyway. I’d love to help.
If there are enough of them he should get the point. If not he is not a good boss and your best option is to switch jobs (or move within the company if that is possible).
"who thinks he's my manager and talks in a way like he knows everything"
If other person's thinking and talking irritates you - the best way is not to respond. Ignore and he moves on.
If you eager to convince him that his way of thinking is not the right one - i think you got a bigger problem.
I find this is effective and saves a lot of face. You might learn a few things and/or after a few times where he is wrong and you’re right he (and everyone else) will start to solicit your opinion from the get-go.
Now I'm older and the solution is to empathise and work out any differences calmly.
Both solutions have their pros and cons. Take your pick :)
Political power isn't something that always follows written rules.
At one company, I know the managers secretary is effectively the manager despite being lower than everyone in the org chart.
My favorite anecdote surrounding that is when a team member was highly frustrated, and send an email to our boss' boss (the CIO), explaining the frustration. The CIO forwarded it right back to our boss with a three word response: "Fix your employee."
I'm not saying he was the greatest CIO ever, but it does show that the results might not be what you expect or desire.