185

How can I productively channel this issue? It's not clear what "productively channel" means in this context. You do your job to the best of your ability. If that means your colleague appears comparatively diminished as a result, that's your bosses problem not yours. Do your work. Get rewarded accordingly. Let Sam and Sam's boss worry about his work and ...


129

I did a series of talks on what makes code simple and readable. There is no absolute answer. Much depends on the vocabulary the reader brings. Take for example: bool retval; if (x > 0) { retval = true; } else { retval = false; } return retval; Compare this to return (x>0); To the complete beginners it's possible the first seems simpler, more ...


78

I think you're doing something here, out of goodness of your heart, that is preventing your boss from seeing the problem. If Sam struggles with something, based on the same-level position between the two of you, you are not actually responsible for him, but your boss. You don't have to be rude about it, but you can say "Hey Sam, I can't help with this ...


66

Disclaimer: this answer will be written as if OP's coding style really is as complex as necessary (not over-complicated) and it's really good, efficient code (not something that could be done easier and in a more understandable way with the same result). I think I was in your position before. I was the "expert" guy working on integrating and ...


43

You have junior teammates, and your organisation needs your code to be comprehensible to them. This is critical. You've been given an unwritten requirement - your code must not only do the job, but it must also be maintainable by others. This is a very difficult balance to play. Compare the abstract factory pattern with a simple hash table of factory ...


34

My code is “complex” because it’s well engineered. Failing that, my code is generally well commented and documented, so if all else fails, my colleagues have the means to help themselves. And yet what you call well engineered and documented code is being considered as hard to work with. Those are contradictory statements, as code that is well engineered ...


19

The issue here is that life isn't fair. Stop focusing on others and focus on yourself. If you are getting paid market rates for your skill and function, let it go. If they are making it hard to hit deadlines, let that be known as that is important to the team and company. Under performing seniors should be terminated, not demoted, but that is an issue for ...


19

Be prepared for an emotional situation. While these people may no longer have value at your company, they do have value -- remember that. I would suggest that you do not go into the specifics as to why they are being laid off -- it simply doesn't matter at this point. I would suggest that you state something like: Sadly your services are not longer ...


16

TLDR: IF nobody else can follow your code, it is you who is the one who is in the wrong, PERIOD When I was a noob, first year of programming professionally, the company had hired three contractors, myself, and two others. One of them was an absolute genius. Two full-time jobs were offered, and the genius didn't get it. Know why? Not even the other two ...


12

There are two possible reasons why working code is hard to read: Either because something easy is written in a much too convoluted way, or because something complex is written in the best possible way. (Being a difficult problem AND written in a much too convoluted way AND working isn’t possible simultaneously). I’ll give you two examples of complex problems:...


10

How can I productively channel this issue? Like a comment suggests, I would not raise it and instead focus on doing your job efficiently. If your coworker really lacks skills for their role it will become evident with time, and with performance reviews. Channeling your time and effort to raise this will only diminish your performance and also not give a ...


9

I was happy with my title until Sam came along about a year ago This part tells us that your core problem seems to be that you feel slighted. Your coworker's skills are lacking, but his title – and probably salary – match yours. I'll tell you that this should not be accepted. Yes, some people were born rich, some beautiful and you will have to deal with ...


8

My code is “complex” because it’s well engineered. It’s like that for many good reasons, which make it easier to read, refactor, test and maintain. In my opinion — at the risk of getting defensive about it — it’s actually easier to work with than the piles of spaghetti that my colleagues churn out. From the feedback you got, your code is not easier to work ...


6

Who should I talk to about this? If you have already spoken to the PM and have asked them to stop "helping" (clearly explaining the negative consequences of his meddling) without any change in behavior then you should speak to your manager. Approach the discussion from the angle that the PM is disrupting your work by either wasting your time or ...


5

