I have been working in the software industry for more than 2 years now, and have been studying it in school for the last 4. I work with an intern who has taken 2 introductory classes (Python and Java), and has never worked in the industry before this job. He is constantly telling me that my code is too complex, my methods have names that are too verbose, and my variable names are too specific. He also insists that every 3 lines or so of code requires a comment, as that is what they teach in the intro courses more often than not. He seems to lack the skill to be able to read code, and doesn't seem to understand that you should be able to write code in a way that is readable. We have gotten into several discussions about this, the last one got rather heated as I was attempting to explain to him that human-readable code is desirable, and verbose method names are not an issue.

During this latest exchange he attempted to tell me industry standards for source code, and how I wasn't following them, when he has never seen any industry code himself. Which is when I started to lose my cool. I am not a people person, which is why I went into computers, and am wondering what advice you all have for, in general, dealing with inexperienced people who attempt to apply the basic 'how-to-code' standards their professors taught them to the real world.

  • Industry standards learnt at school : nice oxymore. Commented Dec 19, 2018 at 6:49
  • 20
    "variable names are too specific" - I snorted milk out of my nose at that one :-) He is an intern. Ignore him & life will sort him out. Just keep doing your own good stuff. And if he inetrns again next year, show him some of the code he wrote this year and ask him to explain it mwuuuhahahahahha !!!
    – Mawg
    Commented Dec 19, 2018 at 8:26
  • 7
    If he complains about the verbosity of Java, he might have chosen the wrong profession :)
    – rath
    Commented Dec 19, 2018 at 13:53
  • 5
    Does your employer have published code standards? A style guide? A formal code review process? What actual, formal responsibility do you have to work with this intern, in the capacity of giving feedback on their work product?
    – dwizum
    Commented Dec 19, 2018 at 14:06
  • 1
    There are two kinds of people: those that know nothing and those that know they know nothing. Perhaps you could explain to him the Dunning-Kruger Effect
    – bxk21
    Commented Dec 20, 2018 at 19:14

8 Answers 8


The following strategies might help:

  • Explain why you are right
  • Ask him to explain why he is right

If he continues to be overbearing, you might also remind him that you have more experience than he has, and that management has entrusted you with teaching him. And if even that doesn't cause him to respect your judgment, you might actually have to involve management, because he has started to disrespect their judgment as well.

Here are some ways you might be putting this into practice:

J: Your code is too complex!

S: Really? What makes you think that?

J: I don't understand it!

S: What don't you understand about it?


J: Your method names are too verbose!

S: I find descriptive names helpful, because they allow me to tell at a glance what the method does. Besides, with a good IDE is not is if I had to type them by hand.

J: But my professor uses much shorter names!

S: On his slides?

J: Yes!

S: Might he not have enough room for longer names on his slides, since they have to be in large font to be readable from the back of the auditorium? Our code only needs to be readable from the chair in front of our monitor, and our 30'' monitors have plenty of room for some extra characters, you know ...

J: Oh.


J: Your code isn't documented!

S: How so?

J: There are no comments! Our professor says we should write plenty of comments!

S: Ah. Yes, that's what they tell you in first year so the assignments will be easier to mark. Next year, they'll start teaching how to write code that can be understood even without comments. You see, widespread comments are like training wheels, useful for beginners, but a pointless hindrance to professionals. I don't mind you using them for now, but you will need to learn to get by without them soon.

If you are sure of your facts, adopting a somewhat patronizing tone (as I do above) can help communicate your difference in experience, and that you expect more respect from him. It can help showing your irritation without making a mountain out of a molehill or requiring assistance from management. Do take care not to overdo it, though - your response should remain factual and instructive at all times.

  • 8
    -1 adopting a patronizing tone is never the answer.... Commented Dec 19, 2018 at 3:20
  • 2
    So you prefer calling in management, or get the trainee fired instead, as some other answers suggest ...? Besides, the core of my answer is that one should have a factual discussion, and give reasons rather than playing power games. So, now that I have given my reasons for my recommendation, what are your reasons why such a tone can "never be an answer"?
    – meriton
    Commented Dec 19, 2018 at 4:23
  • 2
    @Abigail The main problem with comments is that person A writes code + comments, person B either extends functionality and/or refactors person A's code... then when person C comes along and attempts to follow the code, the comments are still there but make little sense against the code. Ideally person B should update and/or remove invalid comments.. but in practice it often gets missed. Readable code is a lot more reliable than unreadable code with verbose comments because comments rely on both the code and comments being updated, when code is just code.
    – James T
    Commented Dec 19, 2018 at 13:43
  • 7
    -1 You see, comments are like training wheels, useful for beginners, but a pointless hindrance to professionals - 25 years of experience coding in both large and small shops tells me that useful comments are always great to have. Instead of advocating getting rid of the comments, focus on higher quality and more useful comments instead of a comment every 3 or so lines. Commented Dec 19, 2018 at 17:21
  • 3
    The discussion about the value and cost of comments is somewhat off topic for this stackexchange site, so I won't go into great detail here, but there are published authors who went on record with statements like "A comment is a failure to express yourself in code. If you fail, then write a comment, but try not to fail". My training wheel metaphor is quite similar to that, is it not? I would never forbid a junior to use comments, but they must be made aware that it is better to express yourself in code, if such is possible
    – meriton
    Commented Dec 19, 2018 at 21:53

