It seems to me that for most corporate entry-level programming jobs, the knowledge of computer science required is really minimal. You probably won't be building any compilers or using assembly language.

There are exceptions, of course. Microsoft is infamous for being demanding of their new hires. You'll likely find that the more a company's core business is software, the more computer science skill they will demand of you. But there are lots and lots of companies hiring programmers who have core businesses other than software.

Which languages to be proficient in varies depending on the sort of work you are doing. Browse current job openings; for the ones you find interesting, look at what languages they are using, and then focus on those.

Contributing to some open-source software project is a good way to develop some practical skills. Two months of part-time effort isn't a lot, but perhaps better than nothing. If not that, then you yourself should learn how to use some sort of version management tool, like Subversion. Go through a tutorial, start storing your homework projects in it, etc. You won't get to see all of the ins and outs of version management using it alone, but it'll be a start.

Thanks for the feedback tjr; especially so in regards to the 'version management' suggestion. I have felt that this is likely someplace I need additional knowledge and experience. I have accessed Subversion repositories, but in truth, have never maintained my own nor would I know what to do in a instance where it was actually required.

Learning version management is on the list to learn now :)

Thanks again, -Matt

You might want to play with Git instead. SVN is very, very easy to set up and use:

svnadmin create ~/svn-repo

svn import myproject file:///home/you/svn-repo/myproject

svn co file:///home/you/myproject myproject-workingcopy

Work in the working copy as you would on any SVN project.

I spawn new branches whenever I start a new project. I've also tunneled it over SSH, HTTPS, blah blah blah, but it's boring now. Git is probably the future for big projects IMHO. (Although GOOG gets by with Perforce, which is basically SVN with some extra hooks)

Version management is a thought habit. Would you walk a tightrope without a net? Why write challenging code without one, then? Similar to automated regression testing, it's just another habit that offloads responsibilities onto the computer so that you can work on more interesting things.

