I have a senior colleague who thinks he's my manager and talks in a way like he knows everything(in reality he doesn't and is transferred to our team because his previous team laid him off). He can't understand simple logic and I have to explain him simple logic and then he acts like I don't know anything. I can't complain to my manager as he's a friend of my manager and I am junior and new in this company!
It's hard to know how to comment on this because there's a huge range in what might really be going on. You might be a bozo. He might be a bozo. You both might be bozos. Or maybe you are both pretty good and both just bad communicators.
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.
+1, though I would add “As frustrating as it may be, it doesn’t really matter who’s at fault because you’ll both end up looking bad if the situation undermines your productivity.”
> 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.
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.
Completely agree. I read your comment as: "There exist OPs so far into the stupid space and senior colleagues far enough into the competent space that good advice may not be immediately apparent to OP, even through the lens of a first implementation." That's spot on and the example you cite is a good one.
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.")
How long have you worked with him? Your language suggest that you are making a lot of assumptions that might be false. This might be related to the fact that you are new and as a junior developer it might sometimes feel like people are against you for some reason. Maybe he actually is like you are describing, but somehow my gut feeling says that you are projecting your own insecurities onto him. I'm not dismissing your claim. Actually, he's a great opportunity to learn how to co-exist with people you don't particularly like.
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.
"If you don't like him, everything he does might seem bad to you" - couldn't agree more on this, that's why I wish reading Pride and Prejudice was a mandatory part of CS.
> "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.
You'd be astonished how many junior developers come into industry knowing nothing more than their technical brilliance (and they may be truly technically brilliant) and thinking they know everything. The fact is when you're starting out, as brilliant as you may be, you have little more than your technical brilliance. 5 years from now, this same junior developer will realize he doesn't know everything and will have a greater respect for everyone he works with... except his juniors who he will probably perceive as thinking they know everything.
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.
I’m sure the sentiment up top is true, but the other side of this is that in technical jobs I’ve had, I’ve driven certain people up the wall by (they would say) not taking them seriously enough. However, these were all fairly arrogant, manipulative people. Humble, trustworthy senior coworkers were always given immediate respect and deference by me. I wonder whether some people don’t have a natural defense mechanism by writing off even good advice and expertise from people they can tell are manipulative and untrustworthy.
That's fair, but often those we perceive as arrogant, especially in the field of engineering have challenges with communication and soft skills. Some never really learn to overcome that. Those that could easily be perceived as arrogant are often saddled with an inability to communicate the bigger picture effectively. This can come off as arrogant until you've spent a few months getting to know them.
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, personally, have quite a few personality quirks... I've been in software development, specifically in web based applications for over two decades. This past year, I've actually worked with someone who has pretty much all of my own personality quirks, but dialed up to 11.
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"
If you're a junior one of the first things to learn in office is to talk, professionally and a whole lot more than you were used to in previous lives. You are pretty much free to vent each and every of these thoughts to the person concerning as long as it's with respect and an attitude of learning. If you don't understand the social dynamics going on - ask. If you think you can do something better than your boss or peers, offer it as a positive suggestion ("I think I'm pretty strong in X, shall I give a first try at this problem?"). Most of OPs thoughts are interpretations. They need to get out of that sphere and into the open.
I’ve found that using precise language and trying to understand actions and motivations instead of assuming, usually incorrectly, what people are thinking helps me to identify common ground and be productive.
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.
While this is true, most solutions to problems are based on changing peoples behavior, not their thinking. Focusing on their thinking, even as a language short cut, isn't productive.
> - "like he knows everything(in reality he doesn't..." -- You don't really know what he knows.
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.
I've been there and I still experience this in life with family, friends and acquaintances.
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.
Once upon a time our team was starting a new project and there were several Senior Engineers including myself working with an offshore team. One of the other Senior Engineers took a very assertive stance as the project got started and was suddenly telling people what to do, assigning work, and generally acting bossy. I asked him to come into a conference room to talk and I told him that I felt frustrated by his sudden assumption that he was in charge of the technical work when the team's previous pattern had been to share technical decisions and apportion work collaboratively.
He responded by saying that our management had actually told him that he was being tapped to serve as the Tech Lead for the project. Our craven management had somehow neglected to inform the other members of the team of the decision. I was so shocked by the dysfunction of that decision that I could only sputter something along the lines of "they should have told us that" and then the conversation ended.
Oh the joys of corporate culture!
I have also experienced something similar. It should never happen, but it does. Before you get too upset, make sure the supposed bossy peer isn't actually your supervisor.
I'm guessing that you two are having a communication problem as it is highly unlikely that a "senior colleague" can't understand simple logic.
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.
> I'm guessing that you two are having a communication problem as it is highly unlikely that a "senior colleague" can't understand simple logic.
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.
same thing here. Today he asked me 'explain this logic' (It was a simple timeout logic for angularjs, pretty obvious if you can google the keyword) but he was literally stuck on it for hours and then asked me to come and explain this logic and what is it doing. He had to add a check around it to make it work for specific function, it's not like I don't like him or anything like that, I like him as a colleague but 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.
> Today he asked me 'explain this logic' (It was a simple timeout logic for angularjs, pretty obvious if you can google the keyword) but he was literally stuck on it for hours and then asked me to come and explain this logic and what is it doing.
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.
> 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.
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.
Why would it be your fault? Is his assignment to understand what you’re doing? If yes it sounds like you hesitate to play your role in this relationship. Is his role to work with you on a codebase new to him? Similarly you need to help him no matter his seniority. I Know sometimes having people lifting the veil of your code can be intimidating but if I were your manager that would be my first suspicion if I heard complaints in the context of the relationships outlined above, i.e. that you have concerns about the quality of your work. I might be wrong, but this is an anecdotal perspective to keep in mind before you escalate.
He might be threatened by yourself. Remember that technology moves at a fast pace - particularly with front end web development - so the bread and butter skills he learned might have been deprecated with the tools that you now consider to be bread and butter. In which case he might still be capable but feeling insecure and just needs some patience and handholding.
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?
> it is highly unlikely that a "senior colleague" can't understand simple logic.
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).
> it is highly unlikely that a "senior colleague" can't understand simple logic
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.
Textbook enterprise development, office politics and connections trumps competence and contribution. Non programmer tech leads / seniors devs / architects are very common.
> I'm guessing that you two are having a communication problem as it is highly unlikely that a "senior colleague" can't understand simple logic.
I've seen code written by a senior developer who writes
if some-predicate
// left blank.
else
// do something
end if
Because it's apparently too hard to work out how to invert logic. It's a pattern I've seen in our code base enough that I've started calling it 'if-meh-else'
> Because it's apparently too hard to work out how to invert logic.
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?
I've written logic like to draw attention to the fact that the ELSE block is the exception.
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.
Do you really think they don't know how to do one of the most basic logical operations in all of computing?
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.
>> '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 don't know if you have read Code Complete. They kinda explain there why such a code would make sense. I've written constructs resembling this many times and got them through rigorous PRs with quite experienced and senior people.
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.
When I have an if clause that is too complicated to work out how to correctly invert it (because while I understand de Morgan's just fine, it can get very detailed), I find it far preferable to start factoring out the expression, e.g. if I need to invert,
if ((a and b) or (a and c and not d)) and not e)
should be something more like
orderSubmitted = a and b
orderValid = a and c and not d
orderNotYetFulfilled = (orderSubmitted or orderValid) and not e
if not orderNotYetFulfilled {
# code here
}
Ideally, a through e are also named something reasonable enough that the variable declarations read cleanly.
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.
In most cases I'd expect so. The rare cases I was thinking of was on the order of "I'm on an embedded system using a crappy compiler and I can't change it and I literally can't afford extra bytes for boolean values the compiler won't optimize away", and on the other end, "I'm in the cloud and my code has confused the optimizer and I have to code this inner loop incredibly carefully because it's going to be called several billion times per second". Maybe the odd other corner case here or there.
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.
Often when I use this, it's to make it explicit that the normal/common case is met and the other clause is truly exceptional.
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.
That could be for readability or some weird convention to make the code more streamlined? I've also seen it done that way so there could be a reason behind it.
something I can think of is that at first the if-branch did do something, then later it got commented out. And later again someone deleted the commented-out code instead of rewriting it.
That'd be something pretty silly to do. But sadly I've seen enough bad code that this would not surprise me.
There may be something going on behind the scenes; consider that the senior colleague may have been asked by your manager to mentor you and make sure you stay on track or may have been told that they need to show "leadership" before they can get promoted to team lead.
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.
Agreed. Work with your manager. If you can't trust your manager to help you, consider finding a healthier situation. Bad teamwork makes people miserable and can actually stunt career growth.
Without downright complaining, you should talk to your manager. Friend or not it is his role to make sure that everything in the team goes smoothly and people get along with one another or at least can work together. If you don't provide him with the tools (i.e, the information) he needs to do that, then he'll just have to find other metrics to explain poor performance. And if that senior member is a hindrance to your work (make you redo stuff multiple time or through convoluted ways), then you will look like the "weak link".
Understand, the goal is not to fire that person, or you for that matter, is to find ways to make you work together. This can be by putting you in different area of the application for instance, so you don't work on each other's toe. Or reminding him than senior does not mean manager and he shouldn't tell you what to do. Or maybe you're actually the problem, and he will have to teach you a few things so that everything run smoothly.
Ultimately, if nothing works, you might have a fundamental difference on how to approach code than the rest of the team. For instance, on party might think performance is the most important thing, and should be seeked, even if it means reusability of the code, while another party think otherwise.
Some might like lean more on the overengineering side of the scale while another might lean more on the hacking quickly side of the scale.
If that's the case, being the new member and more outsider, you will have to either adapt your position or leave.
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.
I had a manager once, that most of the organization thought was an incompetent hardass. However I just treated him the same way I would any computer API I had to interact with (although a rather buggy, undocumented API).
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.
Very wise choice. This will help you in life, not just with this difficult guy.
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.
You can either view it as a learning experience, to handle with him and this situation... or something very bad, such as, it is his fault for being like this and there is nothing you can do. I would rather use the first option.
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.
> Maybe read books on communication and people problems
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.
The OP could be out of line, but there is another factor in play.
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.
“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.”
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?
Talk to your manager, just be polite about it. Don't say things like "this guy talks like he knows everything! his previous team laid him off!" That doesn't seem very considerate.
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."
Go with it. A huge part of experience is learning to work with people you don’t like. Don’t worry too much about who’s whose’s boss. Also try to assess whether he’s trying to tell you something right that you cannot understand yet.
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 :)
A lot of dickheads are that way only if they are allowed to run around unchecked. Nodding and smiling at them is like feeding the trolls, not the best option.
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).
Right on! I'd say try your best to let ego issues pass by and just do your part of the job. His behaviour, however inappropriate, doesn't have to affect you.
Could it be that it's you who doesn't know which way is up? You said it yourself: you're new to the job and the company, so your judgment being off is more likely than everyone else being in the wrong.
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."
You are right but it was a simple one line angularjs timeout function which was used for countdown timer and he was stuck on it and wanted me to explain it to him. I explained and then he was like, ok.
Was it one off situation or repeated pattern? The distinction matters.
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?
I first learned how to make a timed loop for animation in javascript in IE4 when DHTML was new. I'm sure it's a lot different now and I'd need an explanation too. Be happy he wants to know how the new way works. We used to just count to 1000 every loop iteration to slow things down...
If he is senior and friends with your boss in such a way that you can't talk to them (your boss), then he is effectively your boss since he has power over you.
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.
You’re a junior developer. Honestly, you probably don’t know anything besides what you learned in school and you’re finding out that academia is only slightly related to the real world.
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.
This is the kind of bullshit advice that alienates people while they are young. They is no dearth of senior developers who are absolute morons, who have coasted on the other people's work and the only proof of their expertise the $years on their resume.
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.
Heh, maybe it's just the months of pent up frustration that I can't express in real life. Perhaps if I was bit a more abrasive in real life, I'd be more rational here instead of ranting incoherently.
I’ve long stopped getting as emotional and worked up about the goings on at work as you seem to be.
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”
I do my best to keep my head down and mind my own business. But we are in a single team, responsibilities overlap, sometimes I am dependent things this guy does.
> “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.
I also have been doing this $a_long_time and "act like a junior until I get the lay of the land" is the best advice I've heard. I could've done to hear it four or five years ago tbh.
Is your difficult senior colleague assigning work to you? Perhaps in a way that clashes with the priorities set by your manager? If that's the case you should deflect his assignments by saying "more than happy to help, but I need to prioritise this with my manager before working on it." Then discuss relative priorities with you manager. No need for finger pointing or blame storming, and no need to make it personal. Frame the conversation as being all about sorting out competing priorities. If your manager has got a clue he'll see that your senior colleague is introducing dysfunction.
Actually, this one isn't all that hard to figure out. Probably wondering "why" this is the assumption the senior dev is having. The senior dev obviously believes you have been hired to help offload or relieve some of the work going around. What I have seen in this industry over the last 20 years or so is that this may or may not be true. Upper management needs to clear this up- for the senior dev. As for the other issue "can't understand simple logic" consider this is a personality trait for some developers and not a judgement call. There are some developers which require 100% of the information just to get started and they still will act naive because that is who they are. My advice is to not try and change personality traits or spend a lot of time teaching a lesson here because that could take years. Yes, you read that right YEARS and still not get the result desired. The last one "he acts like I don't know anything" probably is more likely "he cannot figure out how to delegate the work". Again, another upper-management thing and not your problem at all. So- either talk to him or "the group" but roles need to be clearly defined. Once this happens you will be onto the next set of hurdles- good luck!
Is his acting like your boss hindering your work? Does he come between you and tasks to be done or somehow take credit for your work, at the same time diminishing you or reporting your work as bad when it is not?
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.
> I can't complain to my manager as he's a friend of my manager and I am junior and new in this company!
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.
I was in a situation like this. Me and another junior developer had to work under a senior developer who repeatedly had to ask us for guidance, took all the credit for everything we did, and called us morons if we couldn't answer questions that he himself couldn't answer.
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
Is it simple? to me, pretty much so, to someone else, maybe not so much. Even more so if the abstractions are custom to a particular library, language or behavior.
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.
From what you wrote, it doesn't sound like there's much of a problem other than you not liking his general attitude. If he was actually instructing you to do stuff like a manager would, that would be something. But it doesn't seem like he's doing that but rather just acting like he knows more than you.
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'm not sure that my social skills is good enough for you to imitiate, but I would do one of the following.
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.
Best advice.
Find another job if you're unwilling to work with this person. Staying there will only make you depressed and its unlikely that they will change for you.
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.
1) for those of you blaming the Poster (happppy), there are 2 things that indicate it is not him, but rather the other person:
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.
Some people have difficult personalities. Usually there are still some thing they are really good at. Try to find out what their strengths are and how you two could complement each other. You don't have to like everybody on your team, you just have to get your work done.
Yep! There are plenty of bullies and/or blowhards out there, always trying to steer the conversation, and they're annoying as hell-- but some of them actually do turn out to be very skilled in certain areas. The rest aren't worth giving the time of day. If you can afford the time & effort to differentiate the two occasionally, though, it could help you.
Ah! I've done this, from the other perspective. What happens is that the senior is asked to "lead the team" by their boss with two major failings:
* 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.
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.
As I was reading the other comments, a tip came to me: speak to your boss that you are getting frustrated at his demeanor where he doesn't give you the credit you deserve. And that he is quick to dismiss.
Don't reveal that you don't think he doesn't know much.
Without knowing a lot more giving, you concrete advice is really challenging. I’d need to pull on your experience for a while to feel like any advice I give won’t be counter productive.
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.
A senior colleague should will interact with you in some ways that are similar to how your supervisor would. That's why there is a distinction of "senior". What exactly that relationship looks like is up to you and your supervisor to determine. Can he task you directly? Are you required to provide him updates on your work? Is he involved in your performance evaluation? Etc.
I think the ideal thing would be to find disagreements where you are objectively correct - where even your boss can see you are right, and then take those to your boss. Don't get emotional.
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).
I default to expressing my opinion politely, trying their idea, and if needed reminding them of my idea.
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.
You may be giving too much importance for what he says. There's what people say and there's what is actually going to be done. These two things only have to match if the person doing the talk is the lead (or, a customer, perhaps).
Since the person who has an issue here is the new junior developer, complaining to upper management that someone "doesn't understand logic" seems like a terrible idea to me. Such an action could make this new junior employee look like he/she is the real problem here.
Depends on your organization. Sometimes it works, sometimes it backfires completely, as both levels of management get frustrated with you.
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.
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.