Lol. Anybody in the industry here want to be my contact? ;-)

(cough)TALONIUSHOWAREYOUDOINGTODAYMYTHAT'SAFINEJACKETYOU'REWEARING(cough)

j/k... sort of.

In all seriousness, I've been absolutely overwhelmed by the number and helpfulness of responses I got to this question. I feel this is some of the most valuable information on the field that I could have found. This whole post is like a melting pot of information on the transition from school to real-world programming. "Thanks" doesn't even begin to cut it.

P.s. if you have more to add, then by all means, keep the thread going! Maybe they'll sticky this bad boy; I certainly see how it could help countless anxious students, wondering what to do when school is done.

Thanks again (and keep the responses coming! ;-))
-Brian

[Edited by - BTownTKD on March 14, 2006 9:02:19 PM]

CS undergrad. Currently interning in a well-known software house and have experience in every 'type' of organizations from small businesses to big corporations to governmental/para-governmental agencies (of 3 different political entities [grin])

Quote:Original post by KingsRevenge
Cool post, I was wondering about this as well. Do you guys have any tips or ideas on what things area a "MUST KNOW" before you get out of college? Things that will help make the conversion to real world an easier move?

You're a CS grad. You need to learn software engineering.

1) Requirements analysis
2) Planning and scheduling.
3) Teamwork teamwork teamwork.
4) Source Code control (Believe me, this warrants a bullet by itself seeing how many grads don't even know how to use it.)
5) Design patterns
6) Self-motivation, leadership and autonomy.

Also, you were talking about a small cleanly coded project. No one cares. What they want to see is a big project that people use, preferably developped as a team. Making good contributions to an Open Source project is a good way to do it.

jfclavette

Could you explain the differnet experiences you got working in your 3 different types of programming fields? Mainly private industry and government?

Quote:Original post by Anonymous Poster

Quote:Original post by KingsRevenge
Cool post, I was wondering about this as well. Do you guys have any tips or ideas on what things area a "MUST KNOW" before you get out of college? Things that will help make the conversion to real world an easier move?

Must know:
1) People skills
2) How to shower
3) How to do laundry
4) How to brush your teeth

Half joking (but, knowing some CS people... only half joking...)

Oh, yes this is true. Plus

5) How to go home
6) How not to make the bed in office.
7) How to enjoy some vacation time (very important to withstand burning out)

P.S. - I was guilty of this at some point of time too. But ofcourse it was my choice

DISCLAIMER: I work for the gov't so it may not be entirely representative of the private software industry, but it's definitely similar in many ways. Our goal is to use the best practices from industry in our software development.

Quote:Original post by BTownTKD
What's real-world programming like (not limited to game design)?

It's like a lot of the engineering you do in college, except now you have to deal with people and office politics. Unfortunately, you don't get to be an engineer all day because you have to deal with meetings, office crap, etc. The work however is in many ways similar to what I did in school.

Quote: Do people recieve more than one programming project at once (like stupid me, taking 2-3 CS classes at once), or is it typically a one-project-at-a-time world?

I work on multiple things at one time (and actually prefer that, as my attention span can be short at times), but ultimately, everything I do is part of the same system, or same type system. One day I might be looking at hardware drivers and another day I could be implementing operational sofware, or maybe developing tools of some kind to support our activity. Maybe later I'll be writing documentation.

Quote: Are the specifications for each project as specific as the specs for school-related programming projects, or do they leave more room for interpretation?

They should be. We have a set of requirements that tells us what the system "shall" do. In our software, we need to make sure we meet those requirements. If there's room for interpretation, there's problems. We deal with software that goes into very destructive weapons, so if there's any ambiguity in a specification it will need to be fixed to explicitly define the requirement. There are however details that truly are implementation dependent, and those are fleshed out in the software design process. This can be things like how you want to break up module, e.g. do you use multiple tasks for this processing, or let it be one task, what type of built in debugging do you need, etc.

Now, I also did an internship where the company was developing a GUI system and the requirements for that were much more nebulous. Ultimately that system was implemented and tested, then the users had to go back and explain what they wanted changed, or how they really meant something to be.

Quote: In general, have you found it to be easier or more difficult than the path to a CS degree?

I actually found college more difficult mainly because of the work load. At work, I go in at 7:15 and leave at 3:45, and once I drive out the gate, I'm not working, and I don't need to think about my job at all. At school, I had to go to class. Get out who knows when, then spend the rest of my time doing homework until midnight. Then I had to do it again the next day, then much of the weekend. Now, I don't do anything for work on the weekends.

Now, as for the problems we're solving, I'd consider them on par with what I did in school, and I do think school prepared me quite well for the types of problems I'm seeing.

Quote: What's the typical day for a programmer? Do they spend the entire 9-5 day programming non-stop, or is it a bit more relaxed than that?

Ok, Here's one of my days from this week
7:15 - Check email and misc. administrative stuff
8:00 - Go over to the lab and start coding.
8:30 - Talk to the contractor about what's going on
8:45 - Code some more, discuss issues with co-workers
9:30 - Code some more, have someone from downstairs tell me the results of some run. Start thinking about what caused a problem
10:00 - discuss problem
11:30 - Lunch!
12:00 - More coding
1:00 - Meeting about something, code review, testing, design review
2:00 (hopefully) - Discuss meeting. Determine meeting was an almost total waste of time (not reviews though, those are very useful when done right)
3:00 - More coding
3:45 - leave

That was one day this week. On an average day, I usually get more actual work done, and I prefer those days.