If you haven't built at least a trivial application in *nix, even just something like a server for Dopewars, give it a shot. Obviously it's rare that you'd need to do it for a job, since most of the interesting protocols have good implementations, but you'll have more insight into when the standard implementation is actually a really bad idea... that is to say, rather more often than you'd think! It won't take more than an afternoon or two if you've done as well in all your CS classes as you say. (One thing you might like to do after that is go back and look at the twisting road the Subversion guys went down as they implemented their DeltaV protocol -- considering that these are old Apache developers, it's enlightening to see that they followed plenty of dead ends, too) For extra value, do it on an embedded system, with its totally different constraints. (If you have access to something like the Xilinx rig that we used for the CPU engineering class I took, so much the better -- FPGLAs can't help but become more popular as vertical markets are more automated)

There are so many opportunities out there for someone with a good grasp of both the theoretical and practical aspects... if you really like building things, you ought not to have any problem finding a job to suit you with your degree.

Thanks apathy, I checked out Git a little while back. I definitely think that I need to learn more about both Git and SVN. From what little contact I have had with companies, SVN seems to be the most widely deployed for those on *nix platforms - that likely has something to do with the ~5yr jump that SVN has (?) though...

Thanks for the encouragement!

-Matt

5 years? If you count from when FSFS became the standard (2005?) it's really more like 3 years. I think Subversion will probably remain the standard for your 'average' developer, and Git will make huge inroads into the more elite/distributed teams, since it's the default repo for the Linux kernel. I don't really see the point of learning how to use tools that other developers are unlikely to use -- CVS, SVN (which is almost identical to Perforce), and git have compelling projects which use them. Most others don't.

If you use SVN in a group, you should also use Trac, btw. It's fucking amazing. looks at Trac Hacks Holy mother of god, someone went and wrote a plugin to make Trac play nice with Git and Perforce (AMZN and GOOG use p4). Well, that's pretty sweet -- no effort required regardless of repo. And apparently they added a continuous integration dashboard, Bitten (http://bitten.edgewall.org/wiki/Documentation/index.html). I love those Edgewall guys. Makes me want to go back to workaday development... almost.

I interviewed a bunch of Stanford CS students recently, and was amazed when I asked them about how much they had worked with databases. The answer I got back repeatedly was "I've used them in class." Not good enough.

One person, who had worked at Google, used a database there. "What kind of database was it?" I asked. "I don't know," was the answer, much to my horror.

Perhaps it's just me, but it seems like no matter which language you love most, or what you're doing, your data will need to be structured, and it will probably find its way into a database at some point in time. I don't care which database it is--just learn databases!

Then at least people like me can think about hiring you.

I wonder how much this has to do with how databases are taught to students.

While I started programming when I was 12, I didn't really do much with databases until I took a db class in college. Databases seemed boring to me, compared to nifty stuff like AI and Lisp.

The class only reinforced that notion. The textbook (and the class) focused mostly on some kinda funky little projects that didn't strike me as useful or fun to build. It wasn't until I started experimenting with web applications that I began to realize the power and intrigue of databases.

Databases truly are cool and powerful. But I don't think they look that way on the surface.

I agree with you. Databases seem boring. I've avoided database classes for exactly that reason, but there's no way to avoid databases themselves. Many applications have database requirements. I've started using ORMs a bit to avoid ugly SQL, but they don't actually simplify things much. They mostly just take care of some caching, transactions, and portability. You still need to understand what's happening below to use them effectively.

If you want to learn how to use databases, look into writing a program backed by SQLite. It's a great little database for desktop applications and it requires almost no setup to use, which is perfect for when you want to learn how to use a database but don't want to mess with actually getting one set up.

I agree that databases seem boring. I'd been using them for about 10 years before last year when I had to write significant parts of one. Once I started getting under the hood I realized how interesting a lot of the database problems are. Turns out, the geek factor is pretty high. Problems like query optimization, fast multi-dimensional indexing, full text search and so on give a nice playground for CS mojo. :-)

Per SQLite: It is probably the simplest SQL database to learn. However, I fear it might give a skewed perspective on SQL to someone just starting with it. While it's fine for the simplest of applications, if you start building up complex queries, its performance is orders of magnitude worse than almost every other SQL DB, potentially leading one to falsely believe that such things were to be avoided.

I personally find MySQL to be user-friendly enough for starting off with. Though, honestly SQL in general is one of those things that I'm glad to know, but find painfully inelegant.

I agree that SQL is painfully inelegant. It's one of those standards you wish had never been established. Like Windows, only worse.

As for starting with MySQL, it does reflect the actual SQL side better, but it's another thing to install and have startup whenever you boot your computer. For just playing around with SQL without committing to anything, SQLite's a nice option.

Thanks jmtulloss, I have played with SQLite a little and thought that might be a good course of action for my learning.

Thanks for the support :)

-Matt

Once I learned that database systemss are an application of relational calculus is when they became interesting to me and it's amazing to me now that nobody ever mentioned this to me during all the years I worked in industry with relational databases.

On the list, thanks! This is what I am looking for - there are certain things that I am pretty sure that I need to know better, but with my lack of applicable experience, I don't know which of my notions are correct and which ones will lead me down an unproductive path.

I too have been amazed at how little databases have been taught in my CS studies. For example, this previous term I was required to take a VB.net course. In this class, integrating a database and an application was mentioned in chapter 12 of a 12 chapter book (the shortest chapter of the book, at that)! My meager exposure to databases in my databases class was hardly sufficient to provide me with what was truly required to bring together databases with application development - sure, I knew how to query and how to join tables in SQL, but I had no real clue to how this pertained to my previous C++ or Java classes.

Thanks for the insight thinkcomp!

-Matt

1. Forget coding, study management. Managers get more money.

2. NEVER put the word 'test' on a resume. Do not mention it in any interview. If they ask if you tested anything, say no. Lie, if you have to. Say the other guys on the project tested. The kind of people who want to be coders usually do not want to be testers. But if you're a tester once, they'll make you do it for years.

3. As the twig is bent, so grows the tree. The title on your first job will stereotype you for your next, limit some opportunities and opening others. The first two combined will stereotype you even more strongly. And so on.

So be as demanding as you can get away with. Don't just accept what they tell you, unless you really have to.

4. Go to grad school instead. You'll end up making more.

5. A young programmer has to build a rep. One way is by making something famous and open-source. Another is to put "Google" or "Microsoft" on your resume as your first job. Or something like it.

6. Figure out where you want to live. If your career is in finance, the headquarters is often in New York. Embedded systems work is on the West Coast, but all over, too.

7. Defense contractors do a lot of software, mostly embedded. They've been known to write a compiler for an airplane. So drop your al-Queda membership and apply to Lockheed. But it's more bureaucratic and "Methodical" in that world.

8. There are three places to be employed in software: a) A software company. b) A hardware company. c) Everyplace else. Software people are first-class citizens in a software company, second only to the hardware engineers in a hardware company, and somewhere below that in stock brokers, banks, and shoe factories.

By hardware company I would include Intel, Cisco, and Sun, for example.

Web companies might be a 4th category, but I don't know those companies as well. Instead of MBA's or electrical engineers (finance and hardware) you have graphic designers.