If it was me in this situation, I would specifically go back to the coding standards of the company. If you work in an established environment, 9 times out of 10 you will already have a standard that needs to be followed. Some places I have worked I agree with the standard and sometimes I don't agree with it. When I don't agree with it, I have some friendly conversations with management about how the process would better suite the company. But overall it's not the day-to-day developers job to establish the companies best practices, that is decided by the team as a whole.

  • 2
    Unfortunately, we are in the QA department and working in Python, while the rest of the company is in a C-based language. We don't have official coding standards to go off of, just the Python pep-8 guidelines, which are themselves rather vague on the verbosity of method names.
    – Daishozen
    Commented Dec 18, 2018 at 23:57
  • 1
    Completely understandable, I myself am an automation engineer and know how difficult it can be. My suggestion would be going to the management team and going over some of the "general" coding standards of the company that apply regardless of the language. Coding standards should be linear from development to testing. If you start to use your own companies standards and back it up with actual documentation, he will not be so easily upset when you bring it to his attention. Software is no place for an EGO.
    – DEnumber50
    Commented Dec 19, 2018 at 0:05
  • 2
    "We don't have official coding standards to go off of" - then create some (with a manager's blessing), but don't let the intern get involved, or wait until he has left before doing so.
    – Mawg
    Commented Dec 19, 2018 at 8:28
  • @Daishozen - as Mawg says, at the least grab a couple of books ("Clean Coder", and "Clean Code" are well regarded by many but there are many others) and establish the all / some or the general ideas in those as your internal team standards
    – NKCampbell
    Commented Dec 19, 2018 at 22:23

Your inexperienced co-worker is creating a real problem for himself, and that problem is that he makes you really dislike him. In his best interest, take him to a one-to-one meeting and discuss his behaviour.

Points would be that what he learned in introductory courses is meant to help beginners; there are rules that beginners should follow until they learned to think for themselves. Like Q: "Should I write a comment every three lines? " A: "If you ask the question, then you should. If you don't ask the question, you do what is right".

When he mentions industry standards, you ask him for written evidence. "Says who?" is always a good counter question. "Quotation needed".

But mainly tell him that his tone is inappropriate. That he is pissing you off with his constant negativity. That instead of criticising you, he should focus on improving his own code.

  • I think you meant "citation needed" rather than "quotation needed".
    – user
    Commented Dec 19, 2018 at 9:56

I work with an intern who .....

He is an intern, you are not. I had a similar situation in which an intern who was not at all a good coder (compared to his peers) instead of programming suddenly started to lecture his sub-par insights on the choice of programming languages and program structure in the project, without being asked or qualified. I recommend that you do what I did: Go to your Boss and have him removed.

  • 4
    While I totally agree with you, I don't think you should have him removed without giving him a warning first.
    – user94342
    Commented Dec 19, 2018 at 1:18
  • this happened after i warned him about his performance.
    – Sascha
    Commented Dec 19, 2018 at 11:47
  • Why is there any need to discuss this issue with the intern? You simply say that he/she should bring this up with his/her supervisor, the topic has been discussed at the Manager level, multiple times, before he/she arrived, and unless there's new standards set from above the current formatting is what we've agreed to follow. Commented Dec 21, 2018 at 21:00

Right and wrong is not the most constructive way to think about coding standards. Discussions about coding standards are like religious wars and they will only get more intense when you interact with more seasoned programmers.

What specific standards you use are much less important than having a consistent standard across a firm. A consistent standard makes it easier to use tools for code search and code analysis, or to digest code written by several different developers.

You are the manager (or at least the senior co-worker) in this interaction and have more experience and more stake in the practices of your firm. That is what matters, not the costs and benefits of any individual coding practice.

Take the discussion to a higher level. Explain that coding standards are arbitrary and mandatory, and that it is a poor use of time to discuss the merits of the standards. The intern will then see you as a wise senior colleague who sees the bigger picture and you will have fewer holy wars about whether to use tabs or spaces.


Well you can shut him up quickly if you show the standards you follow in some of the numerous books written about programming standards...

oh wait...
They are NOT laws, merely recommendations suggesting logical and easy to follow conventions. (unless they're actually part of the language or its syntax)

To answer your question:

  • Point out to him, standards are not carved in stone and are aplenty

  • remind him that in a company most of the time he'll have to follow the standards the company, lead or supervisor set out instead of what he learned - regardless of his approval and comfort

...you could leave it at that or add (possibly in a less polite way,after he still corrects you):

  • he is an INTERN at your company to learn how it is done in the professional work environment outside of the classroom.
  • If he feels that your experience and degree is clashing with what he is being taught in his introductory classes he could widen his horizon by understanding your standard or he needs to bring that to the schools attention instead of disrupting your work.
  • Further, if he wishes not to listen to what you can offer from your knowledge he is welcome to seek another company to intern at.

Sadly, you can't always be the nice person everybody likes. Especially in a supervising position.

My subordinates often question why we do the things like we do. And this is absolutely fine, since I can explain it to them and they will learn out of it.

But this is not just questioning your methods, it's a straight insult. If I'd ever been in this situation, I would have responded with something like:

I really want to avoid this, but if you can't stop questioning my professionalism, I'll have to report this to our management.

I think this is the politest way to give him an admonishment. Everything other than that, would undermine your authority.


Throw pep 8 at them. Problem solved. Better to rip the "Your professors are just lying to you" band-aid off sooner rather than later.

Your intern probably doesn't have the ability to read code. I couldn't do that for a while when I was learning. I know you couldn't either when you first started out. Tell the intern to do some research on medium.

Finally, if the problem persists, make them read "Clean Code" by Bob Martin the correct way.

If this problem persists, warn, and then fire. Interns at software companies should be making a good amount of money. You should be getting some small level of usefulness out of them. It sounds like you're not.

  • I remember being one of a group of young students. Someone had some code on the screen. I pointed at one line and said "there's a bug". He says "but you don't know what the code does." I say "true, but there's a bug". A mate of mine has one glance and says "he's right, there's a bug". And there was indeed a bug.
    – gnasher729
    Commented Oct 13, 2022 at 15:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .