I've done a lot of hiring, and have some thoughts on this.
Unless you've spent a LOT of time solving problems and designing software, you probably won't be right for a senior position. So, some of the options for junior ones:
First, you probably won't have much luck with contract work. Contract folks are looking for demonstrated expertise with specific technologies. Unless they can put you into a C++, or java, or Oracle, or.NET position the next day, you probably won't get many bites.
Big companies (Microsoft, google, etc.) are more likely to take a chance on someone unproven but with evidence of smarts, assuming that you'll learn to eventually view abuse as reward if that's all you're ever exposed to.:) It's not for everybody.
If you're in an area with a lot of software work going on, then you might want to look at intern positions. They can pay fairly well, considering (we pay $20 an hour where I am), and if you prove yourself over the summer, it can often lead to a junior position; or at least a letter of recommendation which will go along way for the next job.
Let me just go slightly off topic for a second and warn you about the #1 thing that makes me reject unexperienced candidates -- no interest. Whether I'm interviewing for a junior position or a senior one, I always ask what projects they are working on at home...maybe it's an extension of your masters work, maybe you're teaching yourself PHP by writing an online poker game. I don't care what it is, but if you're at this point and you don't have something you're excited about working on, you're probably in the wrong field:)
A lot depends on what skills you're bringing to the table. If you put yourself through university working as a network guy and you wnat to break into development, then often applying to an internet company as a 'build engineer' or something similar can lead to a transfer into development. (This just happened where I am, and the guy is amazing, he knows our code better than we do).
Small local companies can be a godsend, especially if you're in a small college town...but they can also sometimes trap inexperienced devs and really mistreat them. I was with a military contractor who had some great international guys, and treated them like crap, thinking "we're in the middle of nowhere, and these guys need work visas, where are they going to go?" If this is your situation, talk to some of your professors, they might know of local startups (in college towns, they're often involved).
There's a lot of options, but a lot depends on your specific situation. Hope this helps.
V.
...well, weekly maybe.
First, throw away any 'official' purpose UML might have had. It's just a way for describing aspects of code design, that's all. So are flowcharts and ER diagrams, etc.
I use UML (and the others) both to sketch out ideas as I'm working through them, and as a common language for describing my design to my dev team, or for collaborating with others.
If you think your code doesn't need describing, then it's either very simple, or you're very wrong.
It doesn't need to be described in every detail, that's the job of the code & in-code documentation. But if anybody ever has to come back to this code in a year -- even yourself -- then they're going to want to know how your objects fit together, or how that little trick you used to get the database working worked again, or what that bizarre recursive function you cooked up was supposed to do, or how those threads interacted...
Yes, you can go back and look at the code. For instance, the project I'm currently on has about 2000 source files written by about 30 different developers over 5 years. There's a half-dozen subsystems running on different servers, and they all talk together in ways that no one ever bothered writing down. Sure, _you_ go look in the code. I'm going to get drunk.
If you're writing a VB app with a fews screens, then a couple of use cases and some screen shots will probably be all you need, if that. But if you can apply the term 'non-trivial' to any aspect of your system, then it needs to be designed before time, and documented throughout the process.
If you don't...well, then I'll be at your ex-place of employment in a couple of years to clean up your mess.
Slashdot Mirror
I've done a lot of hiring, and have some thoughts on this. Unless you've spent a LOT of time solving problems and designing software, you probably won't be right for a senior position. So, some of the options for junior ones: First, you probably won't have much luck with contract work. Contract folks are looking for demonstrated expertise with specific technologies. Unless they can put you into a C++, or java, or Oracle, or .NET position the next day, you probably won't get many bites.
Big companies (Microsoft, google, etc.) are more likely to take a chance on someone unproven but with evidence of smarts, assuming that you'll learn to eventually view abuse as reward if that's all you're ever exposed to. :) It's not for everybody.
If you're in an area with a lot of software work going on, then you might want to look at intern positions. They can pay fairly well, considering (we pay $20 an hour where I am), and if you prove yourself over the summer, it can often lead to a junior position; or at least a letter of recommendation which will go along way for the next job.
Let me just go slightly off topic for a second and warn you about the #1 thing that makes me reject unexperienced candidates -- no interest. Whether I'm interviewing for a junior position or a senior one, I always ask what projects they are working on at home...maybe it's an extension of your masters work, maybe you're teaching yourself PHP by writing an online poker game. I don't care what it is, but if you're at this point and you don't have something you're excited about working on, you're probably in the wrong field :)
A lot depends on what skills you're bringing to the table. If you put yourself through university working as a network guy and you wnat to break into development, then often applying to an internet company as a 'build engineer' or something similar can lead to a transfer into development. (This just happened where I am, and the guy is amazing, he knows our code better than we do).
Small local companies can be a godsend, especially if you're in a small college town...but they can also sometimes trap inexperienced devs and really mistreat them. I was with a military contractor who had some great international guys, and treated them like crap, thinking "we're in the middle of nowhere, and these guys need work visas, where are they going to go?" If this is your situation, talk to some of your professors, they might know of local startups (in college towns, they're often involved).
There's a lot of options, but a lot depends on your specific situation. Hope this helps.
V.
...well, weekly maybe. First, throw away any 'official' purpose UML might have had. It's just a way for describing aspects of code design, that's all. So are flowcharts and ER diagrams, etc. I use UML (and the others) both to sketch out ideas as I'm working through them, and as a common language for describing my design to my dev team, or for collaborating with others. If you think your code doesn't need describing, then it's either very simple, or you're very wrong. It doesn't need to be described in every detail, that's the job of the code & in-code documentation. But if anybody ever has to come back to this code in a year -- even yourself -- then they're going to want to know how your objects fit together, or how that little trick you used to get the database working worked again, or what that bizarre recursive function you cooked up was supposed to do, or how those threads interacted... Yes, you can go back and look at the code. For instance, the project I'm currently on has about 2000 source files written by about 30 different developers over 5 years. There's a half-dozen subsystems running on different servers, and they all talk together in ways that no one ever bothered writing down. Sure, _you_ go look in the code. I'm going to get drunk. If you're writing a VB app with a fews screens, then a couple of use cases and some screen shots will probably be all you need, if that. But if you can apply the term 'non-trivial' to any aspect of your system, then it needs to be designed before time, and documented throughout the process. If you don't...well, then I'll be at your ex-place of employment in a couple of years to clean up your mess.