What I'm getting at is that if you will be working with other professionals in their kind of company, you will need to learn their needs and their business. In a software company it's a bit of the other way around. At least in terms of status: who is in charge.

8. The right answers have to depend on you, otherwise the advice would be the same for everybody. And we'd all be trying for the same job.

9. I'm not rich, so why believe me?

Sorry JFred, I respectfully disagree with almost everything you have said here.

1. No! No! No! The only thing I remember from getting my MBA was, "A degree in business is a degree in nothing." Truer words were never spoken. Get into programming now. Do you really want to be Dilbert's PHB?

2. Never ever ever ever lie. About anything. To anyone. Ever. Enough said.

3. Titles are titular. In other words, meaningless. What you do matters. That's what other smart people will want to know about.

4. No! No! No! You have too much "education" already. Also see #1 above.

5. Your demonstrated performance (what you accomplish) establishes your reputation. Everything else is a smokescreen.

6. Gross generalization. For good hackers, everything is everywhere, with some things more concentrated in some places than others. Either pick where you want to live and find the best job there or find the best job anywhere and move there.

7. Being part of a large institution is the last thing I would want today. Too much small, smart, and nimble is happening now. Do you really want to take a chance at getting pigeon-holed for the next 10 years?

8. I have worked at 4 software companies, 0 hardware companies, and 83 everyplace elses. The worst 4 gigs were the software companies, by far. Imagine sitting in a cubicle for the next 18 months working on your 1.2% of Release 2.3.0.4. Hand me a razor blade please. "Everyplace else" is where "everything else" is happening.

8. Agreed. The best answer for you could be very different from everyone else.

9. There are many kinds of "rich" beyond money. One of the most important is doing what you love every day. You don't have to "believe" anyone, but listen and go with your gut.

Good luck!

"There are many kinds of "rich" beyond money. One of the most important is doing what you love every day. You don't have to "believe" anyone, but listen and go with your gut."

Thanks edw519, I think this is going to be one of my primary concerns when I set out. If I have to work part time doing tech work to make ends, so be it - but under no circumstance do I want to be stuck doing something I loathe... I only have this one life (best I can tell anyways) and I will be danged if I am going to spend it unhappy :)

-Matt

As for #1, I don't really like power (specifically the responsibility over others that it brings) and money is secondary to enjoying what I do. This also relates to #6, which is the beach - so I am thinking I have messed up altogether, and should have studied beach-bumology instead of CS :)

I have considered, and am still considering #4. I like school and I like learning and so it seems like a fit... only problem is, school is freaking expensive, so we will see.

I am also considering #7, as I have some contacts in that world having supervised a small military contract refuel facility servicing Ft. Rucker Army Aviation Training Facility for the previous 4 years of my life (I guess it is suitable at this juncture to mention that I am 27 and that I have worked full time since I was 18 - I have done school off and on along the ways). I also had to deal directly with Sikorski Support and Lockheed Martin, as their operations were in the same town and were related, and so I met people along the way.

As far as #9 is concerned, I solicited advice; I didn't promise to believe it ;) Seriously though, this is kind of a spitball session for me where I am hoping to get a considerable amount of BS, hopefully encrusted with slivers of gold (perhaps from goldscholger?).

Thank you for the tips and the entertaining read - #2 & #3 are things I never thought about and are things that I will be considering from now on!

-Matt

Goto a cheaper grad. school - a state run one. I'm going to san diego state and its waaaay cheaper than most schools and great for what i'm doing (applied math). Professors are almost the same everywhere (some good, some bad) and grad students are into what they study independent of location. If i was in-state, i'd pay only $4k/year in tuition, which is an order of magnitude cheaper than private schools. You might incur a bit of debt while working towards a masters, but you'll learn a ton along the way and be very practical, which is what a masters is for anyway - apply all that theoretical knowledge to a real situation under the guidance of those who've do that all the time.

1. Yes, provided his primary motivator is money. Of course, if he were really motivated by money before anything else, he's probably smart enough, by merit of getting a BA, to figure out where to board the gravy train.

2. If you're doing development work, you've probably been doing testing for years anyway. Saying that you've never tested anything extends to your own code, meaning you expect someone else to clean up your mistakes. Who has time for that sort of attitude?

3. If you let it. If you're a tester and want to be a developer, you'll get a lot farther toward that goal by not developing a false consciousness about your path limitations. A claim I would have no problem believing is that your past experience as a tester will make you a better developer. I was a tester at a small company for a little while before getting back into development. It taught me a lot.