I would suggest moving to another company. In my (not so humble) opinion (I've had similar discussions at past workplaces), if your manager isn't supporting you and providing the opportunity to hire better or more seasoned engineers, then you're working for a company that's trying to get by with the minimal bottom-line. But, that's not an attitude you share. ...


5

He is senior, not because he knows about QA automation, but for something else: He could be a manager, a tester, HR, controller, etc. etc. in senior capacity, and he is (for whatever reason) assigned to his current role as QA automation position. That means he could possibly teach you a thing or two. Take advantage of that!


4

Whenever I want to talk with him about any new idea which may be good for our product, he replies to me in a very arrogant manner and always degrades me and my idea. However, whenever our new version is launched, the new feature which I suggested is added. If your ideas keep getting added, they're probably good ideas. You should draw confidence from this! ...


4

Yes, you are an awesome coder. {{applause}}. But it doesn't matter. Where you've gone wrong - and all of us have at some point - was thinking that this job is about you impressing people with the quality of your code. Right now you are sitting in a high tower looking down on people but the people who run the company are down there too. This isn't good for ...


4

I would propose a few things to ease the situation between you (a more experienced developer) and the juniors: Create a code-style guide and make everyone to follow it. This way junior developers can learn way faster. They can start to understand things because some explanation already exists (be it a broad one, but still). Like people mentioned, have some ...


3

The answer entirely depends on the type of company you're working for. If you're working for a consultancy, AKA a body shop, your value is measured in the amount of work you get done, not how well you do it. Once the work for their current client is complete, a consultancy simply moves on to the next client's work. The end result is software that mostly ...


3

I know that I can't complain to our lead that I feel the discrepancy in our ability would make Sam a junior I think you can absolutely raise this with your lead (assuming you share a line manager here) - although you might not want to phrase it quite that way, and certainly not as though you're pitching for him to be "demoted". It might be sufficient to ...


3

While I agree with the existing answers (you should definitely focus on your own work), I think it's important to keep in mind that two things you mention should be addressed in some way: by the same token there isn't really any higher I could rise without changing my role to something different If that's true, than you career is stagnating right now (...


2

You have a terrible work environment. You need to make a plan to leave. There are three distinct things wrong here: You are not being paid. I am not sure whether this is the norm in India, but that is a problem you will eventually need to correct as you will want to eat one day. Your ideas are being stolen. That is just unfair. Sometimes this will happen, ...


2

But also – "if you have spent any time at all in this business, you have been laid-off before." (And, you have learned to "bounce.") Me? "Thirty-five years, eight layoffs (so far)." Never a serious problem. ("Hey, it's business ... too bad for you that you screwed-up yours!") "But seriously ..." although ...


2

Avoid expressing opinion; let the facts speak for themselves. Your co-worker sounds like the "senior" developer I'm currently cleaning up after. I'd characterize him as a barely-competent junior developer who requires constant handholding to not $#&@ up everything he touches. But I'd never tell my boss that. I let the code do the talking. Pretty close ...


2

The way you deal productively with this situation is by working effectively with your peers, including Sam. Titles, especially title modifiers, mean almost nothing. In many workplaces, you are "senior" "junior" "associate" "principal" or "staff" depending on arbitrary org-chart rules which are devised by HR and based on not much at all. It appears that you'...


2

Like everyone says, focus on your own work. I've had people who aren't up to scratch work with me, and I've always helped them out (as long as they are willing to learn). That's how we all grow. Then again, think about it .. what if somehow through your networking skills you end up in a senior management level job which you are not really qualified for. ...


2

What else can I do? You can teach. I am an amateur dev and my code is not nice. It is readable (at least while I have it in front of my eyes) and does the job. Then a guy who knew how to develop joined my team (we are not developers, but we generate some code for various tasks). He had all these CRUD structures which were simply horrible - code all over ...


2

I don't know the specifics of your situation but I would advise trying to educate your peers about why you're things this way. Consider talking to your manager about setting up a 60-90 minute learning session on a weekly basis. Make it an open invitation for anyone on the team to attend, and optional. This is also helpful if someone has an unfounded ...


1

Other answers cover the main points: in a nutshell, you've got to (a) decide to what degree your code has to be this "complex" to get the job done, or is, perhaps, being "a bit too clever"; and (b) to what degree you should "come down to their level" or they need to get more training. (In reality, it's probably not a binary ...


Only top voted, non community-wiki answers of a minimum length are eligible