
Ask YC: What do I, a graduating CS student, need to know to go into the real world as a programmer? - eznet
What do I, a new graduate, need to make sure I know to land a decent job in the 'real world' as a programmer?  I am graduating in less than 2 months with a Bachelor of Science in Applied Computer Science (BSACS) and feel clueless about what is approaching rapidly - a.k.a THE REAL WORLD.  I know this question has been asked and answered countless times (most of which I feel that I have read), but as is the case with all in the tech world, often this information becomes dated rapidly, is one sided or extremely biased.  So again, what concepts, technologies, languages and various disciplines do I need to KNOW in order to be proficient, or at least to be good enough to land a job, as a professional programmer?<p>I find myself feeling as if I know all this 'programming stuff' but have no real clue of how to sit down and work in a development environment with other developers on a real project.  Not only this, but I feel that I know a little about a lot - i.e. I am a jack of all trades, but a master of none. Clearly I have done problem solving and system design in my classes, but these projects are limited to core concepts based heavily on CS theory and are often very limited in size and complexity.  I have been exposed to C++ (4 classes), Java (2 classes), VB.Net (1 Class), SQL (1 class), Discrete Mathematics (1 class), Project design and management (1 class), Advanced Algorithms and Design (1 class) as well as a sprinkling of various other 'CS-related' classes via my education.  On the side I have played and dabbled with Ruby, Python, PHP, C, C# and a handful of other technologies that escape me now.  I have a 3.6 GPA and have not made less than an A in my core CS classes since the beginning, but again, I still feel clueless.<p>Any tips, suggestions or criticisms are warmly welcomed (well, except criticism, which will be welcomed, just without the warm feelings attached).  Please, where time and willingness permits, be specific - do I need to know how to design/write a compiler?  do I need to know assembly (taking that class this term anyways)?  If I want to make money first and worry about fun later, should I focus on corporate adopted technologies (Java, anything Microsoft, etc.)?<p>Thanks in advance!<p>-Matt
======
tjr
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.

~~~
eznet
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

~~~
apathy
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.

~~~
eznet
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

~~~
apathy
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.

------
thinkcomp
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.

~~~
tjr
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.

~~~
jmtulloss
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.

~~~
wheels
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.

~~~
jmtulloss
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.

------
JFred
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?

~~~
eznet
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

~~~
maximilian
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.

------
ajross
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.

~~~
eznet
"'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!

------
dusklight
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.

~~~
eznet
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!

------
angstrom
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.

~~~
eznet
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

------
wehriam
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.

~~~
eznet
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

------
eznet
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

------
hooande
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

~~~
eznet
"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

------
aristus
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.

~~~
eznet
"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

~~~
pchristensen
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?

------
dasmith2
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.

------
gcheong
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...](http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.htm)

------
dshah
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.

------
jdvolz
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.

------
crystalarchives
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.

------
goofygrin
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.

~~~
Psyonic
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.

~~~
goofygrin
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...

~~~
Psyonic
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.

------
noodle
i think the biggest difference for me was this:

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

------
wallflower
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).

~~~
eznet
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

------
Boydski
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

~~~
eznet
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