4. Go to grad school because you love the topic, want to understand it deeper. If it's really just about the money, there are quicker, cheaper ways to get it.

5. Agree with this, except it's more about what you did than where you were.

7. What the hell is this about Al-Qaeda membership? Are you for real?

8. Yeah, knowing/learning the business is a good call. Knowing/learning the needs of the company is a good call, too. But really, assuming an pre-established pecking order for employees based on the "type" of company, in a very general sense, seems a bit premature. Also, just because your at the top of the totem pole doesn't absolve you of learning about the business or their needs, because being a "software person" doesn't mean you know their software.

8. This is correct, to a point. There is high-level advice that provides some useful guidance to everyone. I get the impression this is the sort of advice he was reaching for first.

Btw, best of luck to you, eznet.

"There is high-level advice that provides some useful guidance to everyone. I get the impression this is the sort of advice he was reaching for first."

Bingo! ;)

Thanks, azanar

The really short answer is "how to code".

Forget technologies; forget grades. At best, they will get you in the door for an interview. They won't make your a productive employee.

If you can produce working, deployable software on your own, then you will succeed. Not that many people can, honestly. If you aren't sure if you can hack, then pick a problem and solve it. If at the end of a week you can give your software to someone else and have them use it successfully, you should be fine.

Everything else is fluff, and can be learned on the job. If you can hack, you'll do fine.

"'If you can hack, you'll do fine."

Thats what I am hoping for. It can just become overwhelming for a young-buck (such as myself) when seeing all these frameworks and libraries and trying to figure out which ones my future employer will want used. In my CS studies, we have focused on a lot of 'whats under the hood' (aka linked lists, binary trees, etc,.) and so when I see these frameworks, I cannot help but think "which one do I use? Can't I just write the algorithm myself?!"

If I am understanding you correctly, if I can do this (know what is going on under the hood), then the rest of the cards will fall into place (?).

Thanks ajross!

Beyond technical skills, there are also people skills:

1. People make bugs, you make bugs. Playing the blame game is not productive, even if and especially when it really is the other guy's fault. Learning how to be diplomatic is important.

2. Big companies like to pretend that we are machines, but we are not. Be aware that your coworkers have egos, feelings and emotions, and they do not behave like machines. Machines don't try to hide their bugs instead of fixing them because they don't want to look incompetent, for example. Machines won't get hostile and obstructive if you don't like talking about their pet dogs during lunchtime.

3. The interests of the company are not always or not ever aligned with your own self interest. If you do good work but your boss doesn't know about it, it's like you didn't do it. A good manager will reward you fairly for working harder. Don't accept pats on the back or "employee of the month" awards for unpaid overtime. Only accept substantive incentives, like larger bonuses or faster promotions, etc.

4. A lot of times there are genuine incentives for an employee to intentionally write obfuscated code -- it makes it more expensive for the company to fire her. You just have to deal with it, and recognize that you should also have some similar kind of leverage with the company.

I pride myself on my interpersonal skills - I just think it is easier and more productive to be friendly (or at least amicable). Hopefully I can carry this with me into the development arena as you suggest, though I don't think it will be too much of a stretch :) As for #4, 'sneaky, sneaky!' Thanks for the tip. Though I don't think I could intentionally obfuscate my work (just seems dirty), I think that there are other ways of leveraging in a similar manner and I will definitely be keeping this in mind.

Thanks dusklight!

First off, feel free to start interviewing now. Most places have a 1-2 month lag time between initial contact and the day you start the job.

Second, don't feel obligated to take the first job offer you get unless you're ok with drifting from job to job like some people are. It's better to have some focus about your career and doing what you enjoy. If they offer and you honestly don't think it's a good fit keep looking.

I have done this on a limited basis, but everyone wants me to start now and wants to pay me crap. I understand that I will have to start lower because of my lack of experience, but on the other hand, I didn't go to school (and pay for school) to start working for $9/hr from some small company. I have had multiple companies try to hire me on for less than I would make working at McD's - all because they are going to be 'paying me with experience'.

I think this sentiment is where you second note comes to play: I am not going to take these jobs :) I guess I will do what I've been doing and just keep my feelers out until the right thing comes along.

Thanks angstrom,

-Matt

yep, wish I'd known that a few years ago. Ah, sweet experience, my favorite teacher!

Matt -

From my experience success as a developer is about your ability to learn, not a list on a resume. That you wrote this message makes me think you're on the right track.

Money will come when you're good at something. It's easy to be good at something if you enjoy it. Moving to a particular technology (only) because the money is good is generally a bad idea.

