First, we expect you to come to work and do your job. We expect you tell us in advance if you are not going to come to work. That seems really obvious, but some of the young people I have had experience with (not necesarily only developers) didn't seem to grasp this. They generally got fired if they didn't change their ways. Yes salaried means you don't have to work exactly 40 hours, but it doesn't mean you can get by with working only 10 either. I can remember one sales guy we hired who thought he could stroll in at 10, take a two hour lunch (not even with a potential client) and leave by 2:30 or 3. He didn't last long. Yes there is some flex, but when you are new, it is best to check with your boss about how much the organization will tolerate. Some places people come in at ten or 11 and stay until late in the night, other places need and expect people there by 9. Learn what your organizational norms are and live with them until you have a track record of accomplishment. You can ask for more flexibility when they know you will deliver.

We expect you to tell us if you have nothing to do.

We expect that, as the most junior person on the staff, you will get a lot of the most boring, least complicated work. (I mean really, if I have a task that must be done that no one particularly wants to do am I going to give it to the guy who makes 125K or to the new guy who makes 50K?) How you handle that will tell us whether to give you more interesting assignments. Expect that once you pass the boring test, the assignments can be much harder than what you did in college. It is not unusual to feel out of your depth.

We expect you to follow company coding standards, use our source control, check in work frequently to source control, follow our software development process, use the tools we are using unless you get permission (Or are told that people can choose their own tools), document your work using the prescribed documentation if there is any. There are reasons why we have all these things - they make it easier to manage complex projects. Cowboys who do what they want and ignore the company needs don't last long.

We expect you to have questions and to ask them. But we expect you to learn from those answers and not keep asking the same question repeatedly. We expect you to be able to generalize answers from one situation to the next.

We expect you to fill in timesheets and to do it on the schedule we requested. If we charge to clients, timesheets are critical to being able to manage the client expectations of how much money they are going to owe us this month and how well we are doing at billing our time. This is particulary true for support time which may be limited. Suppose client A has authorized 300 hours of support time this month and developer b doesn't bother to fill in his time sheet on time. By the end of the month we may go over the hours and have to eat the costs because we didn't know about that 80 hours developer b was going to charge from the beginning of the month. Had we known, we would have put some projects off or asked for more hours. Companies are not fond of eating costs. In fact, they can get right cranky about it especially if you cause it to happen multiple times.

We expect you to be part of a team. That means you don't own the code, there will be decisons you will have to implement that you don't agree with and others may change your code or require you to do so after a code review. It also means that people should make time to help each other out and answer questions. It means we expect people to pitch in sometimes and do things outside their job description for the good of the whole project. Sometimes that includes making copies of a Power Point presentation for the client meeting.

Expect that the code base will be much more complicated than any examples you had in school. They tend to use straightforward examples in school, the real world is often a messy mix of ten years of business rule changes and technology changes (that may only be applied to items that need changing for other reasons). Expect that data is far more important than you ever thought it would be.

Expect that you will hate the code base and wonder why these people did such a lousy job. Please try to remember that we often designed parts of this system before cool tool XYZ was available and the techniques used may have been the best available at at the time. Most of us don't have time available (and most companies aren't willing to accept the risk of new bugs) to change working code just because some new cool thing has come out. And oh yeah, some of that ten year old code was written when we were juniors and didn't know as much as we should have. We cringe when we see it too. But refactoring is a business choice not just a development choice.

Expect that people will not listen to your wonderful new ideas until you have proven yourself. That means by successfully delivering software using the current system.

Expect that older developers actually often do know more than you do. Expect that you will have to deal with them even if they don't and that you will not be allowed, for the most part, to only deal with your age peers.

Expect that you have very much overestimated your skill level. Most junior people do. Expect that when you have ten years experience, you will cringe at that code you wrote back then too! Just like the rest of us.

Expect that your manager and the project manager (if it is a different person) have a right to know what progress you are making and even to see the code in progress. They have to report to various people too. We don't want to see you playing for three weeks and then pulling an all-nighter to punch out some code at the last minute. Well at least the competent PMs don't want to see that. We expect you to actually make some progress every day and to tell us or show us what that was. YOUr days of procrastinating until the day before the deadline should be over.

We expect you to try at least some to figure out the answers to your questions. We are busy and don't want to tell you somthing that ten seconds of Googling would have found. People will be more receptive to questions that are specific to the product or business domain you are working in rather than syntax.

If we have written requirements, we expect the product you give us back will fulfill those requirements. If the requirements don't make sense, we expect you to push back and ask questions. If they are missing key information, we expect you to tell us that too. But in the end, when all the questions are answered (even if you personally don't like the answers), we expect that you will deliver what we asked you to deliver.

