22

I'm a software developer who has recently been recruited by a company as one of the two lead developers (on separate by closely linked projects). I've been assigned a group of 2 interns who I am to train and help in their development, but I'm in California (SF) and the interns were recruited and are staying in Michigan, meaning most of the contact will be through email/skype/phone conferences. I admit, it isn't an ideal situation.

The largest issue right now is that one questions me about my coding style and organization, despite the fact that I am the more senior developer (and the fact that I code in Python, and he's a recent switch-over from Java) and my code usually passes code-review with less than two edits per thousand lines.

Now, the shocker - I'm a 16 (turning 17 in a month) year old high school student starting my senior year (12th grade) in August, while the intern is working as a post-grad. I've been working on open-source projects since when I was 13 and worked as an intern engineer at 14, so I have about 3 years of experience (2 of them have been non-intern), while the post-grad picked up coding a few months ago.

6
  • 1
    This question is related. But I think your situation has some unique elements which prevent them from being a duplicate.
    – enderland
    Jul 31, 2013 at 21:28
  • 3
    I read that one, but I think the difference is pretty significant - in that one the intern feels removed from the OP, while in mine the intern just doesn't think I'm quite qualified Jul 31, 2013 at 21:48
  • This question may also have some useful tips.
    – jmac
    Aug 1, 2013 at 3:58
  • 1
    How do your interns know how old you are? If they're long distance, it's conceivable that they have no idea how old you are. You might look 16 but there are some 25 year olds who look 16, too.
    – Irwin
    Aug 6, 2013 at 16:23
  • @Irwin We had a company meeting where the organization's leader went over everyone's qualifications in the lead management group, and that included me (and my lack of a high school diploma) Aug 7, 2013 at 18:54

7 Answers 7

18
+100

You have multiple problems happening here which need to be addressed separately. First you are significantly younger than the people who report to you and younger than people in professional positions are in general. Second, you are an experienced developer but not an experienced leader. Third, your subordinates are remote. Fourth, you may be perceived as looking down on them because they weren't high school programming prodigies (Note I said you may be perceived that way, not that you actually do. But in all honestly people tend to be intimidated by people who achieve something that is as far out of the norm as that is.) And fifth, the perception may be the opposite as well, that they will look down on you for your lack of formal education even more than for your age.

Dealing with being significantly younger

For the younger issue, this is likely to be a problem for at least the next ten years, so best learn to deal with it now. The key is twofold. First present yourself as professionally as possible. Use correct English grammar in your emails, don't make jokes that your high school peers would get, but which would not be funny to adults. While it is not applicable here due to the remoteness, dress professionally in meetings especially if clients are involved. People will have trouble taking you seriously, so you need to cultivate a serious demeanor. Let people know what experience you have in a matter of fact way. They will look at you and think, "He's so young" and you can't avoid that, but you want them to think next, "but he really knows his stuff."

The second part is to understand where they are coming from. Spend some time learning to understand the cultural history of the people you supervise. My sister likes to point out that different generations are alien to each other because they grew up in very different cultures. It is actually easier for the older ones to understand the younger culture as they at least saw it develop (not that the older people seem to do any better at this task).

For you it is harder because what is their culture is history to you (and if you supervised me, ancient history at that!) It might be useful to you to talk to people of the same age as your subordinates and get an idea where people of that age are coming from. Or read books/articles on cultural history if they are available for the age groups you are supervising. This link may be useful: http://www.beloit.edu/mindset/

Understanding what people of different age groups value and what their work expectations are will help you in knowing how to deal with them. But while are all exposed to the culture of our youth and it, to some extent, shapes our world view, we are also individuals and thus may not actually follow the norms (as you do not follow the norms of your own generation since most of them are not managing subordinates at your age), so talk to them individually and find out what their expectations of you are and what they expect of the workplace. Interns are tricky because (even though they are older than you) they are relatively new to the workplace and often have unrealistic assumptions about how things work. But to help them get rid of those assumptions, you need to talk to them and find out what they are.

Dealing with being an inexperienced leader

First you need to realize that getting them to do the work is your first priority. Yes sure you can probably do it faster yourself, but it is no longer good enough for you to do the work, you must teach them and mentor them so that they can do the work. You will need to delegate and given that you started work so young, you are probably good at what you do and it will be very hard to let go. Do not do their work for them. Do not fix their mistakes, but return them to them to fix. (How else will they learn?) Do not be a snob about how they do things. Ask them to fix incorrect work, yes, but when there are multiple ways to do something, do not insist that your way is the only way.

Treat everyone with respect. Listen more than you talk. But don't be a pushover either. Management techniques that work fine when everyone is a dedicated employee with a lot of skill fall apart completely when you have a problem employee. Since you seem pretty self-motivated, it may be hard for you to realize that many people need to be supervised more closely or they won't produce much or do anything more than adequate work.

And sometimes they have personal problems that affect work. Likely you haven't run into that much yet, but people get divorced, they have deaths in the family, they have drug or alcohol problems, they have personality problems that make them hard to work with. You have to learn to deal with things on a professional level while still showing some concern about their personal lives, it is a hard line to straddle sometimes. Keep your focus on performance and cut some slack when a really big problem occurs. Be prepared to rearrange the workload if a someone goes to the hospital or loses a family member.

It may have seemed intrusive when you were not managing people , but managers need to know the status daily of everyone's assigned tasks. Are they on time, are they behind, are they stuck on something they can't figure out. Are there roadblocks that are keeping them from finishing something,. It is now your job to remove those roadblocks as much as possible.

Remember it is a whole lot easier to be more restrictive at first and then ease off as they prove themselves, than to start off giving them lots of freedom and having to rein them in later because they couldn't handle it. Now I'm not saying to micromanage, but you will need to make sure they know what company standards to follow and what they need to do in relation to things like timekeeping and how much daily communication you expect from them and what you expect in terms of knowing progress. Don't let them flounder around for weeks and then have to come down on them hard because they haven't done anything.

Make sure to treat everyone well whether you like them or not. You are here to work with them not be best friends. The better you treat people the easier they are to deal with.

Dealing with remote subordinates

Communication is the hardest part of being remote. You need to set communication standards for them from the start. How accessible will they be? How often do they need to touch base with you? How will you deal with the person who never responds to emails, phone calls and IMs. Is he really working or not? If at all possible meet these people in person. We have a lot of remote workers and if we bring them to the office for a couple of weeks, we seem to build better relationships with them. They are more likely to contact people they know, they will be more relaxed around you once they see what your personality and work habits are.

Dealing with the perception that you are looking down on them

If you treat people with respect, listen to their ideas and actually change your mind if they sell you on a particular point, you will be most of the way towards convincing them that you are not a snob who thinks everyone who didn't start programming at 8 is an idiot.

Another good technique for getting people to humanize you is to admit to mistakes. Sometimes when I am dealing with someone who is junior to me and he makes a common mistake or is embarrassed that he didn't see something, I point out a time when I made a similar mistake. I sometimes point out that the reason I know how to fix something is because I broke something in the past. You are less intimidating when you let people know you don't think you are perfect.

Try to learn from them too. They may very well have learned some things in their college education that you haven't learned yet from practical experience. I have found that even people I don't much like or respect have often had things to teach me.

Dealing with the perception that they are looking down on you

It is possible that they will look down on you because they have more extensive education than you do. It is hard for someone with a Master's degree to work for someone who hasn't graduated from high school yet. Be sensitive to this. But call them on it they treat you with disrespect. Make sure your own boss will support you if they try to go around you when they don't like a decision you made. Nothing ruins credibility faster than a first-line manager that the people above him won't support.

You may have to rein in some of their more abstract notions too. You are in the practical world of deliverables and deadlines and maintaining the product. Some of them might still be in the pie in the sky theory world. You may have to help them come down to earth with practical questions about how long things will take and whether the client will pay for a solution at that level, etc.

If possible having someone much more senior in the company introduce you to them can help as well. When they understand how much respect people in your company have for your skills, it will make them less inclined to think you are someone they can ignore or discount.

1
  • 1
    I have found that even people I don't much like or respect have often had things to teach me. QFT. It also helps that generally these people are more than willing to tell me about it, too...
    – enderland
    Aug 7, 2013 at 14:11
21

Welcome to the world of work, Snakes. In my last 9-5 role as both a Sr Developer and eventually Manager, I reported to a VP who was 10 years younger than me. In the Real World™, age is moot. It's about capability.

I have two pieces of advice for you:

1) Never mention age as an issue between you and a colleague. It can very easily be pegged as discrimination, and is just as serious as ethnic, sexual or myriad other topical discriminations. The issue you have here is not one of age, no matter how poignant age appears to be on the surface. The issue is capability.

