4 ms·

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

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.

59nadir 7y ago
> 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.
- happppy 7y ago
  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.
  - laumars 7y ago
    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?
  - cgio 7y ago
    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.
  - arebours 7y ago
    > 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.
Udik 7y ago
> 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.
- a_imho 7y ago
  Textbook enterprise development, office politics and connections trumps competence and contribution. Non programmer tech leads / seniors devs / architects are very common.
LandR 7y ago
> 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'
- dsego 7y ago
  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.
  - Insanity 7y ago
    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.
- jcims 7y ago
  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.
- jinglebells 7y ago
  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.
  - C1sc0cat 7y ago
LarryL 7y ago
> 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).

59nadir 7y ago

> 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.

happppy 7y ago
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.
- laumars 7y ago
  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?
- cgio 7y ago
  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.
- arebours 7y ago
  > 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.

Udik 7y ago

> 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.

a_imho 7y ago
Textbook enterprise development, office politics and connections trumps competence and contribution. Non programmer tech leads / seniors devs / architects are very common.

LandR 7y ago

> 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'

dsego 7y ago
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.
- Insanity 7y ago
  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.
jcims 7y ago
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.
jinglebells 7y ago
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.
- C1sc0cat 7y ago

LarryL 7y ago

> 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).