Looking for a preview of my first 6 months or so as a junior programmer
January 20, 2010 6:10 PM Subscribe
When I get my first junior programmer job - fresh out of school, shiny faced and new - what will that look like? What will I be tasked with? What will the expectations of me be?
I sit in my programming classes and am stricken with anxiety as I wonder: how the hell am I going to be of any use to anyone when I graduate? I've been told that employers don't expect much of new graduates at the very beginning - as long as you have a pulse and show up on time, you're fine and you just learn as you go. Can this possibly be true?
Please help me by explaining what a newbie's first 6 months or so one the job are like.
Should it matter, I'm female and 29.
I sit in my programming classes and am stricken with anxiety as I wonder: how the hell am I going to be of any use to anyone when I graduate? I've been told that employers don't expect much of new graduates at the very beginning - as long as you have a pulse and show up on time, you're fine and you just learn as you go. Can this possibly be true?
Please help me by explaining what a newbie's first 6 months or so one the job are like.
Should it matter, I'm female and 29.
It depends a lot on the company you work for. For example, whether it's large or small, mature or a startup. Generally speaking, the larger the company and the more mature the product the more likely the company is to have well defined development processes and the less likely you are to be thrust into a position with a lot of independence and responsibility right off the bat. Smaller companies (and especially start-ups) are more likely to expect programmers to exercise independent judgment.
Smaller companies and startups also tend to require their programmers to wear multiple hats: software designer, programmer, user interface designer, tech support, quality assurance, database administration, etc.
It also depends on the development methodology. A company that uses an agile development methodology will be very different from one that (for example) uses a rigid waterfall development methodology with a clear delineation between development, testing, user acceptance, and production.
How far away do you anticipate this first job being? Do you have any idea what sort of company it might be with? What about summer internships or the like? I would recommend one if you can manage it. Some schools partner with companies to offer internships for credit during the school year in lieu of class work.
posted by jedicus at 6:37 PM on January 20, 2010 [1 favorite]
Smaller companies and startups also tend to require their programmers to wear multiple hats: software designer, programmer, user interface designer, tech support, quality assurance, database administration, etc.
It also depends on the development methodology. A company that uses an agile development methodology will be very different from one that (for example) uses a rigid waterfall development methodology with a clear delineation between development, testing, user acceptance, and production.
How far away do you anticipate this first job being? Do you have any idea what sort of company it might be with? What about summer internships or the like? I would recommend one if you can manage it. Some schools partner with companies to offer internships for credit during the school year in lieu of class work.
posted by jedicus at 6:37 PM on January 20, 2010 [1 favorite]
There isn't going to be one answer to this question. It will depend on the size of the organization, the responsibilities of the hiring organization, the degree of professionalisms this organization and company imposes and probably a half dozen other things.
In most cases they know you are green and new and unless the interview went something like: Company: "We need people who have done x, y, and z with the Foo language" and you said: "Oh yes, I've done a, b, c, x y and z with Foo language all the time and have built many applications used by dozens, nay hundreds of users", then they are going to expect that you have lots to learn.
With that said, you might be learning process or tools, or learning a new language or a set of libraries. Hell, you might even learn a new operating system or two. You may be taught about the business and organization that you are in (after, you need to understand the problem domain to productive in most disciplines). Your immediate tangible tasks might be bug fixing or support or testing or automation. You may be thrown to the wolves and asked to spec out features and build them but that is unlikely in most organizations (unless you've proven yourself with some of there other tasks).
It can be stressful and nerve wracking but exciting nonetheless. You'll be amazed what new stuff you can learn once you put your academic skills into practice.
posted by mmascolino at 6:42 PM on January 20, 2010 [1 favorite]
In most cases they know you are green and new and unless the interview went something like: Company: "We need people who have done x, y, and z with the Foo language" and you said: "Oh yes, I've done a, b, c, x y and z with Foo language all the time and have built many applications used by dozens, nay hundreds of users", then they are going to expect that you have lots to learn.
With that said, you might be learning process or tools, or learning a new language or a set of libraries. Hell, you might even learn a new operating system or two. You may be taught about the business and organization that you are in (after, you need to understand the problem domain to productive in most disciplines). Your immediate tangible tasks might be bug fixing or support or testing or automation. You may be thrown to the wolves and asked to spec out features and build them but that is unlikely in most organizations (unless you've proven yourself with some of there other tasks).
It can be stressful and nerve wracking but exciting nonetheless. You'll be amazed what new stuff you can learn once you put your academic skills into practice.
posted by mmascolino at 6:42 PM on January 20, 2010 [1 favorite]
Lessons of Failure: Hiring Ren and Stimpy -- Here's the BEST dialogue I've ever seen on what to do and what not to do as a new programmer.
posted by SpecialK at 6:56 PM on January 20, 2010 [1 favorite]
posted by SpecialK at 6:56 PM on January 20, 2010 [1 favorite]
I did several Co-op terms while I was in school, so I have had the first day as a student who knows nothing experience a few times.
As everyone says above, it's going to depend on the place exactly what it's like. I was in situations where I was put immediately onto tool development (not the main product, but supporting the main product). Other times it was a slow ramp up toward fixing easy bugs - but it took some time to learn about how to build the software, how the source control system worked, how the debug environment worked etc.
Programming isn't so different than any other job, really. Employers realize that they have a fresh student coming onto the team with a great deal of useful raw knowledge that they've picked up in University. They know it takes some time and patience for that knowledge to fall into place in the job.
Someone said above - they'll classify you. I think that's mostly true . . . some people have a better natural grasp of how to take what they did in school and apply it to a real position, and those people get more responsibility right away.
All that said, try to look forward to it! It's fun. Take every opportunity you can to learn from the senior people on your team. They're usually more than happy to teach.
posted by ChrisManley at 7:04 PM on January 20, 2010
As everyone says above, it's going to depend on the place exactly what it's like. I was in situations where I was put immediately onto tool development (not the main product, but supporting the main product). Other times it was a slow ramp up toward fixing easy bugs - but it took some time to learn about how to build the software, how the source control system worked, how the debug environment worked etc.
Programming isn't so different than any other job, really. Employers realize that they have a fresh student coming onto the team with a great deal of useful raw knowledge that they've picked up in University. They know it takes some time and patience for that knowledge to fall into place in the job.
Someone said above - they'll classify you. I think that's mostly true . . . some people have a better natural grasp of how to take what they did in school and apply it to a real position, and those people get more responsibility right away.
All that said, try to look forward to it! It's fun. Take every opportunity you can to learn from the senior people on your team. They're usually more than happy to teach.
posted by ChrisManley at 7:04 PM on January 20, 2010
For the first month or two I teamed up with a similar fresh out of school guy and we mostly fixed bugs as a way to getting used to working in our dev environment, the company's architecture and coding style, dealing with checking in/out code, doing builds and updating bug tracking software, with a few minor features (e.g. add a new field to this form). I played along while the other guy kept trying to do things his way, he was gone after four months and I learned more in three years than I ever did in school.
posted by furtive at 7:46 PM on January 20, 2010
posted by furtive at 7:46 PM on January 20, 2010
You'll be fine, as long as you're more like Ferdy than Mop Head.
posted by flabdablet at 7:52 PM on January 20, 2010
posted by flabdablet at 7:52 PM on January 20, 2010
Response by poster: Thank you for the answers so far. I'm still 1-2 years away from a job. I'll be in a smaller city then (Halifax, Canada) and as such, I assume I'll end up with a smaller business. And yes, I can do a coop and it seems like I'd be a fool not to.
To those yet to post: don't be afraid to talk to me like I'm 5 years old :)
posted by kitcat at 8:25 PM on January 20, 2010
To those yet to post: don't be afraid to talk to me like I'm 5 years old :)
posted by kitcat at 8:25 PM on January 20, 2010
A company that uses an agile development methodology will be very different from one that (for example) uses a rigid waterfall development methodology with a clear delineation between development, testing, user acceptance, and production.
That bring something to mind: don't be surprised if your fellow programmers have no idea what's going on in the software world and just go "huh?" to terms like "agile" or "waterfall". The corporate software world moves *slowly*.
posted by smackfu at 9:37 PM on January 20, 2010
That bring something to mind: don't be surprised if your fellow programmers have no idea what's going on in the software world and just go "huh?" to terms like "agile" or "waterfall". The corporate software world moves *slowly*.
posted by smackfu at 9:37 PM on January 20, 2010
Some pieces of advice:
- socialize with your new colleagues *fast*. Then go to them when you don't understand stuff, it will play double in your favor: one is that you won't stay stuck; two is that it will make them shine to help you.
- take some time to peek around and read stuff, to understand company culture, especially jargon. It really helps feeling comfortable to be able to use the same words as your colleagues.
posted by knz at 10:08 PM on January 20, 2010
- socialize with your new colleagues *fast*. Then go to them when you don't understand stuff, it will play double in your favor: one is that you won't stay stuck; two is that it will make them shine to help you.
- take some time to peek around and read stuff, to understand company culture, especially jargon. It really helps feeling comfortable to be able to use the same words as your colleagues.
posted by knz at 10:08 PM on January 20, 2010
If it's at a small company, you may get stuck doing some menial netadmin tasks in addition to your programming duties. So you'll need to suck it up and deal; consider it part of paying your dues. Just don't let it become your career, unless you REALLY want to be a netadmin.
posted by Afroblanco at 11:21 PM on January 20, 2010
posted by Afroblanco at 11:21 PM on January 20, 2010
I helped write this Politics-Oriented Software Development thing a while back. Maybe a bit cynical, but could be useful.
posted by TheophileEscargot at 1:36 AM on January 21, 2010 [1 favorite]
posted by TheophileEscargot at 1:36 AM on January 21, 2010 [1 favorite]
Having just gone through what you have, I can share my experience as it was nothing like I expected. I joined a small branch of a big company, as a software developer for internal projects, which were supposed to automate some of their ancient processes.
My manager was simultaneously an operations manager, so he was often too busy to supervise me and after I delivered the first simple application successfully he basically left me to it. With no technical guidance, and no discernible software processes in place I was left to manage myself.
It was both good and bad. It was good because I learned how to implement code control (not just use it), how to work to Agile and because the software was small and standalone, I could actually pick the language I worked in (seriously). I spent my time teaching my self Ruby, Python and Perl because whenever anyone walked by they just saw a bunch of code. I ended up doing database management, giving me lots of MS SQL experience for free.
On the downside, after a year and a half when I left, I had no clue how a serious software company did things. I learned a lot, but it was more like a paid extension of university rather than actual job experience.
Anyhow, best of luck.
posted by Rei Toei at 1:59 AM on January 21, 2010
My manager was simultaneously an operations manager, so he was often too busy to supervise me and after I delivered the first simple application successfully he basically left me to it. With no technical guidance, and no discernible software processes in place I was left to manage myself.
It was both good and bad. It was good because I learned how to implement code control (not just use it), how to work to Agile and because the software was small and standalone, I could actually pick the language I worked in (seriously). I spent my time teaching my self Ruby, Python and Perl because whenever anyone walked by they just saw a bunch of code. I ended up doing database management, giving me lots of MS SQL experience for free.
On the downside, after a year and a half when I left, I had no clue how a serious software company did things. I learned a lot, but it was more like a paid extension of university rather than actual job experience.
Anyhow, best of luck.
posted by Rei Toei at 1:59 AM on January 21, 2010
First off, absolutely go for that co-op job. It will help tremendously in job hunting because you will be starting off with some real world experience, and it will help you a lot to understand what professional software development is like. You might even learn that you don't like it at all and will give you time to change direction in school (this happened to me - switched from EE -> CS).
You didn't mention if you are in a traditional computer science program or some other technical school program. If you are in a traditional CS program then you should be aware that a great deal of what you learned in school (algorithms, data structures, compilers, advanced math, etc.) won't be directly applicable on the job and you will initially feel like you don't know anything. Professional software development is a lot different than computer science - there are a lot of things that they just don't teach you in school. (Not that the knowledge isn't useful, it's just not stuff you use day to day.) Employers usually know this about college new hires and therefore will cut you some slack for the first few months as you get to know the ropes. As others mentioned, you probably will spend the first few months doing testing or fixing small bugs rather than building whole new applications. This is a good thing, as it will give you time to understand how things function in your company before you are put under some real pressure to deliver on time. (The opposite is true as well.)
As far as the actual programming work goes, there are quite a few good books that can prepare you to be a professional programmer. I found this great list yesterday. Code Complete is pretty much the best book on programming, ever.
You can also get a jump on things if you can get involved in some open source projects. That should help a lot in your job search as well.
posted by kenliu at 7:00 AM on January 21, 2010
You didn't mention if you are in a traditional computer science program or some other technical school program. If you are in a traditional CS program then you should be aware that a great deal of what you learned in school (algorithms, data structures, compilers, advanced math, etc.) won't be directly applicable on the job and you will initially feel like you don't know anything. Professional software development is a lot different than computer science - there are a lot of things that they just don't teach you in school. (Not that the knowledge isn't useful, it's just not stuff you use day to day.) Employers usually know this about college new hires and therefore will cut you some slack for the first few months as you get to know the ropes. As others mentioned, you probably will spend the first few months doing testing or fixing small bugs rather than building whole new applications. This is a good thing, as it will give you time to understand how things function in your company before you are put under some real pressure to deliver on time. (The opposite is true as well.)
As far as the actual programming work goes, there are quite a few good books that can prepare you to be a professional programmer. I found this great list yesterday. Code Complete is pretty much the best book on programming, ever.
You can also get a jump on things if you can get involved in some open source projects. That should help a lot in your job search as well.
posted by kenliu at 7:00 AM on January 21, 2010
Response by poster: Thanks, folks. This is all really helpful. I've had many jobs, but never one where you go in so very incapable of jumping right into things. This is definitely helping in knowing what to expect.
Thankfully, my program isn't a traditional CS program; almost everything is hands-on and there is no complier stuff, no advanced math...Still it's very generalist. We seem to learn a bit of everything.
Anyhow, could someone please help me out with the following terms (used above) as they apply to development projects?
support
automation
spec out features
tool development
source control system
doing builds
code control
posted by kitcat at 9:17 AM on January 21, 2010
Thankfully, my program isn't a traditional CS program; almost everything is hands-on and there is no complier stuff, no advanced math...Still it's very generalist. We seem to learn a bit of everything.
Anyhow, could someone please help me out with the following terms (used above) as they apply to development projects?
support
automation
spec out features
tool development
source control system
doing builds
code control
posted by kitcat at 9:17 AM on January 21, 2010
support: users phone you up with their problems
automation: writing code to do something previously done manually
spec out features: taking an idea for a new feature in a program and thinking through how exactly it should behave
tool development: you write programs used by other programmers to do their jobs.
source control / code control: the system that records every change you make to the source code and refers back to the database of jobs. So, if I want to know why line 32 of foo.cpp has something weird on it, I look it up in source control and find that John changed it last January because of a particular obscure crash problem reported by Bill.
doing builds: in some places it really can take 24 hours or more to compile and put together everything required for a whole product. The developers each work on a small part to make it manageable, so one unenviable individual gets the job of rebuilding EVERYTHING from source control every so often, to check that nobody has broken something. In a decent place of work, this will happen automatically overnight. Still it may require a babysitter whose job it is to track down those responsible for breakages and make sure things get sorted out.
posted by emilyw at 9:43 AM on January 21, 2010
automation: writing code to do something previously done manually
spec out features: taking an idea for a new feature in a program and thinking through how exactly it should behave
tool development: you write programs used by other programmers to do their jobs.
source control / code control: the system that records every change you make to the source code and refers back to the database of jobs. So, if I want to know why line 32 of foo.cpp has something weird on it, I look it up in source control and find that John changed it last January because of a particular obscure crash problem reported by Bill.
doing builds: in some places it really can take 24 hours or more to compile and put together everything required for a whole product. The developers each work on a small part to make it manageable, so one unenviable individual gets the job of rebuilding EVERYTHING from source control every so often, to check that nobody has broken something. In a decent place of work, this will happen automatically overnight. Still it may require a babysitter whose job it is to track down those responsible for breakages and make sure things get sorted out.
posted by emilyw at 9:43 AM on January 21, 2010
And to follow on to emilyw's build comment. While the 24 hour example is a far outlier, it isn't too uncommon for even small and medium sized projects to depend on components from multiple projects. The default and naive way is to manually merge these things together. Lots of people do that because they either don't know better or it is easier to do that in the beginning.
Combining automation and builds allow you to script up a process that gathers everything, compiles it and builds then result of the project. You can even go further and script out the deployment of such code and the running of automated tests and so on throughout the software lifecycle.
posted by mmascolino at 9:53 AM on January 21, 2010
Combining automation and builds allow you to script up a process that gathers everything, compiles it and builds then result of the project. You can even go further and script out the deployment of such code and the running of automated tests and so on throughout the software lifecycle.
posted by mmascolino at 9:53 AM on January 21, 2010
and to answer the original question:
Popular tasks for new people involve testing software, writing tests to test software automatically, writing text for manuals, tracking down bugs, or doing small and self-contained programming tasks ("write a command line tool to read reports in this format and output them as XML").
You may well be amazed at how much more you know than other much younger graduates, just by having more life experience. You are probably better at managing your own time, you may have a better understanding of how business works, you have better research skills, etc etc.
There are two main things you will have to learn: firstly, the business and the software of the firm you work at (and every newcomer to that company will have the same problem), and secondly, the skills of writing software that can be maintained cheaply. Nearly all of "real" software engineering is about making a system in which you can fix problems or make changes quickly and without breaking anything else. This is a really big deal: maintaining software is expensive, and maintaining crappy software can be SO expensive that it needs to be rewritten at even further cost!
Some reading material to get you started with some of these things they don't teach at university:
"Refactoring: Improving the Design of Existing Code", Martin Fowler et al.
"Code Complete: A Practical Handbook of Software Construction", Steve McConnell
"The Pragmatic Programmer", Hunt and Thomas.
"Working Effectively with Legacy Code", Michael Feathers
If you go in having read some of those things you'll have a good head start on any other graduates who are still playing "hack until it works".
Oh and one more book: "Nice Girls Don't Get the Corner Office", Lois P. Frankel. Being female in a male dominated environment is not as much of a problem as it once was, but there are skills involved in making the best of it and this book is good at explaining them.
posted by emilyw at 10:12 AM on January 21, 2010 [1 favorite]
Popular tasks for new people involve testing software, writing tests to test software automatically, writing text for manuals, tracking down bugs, or doing small and self-contained programming tasks ("write a command line tool to read reports in this format and output them as XML").
You may well be amazed at how much more you know than other much younger graduates, just by having more life experience. You are probably better at managing your own time, you may have a better understanding of how business works, you have better research skills, etc etc.
There are two main things you will have to learn: firstly, the business and the software of the firm you work at (and every newcomer to that company will have the same problem), and secondly, the skills of writing software that can be maintained cheaply. Nearly all of "real" software engineering is about making a system in which you can fix problems or make changes quickly and without breaking anything else. This is a really big deal: maintaining software is expensive, and maintaining crappy software can be SO expensive that it needs to be rewritten at even further cost!
Some reading material to get you started with some of these things they don't teach at university:
"Refactoring: Improving the Design of Existing Code", Martin Fowler et al.
"Code Complete: A Practical Handbook of Software Construction", Steve McConnell
"The Pragmatic Programmer", Hunt and Thomas.
"Working Effectively with Legacy Code", Michael Feathers
If you go in having read some of those things you'll have a good head start on any other graduates who are still playing "hack until it works".
Oh and one more book: "Nice Girls Don't Get the Corner Office", Lois P. Frankel. Being female in a male dominated environment is not as much of a problem as it once was, but there are skills involved in making the best of it and this book is good at explaining them.
posted by emilyw at 10:12 AM on January 21, 2010 [1 favorite]
Also, from my experience being, and then working with, interns in your position: the only ones who have failed hard are the ones who aren't willing to learn new techniques or admit they're wrong. If your company sucks, you won't get much criticism on your code in the beginning, if it's great then you'll get great, constructive criticism. You can fill out the rest of the rubric.
And, for the tasks you start out with, it's all about quality; basically, try really hard to make things good enough that rarely do you have any code fail or anyone yell at you for bad technique.
You should try out svn and git yourself (if this is a somewhat open source shop) so that your head is somewhat wrapped around the core concept. Learning version control is one of the big getting-started tasks like setting up your new laptop, since it's as essential and fundamental as saving a file in software development. If you can demonstrate that you're already slightly in the know, that'll mean more productivity and acceptance off the bat, which is vital.
posted by tmcw at 12:31 PM on January 21, 2010
And, for the tasks you start out with, it's all about quality; basically, try really hard to make things good enough that rarely do you have any code fail or anyone yell at you for bad technique.
You should try out svn and git yourself (if this is a somewhat open source shop) so that your head is somewhat wrapped around the core concept. Learning version control is one of the big getting-started tasks like setting up your new laptop, since it's as essential and fundamental as saving a file in software development. If you can demonstrate that you're already slightly in the know, that'll mean more productivity and acceptance off the bat, which is vital.
posted by tmcw at 12:31 PM on January 21, 2010
support: users phone you up with their problems
Although for us, "support" for a developer is more like "fix this bug you are assigned". We would pretty much never let a straight-out-of-college developer talk to a customer. They're too honest.
posted by smackfu at 1:01 PM on January 21, 2010
Although for us, "support" for a developer is more like "fix this bug you are assigned". We would pretty much never let a straight-out-of-college developer talk to a customer. They're too honest.
posted by smackfu at 1:01 PM on January 21, 2010
menial netadmin tasks ... Just don't let it become your career, unless you REALLY want to be a netadmin
As a burned-out ex-embedded-systems-programmer who drifted sideways into netadmin by accident, I was pleasantly surprised to find that most of what I now do engages the same parts of my mind as the aspects of programming that I used to enjoy most: debugging, system design, and interacting with smart people.
Had I found out earlier that netadmin was not just menial busywork done badly by a rarely-seen incompetent from the Information Disasters department, I probably would have paid more attention to it as a serious career option, and might now be doing it on a consulting basis for serious money instead of for beer money as a school employee.
But I probably wouldn't be happier. Burnout is OK; it gives you a lot of perspective on what actually matters.
posted by flabdablet at 7:27 PM on January 21, 2010
As a burned-out ex-embedded-systems-programmer who drifted sideways into netadmin by accident, I was pleasantly surprised to find that most of what I now do engages the same parts of my mind as the aspects of programming that I used to enjoy most: debugging, system design, and interacting with smart people.
Had I found out earlier that netadmin was not just menial busywork done badly by a rarely-seen incompetent from the Information Disasters department, I probably would have paid more attention to it as a serious career option, and might now be doing it on a consulting basis for serious money instead of for beer money as a school employee.
But I probably wouldn't be happier. Burnout is OK; it gives you a lot of perspective on what actually matters.
posted by flabdablet at 7:27 PM on January 21, 2010
support: In most companies, developers do not directly talk to customers. Usually there is a help desk to triage problems and deal with simple issues like password changes, and problems are escalated to support if the customer's problem is severe or too complicated. So in this context, "support" usually means looking through the code and figuring out how to solve the customer's problem and usually to figure out a workaround.
automation: In software development there are inevitably some manual ancillary tasks (usually involving copying files, creating zip files, moving things around a network, or backups). These are usually time-consuming, tedious, and error prone, and a team benefits by creating scripts to automate the process.
source control system, code control, version control: Development teams use a source control system, which is basically a specialized database that stores snapshots of all the source code and tracks changes over time, sort of like the "Track Changes" feature in MS Word. Developers can check their files in and out of the system. Visual Source Safe (VSS), Concurrent Versioning System (CVS), Subversion (SVN), and Git are the most commonly used. SVN and Git are the most popular for open source software.
Remember this: if you interview at a company and they don't use a source control system, RUN AWAY. QUICKLY. IT WILL BE A DISASTER, GUARANTEED. (If they use VSS, walk away at a brisk pace.)
posted by kenliu at 7:31 PM on January 21, 2010 [1 favorite]
automation: In software development there are inevitably some manual ancillary tasks (usually involving copying files, creating zip files, moving things around a network, or backups). These are usually time-consuming, tedious, and error prone, and a team benefits by creating scripts to automate the process.
source control system, code control, version control: Development teams use a source control system, which is basically a specialized database that stores snapshots of all the source code and tracks changes over time, sort of like the "Track Changes" feature in MS Word. Developers can check their files in and out of the system. Visual Source Safe (VSS), Concurrent Versioning System (CVS), Subversion (SVN), and Git are the most commonly used. SVN and Git are the most popular for open source software.
Remember this: if you interview at a company and they don't use a source control system, RUN AWAY. QUICKLY. IT WILL BE A DISASTER, GUARANTEED. (If they use VSS, walk away at a brisk pace.)
posted by kenliu at 7:31 PM on January 21, 2010 [1 favorite]
« Older Is this bargain electronics site a scam? | How am I ever going to find a ring I like for our... Newer »
This thread is closed to new comments.
The employer and fellow employees will very rapidly sort you into the "great" or "average or worse" bucket. If you have a manager who cares, and they think highly of you, you will be given a chunk of somewhat independent code to work on (a new feature or what have you) or to shadow a senior developer.
posted by rr at 6:28 PM on January 20, 2010