2) Never allow others' questioning your capability or authority to be anything other than an opportunity to validate your role. As a leader, you have to constantly prove you are capable to those who doubt; that's part of being a leader. That does not mean to smash down the non-believers. It means to act like a leader, and inspire your team to follow you by example. In this case, examples are solid code. That's an easy one, as long as you write solid code. So just do that, and let your work speak for itself.

Bear this in mind: if your reports think they're better at your job than you, then one of two things holds true: a) they are, or b) you haven't properly illustrated your capabilities to them. So answer their questions when they ask, rise to their challenges when presented. Just don't do it out of anger, annoyance or pride.

  • Consider that their questions might be valid.
  • If they aren't valid, treat them as though they were anyway.
  • Provide thoughtful answers.
  • Be objective.
  • Be civil.
  • Make sure you document your conversations, in case you need to refer to them later. Unfortunately, in the Real World™, a little CYA is always good idea.
  • Ask your boss for advice. Just like that. "Hey boss, I need some advice."

In other words, be a professional: do your best work, always, and treat your coworkers thoughtfully, always. Take the high road, always. Others will respect you for it, and you'll maintain your self respect as well.

Pretty simple life methodology, too, come to think of it. ;)

Best of luck.

4
  • This response was exactly what I was trying to express but you put it much better into words than me.
    – cYn
    Aug 1, 2013 at 21:55
  • FYI, Age Discrimination in the US is protected by the AEDA which only applies to employees over 40. In that sense age between a 16 year-old and a 20-something is not on the same level as discrimination on the basis of race or gender in the US according to the law.
    – jmac
    Aug 6, 2013 at 0:28
  • 2
    Lot's of good advice (+1) but “In the real world, age is moot” sounds like wishful thinking and/or culture-specific.
    – Relaxed
    Aug 8, 2013 at 4:23
  • @Annoyed, during the interview process, I am forbidden from asking a candidate their age, among other things. Even if I weren't forbidden, it wouldn't matter to me anyway. That said, I'm aware that there can be undercurrents and yes I am speaking idealistically. But as jmac pointed out, the law only addresses 40+, and this question wonderfully illustrates how it fails its own ideal. So I'll concede that you're right, but contend that it doesn't mitigate my advice. Thanks for the +1!
    – kmunky
    Aug 9, 2013 at 20:24
