What to do in the situation of being encouraged to go slow as a student programmer?

Question

I'm currently doing a co-op term at a government position. It's my first co-op term and I'm really interested in learning lots of new things, as well as gaining practical experience.

Unfortunately, working ahead of schedule isn't exactly encouraged. I was added to an app late into its development cycle where I cannot be adding new functionality. I was asked to implement an authentication model, and when I'd done it, I'd been asked to take it back out. Not because it was poorly done, but because they had expected me to spend MUCH more time trying to figure out how to do it and they aren't ready for it.

I'm almost being forced to work less, which isn't what I want to take away from my co-op experience. I realize that I should be testing and that is really something that I could do continuously for the next eight months, but that's not really what I'm looking to do.

What are some ways that I can still take useful experience and learn lots, while being in this predicament?

Answer 1

Unit tests. Write lots and lots and lots of unit tests. They serve the dual purpose of not introducing new functionality to the system that they may not be ready for, and increasing the overall stability of the system through increased test coverage. Plus, they're a great way to get to know the system you're working on. And they're a non-trivial process, so you won't get TOO bored.

Answer 2

Talk to your manager or project lead. Let him know you're motivated, interested and "raring to go". Tell him to give you more responsibilities in a nice manner.

Showing the initiative yourself goes a long way, instead of wondering why you aren't being given the initiative.

Answer 3

In a situation like that where you are doing government work there is likely to be a set way of developing software that prevents you from being overly innovative or proactive at least when it comes to public facing tools and applications.

See if there are any internal tools that you can develop or modify that might help speed up segments of the development/production process, but don't require as much oversight to integrate them into the system. Definitely ask around about opportunities like that and make it clear that you want to work.

It's hard to say what else might be applicable and I'm making assumptions since we don't know what sort of software you are developing.

Answer 4

Welcome to government work! In all honesty this is really not how all government teams work. Where I am, we actually keep a pretty fast pace on the development cycle. I am sure you all have regular status meetings (government likes to talk alot), so my suggestion is to take the time to read through as much of the code as you can. That way you can get a strong understanding of the application. Try to find the weak spots, or things you see that could be better. Make suggestions to your lead and see if he/she is receptive to it. Either way in the meetings you will be able to provide your input on problems once you have a better understanding of the application. Once you have their trust they will give you more interesting things to do.

Good luck.

Answer 5

Government work is likely to have this pattern because there is no profit motive behind the project management. Advancing the project at any rate besides that mandated by the official schedule is pretty useless.

Instead you can spend time improving the quality of the code. McWafflestix suggested adding unit tests and this is a great place to start. Another option is refactoring poorly written code. Improve the style where work from different contributors differs from the project's standard. You can document existing API's.

Answer 6

I'd try and read as much as possible in the "down time" you've created for yourself. Also, to go along with your example, try and approach the problem from a different angle and mindset with the same end goal in mind. You may find a better solution to implementing your authentication model, or find weaknesses you hadn't thought of.

In either case, you are learning something. The corporate world doesn't always go the direction or the speed at which you hope. I'm not suggesting this is a good thing or a bad thing, but it does take some getting used to when you're coming out of a situation where you're always the lead. You may not like what you're learning in an "office politics" sense, but dealing with a situation and the parameters you're asked to work within is a lesson in itself.

Answer 7

The SOP answer here is: go to your Boss/Co-Op manager and tell them that you feel under-utilized and you want to do more.

That said, the risk with that approach is that they, not wanting the burden of coming up with more for you to do and then managing it, will say "do more testing and documentation". Important work, but not the greatest learning experience.

Better is to go to them with a plan or specific suggestion in the first place. One thing that you might want to do is to fish around for what other people are doing, and which people/projects could use some help.

Managers like self-starters, go-getters with initiative who are almost self-managing. So try to find something that interests you, that could benefit from short-term help from you and go to you boss with a plan for you to do it.

Answer 8

We have a co-op program where I work, too. The best of the student workers are curious, and learn about everything they are exposed to in their work environment. Take advantage of your slack time to learn everything you can about the organization, the position, how people work together, the processes, everything. The last co-op that was here that did this enthusiastically was well liked and respected, and if an opening is available, he will have a job waiting for him when he gets out of school.

If your work environment is anything like mine, there is a software validation and verification process that must be adhered to. This process alone could take weeks. Be patient and help the process along by being available to ask questions and offer assistance.

Has all of the supporting work, like documentation, been completed?

Answer 9

Boredom is a personal decision. Try viewing this as preparation for being married some day, or working at your next job. Ask your supervisor if you can watch "Groundhog Day" on some afternoons.