Thanks wehriam, Of all of the things that I am 'sure of' as a result of my education, my ability to learn something foreign would have to be it. I remember my first C class - swearing that there was no way this voodoo magic could ever make sense and actually be put to work and then by the end of the class having to reference the examples less and just knowing more.

Thanks for the encouragement,

-Matt

Sorry to everyone who has posted here that I have been unable to respond to. This thread grew quickly; which is FREAKING awesome - there is a list (on paper) growing on my desk every couple hours from the nuggets that you all are providing. I am a bit under the weather at the moment and have not been able to compose very intelligent responses (its difficult when your head is in the fog of theraflu and tussin). I have been really nervous about moving to the next phase (aka education to employment), but this thread has really shown me what I need to focus on more (a good deal of which I suspected, but now 'know' because of all of your help) and what I already know that I need to carry with me. Thankfully, much of what you all have said has let me know that I am aware of more of the basics than I previously thought. What I do not know, I now know that I need to know :)

Thank you again, to all of you! This thread is more valuable to me then I could ever express with a simple 'up' rating :) Your time and words mean a lot, so again, THANK YOU ALL!

-Matt

Programming isn't rocket science...there are elegant ways to solve problems and brute force methods, but in the end the only thing that matters is that it works and the client is happy. There isn't much they will teach you in school that will really make you that much "better".

The biggest difference between school and work for me was the process and the environment. Some of the big things I saw: * version control and development process * rapid bug fixes and changes * managing your own ego * testing your own code * working in teams, dealing with other people's code

These things are almost impossible to learn on your own. They are all things that can inherently only be learned in teams. Which I think is the big difference between school and your career...school is about you, your career will be about what you can produce with others. You need to find a project, anything, and get some experience working with a team (even a two person team). That's my two cents

"That's my two cents"

And I thank you greatly for them as I, myself, only have about 1/2 a cent right now :) I am seeing a lot of reoccuring themes there - notably version control, egos, teams and testing, and from this I know where I need to go next.

So, again, thank you for your cents!

-Matt