6

Executive Summary

"Age is an issue of mind over matter. If you don't mind, it doesn't matter."

-- Mark Twain

You are the lead programmer, and with that comes certain responsibilities. Regardless of age or experience differences, you need to fulfill your end of the deal to your employer, and so does the intern working under you. That should be the focus.

Age vs. Experience

Take a 15 year-old and a 30 year-old doing the high jump. The 15 year-old will throw themselves in to the act, and have a far higher chance of making the jump even though the 30 year-old is much taller and stronger. The 15 year-old doesn't know if they should be able to do it or not. The 30 year-old knows that it will really hurt if they screw up and will end up doing it with reserve.

Take the same two people and have them ask someone out. The 15 year-old will hem, haw, delay, and generally inflate the importance of the event, while the 30 year-old will just get it over with. The 15 year-old hasn't tasted failure and doesn't see the long game, while the 30 year-old has experienced their share of rejection, and knows there's always next time.

Both age and experience have their merits, but humans will typically see more merits in whichever approach is closer to their own. Trying to change their outlook from the get go will be less successful than understanding that there will be differences in perception and finding a way to overcome them to produce effective work.

State the Obvious

If both you and this intern feel there is a barrier due to age, I would address it up-front. I would probably have a chat with him over Skype and state something like:

It is a bit new to me to be working with an intern who is older than me by X years. While I teach you about programming on this project, I hope you will help share some of your experience with me so that we can both learn over the next Y months, and produce better work by sharing our strengths.

After stating the obvious (that this is a new experience for you), the goal is to clearly state that you have things you will teach him (that is why he is there), but to acknowledge that you respect his experience and don't want him to feel that you don't. Ultimately, the goal is to use the resources you have to create something good in the end.

Focus on the Work

Clearly outline what needs to get done on both sides. You are the lead developer, you are responsible for the project, and making sure that he understands what his position is at the moment. I would suggest something like this:

Since I am the lead developer on this project, I'm ultimately responsible for the quality of the code. While part of my responsibility is to let you guys know how our code is written and organized, and I am more than happy to discuss it, at the end of the day the code that gets committed is my responsibility. In turn, you guys will be evaluated on A, B, and C, so your priorities should be to get up to speed on our code base and this project, so that you can start helping to contribute.

I would make very clear that you are the lead developer and that you are responsible for the code quality. You should invite questions on your code and organization, but at the end of the day it should be clear that you are the one making the decisions in regard to it. If you are going to be evaluating them on their code or contributions, be sure to state that clearly as well.

Be Transparent to your Bosses

Let your bosses know what you are planning to have the interns focus on, and be sure to understand who will evaluate them and on what. If you haven't done it, obviously have this discussion before talking to the interns about how they will be evaluated. Send regular updates to your bosses letting your bosses know their progress, any special successes, and any potential issues.

On the side, let your boss know that one of the interns seems to have an issue with your age, and that you will handle it. Something like:

