How to handle interns' unprofessional behavior?



I am a software developer in a small company (a few dozen employees). We have a summer internship going on. The interns are college students with no professional experience and with rather basic knowledge of the programming language. (I was not involved in the choice of interns). Some of the interns will be hired in the company in the future based on their performance.

The interns are developing a simple application (not for the company, not a production code) just to get some basic principles and get to know each other before they move on to more complex stuff.

I am helping them in the development on a day-to-day basis (quick meetings to resolve issues they cannot resolve on their own) and doing code review. One of the main issues they have is they don't follow naming conventions and create poor and short names for methods (like convert). Of course, I explained to them that proper naming is very important, that they should not be afraid to use longer, descriptive method names (like convertGallonsToMilliliters). Unfortunately, a few of them (and I know who, because they are using version control) apparently decided to have some fun (or mock me) and started creating silly method names like convertToMillilitersBecauseIAmUsingSuchCleanCode - not a single occurrence, but a few.

How should I react to this? I know it's not production code, but I spend a fair amount of time reviewing and I'm doing my best - to help the interns learn and to have them pick up best practices when it comes to clean code.

Should I react by

  • laughing it off ("Yeah, it's funny but please remove it")
  • just asking politely to remove it
  • telling that I don't like when someone wastes my time and they should take the code review more seriously

I know it's probably not such a big deal but it's my first time helping the interns and I'd like to know how to handle such situation properly. Still, their performance during the internship will affect their chances of being hired and situations like this can play a role later. Or I should tell them something along these lines to make them more motivated to actually learn something?

EDIT: Thank you for your great answers. I discussed the issue with my manager and talked to the interns. I wrote the method name on the whiteboard and asked if they think it's a good name. I also discussed with them briefly the purpose of code reviews again. I told them that in real projects we have external companies doing code review audits - this kind of joke could really get them in trouble later on. So it's actually better for them to learn this lesson during the internship.

After we talked, they admitted that they shouldn't commit such code. They also told me that they are thankful for the time I spend on reviewing their code and for my help. But the best part is that their work quality has really improved since then. Actually, the guy who commited the joke has started delivering the best code in the group - I see him (and other interns, too) taking my notes from code review much more seriously now.


Posted 2017-07-11T16:05:54.450

Reputation: 1 691


Comments are not for extended discussion; this conversation has been moved to chat.

enderland 2017-07-12T00:00:33.823

114One potentially hilarious option: run an obfuscater over their code and tell them that's what short variable names are like when revisiting code written 6 months ago.Maybe_Factor 2017-07-12T01:22:56.017


Have you ever seen the Linux kernel code? Take a close look at this for instance. Surprisingly, it works, and works so well that it is used worldwide. I don't know the details of the project they were working on, but generally speaking, camel case is not the only valid style of naming and I can understand their frustration if you were trying to impose your own personal preferences in coding style without explaining why the style you are suggesting would objectively be better for their project.

undercat 2017-07-12T04:23:33.257

51As a caveat, this is why you don't get new hires to make new code. You get them to maintain code and that's where they'll really learn why you take coding standards seriously.Nelson 2017-07-12T04:44:35.860

5Consider the possibility that you are at least as wrong as your interns, and that trying to stuff information that ought to be in comments into sesquipedalian variable names can be just as harmful to readability.jamesqf 2017-07-12T05:11:23.790

12For what it's worth I actually found your example pretty funny. If theirs are like this, I think letting them know you enjoyed the humor might soften the blow of telling them it's not professional and that they need avoid it in the future. It'll also get you some chillness/coolness points which will probably help make them actually listen to you. (Make it clear that you won't enjoy such humor again though.)Mehrdad 2017-07-12T06:12:49.497

6Off topic, but something I noticed: "Some of the interns will be hired in the company in the future based on their performance." No, you will give some of the interns an offer to work in the company. You should not assume that they will take your offer.Pakk 2017-07-12T06:55:05.123

7Offtopic... but, am I the only one who feels like convert is a MUCH cleaner name for such a method than convertGallonsToMilliliters (given the right class & context, of course).Priidu Neemre 2017-07-12T08:10:23.247

18@jamesqf The only information that should be in the comments is the why, not the what. If your code doesn't show clearly what it does, it's bad code and bad code cannot be repaired by throwing comments at it, especially as the chance for comments to be updated is even smaller than for code to be updated.Florian Schaetz 2017-07-12T08:40:03.447

17@PriiduNeemre If you have dozens of convert methods floating around in your code (and yes, you never have... when you start, but soon you will have), it will become difficult to see immediately, which one this is. By naming it clearly or using other ways to make that clear, you can reduce reading complexity. Of course, something like Gallons.of( x ).convertTo( Unit.Milliliters) is also a possibility. Only if you are 110% sure that this will be to only conversion ever done in your code... But even then, just if the context around it makes it clear, what this conversion is about.Florian Schaetz 2017-07-12T08:45:49.283


@PriiduNeemre: I suppose the people writing the software for Mars Climate Orbiter assumed they were writing clean code in a well-defined context, as well.

O. R. Mapper 2017-07-12T09:08:49.317

10Add a new method to the project to demonstrate. FireEmployee(string employeeName, string reason) and add a unit test calling the method with problem employee's name and reason explaining what they have done wrong. Show that this test passes and is ready to go live ;)Glen Thomas 2017-07-12T10:00:34.957

2@FlorianSchaetz: Indeed, I had something like your second example in mind. IMHO it is important to have descriptive names not just on the method level, but also on the class and variable levels (e.g. DtoAssembler.assemble(customer), instead of CustomerHelper.assembleCustomerToCustomerDto(entity), although this is maybe not the best example). If you feel like you need to bloat a simple convert to such proportions, it is probably in the wrong place to begin with. Anyway, this is probably venturing too far off the initial question :).Priidu Neemre 2017-07-12T10:43:46.133

3@undercat What am supposed to see in the Linux source?CodeSeeker 2017-07-12T15:29:58.550

4@undercat makes a significant point here. There's a long tradition of irreverent humor hidden away in source code; asserting that it's unprofessional to do so is a local standard, not a universal one.bgvaughan 2017-07-12T19:00:11.693

3I don't agree with Mehrdad. We're talking about professionalism? Why would you have to spent time getting the respect of your interns so they listen to you? This is proving grounds, they should be getting your respect. I understand being a stickler can definitely ruin communication, but I think giving guidance this is not applicable. If they aren't taking your guidance, if they're not responding to code reviews, that is not professional. The humor wouldn't matter so much if it wasn't condescending.tsturzl 2017-07-12T20:30:40.547

1Furthermore, you shouldn't have to be motivating them to learn. Their ambitions are their responsibility. If you want something, you go get it. Just because you went to some university got a degree, landed an internship, it doesn't matter when it comes to your career unless you take your own initiative beyond that. You shouldn't have to worry about your status among them, you should just make it clear that they are choosing their own fate.tsturzl 2017-07-12T20:36:06.270

