201

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.

  • 126
    One 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 Jul 12 '17 at 1:22
  • 22
    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 Jul 12 '17 at 4:23
  • 56
    As 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 Jul 12 '17 at 4:44
  • 19
    @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 Jul 12 '17 at 8:40
  • 19
    @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 Jul 12 '17 at 8:45

22 Answers 22

277
+100

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.

  • 187
    this 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 Jul 11 '17 at 17:30
105

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 doesn't 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.

  • 50
    Agreed. 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 Jul 11 '17 at 17:47
  • 9
    I 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 Jul 11 '17 at 20:00
  • 20
    I'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? – candied_orange Jul 11 '17 at 21:19
  • 13
    @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 Jul 12 '17 at 0:42
  • 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 spirits – Tasos Papastylianou Jul 12 '17 at 10:42
45
+200

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.

  • 17
    First of all, forget about the coding conventions. The issue is not related to computers or programming. This is a really good point! – Cypher Jul 11 '17 at 22:15
  • 23
    Sorry, 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 Jul 12 '17 at 8:06
  • 6
    "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 Jul 13 '17 at 10:05
  • 10
    @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 Jul 13 '17 at 11:54
  • 7
    @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 "I.run()", 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 Jul 13 '17 at 18:34
33
+400

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.

  • 23
    @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 Jul 11 '17 at 17:01
  • 6
    @Cheshire they played the "exact words" game. This isn't one that's going to be solved with brute force. – Retired Codger Jul 11 '17 at 17:05
  • 29
    @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 Jul 11 '17 at 17:43
  • 7
    If 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 Jul 11 '17 at 20:19
  • 14
    @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 Jul 12 '17 at 1:05
24

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.

  • 7
    not 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 Jul 11 '17 at 20:12
  • 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 Jul 11 '17 at 20:23
  • 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 Jul 12 '17 at 1:30
  • 3
    It 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 Jul 12 '17 at 2:38
  • With version control around, this is fixed in 30 seconds by a single rollback. – Dmitry Grigoryev Jul 12 '17 at 14:50
20

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.

16
+500

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.

14

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.

  • 8
    I 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 Jul 12 '17 at 13:31
  • 2
    You 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 Jul 13 '17 at 11:57
  • @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. – user27051 Jul 13 '17 at 14:17
  • "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 Jul 15 '17 at 17:22
  • @user27051 then again, others will come if they hear you adhere to proper standards and get rid of people who are more in the way than help... – Frank Hopkins May 6 at 17:23
12

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.

  • 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 Jul 15 '17 at 22:46
9

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.

  • 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 Jul 12 '17 at 8:08
  • 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 Jul 12 '17 at 21:48
4

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.

  • 4
    That first sentence doesn't seem to really add anything to the rest of your post. Am I missing something? – Cypher Jul 11 '17 at 22:24
3

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.

  • 1
    Unfortunately, with modern IDEs, long names are not nearly the coding pain that they used to be. – cdkMoose Jul 11 '17 at 18:26
3

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.

3

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.

2

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.

  • 7
    Interesting. 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 Jul 11 '17 at 16:31
  • 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 importance – cheshire Jul 11 '17 at 16:35
  • 2
    "Asking others what they think a function does based off the name" xD I like that. – Will Jul 11 '17 at 16:49
  • 7
    @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. – Retired Codger Jul 11 '17 at 17:08
  • 2
    These 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 Jul 12 '17 at 0:32
2

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.

2

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?

1

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.

0

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.

  • 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 Jul 15 '17 at 1:51
  • +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. – Thern Jul 18 '17 at 8:29
0

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.

-3

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.

  • Code reviews are not people management. Don't confuse the two. – Philip Kendall Jul 15 '17 at 15:56
  • 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 Jul 15 '17 at 17:48
  • Code reviews are not people management. Don't confuse the two. which is my point. So why downvotes ? – sandun dhammika Jul 15 '17 at 17:49
  • 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 Jul 15 '17 at 22:52
  • It's a valid suggestion, HR managers should handle people management if necessary. – sandun dhammika Jul 16 '17 at 4:27
-4

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

  • 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 Jul 15 '17 at 13:48
  • naming conventions should follow the rules in the existing project. – sandun dhammika Jul 15 '17 at 17:55
  • 1
    I 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 Jul 16 '17 at 3:12

protected by enderland Jul 12 '17 at 0:00

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.