Hey boss. One of the interns in Michigan is a decade older than me as you know. I don't anticipate that it will be an issue I can't handle, but I wanted to make you aware. I really appreciate that you guys focus on my ability rather than my age, and would appreciate if you guys continue to do the same.

The point here is to tell your boss, "There is a potential issue here I'm trying to handle, I'm not asking you to get involved, just asking you to be aware in case something comes up." If your intern tries to go over your head, your boss will be able to deal with it better (and hopefully back you up/let you know so you can handle it yourself).

Assume the Best

Your interns may be older, but they are also starting a new challenge of their own. They may be feeling nervous or awkward themselves, and this could just be a temporary way of coping with that stress. Assume they are both good people who will appreciate your talent and experience long-term if you are fair and do a good job teaching them.

If you lay out the groundwork to establish a good working relationship, you should be able to build on it and get the kinks out of the system. In the meantime make sure your managers understand the situation so that they don't get surprised just in case something goes wrong.

At any rate, communication and reporting with people in different places and of different ages is something that will be useful in any stage of your life, and will give you a lot of lessons you can apply in the future. Best of luck!

5

Is the intern questioning you as if you're writing crappy code or is the intern questioning you because he wants to learn? I think you feel that with your experience, your coding is far superior than they are but there are a thousand ways to do things. Yes some are more inefficient than others but that doesn't mean you can't be open to what other people say about your style and organization or suggestions.

You might have a lot of experience in coding, but you're young. You lack the experience of leadership, which is the position you're in. Speaking from experience as a SGT in the Army, being a leader doesn't mean always being right. When they ask you something about your code, explain it to them. Give them reason. Subordinates never do well when you leave them in the dark. When they suggest something, don't brush them off. Listen to it, think about it, be open to it, and again give them explanation and reason on why you think it would or wouldn't work. The moment you discredit your subordinate's ideas is the moment they lose motivation to contribute to the work. If you want to get off on the right foot with them, make them feel like they can contribute.

4

It's not going to be possible to meet over a beer, or in another social situation to break the ice. That would have helped since it would remove the need for either of your to prove your status as the "expert programmer". I'd recommend you use Skype or phone calls rather than emails - which almost always come over as authoritative an impersonal.

Also, put yourself in the other guy's shoes. He's a few years older than you and will find it hard taking instructions from someone who he might consider a kid. I would suggest that you listen to what he says - I still learn stuff from my juniors, even one who are half my age! It might also help when given those confrontational "Why do you do it this way" questions to deflect them with an answer like "Well, I have looked at a few ways of doing it, and have found this the best way for me". Also bear in mind that programming style and code organization are very personal things, sometimes there is more than one best way of doing something and it just depends on personal preference.

I guess the main thing to remember is that when you're in a position of responsibility, you spend a lot of your time listening. If you want to make someone do something then the best way is generally not to force them, but to lead them to work out for themselves that what you are suggesting is actually the best way. If you lead, then often they will follow, but if you force them they will rebel. That's probably why we are called leaders, not enforcers.

1
  • 11
    The OP isn't old enough to buy a beer. Aug 1, 2013 at 15:16
3

What does "questions" mean precisely?

Is there any way to interpret questioning your style and organization as an attempt by an intern to learn something? Particularly when you're communicating via email, it's very easy for tone of voice to get lost. If the intern is coming from an academic programming background and from a different language, it's likely that there are lots of things that you are doing that are unfamiliar to him and that he would benefit more from learning why you are doing it rather than simply copying what you're doing.

Even if you don't think that's what the questioning is really driven by, if there is any way to interpret it as the way the intern gains additional background, answering as a mentor trying to help is probably the right way to go. If you demonstrate that you welcome questions and that you're open to other points of view but that you have well thought out reasons for doing things a particular way, you make it much easier for the intern to realize that he's potentially being presumptuous. If you listen to the intern's concerns, suggestions, and alternatives, you'll probably find cases where there are pros and cons of both approaches and good programmers are split on the merits of both approaches and cases where you're doing things out of habit rather than having particularly solid reasons. Some of these may provide interesting and informative discussions for your interns to have. You'll probably find cases where you're happy to provide a bit of flexibility if the intern has a strong opinion and, hopefully, you'll find occasions where the intern makes a good point that might change your opinion a bit.

1
  • Particularly when you're communicating via email, it's very easy for tone of voice to get lost. Important point, +1
    – rath
    Aug 4, 2013 at 2:47
0

You will always face people questioning your capabilities, wether you were 16 or 61. Skepticism is good in the workplace, it helps employees learn faster. Part of the senior job is to be able to communicate their knowledge, so hone your communications skills. Explaining yourself clearly will lead people to believe in you, trust you, and consequently follow you.

You must log in to answer this question.

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