Learn to write concisely and clearly. (eg, don't use "feel" as a catchall for "believe", "think", "be", etc. Cut out useless and passive phrases: "Clearly", "where time and willingness permits".) Writing clearly is necessary for thinking clearly.

The reason your question has been asked & answered so many times is that it is too broad. Do you really think the people writing simulators at JPL have anything in common with a cubicle drone at a bank? Would Java help a games programmer, or a modeler at ILM? No -- no more than compiler design is relevant to a cubicle drone.

I suspect you have not yet found anything you love to do. Figure that out first and the rest becomes easier. I advise you (you, not everybody) to take a "money job" at a reasonably tech-oriented company and learn as much as you can. Do projects on the side, etc.

"The reason your question has been asked & answered so many times is that it is too broad. "

I believe this to be an inherent byproduct of the asker's current phase in their own personal development. When we ask, we are curious and unsure of where to go next. I know the question is broad, as too are the answers, but again, this comes from the fact that we are asking the 'seasoned' members of a community for insight - insight gained from experience that we simply do not yet have ourselves. Although I know there is no definitive 'ANSWER' for this question, I do believe there to be beneficial and constructive input on the topic that may still be made - hence, why I asked.

As to your suspicions pertaining to my lack of finding a passion in all of this, I think you may possibly be correct. Don't get me wrong; I love computers, languages, semantics and technology in general. One of my favorite pass-times when playing with a new language is to implement some of the algorithms and concepts from my advanced algorithm design and discrete mathematics classes - its just fun to me. Despite the entertainment found from doing exercises such as these, I have yet to find 'that special thing' that drives me to working until 3 a.m.

I think that (for me) you might be correct; I was discussing this very same "money job" topic with my wife before reading your response. It just seems logical, considering my current knowledge (or lack thereof), to find a tech oriented company to work from, hopefully encounter some mentor-types along the way and learn what to do from there.

Thanks aristus7,

-Matt

I've been through a few jobs in the last few years, and I keep looking back at them thinking "What an idiot I was for doing X" (for many, many values of X). But then I realized that I hadn't really defined myself, my views on software and development, business, etc. I was like someone who could run, jump, do jumping jacks, etc, who went around saying "I want to do sports for a living". I had basic tools and skills, but no direction. It sounds a little embarrassing to say, but how else was I supposed to gain direction without going through different experiences?

If you're not sure what you want to do or what really drives you, don't be afraid to take a decent looking (but not necessarily dream-) job offer, stay a year or so, then go to another different type of company. Think of it as a slow, well compensated data collection process that will lead you to a better understanding. Sure it sounds lame when put next to the laser-focused entrepreneurial stories on HN, but so what? Do what's best for you (and your family - important consideration).

PS If you do that, don't forget to code and learn something completely different in your spare time. That push/pull helps you grow a lot faster and benefit both parts of your life. Right now I'm .Net by day, Lisp by night. How much more different can you get?

Here's what I did, and it worked out really well for me (I made $68 / hr last year, 3 years out of undergraduate). I got a job that paid a miserly $30,000 / yr at first, but it was a small company and I got tons of experience. I was in way over my head at first as you can probably guess from reading everybody else's posts. But I worked and learned hard, and after that it was a piece of cake.

If you are like me, I only wrote a couple of thousand of lines of code in college. I'm up to somewhere around 150,000 now, and I feel proportionally more confident and capable. I just scored an internship at Google actually.

Then my only problem was that I got bored, so I'm spending all that money on a masters degree, which I am thoroughly enjoying.

Worry aboout having fun now and the money later. If you worry about the money now, you might end up chasing jobs with high pay and little future then you might get used to the money and the fun jobs will look too risky. But if you're having fun, learning new things the money will be there eventually because you'll be making yourself more and more valuable.

Here is a good post that I think should give you some specific answers to your questions: http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...

You should know that the world is starting to slowly figure out that programming is not like a manufacturing plant at that finding the cheapest possible labor to do it is sub-optimal.

As such, you should (hopefully) have better opportunities as a developer now than was the case a few years ago.

I'd recommend finding a team that you'd be really happy working with and can learn from. The standard deviation on compensation is not that high in your early career -- but that on fun and learning is. Pick the right group to work with, it makes all the difference.

Long story short:

Version Control (Subversion, Git) Test driven development / Continuous Integration Waterfall vs. Agile Practice talking to customers about what they want (not sure how you do this without actually having customers) Databases (MySQL, SQL Server are decent starts and commonly used) Apache / IIS (depending on your platform) Pick a scripting language and learn it well enough to automate things that are annoying. I like Ruby, but Python and others are reasonable alternatives.

I'd recommend getting familiar with Windows, Mac, and UNIX/Linux environments. A lot more opportunities open up to you when you're competent in each of the Big Three operating systems; you don't have to be a guru, just be experienced enough to work comfortably in any of them.

It also gives you a chance to personally evaluate their strengths and weaknesses and to see the design tradeoffs.

I'd say the old standby of "it depends."

There are a couple things that my college degree never taught me:

- source control. If you're going to be in the MSFT stack, learn how to use VSS. If you'll be in the LAMP stack, then learn svn. You don't have to know how to administer them, just how to use them on a day to day basis.

- databases. Learn to write queries (select, update, insert, join, create, alter, etc.). Learn SQL Server and mysql and oracle syntax (probably not in an out, but enough to know that there is a difference).

- use cases and UML. Large companies and consultant shops will tend to produce a lot of documents. If you know some UML and are able to make use case documents, then you'll be ahead of the game.

- build and deployment. Learn (n)ant, build, make, shell script, whatever. Be able to build a piece of software and deploy it. It amazes me how many pieces of software have no automated build or deploy scripts.

The question is how do you get this knowledge. It's too late now, but you should have tried to either get an internship or a job while you were in school. Now, I would pick something that you think would make a good project and actually build it. Not just start hacking, but think about the problem and really build it. If you are going to get a corporate or consulting job, this is what you'll have to do, so get used to it :)

Pick something you're reasonably knowledgeable about and that you think that you'd want to use or someone else would.

Here's a couple good ideas: - student/employee/company directory application (I've written at least 3 employee directory apps for clients. If you could write a good one, this would be a definite way in to some places). - movie/bar/store/music/concert review webapp - twitter clone - facebook clone - cms tool (think lightweight cms) - carpool creation site

All of these can be shelled out in a couple days with RoR/Django and would give you a HUGE confidence boost and would be a great addition to a portfolio. Of course, using a framework with obscure the sql details so maybe you'll want to do it in ASP.NET with C# (VB.NET is not what you want to know if you want to be "in demand") and then do it in RoR/Django to get a feel for one vs. the other. In fact, you could make a business out of them (if they didn't suck too bad!).

I would use them as a learning tool, writing some rudimentary use cases for what you want the app to do, diagramming a bit of your preliminary design (and it will change, it always does), building a db schema, running queries, writing code and integrating with a source control system. Treat it like a job too and dedicate at least 3-4 hours a day 5 days a week to it.

