How do I get the most out of my co-op job?

May 23, 2012 1:24 PM

Programmers and other IT folks: what advice can you give a programmer co-op student to help her get the most out of this summer job experience?

I'm almost a month into a summer co-op doing some programming (along with two other students) at a large company. What I want most out of this is to learn how to be a more skillful and knowledgeable programmer. I've learned a few things so far, but not nearly as much as I had hoped. Our team lead is too busy to give us much guidance. To give you an idea of what we are doing, we were given a .NET application to re-target to 4.0 and refactor (largely, do whatever ReSharper suggests). While we're done with that one, I'm still not sure I understand what the program actually does and how it does it. We're about to do the same with another application - happily, there is more documentation for it. Things seem disorganized. The company does not have coding standards set up. For this next project, we apparently won't be able to test our code with any data. I feel uncomfortable with the lack of structure. Maybe this is typical, though.

Luckily, we have great access to a lot of employees who are happy and enthusiastic about helping us. I just find that I don't know what to ask them. Also, sometimes I feel a little afraid to reveal the extent of my ignorance. I don't know how to make the best of all of this and to get the most out of such a great opportunity. I find that I roam Google pretty aimlessly trying to learn about technologies or coding techniques that I'm encountering, but things aren't really fitting together for me.

I apologize that this is a pretty rambling question. What I'm looking for is advice, from new or seasoned programmers/IT people. How do I really take the reigns here and walk out this at the end of the summer feeling learned and accomplished?

posted by kitcat to work & money (13 answers total)

Also, sometimes I feel a little afraid to reveal the extent of my ignorance

This is the #1 thing you need to work on. The field is vast, and after you've been programming for decades, you likely will still have only touched a small part of it. Embrace your ignorance. There is no better employee in IT than someone who asks the right questions.
posted by empath at 1:41 PM on May 23, 2012 [6 favorites]

Although, I guess I should add, your co-workers are working on stuff also, so you don't want to pepper them with questions non-stop. You want to be at least a little bit economical with your questions so you don't waste their time. And also, try not to ask about the same thing more than once if you can avoid it. But in general, absolutely do not be afraid of looking dumb for asking about something you aren't familiar with. You can always couch it with "It's been a while since I've done this", or "we only spent a week on this in class," if it makes you feel better.
posted by empath at 1:46 PM on May 23, 2012 [1 favorite]

Also, sometimes I feel a little afraid to reveal the extent of my ignorance.

DON'T THINK THIS.
Honestly, most people you work with probably already consider you at least as ignorant as you really are, if not more so. So it is going to be difficult to decrease their expectations/opinion of you by asking questions. I work with interns and new college hires, and the number one indicator of future performance I've seen is ASK ALL THE QUESTIONS. Caveat - there are dumb questions. Here is a guide to not asking those ones.

For instance, for the program you just finished working on - do you understand what ReSharper suggests and why, each time? Would you recognise the original problem in new code next time? If you don't understand the problem it identified and can't find a good explanation on the internet, ask a co-worker.

Is there no documentation for it? Is it something anyone will ever want to use? Write the documentation - now you have structure for going around and asking people what it does. But first write down all your assumptions and guesses and what made you think that, so you can cross check this with the information you get. If they tell you it does something that doesn't sound like it matches the code you read, ask them about that mismatch, to explain the code to you.

Do you have an individual who is your mentor? Do you have regularly scheduled meetings with them to ask your questions? (Like, minimum an hour a week). If not, can you set one up with someone? What did they promise you in terms of development, going in?

If they have no coding standards, is there one [or more] engineer who is considered the 'expert' or who cares about that kind of thing? Do they have code reviews for each other? Are you included?

Find someone who is interested in a topic and ask them to come and answer questions from the three of you for half an hour - maybe refactoring in general, maybe the domain knowledge of the program. Ask them if anyone else would be interested, it could turn into a Tech Talk for the entire team.
posted by jacalata at 1:48 PM on May 23, 2012 [2 favorites]

I've been on the other side of this, and it's unfortunate that you're having this experience. I suspect that the lead is unfamiliar with what it takes to accept a co-op and now doesn't really know what to do with you. Done right a co-op can be rewarding to both sides, done wrong everybody is unhappy.

Start by meeting with the team lead and ask if he/she can assign you someone from the team to be a mentor. Let them know that you recognize they're busy and this might take some of the load and expectation off of them. It should be phrased in a manner that doesn't seem critical of them.