Quote: If someone in a team finishes their specific task, do they get to kick back until the rest of the team catches up, or are they immediately assigned another one?

There's usually a sufficient queue of projects that need to be completed, so no one really has nothing to do, though many people are more than happy to do nothing. We have meetings almost every week where were go over what needs to be done and by whom.

Quote:I've heard that debugging, pointers, and sloppy uncommented code are a few huge problems among programmers: if I've got a solid grasp of all these skills, do I really have that much of a leg-up in the industry?

I consider general debugging and pointers to be fairly trivial at this point. I will agree that maintaining sloppy, uncommented, poorly written code is one of the hardest things to do. In many cases, it becomes easier to rewrite the code correctly than to attempt to fix the existing code. I've had many cases in the last few weeks where I looked at a piece of code and literally said "WTF?"
Well written, consistent, commented code is a pleasure to maintain because that's the right way to write code.

One of the guys at work gave me a list of what he considers to be the hardest problems (and if he considers them hard, they're hard).
-Caching problems
-Interrupts
-Mutual exclusion

Doing embedded hardware stuff, these problem can be nightmares. It's not surprising to have to dig through a 700 page manual to determine what bit 5 of register X means. If you're doing Windows development, you're not going to see problems like this though. There will be other problems that present themselves as the big problems.

Quote:Yeah, it's a REALLY naive question; I'm interested anyway.

Actually, I think these are very good questions, and if I were interviewing someone for a position, I'd like being asked questions like this.

EDIT: More answers.

Quote:
What kind of hours do programmers pull? I've heard 10-hour days, sometimes 7 days a week, but is that typical??

I almost always do 5, 8 hours days. Sometimes I stay later to get credit time. Rarely am I every required to stay longer. IMO If your organization has you working 10 hours days, 7 days a week, they scheduled poorly. Furthermore, the quality of code developed after 8 hours of coding drops dramatically. Ultimately, a progammer working 40 hour a week is very likely going to be more productive than one working 80 hours a week. Electronic Arts, I'm looking at you[evil]

Quote:How much time does one actually spend at the office? I.e. How often does one hear of a programmer that programs mainly at home, and spends little time at the office (maybe they only go in to get updated specs or collaborate with other teammates, then does the work at home).

Well, I guess since my work is classified, I'm not going to represent the norm here. I work 100% in the secured lab. I'd doubt many programmers work a significant amount of time away from the office though. There's a lot of interaction that happens between co-workers.

Quote:I feel I have a really solid skill with writing clearly and concisely, that might otherwise go to waste if there wasn't the opportunity to write doumentation and such.

Congratulations!!! You're going to be writing all the documentation[wink] J/K...hopefully. Seriously though, I believe that my internship as a tech. writer got me my current job. A competent engineer who has proven proficiency in technical writing is incredibly valuable. Definitely put it on your resume and make it stand out.

[Edited by - Cold_Steel on March 15, 2006 9:46:43 PM]

Quote:Original post by KingsRevenge
jfclavette

Could you explain the differnet experiences you got working in your 3 different types of programming fields? Mainly private industry and government?

I don't have intensive experience in all of them, and this is mainly opinions and obviously will vary a lot. However, my experience has been:

Governments (Québec's government, some European country's government):
- Often better work-life balance than everywhere else. Not as much pressure as the private industry.
- Less 'will' to make it work from the upper management, which often translates in fear of confronting employees (read, the dumbass who can't program but somehow got in will NOT be fired unless he really screws something up.)
- BORING work environment. (Not talking about coworkers specifically, but rather the whole culture. YMMV)
- Often oversized benefits compared to similar job in the private industry.


Small private (Mom and pop software shops you don't know about):
- Small business are hard to nail since they vary so much. Some are awesome, some are the crappiest place to work ever.
- If your employer skips payday, even once, sue him right away and bail out. Unless you somehow know him personally.

Software corporations:
- Most corporation pay employees pretty well.
- More challenging and demanding.
- My favorite by far. Take this with a grain of salt since I've always wanted to be in the "shrink wrap" software industry.

Non-software corporations:
- My worst experience. All the bad from government with more pressure.

Quote:Original post by Cold_Steel
I will agree that maintaining sloppy, uncommented, poorly written code is one of the hardest things to do. In many cases, it becomes easier to rewrite the code correctly than to attempt to fix the existing code. I've had many cases in the last few weeks where I looked at a piece of code and literally said "WTF?"
Well written, consistent, commented code is a pleasure to maintain because that's the right way to write code.

on the issue of comments, what do good comments tell you and more importantly what do they not tell you. Also is it wastful to write comments that basicly say what can be derived instintanisly from well written function names and parameters.

For example the function

int
CalcVolume ( int len, int wid, int hig)
{
}

is not something I would write a comment for because just by looking at function I can see that Calculates the volume and returns it in an integer form. The inputs though only three letters long are restricted by the function name regarding what they stand for and as it is calculating the volume len to me is restricted to meaning length, wid to width and hig to hight.

as far as class function members go the same type of logic applies, I could have both these functions but don't see a reason to put any comments

int
Box_Class::lengh ()
{
return m_lengh;
}

void
Box_Class::lengh ( int len)
{
m_lengh = len;
}

well both have the same function name lengh, the one returns an integer which means it is most likly used to access the member of Box Class called m_lengh, well the second one sets the member m_lengh to the value supplied by len.

Good info, please keep it coming.

Yeah, really appreciate the things being posted here. Very helpful. Thanks (and keep it up)!