Hacker News Reader

Comment by happppy | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com