• First, we expect you to come to work and do your job. We expect you tell us in advance if you are not going to come to work. That seems really obvious, but some of the young people I have had experience with (not necessarily only developers) didn't seem to grasp this. They generally got fired if they didn't change their ways. Yes salaried means you don't have to work exactly 40 hours, but it doesn't mean you can get by with working only 10 either. I can remember one sales guy we hired who thought he could stroll in at 10, take a two hour lunch (not even with a potential client) and leave by 2:30 or 3. He didn't last long. Yes there is some flex, but when you are new, it is best to check with your boss about how much the organization will tolerate. Some places people come in at ten or 11 and stay until late in the night, other places need and expect people there by 9. Learn what your organizational norms are and live with them until you have a track record of accomplishment. You can ask for more flexibility when they know you will deliver.

• We expect you to tell us if you have nothing to do.

• We expect that, as the most junior person on the staff, you will get a lot of the most boring, least complicated work. (I mean really, if I have a task that must be done that no one particularly wants to do am I going to give it to the guy who makes 125K or to the new guy who makes 50K?) How you handle that will tell us whether to give you more interesting assignments. Expect that once you pass the boring test, the assignments can be much harder than what you did in college. It is not unusual to feel out of your depth.

• We expect you to follow company coding standards, use our source control, check in work frequently to source control, follow our software development process, use the tools we are using unless you get permission (Or are told that people can choose their own tools), document your work using the prescribed documentation if there is any. There are reasons why we have all these things - they make it easier to manage complex projects. Cowboys who do what they want and ignore the company needs don't last long.

• We expect you to have questions and to ask them. But we expect you to learn from those answers and not keep asking the same question repeatedly. We expect you to be able to generalize answers from one situation to the next.

• We expect you to fill in timesheets and to do it on the schedule we requested. If we charge to clients, timesheets are critical to being able to manage the client expectations of how much money they are going to owe us this month and how well we are doing at billing our time. This is particulary true for support time which may be limited. Suppose client A has authorized 300 hours of support time this month and developer b doesn't bother to fill in his time sheet on time. By the end of the month we may go over the hours and have to eat the costs because we didn't know about that 80 hours developer b was going to charge from the beginning of the month. Had we known, we would have put some projects off or asked for more hours. Companies are not fond of eating costs. In fact, they can get right cranky about it especially if you cause it to happen multiple times.

• We expect you to be part of a team. That means you don't own the code, there will be decisions you will have to implement that you don't agree with and others may change your code or require you to do so after a code review. It also means that people should make time to help each other out and answer questions. It means we expect people to pitch in sometimes and do things outside their job description for the good of the whole project. Sometimes that includes making copies of a Power Point presentation for the client meeting.

• Expect that the code base will be much more complicated than any examples you had in school. They tend to use straightforward examples in school, the real world is often a messy mix of ten years of business rule changes and technology changes (that may only be applied to items that need changing for other reasons). Expect that data is far more important than you ever thought it would be.

• Expect that you will hate the code base and wonder why these people did such a lousy job. Please try to remember that we often designed parts of this system before cool tool XYZ was available and the techniques used may have been the best available at at the time. Most of us don't have time available (and most companies aren't willing to accept the risk of new bugs) to change working code just because some new cool thing has come out. And oh yeah, some of that ten year old code was written when we were juniors and didn't know as much as we should have. We cringe when we see it too. But refactoring is a business choice not just a development choice.

• Expect that people will not listen to your wonderful new ideas until you have proven yourself. That means by successfully delivering software using the current system.

• Expect that older developers actually often do know more than you do. Expect that you will have to deal with them even if they don't and that you will not be allowed, for the most part, to only deal with your age peers.

• Expect that you have very much overestimated your skill level. Most junior people do. Expect that when you have ten years experience, you will cringe at that code you wrote back then too! Just like the rest of us.

• Expect that your manager and the project manager (if it is a different person) have a right to know what progress you are making and even to see the code in progress. They have to report to various people too. We don't want to see you playing for three weeks and then pulling an all-nighter to punch out some code at the last minute. Well at least the competent PMs don't want to see that. We expect you to actually make some progress every day and to tell us or show us what that was. YOUr days of procrastinating until the day before the deadline should be over.

• We expect you to try at least some to figure out the answers to your questions. We are busy and don't want to tell you something that ten seconds of Googling would have found. People will be more receptive to questions that are specific to the product or business domain you are working in rather than syntax.

• If we have written requirements, we expect the product you give us back will fulfill those requirements. If the requirements don't make sense, we expect you to push back and ask questions. If they are missing key information, we expect you to tell us that too. But in the end, when all the questions are answered (even if you personally don't like the answers), we expect that you will deliver what we asked you to deliver.

Expect that the code base will be much more complicated than any examples you had in school. They tend to use straightforward examples in school, the real world is often a messy mix of ten years of business rule changes and technology changes (that may only be applied to items that need changing for other reasons). Expect that data is far more important than you ever thought it owuld be.

Expect that the code base will be much more complicated than any examples you had in school. They tend to use straightforward examples in school, the real world is often a messy mix of ten years of business rule changes and technology changes (that may only be applied to items that need changing for other reasons). Expect that data is far more important than you ever thought it would be.