How to handle interns' unprofessional behavior?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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?

Answer 18

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.

Answer 19

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.

Answer 20

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.

Answer 21

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

Answer 22

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.