1@CodeSeeker probably the comment on line 9mcalex 2017-07-13T05:19:08.373

3This question isn't "Should methods have long or short names?". It's "What do I do about co-workers putting stupid jokes into source code?"jwg 2017-07-13T09:02:28.197

1Is that really a good example? The verb alone, convert, should be the function name, and the details are part of the argument types. Maybe auto result= convert<mililiters>(original); whereoriginalis of typegallons`. IAC units should be strong types and operations should be for the underlying abstract quantity not* specific to particular units.JDługosz 2017-07-13T09:29:15.467

How do you know that they did it to be rude? Maybe the intern did it to show you, explicitly, that he listened to what you said and understood why you said it.James Monger 2017-07-13T09:47:23.973

1I'm a developer with more than ten years of professional experience. When I need to make jokes in code, I do it in the data for unit tests. I give unit test customers witty streets or last names, I choose out-of-domain products for my tests, like chainsaws or moon-rockets. My last trainee picked male Marvel and DC characters as the unit test users for his project, complete with email addresses and the passwords are their girlfriends' names. He went through with that scheme. I thought it was smart and hilarious, and I encouraged it. There's a place for fun, but not like they did in the questionsimbabque 2017-07-13T10:28:44.097

1Simple answer: schedule a code review. Part of the normal software development cycle in most software shops.Ogre Psalm33 2017-07-13T12:20:04.507

3Change convertToMillilitersBecauseIAmUsingSuchCleanCode to convertToMillilitersBecauseImUsingSuchCleanCode and wait for a NoMethodError.Eric Duminil 2017-07-13T13:01:22.267

The accepted answer, with the adjustment @inappropriateCode made in the comment to that answer, is the way to go. On top of that, don't hire the interns that behave this way.BobbyA 2017-07-13T16:18:08.330

Group meeting and then the words "Look, you little snots - this ain't college anymore, it's the real world. And in the real world, nonsense like this gets people fired. Do it again and you're gone."Omegacron 2017-07-13T16:44:27.073

@Florian Schaetz: If your code shows clearly what it does, you are not working on very complicated problems :-) Try to implement say an eikonal equation solver that you can understand from the code. Using really long variable names won't help. Indeed, it will hurt when you're referencing back to the equations in the original paper.jamesqf 2017-07-13T17:01:24.590

@jamesqf Write an eikonal equation solver where to documentation can fit nicely into the code. It won't. In this case, you will simply have to refer to the original paper in any case. But what you can do is wrap the whole solver so that it is clear what it does, even if the "how" is just answerable by "math" via the code itself.Florian Schaetz 2017-07-13T18:48:03.490

Reject the PR with a short note stating why. Don't accept future PRs that contain these types of issues.FreeAsInBeer 2017-07-13T18:49:39.023

Simply put, those are the ones you won't hire. End of story.user441521 2017-07-13T19:15:24.303

3I dunno, personally I found this hilarious. I don't see anything wrong with a cheeky sense of humor. All it shows is that they don't truly understand the benefit of appropriate function/variable names - and being interns, this is expected. I think it shows poor judgement to take this personally and not hire them based on this.Edmund Reed 2017-07-14T01:29:58.473

3If that's the worst thing about their code, you got some really awesome interns ;) .Radu Murzea 2017-07-14T11:00:34.010

they likely don't see a point of using proper names. Doing so is something that typically comes much much later and with experience. If this project is meaningless, let them have fun. If the project really matters, bring in the people who are involved into the project and have a conversation about how that code will be maintained in the future by the team members.Dennis 2017-07-14T14:06:20.350

@PriiduNeemre You're not the only one based on the upvotes to your comment, but I wholeheartedly disagree with you. Better naming is one of the most important ways to make code more readable. Unless the class name is GallonsToMillilitersConverter, Convert is a horrible method name.CodeSeeker 2017-07-14T17:40:04.730

@EdmundReed I totally agree about not taking things personally. There's no need. See my answer on this page and the comments.CodeSeeker 2017-07-14T17:40:37.237

@CodeSeeker: did you even read my other comment (and the one by @FlorianSchaetz)?Priidu Neemre 2017-07-14T19:02:52.137

1@PriiduNeemre I did read it earlier, though not at the time of commenting. I do take your point, really, I do, but in some cases software doesn't have to be over-engineered. Sometimes you just need ConvertGallonsToMilliliters and there's no room for creating a whole context in which conversion can be promoted to be a proper domain-level concern. My point is that it's wrong to just flatly call such a name wrong. It might be right for a particular context.CodeSeeker 2017-07-14T19:33:56.883

@CodeSeeker: Good argumentation, I can live with that :). To be honest, I wasn't really trying to make a blanket statement anyway... I guess it did turn out a bit on the provocative side, though.Priidu Neemre 2017-07-14T20:32:31.880

2I don't understand why the interns "getting to know each other" is a factor at all. They are not there to get to know other college age kids with no connections and no experience; they are there to "get to know" professional developers. Similarly, having a project primarily or entirely worked on by interns means instead of learning from and about (the good, bad, and ugly of) real code, they are learning from each other, the blind leading the blind. It would make far more sense, if you have multiple teams, to assign one or two interns to each team, alternatively, to volunteer mentors.Derek Elkins 2017-07-14T22:07:59.580

1I seriously think that this question doesn't belongs to here. It belongs to 'programmers' stack exchange. The OP is an engineer and he is trying to do people management of interns and he have learned the lesson, So be it !sandun dhammika 2017-07-15T15:13:00.440

@FlorianSchaetz If your code doesn't show clearly what it does, it's bad code - depends upon the language :-/Steve Ives 2017-07-17T08:02:52.950



I don't think laughing it off is the proper approach. They need to learn that they are not in school anymore. That being said, I don't think you should take it too far the other way either.

I would recommend that you be firm with him/her and say something to the effect of:

The reason we went over naming conventions is because they are very important. This code needs to be maintainable in the future. A lot of people around here have worked hard to get where they are, and they may not appreciate these types of jokes. Please refrain from using these types of names in the future as it can cause people to question your professionalism.


Posted 2017-07-11T16:05:54.450

Reputation: 5 852

175this seems like the generally right approach. personally, i'd level with them using less formal language. i'd call them into my office and say, "hey, i noticed you were using some goofy names for your methods. what's the deal?" calling them out this way in person, i think, would be more likely to induce feelings of shame and remorse. an overly formal written scolding might just give them more fodder for mockery.dbliss 2017-07-11T17:30:55.160


First off, this seems like a joke that was put into code that they are well aware will not be used for anything or read ever again. I think you are reading far too much into this incident. The important thing is that you told them about the naming convention and they did not ignore you, they did use longer and more descriptive names (albeit sarcastically).

After watching this video:

I can see that workers desire 3 things.

  1. Autonomy
  2. Mastery
  3. Purpose

What you are asking them to do is not autonomous, is probably of trivial difficulty for some of them, and serves no purpose in their eyes.

Fix the assignment, and the workers will follow.

Some examples:

  1. Here is this project, work together and have it done by ____, let me know if you get stuck.

  2. I know this doesnt seem important, but in order to assess your skills and assign you work that we think will help you grow we need you to finish this task.

Joe S

Posted 2017-07-11T16:05:54.450

Reputation: 1 663

48Agreed. They know they're working on something that is completely meaningless, which can be frustrating. Humor is a good way to let off steam.Llewellyn 2017-07-11T17:47:40.163

8I really likes this answer because it shares the blame of the intern's unprofessional behavior with the management. As someone who was, until recently, stuck completing menial tasks in a subservient role, I understand the negative effects that micromanagement and lack of autonomy can have on my own productivity. While discipline may lead to a short-term fix, it doesn't address the underlying problem.AffableAmbler 2017-07-11T20:00:51.437

19I've seen the video and I love these points. However, this is clearly subversive and disrespectful. The question is why. Getting to work on a toy before being thrown into the deep end of the pool is not micromanagement. Though the interns might not understand that. The best way to react to this to ask why. Are they poking fun at the exercise, the standards, the management, or was it just to much time at the keyboard and not enough time holding a Nerf gun?CandiedOrange 2017-07-11T21:19:15.400

4Don't read anything at all into it until you have a handle on it. This isn't even management's business. This is a code review issue. The reason you don't do this isn't because management will fire you. It's because your coworkers know where you keep your coffee mug.CandiedOrange 2017-07-11T21:19:25.233

Agreed. They're kids who haven't worked in a professional environment before in a role where one of the goals is to teach them how to work in a professional environment. Firing them for not being professional seems to miss the point.Jaguar Wong 2017-07-11T21:23:21.977

11@JaguarWong "They're kids who haven't worked in a professional environment before in a role where one of the goals is to teach them how to work in a professional environment." They're probably 20-somethings that very shortly will need to do this or continue having mom & dad pay for them. Frankly "don't mock your mentor" is something they should already know.Andy 2017-07-12T00:42:34.247

13@CandiedOrange re "subversive / disrespectful": not necessarily true. We only have the manager's account of that. For all we know convertToMillilitersBecauseIAmUsingSuchCleanCode is an "exaggerated" example. Maybe rather than "to mock", the interns did it "to bond", and the manager is insecure and went for the worst possible explanation. Maybe the intern was proud to put that there, showing they not only listened, but enjoyed, and managed to have some fun with it. The manager assumes he "cunningly figured out who", when the intern probably wasn't hiding and was just trying to lighten spiritsTasos Papastylianou 2017-07-12T10:42:56.100


TL;DR: I object to the method name because it (in my opinion!) voices disdain for the boss and/or the "rules" (here: style guidelines). In the workplace, I expect people to abide by the rule "love it, change it, or leave it". In this case, the intern, who seems to be of the opinion that the guideline is unnecessary, should either just accept it anyway; or keep the discussion about it going; or stop to do what he does. Not put in the equivalent of some smearing on the toilet. I would have had no objection whatsoever against a truly funny, creative method name. If you (the OP) find the method name just funny and not "bad" as I do, then ignore this answer please.

As a background, I have supervised a few highly intelligent and (self-)motivated interns in the past, and never once was there any question of whether they would behave professionally or not. Bringing school-level silliness to a workplace as an intern is so far out of the acceptable, that I would suggest not to fool around. For your own and especially for their sake.

I'd like to know how to handle such situation properly.

First of all, forget about the coding conventions. The issue is not related to computers or programming.

  • Don't lie. Don't mince words, don't laugh it off, because it really is not a laughing matter.
  • Don't get personal. It is not about you the OP, nor about your relationship with them. It is purely and strictly about their behaviour.
  • Explain things as they are. You absolutely can tell the offender that you kind of understand how he got the idea to do what he did, and that you are not personally angry at him or whatever (keep emotions out), but that you are viewing the internship as a screening of whom to take on board later.

If you wish to convey any emotion about it, stay far away from anger. You can display mild sadness (and frankly, that would be exactly what I would actually feel) and show them that you were quite disappointed.

Still, their performance during the internship will affect their chances of being hired and situations like this can play a role later.

Absolutely! Don't fuzz around with "can play a role later". Behaviour like this can, should and will make their chance of receiving an offer after the internship zero. You can say that in whatever way you normally speak to them, plain and clearly.

Try to find the root cause. If you find out that either...

  • ...they are here against their free will (maybe their parents, or their school or whatever, made them pick some internship and they just so happened to pick your company)...
  • ...they are not interested in "business" style software development at all...

...then offering to abort the internship would not be the worst you could do. The problem is not that your time is wasted (you had allotted plenty of your time for supervising them in any case, they didn't actually make it worse for you), the problem is that their time is wasted.

Or I should tell them something along these lines to make them more motivated to actually learn something?

I'd quip "every human can learn, but no human can be taught." I think you will find it very hard to motivate that person to learn about the usefulness of coding conventions since they already demonstrated that they have zero interest in those. You can teach those that are interested in what you have to say; but if someone is disinterested, there is nothing whatsoever you can do, really.

If you actually really want to help that person to "see the light", then ask them to try and play along for their own sake, maybe they learn appreciate what you can offer, later. Internships are an exchange of whatever limited services they can offer, against the experience of working at an actual workplace. If they are not interested in assimilating the experience, then there really is no point. Presumably, your company is not dependent of having their "man power" for some real project.


Posted 2017-07-11T16:05:54.450

Reputation: 3 845

17First of all, forget about the coding conventions. The issue is not related to computers or programming. This is a really good point!Cypher 2017-07-11T22:15:16.197

19Sorry, but -1 as I find your answer way to harsh and overreacting. I find phrases like "is so far out of the acceptable", "they already demonstrated that they have zero interest in those" and "make their chance of onboarding later zero" not applicable to this situation. They just choose some silly names for a non-relevant piece of code, an action which can be corrected in a few seconds (and btw using some silly names is quite common in many serious applications). They did not murder their boss!dirkk 2017-07-12T08:06:16.400

No need to be sorry, @dirkk, yours is as valid an opinion as everybody elses. I guess it would probably help to know what age and/or background these guys have and what the context of their internship is.AnoE 2017-07-12T09:16:09.430

5"because it really is not a laughing matter". This is a method name, not a medical emergency. Yes, it should be perfect, sterile and battleship grey, but if you really select people based on that criteria, be prepared to have your perfect, sterile and grey shop taken over by scripts and AIs in the near future. All humans make mistakes and if their only mistake is finding a rule conforming, but humorous method name, then I'd definitely employ them.nvoigt 2017-07-13T10:05:35.827

9@nvoigt It's perfectly possible to write good code with programming flair without preschool stupidity. (And no, it's not conforming to the rules.) Their mistake is seeing the OP as just another teacher in an us-and-them situation, instead of as a co-worker trying to help them. If they keep up with that childish attitude, why would you employ them? If there are plenty of interns and fewer full-time jobs, they need to give you a reason to want them working with you, otherwise you're better going with someone else.Graham 2017-07-13T11:54:16.713

3@Graham based on what you are writing, your country seems to be overflowing with perfect CS people begging for jobs. Mine is not, I will take somebody who's biggest flaw is finding a funny method name inside the rules any day.nvoigt 2017-07-13T12:50:18.310

6@nvoigt, the problem (for me) is not that they used a funny method name. For example, one of our devs called a package "I", leading to method names like "", etc. That's OK, that's funny etc. The method name the guy in this question chose is roughly translating to "myBossSucksButIDoWhatHeSaysBecauseHeSaysSo". Yes, of course that is just my opinion, but we're in Workplace.SE, and a little bit of opinion should be allowed here, especially since the voting mechanism takes care of it.AnoE 2017-07-13T18:34:03.373

@nvoigt: added a TL;DR to better explain the spirit of my he answer.AnoE 2017-07-13T18:46:50.750

2@dirkk As AnoE mentions, this isn't "just a silly name". Essentially this is written-down sarcasm intended as a slight against the OP and that is simply beyond the pale in a workplace. This is relatively mild and is likely just an inappropriate attempt at humour but if this wasn't about interns I'd be throwing around terms like passive-aggressive behaviour, malicious compliance, reputation damage and career limiting move. But interns new to an office culture are expected to screw up and this should be a teaching moment. Not taking this seriously would be doing these interns a disservice.Lilienthal 2017-07-14T10:39:13.770

@AnoE I follow your take on this but if I may offer some (hopefully constructive) criticism, I find that your answer is a bit unstructured and rambling. I think it would help to summarise the main issue with the behaviour (unprofessional, not appropriate in a workplace) and what the OP should do (explain why it's inappropriate to people new to the workplace = manage his interns). I'm also not sure about your section on the root cause. I wouldn't automatically assume that they were unmotivated over this particular incident of bad judgement.Lilienthal 2017-07-14T10:45:23.433

@Lilienthal: thanks for that feedback, it seems that's generally a problem for me (getting to the point), occasionally. I'll try to work on it. ;)AnoE 2017-07-14T13:02:21.657

@AnoE I know the feeling, it's only the 600 character limit that keeps my comments in check.:) Ping me in [chat] if you want to reply, I don't want to keep adding to this comment thread. Go ahead and flag my comment above obsolete if you want to clear this part of it.Lilienthal 2017-07-14T13:24:09.187

1"The issue is not related to programming." This is a fantastic point and gets to the core of the issue. I think most other answers sort of implied it, but kudos for explicitly spelling it out.Masked Man 2017-07-16T16:33:07.697

Yikes, thanks for the +200! @LilienthalAnoE 2017-07-17T13:24:26.693


We all hate doing it, but sometimes you just have to fix problems using authority. Call the interns to a meeting, and demand to know why the naming conventions were not followed.

I explained the naming conventions to be followed in our previous meeting. I came across a number of instances where the naming convention was not followed. For example, convertToMillilitersBecauseIAmUsingSuchCleanCode. Could you please explain why this name was chosen?

Their "answer" is irrelevant, this should serve as enough of a "first warning" that going against the directions of their supervisor (which I presume you are) and making jokes at his expense is not acceptable in a professional environment. That even fits well with one goal of internship, which is to show students how to work in a professional environment.

If they continue with their childish behaviour, then well, I think you have arrived at the conclusion to this:

Some of the interns will be hired in the company in the future based on their performance.

Masked Man

Posted 2017-07-11T16:05:54.450

Reputation: 33 546

The problem here is they did follow the naming conventionsJoe S 2017-07-11T16:56:18.670

21@JoeS how? convertToMillilitersBecauseIAmUsingSuchCleanCode is not following the instruction of should not be afraid to use longer, descriptive method names. It is long, but not descriptive.cheshire 2017-07-11T17:01:55.587

6@Cheshire they played the "exact words" game. This isn't one that's going to be solved with brute force.Richard U 2017-07-11T17:05:51.257

28@JoeS No, they didn't. It is obvious that their behaviour was passive aggressive, and they chose the long name just to mock the supervisor. I would be interested to see a full-fledged working professional behaving similarly and not getting strongly reprimanded (if not worse). There is no justification for choosing names longer than they need to be, they aren't playing the "best loophole abuse" game, and even if there is something wrong with the rule, they should bring that up constructively, not by behaving obnoxiously. PS: I honestly hope you were joking though.Masked Man 2017-07-11T17:43:08.757

7If their answer is irrelevant then why would you call a meeting to ask the question? A first warning should be an actual warning - not a rhetorical question.mwbl 2017-07-11T20:19:13.107

12@mwbl Because the goal of putting it as a question is to put them in the uncomfortable position where they have think about it and give some answer on the spot. He has already told them about the naming conventions and they didn't "get" it. Telling them "thou shalt not use silly names in thy code" will be met with "yeah right, the oh-so-clean code we are talking about". The interns need to realize the difference between college and a professional environment.Masked Man 2017-07-12T01:05:53.717

2"Could you please explain why this name was chosen?" is quite passive-aggressive behavior when you clearly see it is a joke. Your goal is better coding conventions, not showing off your authority, I hope.Boat 2017-07-13T09:54:37.417

2@Boat While I can't speak for MaskedMan, the goal here is most certainly not teaching better code conventions: that's incidental. The goal of this meeting should be to make it clear to these interns that a workplace plays by different rules than a programming course and that passive aggressive behaviour like this is very much Not OK and often a career limiting move and which for regular employees would prompt phrases like "final warning" or "please pack your things". The real value of internships is teaching soft skills and adjusting to an office culture, not technical skills.Lilienthal 2017-07-14T10:54:32.860

1@Lilienthal, Well, then you can just say for example "it is inappropriate to joke in naming conventions". If you pretend to not to understand, you are just saying "I'm the boss and you should learn your place". It's not about social roles, it's not about your ego, it's about working conventions and the boss should be able to communicate it in constructive way. Just because the intern acted childish way, doesn't mean you have to do the same.Boat 2017-07-14T11:22:37.933

@Lilienthal I was going to respond on those lines when I found the time, but you certainly expressed it much better than what I would have said!Masked Man 2017-07-14T11:22:47.833

1@Boat What exactly is childish here about asking the interns to explain why they did not follow the rules? The interns are not in kindergarten, you shouldn't let them carry the impression that they will be pampered in the professional world. The supervisor already told them once to follow the naming conventions. There is no such obligation on his part to "let them joke the first time, and explain the rules again till they stop joking". There is nothing unconstructive about a boss telling his subordinates to do their job, he doesn't need to babysit them to get the work done.Masked Man 2017-07-14T11:29:39.090

1@MaskedMan-仮面の男 Indicating that it's not okay to joke around is perfectly fine. But asking an explanation pretending like you are interested in the answer is not okay, because in reality you just want them to answer "because I'm stupid". It's the same as demanding an explanation for every writing mistake: you know it's not meant to be there because they think it's correct, but you pretend like you don't. Just tell them joking/writing mistakes is not okay and kick them out if they don't change their behavior, but don't pretend.Boat 2017-07-14T11:56:03.910

@Boat Hmm, this probably just comes down to a difference in work culture. In the work culture that I am familiar with, what the interns did there is called insubordination. I am cutting them a lot of slack because they are interns, and suggest asking them to explain precisely because they should think about it and not just conclude "we shouldn't disobey the boss because the boss said so". The issue here is not that they "joked" per se, but that they showed utter disregard to their supervisor's instructions.Masked Man 2017-07-14T12:08:14.977

1@boat "I'm the boss and you should learn your place". I actually think that's one of the lessons the interns in this question need to learn.Andy 2017-07-15T01:42:13.553


Oh, a bunch of screw offs, eh?

Take some working code and do something to deliberately break it. Then run it through an obfuscator that changes all the class, variable and method names to things like "a___1318798_" and "xy23_7a963"; or worse, variable names with lots of letter O, letter I, number 0, and number 1 characters in them. Make it their assignment to document what the code is doing, and fix it.

This will cure that joking around.

Xavier J

Posted 2017-07-11T16:05:54.450

Reputation: 25 894

7not sure why this answer got downvotes. I'm pretty sure that this "assignment" nails the issue of naming conventions on the head. The professionalism though... too bad there isn't a rollback on "I was a jerk to someone who influences whether or not I'll be hired"BlackThorn 2017-07-11T20:12:00.160

7@TBear This would waste more time than has already been wasted, probably without teaching a very useful lesson, orat best, teaching a lesson that could be taught more easily with a quick explanation. Although I did not downvote it personally, I believe that is why others have.mwbl 2017-07-11T20:23:32.357

I thought the same thing, but posted it as a comment since it's probably not a good solution to the problem. Depends heavily on the culture of the development team and whether or not you address your interns as "Maggot" in Major Pain style.Maybe_Factor 2017-07-12T01:30:18.487

3It got a bunch of downvotes (not from me I promise) almost certainly because it only increases the interns' perception of the exercise as unserious.wberry 2017-07-12T02:38:16.570

With version control around, this is fixed in 30 seconds by a single rollback.Dmitry Grigoryev 2017-07-12T14:50:41.853

@DmitryGrigoryev you dont have to give it to them through git ;)Leon 2017-07-14T11:25:18.227


I know it's probably not such a big deal but it's my first time helping the interns and I'd like to know how to handle such situation properly. Still, their performance during the internship will affect their chances of being hired and situations like this can play a role later. Or I should tell them something along these lines to make them more motivated to actually learn something?

When you encounter such silliness during your code reviews, laugh, stop the code review, and tell them to come back once they have removed the humor.

I'm assuming they aren't stupid, and already know that the overly-long name is inappropriate, even if they get a chuckle out of it. If not, explain why one time.

Hopefully, you are keeping track of their performance and can note how often this happens.

Joe Strazzere

Posted 2017-07-11T16:05:54.450

Reputation: 207 512


I would have a heart-to-heart with each of them, privately, in a frank and serious but not stern tone, something like this:

"Intern, I saw your joke method name. I understand why you did it, but I didn't think it was all that funny, myself. So it occurs to me to ask you, what are you here to do? What would you like to accomplish?"

If the interns says he's just there to screw around, then speak with management to end his internship. You're wasting your time.

If he says he's there to learn, then say something like this:

"I realize that it can be hard to take seriously something that you know won't be used in production. But please realize that you're not just taking your time, you're also taking my time. The internship you've been provided by the company is, in essence, a kind of interview. The only thing stopping it from being outright charity on our part is the hope of finding good candidates. So it's worth my time, but only if you are serious about it."

"If you can't take it seriously and work as if you're writing important production code, how can we properly evaluate you and decide whether to offer you a job? And even if we don't offer you a job, if you still don't take it seriously, how else will you acquire these skills and be able to practice under the valuable direction of someone with more experience than you?"

"If I were you, I'd do my best to follow the lead of the folks guiding you, who are, somewhat charitably, taking unprofitable time out of their work to invest into you. Consider that you'll benefit from this internship whether we hire you or not! I would personally appreciate it if you took this a little more seriously. Do it for yourself! If you don't want to do it for yourself, do it out of respect, or just gratitude, for the time I've taken away from my normal productive work to invest in you and your future."

It probably is appropriate to somewhat directly address the behavior itself, and why you're making somewhat of a big deal out of it. You might consider something like this:

"For what it's worth, this kind of action is considered disrespect, or even mocking, in the corporate world. I'm sure you didn't mean it that way [even if you don't believe this, say it], but please just follow my directions in the future without putting snarky things into the code."

Giving the "out" of the intern saying "oh, yeah, I meant no disrespect" lets him save face and repair the relationship in the most painless way possible. There is no need to extract a confession that he did mean it disrespectfully or to garner some huge apology. The point here is not power-over but successful internship.

If after all this, the negative behavior continues, you can address it more head-on. There is no reason you can't give a performance goal to an intern just like you would to a problem employee, or use any other strategy you would use with a regular employee. But remember that the interns are NOT experienced in the work world and should be given a break or two while you gently, but firmly, accustom them to the standards of the professional work world.


Posted 2017-07-11T16:05:54.450

Reputation: 1 868

Comments are not for extended discussion; this conversation has been moved to chat.

Lilienthal 2017-07-14T19:41:35.763


I worked with a few guys fresh out of school. They did this kind of thing not on purpose, but because they felt there was no point to be too pedantic. Code readability or re-usability simply didn't make sense to them. So, I got upset, but I couldn't reprimand any of them since I wasn't their boss.

Programmers are generally a smart bunch and "because I said so" is rarely a good enough reason to implement something even if it is the best programming practice.

I would review the code, make sure to tell them the humor is misplaced, and their odd naming conventions waste quite a bit of time. For the next task I would divide them is two: the funny guys on one side, the rest on the other. They would do the same task but the funny group should take much longer because they are not following the best practices. I would make sure that task is complex enough to make them waste lots of time if they keep up their conventions.

You can also assign a funny guy to debug the code of another funny guy. I don't think functionThatDudeToldMetoDefine would make it into the final version with this name.

In any case, the only way to increase your authority is get them in situations where they prove to themselves that what you claim is true.


Posted 2017-07-11T16:05:54.450

Reputation: 320

8I feel like this sentence is very good advice: "the only way to increase your authority is get them in situations where they prove to themselves that what you claim is true." If they don't follow the convention it's because they don't understand its value. Letting them see the value themselves will likely help them use the convention.Forklift 2017-07-12T13:31:44.517

1You can't reprimand them, sure. But if you're doing code review, then you can send it back, and send it back, and send it back. And if it keeps going, escalate it. Your boss certainly should have an opinion about code readability and reuse, since that directly impacts on his team's timescales down the line. And if they can't follow a coding standard, get rid of them. Kids just out of school are ten a penny, and if they won't learn then you can fire them and get someone who can.Graham 2017-07-13T11:57:53.843

@Graham If the job market is as in US or western EU, it is easier to replace the "defective" ones. Where I live, qualified workforce is hard to come by, so you don't have so many options. If word gets out you are too tough, people would look for other options.Magicsowon 2017-07-13T14:17:49.667

"Programmers are generally a smart bunch and "because I said so" is rarely a good enough reason" That may be theoretically true, but in practice we the exact opposite with programmers practicing stupid bigotry like "Emacs vs Vim", "Chrome vs Firefox", "C++ vs Java", "Windows vs Linux", etc. In many cases, the reasonable thing to do is learn enough of as many tools as possible and choose the right one for the job, yet programmers insist on doing everything with their "preferred" tool even if it can be done better with another tool and they know it.Masked Man 2017-07-15T17:22:12.770


The interns in question are wasting your time and patience. Your time and patience are expensive and limited resources to the company and the interns profiting from the company's investment into them, an investment that is constrained by the company's resources.

Their willingness to waste company resources needlessly is a relevant part of their performance evaluation and may lead to a premature termination of their internship in order to spend company resources only on those interns actually interested in learning how to be a valuable, responsible and reliable part of the workplace who can be entrusted with both tasks and instructions.

I'd tell this to all the interns, showing some example code, not mention its author, not spend more than 2 minutes on it and, if the code is subsequently fixed and similar incidents do not repeat, not mention it again.

If the warning shot goes unheeded, the next step is an open-ended talk with just the intern in question and possibly a superior of yours (make sure that he's in your boat though). Then you need to decide whether you owe it to the other interns to remove the one who is sabotaging their chances of a succesful internship.


Posted 2017-07-11T16:05:54.450

Reputation: 121

The point of hiring interns is that you're going to teach them some of the workplace norms that people with experience are used. That should in my view also involve clear and direct feedback. Dropping hints is never a great management strategy and I'd consider it especially likely to fail with these interns. And while this should be treated as a serious issue, interns are expected to make mistakes like these. A lapse in judgement isn't the same as not being willing to learn.Lilienthal 2017-07-15T22:46:58.337


It sounds like there are two main issues here: 1) They are being irreverent and 2) The name of the function still sucks even though it's now longer.

Reprimanding them for joking around is probably not going to make them respect your authority more, so I would focus on the issue as if it were any other poorly named function. I wouldn't necessarily play dumb and pretend like I don't realize it's a joke, but I would question them on why they chose the name they did:

"It seems like there are some superfluous words in this function name that don't help explain what the function does."

That way, it's a learning opportunity for them on what makes a good function name and you aren't directly confronting them. As an added bonus, they may fess up to the fact that they were just messing around and may feel some shame for wasting everyone's time.


Posted 2017-07-11T16:05:54.450

Reputation: 191

1"I wouldn't necessarily play dumb and pretend like I don't realize it's a joke," this part I think require some futrther explanation because it seems the "irreverant" part is quite important here.Jylo 2017-07-12T08:08:09.757

1"It seems like there are some superfluous words in this function name that don't help explain what the function does." It seems like that's the point the interns are trying to make about convertGallonsToMilliliters. I recommend you explain why convert is unclear and the longer one is worth the extra verbosity instead of trying to "handle their behavior". (And if you argue in favor of precision and they argue in favor of brevity, you might even end up with function names like gal_to_ml that combine the best of both worlds.)Ray 2017-07-12T21:48:49.843


If you have to remind people that you are in charge, then you never were.

It would be better to conduct a code walkthrough where the developer has to explain their code to those in authority.

  1. This instills personal responsibility for the outcome of the project
  2. Provides immediate professional feedback
  3. Give the developer a sense of urgency for completing the project

Utilize your leadership as a part of the team to uphold your organization's standards. Then, help the younger employees meet those standards and avoid embarrassment of presenting substandard work.


Posted 2017-07-11T16:05:54.450

Reputation: 49

4That first sentence doesn't seem to really add anything to the rest of your post. Am I missing something?Cypher 2017-07-11T22:24:18.500


Obviously, you need to get them to stop, but simply telling them to might not demonstrate why.

I know the 80 character-per-line guideline isn't a hard-and-fast rule, by any means, but trying to stick by it is good practice, so having a 48 character variable name is pretty dumb.

I'd suggest telling them to try and follow this guideline from now on, but also don't allow them to change the variable names they've chosen. Sort of a "you've made your bed, now lie in it" type of thing.

You'll get to try and hammer a new practice into their heads (assuming they aren't already keeping lines short), interns who don't understand why long variable names are bad are about to find out, and the "clever" interns will soon discover they aren't being as clever as they thought.

It's obvious to more experienced coders why convertToMillilitersBecauseIAmUsingSuchCleanCode is particularly bad, but rather than tell them "that's bad", force them to find out why. I bet you'll encounter far fewer verbose names, and with luck, fewer future attempts at being snarky as well.

Lord Farquaad

Posted 2017-07-11T16:05:54.450

Reputation: 1 216

1Unfortunately, with modern IDEs, long names are not nearly the coding pain that they used to be.cdkMoose 2017-07-11T18:26:18.163


This doesn't have to be "One Size Fits All".
All Sizes Fit Some:

Each of the proposed approaches can work out great, and may be the best approach depending on the circumstance. Here's my response to each of the approaches asked about:

Should I react by

  • laughing it off ("Yeah, it's funny but please remove it")

This is a great idea when: You have an excellent rapport with these co-workers, who have become good friends with

  • just asking politely to remove it

This is a great idea when: You want to be direct so there is no misunderstanding

  • telling that I don't like when someone wastes my time and they should take the code review more seriously

This is a great idea when: You wish to communicate annoyance, and stick to an authoritarian approach.

(I'm inclined to think you might be able to combine all of those approaches into a non-offensive, polite, funny way that does communicate there is a bit of actual annoyance. "This sort of thing must stop because it just makes me go [mock-scream] " just might be a humorous way to accomplish that.)

Personally, I like the friendly method. I'm a believer in that way of doing things. However, I will readily admit that there are times when such approaches is less effective.

But What's Best?
Your basic question is: "How should I react to this?"

Basically, what this question boils down to is like saying: "I need to get somewhere. Should I use a unicycle, pogostick, bicycle, or bus?"

Any one of those transportation approaches may be best. Similarly, to answer the question of how you should react: Your best reaction might not be my best reaction.

This is a key reason why, even though the different answers seem to agree that the interns' behavior is not suitable for production results, the different answers seem to favor different approaches. As noted, we may not have a single "one size fits all" approach that will universally work best for everyone.

We're dealing with people here, so what works best in some scenarios may not work as well in other scenarios. One of the key factors is you. Can you be stern without burning bridges? Can you befriend them by being light-hearted, yet ensuring enough compliance and inspiration to get desired results? What works best for me might work atrociously terrible for you. Ultimately, you need to make a judgement call on which of those approaches to take.

Flexible Teaching: Don't commit to just one approach.

Just choose whichever method you feel most comfortable with. Make sure you don't go overboard (bad/offensive humor, or creating an uncomfortably threatening environment in an effort to be strict).

No matter which of your excellent suggestions you decide to proceed to move forward with, keep a close eye on the results.

It's very possible for you to make a judgement call that doesn't work out as hoped. As long as you didn't cause any major problems, this may be very recoverable, if handled positively and quickly. That is one reason why you shouldn't worry too much about trying to make the most perfect decision. If things don't go well, your situation can work out fine. People are different, and learning can be unpredictable, and there needn't be any shame in a first approach needing modification. As long as you recover quickly, this can be a non-issue.

The key is to make changes as soon as you start to find undesirable results. Expect to need to adapt quickly. When some approach isn't working, be very ready to quickly modify the approach, or even entirely toss it out the window. If what you're doing isn't working, determine whether you're likely to be on the verge of a break-through, or if you need to try something different. (Getting feedback will help with this determination.) If you need to try something else, then do. Keep doing that until you do get working results.

As long as you act quickly (before long term feelings like bitterness start to take hold), minor imperfections can easily be brushed aside as insignificant compared to the positive results you achieve overall. (Just make sure that if things go imperfectly, the problems are minor. Major screw-ups may be a bit harder to forget. For example, attempted humor can be dangerous.)

For instance, if you find they start hating you, dreading the environment, etc., make sure to clear up any misunderstanding. Assure them that you're on their side. Encourage desired behavior. etc.


Posted 2017-07-11T16:05:54.450

Reputation: 2 292


Just tell the offender (personally or via e-mail) that the internship is hardly an appropriate place for such jokes and that they have to take it seriously if they want to start a career.

Ask them to fix the code, or (if you want to show some authority) just rollback their changes in the version control.

Dmitry Grigoryev

Posted 2017-07-11T16:05:54.450

Reputation: 3 667


Two years ago I was in a similar position to the interns at your company. I can picture a scenario where I would have done something similar. I think some interns have an issue with your authority; being pedantic and\or unprofessional. This is mainly due to a lack of respect my generation has towards elders and those in a higher positions. I would try the following methods to resolve the situation.

  • Earn respect of the interns by outwitting the "leader", "alpha".

  • Use the pedantic function name as a lesson to everyone, optimal function name length: goldilock's zone.

  • Point out a flaw in the "convertToMillilitersBecauseIAmUsingSuchCleanCode" function and suggest a rename to something appropriate(/demeaning)

  • Take no notice, ignore the function name; focus your time on the individuals that want to learn.

I would note the names of the unprofessional interns as a precaution.


Posted 2017-07-11T16:05:54.450

Reputation: 308

7Interesting. I am actually maybe only 3-4 years older than the interns, so they don't treat me with respect (though I have much more experience). The guy who did it is actually kind of an "alpha" there, so I will probably just write the name of the function on the whiteboard and ask the interns if they think it's a good name and how they would name it better. The name of that intern will be noted.Scramjet 2017-07-11T16:31:49.463

3@Scramjet I kind of like whiteboard idea. I was going to write answer where you should ask ridiculous, rhetorical questions to drive proper naming point home. Something like, Wow! Because of your "clean code" you can convert anything to millimeters?! I'm real curious how you convert 'Hello World' to millimeters! Asking others what they think a function does based off the name will definitely show the importancecheshire 2017-07-11T16:35:56.697

2"Asking others what they think a function does based off the name" xD I like that.Will 2017-07-11T16:49:53.220

6@Scramjet I think part of the problem is that they DO see you as a peer and not an authority. Go for a more aggressive, and most of all, HUMEROUS approach. He's trying to get a laugh at your expense, get a few at his.Richard U 2017-07-11T17:08:20.703

2These seem like terrible ideas. Frankly, as a non-intern, its the interns role to earn the respect of the person actually earning a living, not the other way around. If the OP could, I'd suggest dismissing the intern that committed the code for unprofessional behavior.Andy 2017-07-12T00:32:38.637

I think you are confusing a group of adults (over which the OP has management authority) with a pack of wolves...Lilienthal 2017-07-14T11:01:22.903


Should I react by

  • laughing it off ("Yeah, it's funny but please remove it")
  • just asking politely to remove
  • telling that I don't like when someone wastes my time and they should take the code review more seriously

How about "Understanding why they did this?"

Whenever someone does something you don't expect or desire them to, you can either react to it in order to make them do the thing you want them to or you can try to understand why they did exactly that.

It might be useful to understand why. If they are playful by nature but aren't getting to air their frustrations about something, this is how someone can channel it. We can all agree that this is not a positive way to channel it.

An alternative approach

So what is a positive way to channel frustration and playfulness? I've worked at companies where people sometimes did projects 10% of the time, like program a microcontroller to take a selfie with a dslr. Not only did they get free reign to do it, they were given responsibility to turn that into a shippable product. It went from a one-day hackathon to code examples that are now published on the company's website. People can take that example and turn it into a remote control for deep sea cameras that can be turned on with the click of a button.

My point is that pranks like this can be indication of untapped potential. If you want interns that conform to the standard you have in your company, this potential is not for you and in that case, consider letting them go. However, if you see the value of shaking things up, get these pranksters to create something useful with their pranks. Ultimately, it is up to you. Who do you want these interns to be?


Posted 2017-07-11T16:05:54.450

Reputation: 798


As a professional for almost 30 years now, I'd say the high-rated answers mostly have it right.

However, as a professional software developer for almost 30 years now, I'll say that coding guidelines are nearly always over-prescriptive. Even worse, often this is seized on by people more concerned with their Authoritah than with producing readable code. This kind of passive-aggressive behavior out of junior engineers is exactly what you typically see when that happens.

Putting silly things in code comments, or even identifier naming, is really a time-honored tradition among software developers. Here's an example of standards-induced protest naming from my own junior days (which got 48 upvotes).

If there's an issue here, it should be that there are legit readability/maintainability issues with their source code in your environment. I'm not saying the top answers here are wrong. They aren't. But when you see this kind of behavior from multiple junior engineers, then after cleaning up the bodies you should really look into if there might be an underlying reason your canaries keep dying.

The end goal needs to be code quality. Coding guidelines should just be their tool to help them get there, built by developers for developers, not some kind authoritarian program for how to write programs.


Posted 2017-07-11T16:05:54.450

Reputation: 267

Let us continue this discussion in chat.

Lilienthal 2017-07-14T19:22:40.170


It sounds like you have a very good example to show them of why using this type of coding convention is inappropriate, even for small projects like this.

You saw it.

Even if their project isn't being used by the company directly, it is meant to act as an assessment of their skill and, in part, as a learning experience for these interns looking to make their way into your company.

I wouldn't be too harsh on them - after all, this is just a trial for them - but I would definitely point out that, in the future, such coding practices could get them in trouble, especially if their next boss isn't as patient with them as you are.


Posted 2017-07-11T16:05:54.450

Reputation: 6 375


Starting by assuming good faith, my gut tells me the interns did this because they really cannot see any problem with names like convert. I would bet a small sum of money that the sarcastic names do not come from a desire to be rebellious but from frustration that they don't know how to come up with a better name, only a longer name. And that kinda-sorta is what you told them, right? Short bad, long good.

If you want these individuals to improve, you simply need to discuss, in the daily meeting, exactly why convert is a poor name and convertInchesToCentimeters is a better name. If you have an example from your experience of poor name choice causing problems, that will help them. That "why" will allow them to choose good names from now on - whether those good names are long or short.

Also let them know that it is OK to ask you or their peers for help or consult with them within reason, that this is not a test where everyone has to work alone, this is a collaboration. (I hope this is true!) Maybe that will allow them to ask questions and talk to each other, and resolve frustrations early, rather than wait for passive-aggressive stuff like this to show up in code review.

Only if such behavior continues would I find it necessary to explain, yes this is not a real application, but this exercise and the style guidelines should be taken seriously for multiple reasons:

  • It is worth my time to spend with you on this effort, when I could be working on "real" applications, so please give it your best effort also
  • This exercise prepares you to work on a real project that is serious and in which you must follow style guidelines
  • This exercise enables us to decide which of you, if any, to extend offers of employment to after your internship is concluded

While not exactly wrong, I think accusing them of disrespect, etc. at this point will likely silence the behavior, but will also not help them understand why they need better names or how to come up with better names. If you take this path, you might find them just coming up with longer bad names and avoiding your steely gaze.


Posted 2017-07-11T16:05:54.450

Reputation: 478

I'm not great at naming things either, but the name in the OP is something I'd never pick. This answer is a copout for the interns; they are in college and probably 20-somethings, they knew full well what they were doing.Andy 2017-07-15T01:51:08.783

+1 for mentioning that it might well be that they didn't grasp the concept of descriptive names and just understood "longer names". Doesn't shed a bright light on them, though.Nebr 2017-07-18T08:29:57.060


First of all, I don't think this is that bad. They put a joke in the code about a topic (name conventions) that they probably don't grasp completely. Placing some internal jokes in the code is not something new. Also, they may consider the code an "internal sheet".

I also disagree with the view that they wasting your time with this. If they make a commit just to rename a method, then yes, they are wasting your time, and the change should be rejected. But if they needed a new method and chose a poor name, the time to review would be similar with either name. I don't know if you are reviewing pre-commit or post-commit, but when someone wants to have code approved/merged, what they are doing is actually working against themselves, as they are simply adding roundtrips for actually getting the code accepted.

It is also trivial for you to rate negatively with wrong names, without actually looking at what the code does. The issue is that you feel annoyed at those names.

Now, nailing to the actual question on what to do, I recommend bringing up that they had some problems with name conventions and asking them to review the work from last week to see if they have been using proper names and think whether they would understand it easily in a few years / if they came new to that project. Have them prepare a short report about the functions they added in that week and shortly justifying it.

Ideally, that would be about a line per function, eg.

convertGalToml: Converts Gallons to Milliliters. Camel case was not used on milliliters abbreviation to avoid being confused with megaliters.

It is expected that while reviewing the code, they may notice new issues or think up a better name, eg. rename convertGalToml to convertGal2ml.

I suspect your joker will get the point and silently rename it.

The point is, function names are documentation. Although it is a more technical audience than eg. the user manual, they should be comfortable justifying their choice in front of their peers.


Posted 2017-07-11T16:05:54.450

Reputation: 391


You are not their manager, it even doesn't matter you interview them or not. You are an engineer like me,

So you know what to do, Talk to your manager and then suggest a code-review. Then advise them to not to write code like that via a system like code collaborator. You don't even need to email them or interact with them or take these stuff personally. Introduce a grading system based on that code-review. Don't try to control them or be their manager, or try people management. That's not your business.

Talk with your manager and keep that privilege to reject or approve commits after a review to yourself. Suppose each intern have an initial 10 points,and he/she should earn 100 points through your grading, and if they really want to join your team they will be motivated to score it. Not to lose any points.

If I was an intern and I'm working under you and you just a senior engineer, even I hate if you doing my people management. It's NOT your job.

It sounds to me that you have gone too far and it's gone out of control. Learn that lesson as an engineer. You are an engineer, not their manager to people manage them.

sandun dhammika

Posted 2017-07-11T16:05:54.450

Reputation: 292

Code reviews are not people management. Don't confuse the two.Philip Kendall 2017-07-15T15:56:51.573

No I never meant to people manage via code reviews. From OPs question , he mentioned that he is helping interns and involve with code reviews. So this nothing to do with people management. This is not the correct way to do a code review. I strongly argue this question about how to do a proper code review does not belongs to here either.sandun dhammika 2017-07-15T17:48:18.497

Code reviews are not people management. Don't confuse the two. which is my point. So why downvotes ?sandun dhammika 2017-07-15T17:49:16.123

You're saying the OP shouldn't be managing anyone but at the same time you're telling him to set up a gamified performance review system. But I guess the biggest reason you're getting downvotes is the questionable suggestion that a technical profile can't or shouldn't manage.Lilienthal 2017-07-15T22:52:17.890

It's a valid suggestion, HR managers should handle people management if necessary.sandun dhammika 2017-07-16T04:27:20.857


While the interns' behavior may be unprofessional, it's also unprofessional for management not to consider that they might be wrong. Clearly convert may be too short of ambiguous in many contexts, but convertGallonsToMilliliters is way too long for an identifier name. Rather than imposing arbitrary naming verbosity requirements across the board, you should challenge your interns to justify when a name they choose really is ambiguous (which they won't be able to do) and come up with something reasonable that improves program readability rather than hindering it.

This really feels to me like a case of the common pattern of "why aren't my subordinates respecting me?" really being a matter of "what about my own attitude is making it so that people don't respect my position?"


Posted 2017-07-11T16:05:54.450

Reputation: 794

Naming conventions are highly subjective. Rather than phrasing this answer like "OP, you're wrong", you may want to simply focus on the fact that it's a subjective topic and that justification from either side and letting them suggest something better on their own might be a better approach (although this is already covered in other answers). But it's anyone's guess whether OP would actually be able to convince them to conform to company standards (at the end of the day, any given employee should be able to ignore their individual style preferences if they conflict with company standards).Dukeling 2017-07-15T13:48:21.893

naming conventions should follow the rules in the existing project.sandun dhammika 2017-07-15T17:55:15.707

1I see nothing wrong with convertGallonsToMilliliters. I also see nothing wrong with convert if it is a general-purpose conversion routine. I do see a whole lot wrong with e.g. cvtGtoM, cvtGals2Millis, and various other abbreviated names. I like nice long names which spell out what a routine does - because I know from bitter experience that development happens only once, but maintenance continues forever, and the code you maintain may be your own. :-)Bob Jarvis 2017-07-16T03:12:37.923