I think the biggest change for full time students that don't work to handle is going from 12-15 hours a week in school to 40+ hours a week at a job. At school you have 5 times more free time than you do at a job.

I may be unusual, but I have more free time in the summer, while working full-time programming, then I do during the school year. But maybe that is because I'm taking 17 credit hours (5 CS classes, all upper division) at once. I probably put in 60-80 hours a week, no exaggeration.

I'd say that you're doing the wrong thing.

I went to school full time (min 12 hrs) and worked full time (min 40 hrs, sometimes 2 jobs) the entire time I was in college (hey graduated with only $7k in debt though!). There is no way I'd have been able to, let alone wanted to put in 60-80 hours for course work (still graduated cum laude, 3.5+ gpa). Either you're in courses that you shouldn't be or you're doing too much "extra work."

JMNSHO though...

You may be right. This is the last semester of my Senior year and I'm trying to finish my undergrad up so I can start on my Master's next year. My Junior and Sophomore years weren't as bad school wise, but I was working part-time during both of them, so all in all I was probably still busy about 60-80 hours a week. I guess my point is that I've gotten used to being really busy, and working only 40-50 hours a week won't be a problem. Sounds like you're used to being busy as well, working full-time all the way through school.

Source control, DBs, and Documents - Check, Check and Check :) I had my suspicions here - now I have some confirmations. I know the basics here, but I definitely could stand to be more proficient.

School has taught us nothing of Source Control; I don't even think it has been MENTIONED - likely because we have not participated on a project that has a complexity that would really justify it (other than the practice).

SQL doesn't seem too terribly difficult (the class was a cake walk), but I need much, much more practice in it so I can stop referencing docs every time I need to do something more complex than 'SELECT *....'

As far as the documents are concerned - guess I need to break out the old text book again :) I did it, and I made good in it, but I hated it. I will not lie, I despised use cases, requirement specifications and UML diagrams, but I guess I need to get over that and learn to like it - or at least tolerate :)

I have to admit complete ignorance on automated builds and depolyable code. I guess I need to get my butt in gear and get familiarized. My university (Troy University) has only taught using MS technologies (I use Linux personally - thank god my Q6600 runs XP smokin' fast virtually) and so the extent of our deployment has been zipping up the solution files and the compiled executable and submitting it to the teach (heaven forbid you send something ending with '.gz' - I was actually told I sent a corrupted file one time).

I guess I need to get my ideas out and working. I have been hashing around in my head very similar projects to what you are suggesting... I actually purchased a domain a while back for doing just that, but, well, just haven't done it. I really like RoR, but my webhost (FriHost) doesn't support RoR, so I guess I will be limited to python if I really want an opened deployment :)

Thanks for taking the time to respond with so much valuable info!

-Matt

i think the biggest difference for me was this:

the "best" solution isn't always the right solution.

Congratulations on graduating. There is a lot of excellent advice on developing into a better programmer here.

Programming can be challenging and financially rewarding. And it can give you the money to do the things you really like to do (which is up to you). Expect burnout. It happens to most everyone.

If you are nervous interviewing, there is a fundamental behavioral-based interviewing technique that you should know. A professor's husband told me the secret (so many people do not know the secret to interviewing well [programming trivia/programming whiteboard stress tests aside]). Google "STAR" + interviewing. Or I can do a short essay. Take interviews to practice - even if you're not necessarily attracted to the particular company. Actual practice (even mock) desensitizes you so you can shine better. After your interview, mail a typed, hand-signed letter to your main contact - in it thank them and this is key tell them you will followup at such-and-such a date and time (imagine which candidate will stick out - the one who took the time or the one who could care less to put effort in formally conveying interest in landing the position). CollegeGrad.com is an excellent resource (and a has a book worth buying - the advice landed me my first job) because someone who was a hiring manager opened-the-kimono on what he expects (from cover letter to screening interviews to site visits to even salary negotiations).

Before you start your job, consider taking some time off. To pause before you start your career. Ideally, travel. Or do something you like. Once you start working, your longest vacation will probably be two weeks long. The hardest adjustment is from a collegiate environment to a professional one. With few exceptions, all of us you meet on your first day of work have much more work experience. Your "first day" may feel like its a big deal but to us grizzled workers - it's not. Therefore humility is important. Don't show off your knowledge. Ask questions about what people are doing. The more you talk, the more they'll realize what you don't know. But if you don't talk a lot and ask smart questions, they will assume you are smart. On the flip side, take the initiative if there is something that interests (or more likely bothers you about the way something is being done) - we get sometimes blind-eyed to the problematic parts of a project - fresh perspectives help. Just be diplomatic.