It's perfectly true that a bad work situation will threaten your well-being, but at least when starting, you must try hard to see if things may improve. Health and strength are gained by finding the hidden opportunities that may exist, and exploiting those. "Le Fete de Babette" ("Babette's Feast") may be helpful also, though one viewing is probably enough.

Oh yeah, do the Unit Test advice.

Answer 10

I see nothing odd or unusual about what they asked. They were basing the time estimate on the average student they have had in the past. If the rest of the app is not yet ready, of course they need it backed out or other stuff will break. You probably impressed them with being able to do the task at all (honestly you should see the total lack of ability many co-ops have).

You are also being judged on attitude even more than performance. If you come across as the smart kid who thinks he is better than any of the experienced developers, I guarantee you won't get good grades or much to do. Juniors are expected to take direction well especially if they disagree with it. So be eager, make sure that your boss knows when you finish something and make sure to ask for more, but don't come across as disapproving of them or their process or act as if the tasks you are being given are menial and beneath you. It can be a real balancing act, but performance in the work place always is.

You have to look at things from their perspective, you are a co-op, you aren't going to be there very long and someone else will have to support what you do. What incentive do they have to give you the more interesting stuff? This is a normal part of being the most junior, most expendable member of a team. You are most junior, you are going to get the most boring tasks. How you handle it is part of how you are evaluated in order to get the more interesting tasks. As a co-op you probaly won't progrees to really interesting as they know you are a temp. But learning how to be junior and to impress your supervisors while doing dull tasks is part of what you are there to learn (work isn't all about techology).

Aa a government office, I'm sure the project is large and complex. When you finish a task and until they give you another one, take time to investigate the current code in depth. This will help you immeasurably when you go to a non-co-op postion as you will earn how to understand the current system which will get you up-to-speed faster. If in doing this you see things that can be optimized, suggest a chnage. Wait until you understand the whole system first (or enough of it to truly know how hard it will be it integrate the change with the rest) and ask why they did it that way, you may be surprised at the answer, there are many constraints in developing software you are not aware of yet.

Ask your boss if there is something they have always wanted to have but have never been given the time or money to build. You can work on that when you finish something early and there is no new task yet ready for you. If you don't get it done in your co-op period, they haven't lost anything and you will have learned alot by trying to build it. If your boss won't give you a side project like that to work on, then decide what you personally would like to have if you were working there permanently and work on building that (do not do that during work hours though unless you have truly run out of work and asked for more but not received it, working on something unoffical because it is more interesting than the actual tasks you were given is a sure way to get shown out the door.)

And yeah, do the unit test advice. I think you will be surprised to find out how much you can learn about design, development and requirements from doing unit testing.

Another thing you can do is sit in on any code reviews you can. You can learn from what the more senior people see and you get exposed to a lot of code. If code reveiws aren't a part of your process, nothing is stopping you from asking for them from senior developers on whatever code you write. The more junior you are them more important it is to your development to start to see the perspective of the more senior people.

In a place where the seniors are good, they will ask a lot of questions about things that may have never even crossed the mind of a junior person. This is how you learn to start considering those things. For instance , in the example you gave, you did a task and then loaded it up to the project and then it had to be taken out becasue other parts weren't ready. Did you even consider if you should have asked how your code might impact other parts of the development process? If you didn't think of that, will you think of it next time?

Answer 11

Chris: If anybody has some truly excellent resources for unit testing, I would love to read them.

Well, I would definitely recommend a great Unit testing book from author Roy Osherove, The Art of Unit Testing.

On given link you can also find some sample chapters.

Answer 12

What are some ways that I can still take useful experience and learn lots, while being in this predicament?

Writing unit tests in order to get to know the program, as well as running it in a debugger (gdb), profiler (gprof) or memory leak detection tool (valgrind) will surely help improve your understanding of the program, and you might even be able to contribute valuable bug fixes at some point.

If you are also interested in keeping an edge while not at work, you might want to consider participating in related/interesting open source efforts in order to additionally hone your skills: If you decide for example to use an open source unit testing suite, you could start participating in the corresponding unit test project, too. Which would also help you better understand the tools you are using at work.

Similarly, working with gdb, gprof or valgrind while using your project, may show possible improvements to any of these projects, too.

Another thing that I would personally look into doing in your situation would be to start improving the source code comments as well as existing documentation, you could provide corresponding patches to your peers for review. Similarly, you could set up a wiki to improve the documentation.

If there is no formal issue tracking used so far, another thing to contribute to the project, without stepping on your colleagues toes, would be to set up an issue tracker like bugZilla or mantis. By volunteering to set up and maintain this initially, you will also get a better understanding of open issues in the source code. Which in turn provides you with new opportunities to help improve the project.

Initially, this could be as simple as splitting huge files into distinct modules, or do other minor refactorings that help improve the overall structure.