University to industry transition - C++

Hi all,

I am starting a years work placement in a few months as part of my degree course, and wondered how people found the transition from Uni to industry with respect to applying their programming skills. I admit, I am still extremely new to programming and in particular C++, only applying my knowledge to small scale problems. I have the next 4 months, without any uni distractions, to get my skills developed further (I have been spending, and intend to continue to do so, around 3 hours daily reading and practising)
Any advice would be welcome.

Thanks.

What are you doing, working two jobs or just watching a lot of TV? How 'bout pushing that up to 5 or 6 hours?

Originally Posted by MK27

What are you doing, working two jobs or just watching a lot of TV? How 'bout pushing that up to 5 or 6 hours?

Ha....no, as uni has finished now, I only work at weekends. I don't see any reason why I can't up the hours...I do tend, however, to have a sore head when taking in too much at once

First, what I learned in school...

I had a database prof who said we would never understand SQL until we mucked around with relational algebra.

I had a "Theory of Computation" class where we apparently learned how to make alphabet soup.

UML... useless modeling-or-something language.

Transitioning to the work world...

I begin to see a recurring "design pattern" everywhere I look, the "great idea, poor implementation" pattern.

uh oh, here's that UML-crap again, "what!? I ain't writing no f*****g documentation! Get out of here!"

oh geez, the project manager is screwing with the code again... quick, somebody login to Trac and start pressing the blame button!

"What the hell is wrong with this SVN thing!, All I want to do is commit my files!"

You'll gradually learn how programming in the workplace is actually quite different, in several ways. Here is just a few I'll pick out at random:

At University:
You write mostly new code, or at least build upon your earlier projects.
At work:
You spend as much, if not more time maintaining existing code.

At University:
The people handing out the work know how to do it, though you might not.
At work:
The people giving you the work have less of an idea how to do it than you do.

At University:
You mostly just have to fix your own bugs.
At work:
You spend a lot of your time fixing other people's bugs (sometimes discovering that they are actually yours from way back).

At University:
You comment your code by explaining what the code does.
At work:
Your main reason for commenting code is often to explain why it is doing what it is doing, so the next idiot doesn't "fix" it, thinking it was wrong.

At University:
The only people who need to be able to understand your code are yourself and the person marking your work.
At work:
The next person to touch your code could be a total dumbass and if you write really clever code then the next person is probably going to screw it up.

At University:
If you have a bug, you are the only one affected by it.
At work:
Sometimes bugs get political, and you may be required to hide the bug's symptoms if you cannot fix it quickly.

At University:
Changing code is only risky if you don't have a backup copy
At work:
You need to consider the risk of every maintenance change you make, despite having version control systems in place.

I could go on and on...

Originally Posted by StainedBlue

oh geez, the project manager is screwing with the code again... quick, somebody login to Trac and start pressing the blame button!

Wow, that's an issue I'd get sorted out asap! They should never have write permissions, and perferably not read either.
A project manager has about as much business changing code as you do rescheduling/reprioritising their projects.

Originally Posted by iMalc

Wow, that's an issue I'd get sorted out asap! They should never have write permissions, and perferably not read either.
A project manager has about as much business changing code as you do rescheduling/reprioritising their projects.

Don't we wish. But he only screws with html/css/and a bit of javascript. It's nothing that breaks the application, but enough for others to have to go behind and re-do.

It's a pain if nothing else.

Originally Posted by darren78

Ha....no, as uni has finished now, I only work at weekends. I don't see any reason why I can't up the hours...I do tend, however, to have a sore head when taking in too much at once

That's what practice is for. I can only play guitar for half an hour at a time before my hand cramps up, but then I am not much of a guitarist.

I imagine if wanted to say, become part of a working band that expects to perform on stage, I'd better get comfortable playing longer. Part of that, I imagine, is learning to pace yourself and understanding your own rhythms (pun!).

Actually, a big part of the reason I have so many posts here is because when I'm working on something, the easiest thing to do to clear my head sometimes is answer a forum post, because I am still at the keyboard and thinking about code, or something related, but not the same code. If I just get up and walk around or something, I tend to keep going over what I was just doing. Sometimes that's good too (I'll often solve a problem I've been grimacing over at the keyboard during the 5-10 minute trip to the corner store for liquor/drugs/ammo).

Maybe you need to try a big personal project that you can't help but obsess over 70 hours/week for a while Of course if you are still in school maybe you are burnt out from that kind of thing and do need to take a break for a few weeks.

More to add to iMalc's list:

At University:
The number of people working on the code at any one time is 1.
At work:
The number of people working on the code at any one time can be many.

At University:
The time taken to finish a program is measured in hours or days.
At work:
The time taken to finish a program is measured in days, weeks or months.

At University:
The size of the project can be up to 1000 lines (possibly larger).
At work:
The size of the project can be up to 1000 files (possibly larger).

(for large companies at least).


If you're with a outfit where there are only a handful of coders in the entire company, you might end up being in total control for an entire program. So problems such as "what someone else just checked into the repository" are somewhat curtailed.

But you still need your head screwed on the right way when it comes to planning and designing your program. Just sitting and hacking away is seldom productive on programs that take more than a few days to write (you quickly forget some nuance from the day before yesterday, and that's when the bugs start appearing).