Mentoring. Find a mentor. Don't force it - you have to become friends first. Ideally someone who is 3-5 years older and ahead of you and at a position where you want to be in three years.

Where do you want to be in 1/5/10 years? I started out with a group of college grads who unlike me got out of their cube and took on initiative and have easily jumped 2 or even 3 levels (e.g. managing 60-70 people). I'm still a developer - I never really was interested in management but I need to emphasize that you need to be proactive if you want to move into management.

On a side note, once you leave college you may fall out touch rapidly with your friends, especially if geography is involved. Facebook helps but if you truly want to keep in touch with your friends - you should take the initiative - organize reunions (e.g. annual trips to New Orleans Jazz Fest). And (Facebook helps again), have a system to remember their birthdays (and call them).

I think that it has been hardest for me to find a mentor or even people in similar situations as a result of my education being primarily online for the last year - a decision I really regret making now. My wife took an accounting job in a different city and Troy University offers the CS degree online (primarily for the military) and so I have been completing my senior year on the computer. This has made it difficult to meet people who are doing what I am doing and to share our experiences about our journeys - thats why I turn to kind people such as yourself ;)

I have joined some computing and programming groups here, but it seems like most of them work together and the group is just an excuse to eat and catch up on people's families and such. If I mention group coding or similar activities, generally, the response is 'we should' and then no one can or does... I feel like this is what I am missing the most - just being able to lean over to my neighbor and asking 'hey man, how do you think you would do this?' or 'How did you get that to work like that?' The personal touch, you know?

Thanks for the tips wallflower!

-Matt

Hey Matt,

Here are a few of my own humble suggestions for you. I've been developing for 23 years and have been in OOP on the Microsoft platform of tools for 10 years:

1) Most of the bulleted items below are great. Dusklight has some VERY important things to say, as being a developer is surely NOT all about slinging code.

2) Nearly everything JFred said below is great advice. However, I very humbly do not agree on his #1 recommendation. If you are a programmer, then be one. If you are a manager, then be one. If you try to be what you're not, then you'd be happier stocking shelves at China-Mart at night. Concerning the upper tier of income for developers, they make more than the managers, have way less stress, easier schedules and WAY more fun. Consequently, every single developer I've ever known that has climbed into management has loathed it. I personally know a CTO who hated his job and busted himself back down to programming. Same for a former corporate department director...went back to programming (each making around the same money, BTW).

3) Now that you're graduating, your education is only now starting. Put www.bookpool.com in the top 5 of your bookmarks...buy everything from them (unless someone can give you a better, cheaper alternative).

4) Don't think on this one, just do as I say: Buy every single Head First book you can, starting with the ones you know you'll be using right away: "http://www.bookpool.com/ss?qs=head+first" Buy the "Software Development" and "Object Oriented Analysis & Design" books immediately. These are not quite as daunting as some of the other books out there that practically speak to us in machine language.

5) If you end up going down the Microsoft path of development, then focus on C#, not VB.Net. This is an extremely religious subject, so please don't allow me to explain. I have an entire word document I created as to why. If you do indeed go down this route, then buy the following Wrox Box as soon as you're able: http://www.bookpool.com/sm/0470048409

6) Subscribe to every coding newsletter you can related to your chosen technical focus and create a rule in your email client to funnel them into a folder. Read them.

7) In my humble opinion, you're like a hammer without a handle if you can program but don't know SQL and a DBMS or two. You may already know this, but Microsoft's DBMS is SQL Server.

8) If you do go the Microsoft path, you can get versions of Visual Studio and SQL Server Express for free. Also, since you're a student, they've also recently come out with plans for you. Download what you can while you can before you leave school!

9) Go out to various auction type development sites to bid for jobs that'll allow you to not only practice and hone your skills, but will also give you a small stipends and give you another notch in your resume. Example: www.rentacoder.com

10) Relax. You're going to do great!

Boyd

Thanks Boyd, I have checked out the design patterns head first book and it was incredibly intuitive and even entertaining to read. I have obtained a couple more since, I just have yet to wade through them as of yet... I am going to stop procrastinating on it and start reading them - tomorrow ;) I have recently come to realize the importance of knowing a database (and management) system or two. I kinda always knew that would be something I would need to get a firm grasp on - something confirmed from your and other's words on this thread. I feel that to be at the top of my list. I have read theory, best practices and paradigms for four years now. I think I have come to a crossroad where the application of all this theory and mess is the next move; a move where databases will be important.

Thanks for the words of encouragement, Boyd.

-Matt