Nobody expects a co-op to have the experience or skills that a permanent employee has (or they shouldn't). This means that what ends up being handed to a co-op is generally of the type "what can I offload that I'm ok if it's not absolutely perfect or doesn't require a whole lot of deep thought?", at least until they have a sense of where your skills lie. This generally means scut-work of some sort, unfortunately. If on the scut-work you demonstrate ability it leads to more interesting work.

The best co-ops I've had were the ones who had a deep curiosity on what we did and were willing to be interactive. The one's who would respond to tasking with either "OK, I understand", or "I have a question about X subtask", or "What do you think about this alternate solution". The one's who were willing to speak back to me asking for clarification or guidance. The one's who just responded with "OK, I got it" when what they really meant was "Words came out of your mouth but I don't understand them and I'm afraid to ask for clarification 'cause I'll look dumb" ended up being very frustrating 'cause they'd then go off and do something that required re-doing. The amount of work for answering questions and clarification up front is less than a re-do.
posted by Runes at 1:58 PM on May 23, 2012

The question I think was rhetorical, but for reference, yes, we have 'buddies' and while they're very busy, we can generally go over to their desks, talk to them on Communicator whenever, and go for lunch with them once a week or even coffee daily. They work on different stuff, though.
posted by kitcat at 2:00 PM on May 23, 2012

Ask question to understand the "why?" of what you are doing. This is espacially true of your applications true purpose.
posted by mmascolino at 2:45 PM on May 23, 2012 [1 favorite]

Co-op jobs have several functions, from a manager's perspective, including:
1. A duty to help train new programmers, for the good of the field (especially things like coding best practices and project/task management, which universities don't focus on).
2. An opportunity to evaluate students' coding skills with a view to hiring them on graduation.
3. An opportunity to seduce soon-to-be-graduates so they'll want to work for you and/or refer their classmates.
4. An opportunity to get some work done. Usually work that won't need support as you'll be leaving in a few months.

It sounds like the co-op isn't working that well on 2 and 3, and it could do better on 1.

Depending on the manager, it's possible 4 is your manager's main priority, but IMHO that's unlikely. If I were you I'd have a chat with him/her and try to establish what his/her priorities are. It's possible that the company isn't on course to get out of you what it hopes to get out of you (in terms of 3) which is the sort of thing managers sometimes need to have brought to their attention.
posted by Mike1024 at 4:38 PM on May 23, 2012

Mike1024: Do you mean manager, or team lead?
posted by kitcat at 5:54 PM on May 23, 2012

Here's what you should do. When you get a task done, instead of surfing, find an experienced engineer and ask if you can sit with him/her and watch them work. Just watch. When you get comfortable, start asking the the why and how questions. Eventually you should be able to help catch bugs as they're being typed in.

This is called pair programming and we do it in the big leagues and it's considered a Very Good Thing. I'm the most senior coder in my shop (they call me an architect at this point) and I make it a habit of grabbing other people when I'm working on sticky or interesting problems. Why? Because it disseminates knowledge and allows other people to see directly what I'm working on and how I work. If I can get other people working on my code, it makes it easier to delegate later and also answers the big question, "what if I won the lottery?" (most likely, I would work for $1, so I usually refer to it by the more negative, "what if I were hit by a bus?").

Don't just work with one person. Look at a variety of styles. For example, I have made my peers turn white when they see how fast I use copy/paste coding (which you should avoid when possible because it suggests better factoring is needed), but over the years I have also developed skills to make it less error-prone. On the other hand, I refactor like a demon and eschew refactoring tools except for the most trivial of refactoring. Why? Again, I have learned techniques to make the compiler do most of the work for me.

Best of luck.
posted by plinth at 6:20 PM on May 23, 2012 [1 favorite]

I would add that you probably ARE learning more than you think, just by spending 8 hours a day doing coding. You'll make mistakes, and fix them. Things that seem to work in a small program will be confusing as the program grows.

If possible, when you've finished a piece of coding, ask someone - your "buddy", or the team lead, or someone who seems helpful & interested - to sit down with you & go over what you've done. Ask questions. Not just, "will this work" but "would you have done it this way?" and if not, why not?

If they don't want to "waste their time" doing this, then you've pulled a lousy co-op assignment. Tell your friends when you get back to school.

(this is from a manager who currently has a couple of co-ops, who I hope are having a better experience than you are)
posted by mr vino at 6:58 PM on May 23, 2012 [1 favorite]

To be honest, you're probably not going to get very interesting projects to work on, and that's because you're just seen as cheap labor to do the "grunt work" (implementing what ReSharper says is definitely in this category). So if you want to get something out of it, you're going to have to look beyond the actual coding you're doing.

Ask yourself "How does this app work?", and figure it out. Learn how to read code. Visual Studio has a great debugger, so use it and step through the app, line by line as it runs. For us devs, stepping through someone else's code is our equivalent of an golfer watching slow-motion golf swing technique videos.

If there's one thing I'd like to improve with my peers, it would be how to debug a problem. Find the person in the office who has a reputation for fixing things, and ask them to step through some bugs with you. Everything is literally in front of you, you just need to know where to look--but that's what comes with experience.

Learn what tools others use to get their job done. Efficient coders don't just stay in Visual Studio all day long--they open up other specialty apps to get certain tasks done easier. Start building your toolbox.

What others above said about hiding what you don't know is very true. Honestly, it is the first thing I look for in an poor performing employee--not letting others know what you don't know.

So use this experience to figure out if this is really what you want to be doing for the rest of your life. It's not for everyone, and the environment you're in isn't uncommon. You seem like a person who likes a lot of structure, and while software engineering would seem suited for the structured person, it actually can be a disability. Software is more like an art form than a science--there are many ways to do the same task, and the best way isn't always obvious.
posted by razdrez at 9:15 PM on May 23, 2012 [1 favorite]

Can you get a project manager to spend an hour telling you how a project goes through its life? Or sit with a product manager and hear how your code updates will fi into the product's long-term lifecycle?

The coding is only a small part of the whole organization, and getting some context might make you feel better. :7)
posted by wenestvedt at 7:22 AM on May 25, 2012

(sorry for the slow response) kitcat: This depends on the organization. Where I work team lead is the most junior of managers, and it's at the level above that decisions about what co-ops should do is taken. At my organization I'd go directly to this person, but some places this would be "going over my boss's head" and bad form.
posted by Mike1024 at 1:34 PM on May 27, 2012