# What do you wish you had been taught in uni before moving to industry?

Is there something that you wish you could have learnt, as part of a course or something, in uni, now that you've been in industry for a while? Maybe something such as "I wish there was a course in time estimation" or "I wish I had learnt how to work in large projects", and so on.

-
@Jonathan, related, but not duplicate. This one asks for what was not taught at uni even though it should have been. OTOH this is likely a duplicate of other earlier posts - will try to dig up some links. –  Péter Török Mar 9 '11 at 20:46
I find this hard to answer, as curriculum varies between universities and even at the same university over time (Python is the new intro language?). I like the question What are the set of skills that every programmer graduating from college should have?, although I was hoping I'd find an answer in the form of a checklist of technical knowledge (e.g. OOP, design patterns, Big-O, algorithms). –  Jeff Mar 9 '11 at 20:54
Linux. (That's all I really have to say, but it won't accept comments that short...) –  Beekguk Mar 9 '11 at 22:53

I agree with time estimation, my boss recently told me that as a new programmer I should always double the estimate I think something will take. We barely covered this in college as a computer science major. And it's a pretty important skill to have because giving too short of an estimate sets unrealistic expectations.

-
I find that even that estimate is too small. The double-then-double-it-again method seems to give a good-enough estimate, but that's not really an estimate: that's the not-knowing-what-the-hell-you're-doing-so-better-make-it-safe-by-a-long-shot method. –  gablin Mar 9 '11 at 20:52
@gablin, if you can't give an accurate estimate, don't. Break the task down until each part can be done in, at most, less than a day. –  CaffGeek Mar 9 '11 at 22:21

The importance of 'soft tasks' in a work environment. Things like:

• Version Control
• Bug tracking
• Automated Testing
-
+1 for version control. Never has this been even considered in any of my courses (usually I've imposed that on my team members, for everyone's sake). –  gablin Mar 9 '11 at 20:57

## How To Use Google Effectively

I once had a course where we were instructed to make a website for course scheduling using JSP & Apache. Thats it, end of requirements and no training(pretty on par with what I often receive in the industry). No one in the course had any experiance with webservers, html, css, etc. It didn't matter we still had to set up an apache server and create a functional website on it with out any instruction.

This is one of the most valuable skills I ever learned. I had to find out everything on my own with the help of a search engine. I use this skill constantly and feel very secure that given an hour or so I can find the solution to most problems.

I'm often shocked how many questions I am asked at work that can be solved with "let me google that for you dot com"

-
I had www.inygb.com for a while - "I'm Not Your Google Btch". Let it lapse once the joke wore off. –  Мסž Mar 9 '11 at 21:30
–  Morons Mar 9 '11 at 21:50

Effective argument/debate and working with people of various other roles. In school you mostly deal with people who are similar to you - technical, taking a technical major like CS, but in the real world, you will deal with a variety of people who don't understand the same terminology as you, or who don't see things the way you do.

For example, product managers, marketers, business people don't care about ultra cool technology, they are more focused on the business, the company finances, working with customers, etc. Being able to discuss and 'argue' with them would be useful to learn, for those situations that inevitably arise where you have to defend something from being cut out of a project or why something should not be done the way they want, etc.

So in summary: people skills for interacting with other people and customers.

-

How to handle large, pre-existing systems!

What I mean is that it is rare to just walk into completely new development. Usually you go into an environment where the code has been around for a while. So things that could be taught are:

• Debugging large systems.
• Code comprehension of large systems.
• How to build large systems.
• How to handle supporting large systems. i.e. field issues.
-
Worse, many lecturers do stupid stuff like "you can only use the libraries I supply and code you wrote yourself, no getting code off the net". Which makes it easy to mark, but that approach hurts you a lot once you get a job. –  Мסž Mar 9 '11 at 21:31
Large systems are hard to do in a 3 or 4 month semester. There just isn't time to get into one (at least by my definitions of large). –  FrustratedWithFormsDesigner Mar 9 '11 at 22:19
+1 for "Code comprehension of large systems" - especially messy, poorly-documented ones. My supervisor just noted a large uptick in my productivity ... only happened because I finally had a good idea of what I could change without breaking the rest of the project! –  Beekguk Mar 9 '11 at 22:31
–  TheLQ Mar 9 '11 at 23:51
@Mark C: I've often wondered why there were so few year-long CS courses when I was in school. Some subjects really could have used a much deeper examination of the material. Oh well, I guess they'd say that's what graduate studies are for. –  FrustratedWithFormsDesigner Mar 10 '11 at 14:39

Real life examples. Often the examples in textbooks are so oversimplified as to be useless.

A class in dealing with difficult people.

A course in how to do software support. It is hard to maintain an Enterprise system if you don't know how.

-
Hm ... I would hate to pay for a class on how to do software support. –  Job Mar 9 '11 at 22:32
"Dealing with difficult people" sounds like something that should be learned by experience. –  larsmans Mar 10 '11 at 10:21
"A class in dealing with difficult people" - that why a graduate's first job is in a call centre ;) –  Matt Ellen Mar 10 '11 at 12:33

Half of my job seems to be helping to write documents - like operational concept documents, requirements documents, design documents, user documentation, etc. I took a technical writing class in college, but I wish I had been even better prepared for all the writing I have to do.

Also, I wish college had better prepared me for changing requirements and scope creep. Every programming assignment I had in school had fixed requirements that never changed. However, in the real world, rarely have I worked on a project that didn't have significant requirement changes while it was being developed. Even when you have a customer's requirements seemingly nailed down, they change. It used to bother me when requirements would change and I would have to redo a bunch of work - now I expect it and know to extend time estimates because of things like this.

-

How to code for future developers

Sure, college taught me to write code that works. What I had no idea was how hard it is to write code that needs to be changed in a month or in a year. This means real documentation, loose coupling, dependency injection, etc. It is very painful learning this stuff the hard way out in the workforce.

-

Unit testing and Test Driven Development. To be fair, I finished uni around 2002 and TDD only originated around 1999, but it wasn't at all obvious how to get started with TDD when I was basically teaching myself. For me, TDD was a gateway to a vast number of other practices and principles, such as IoC, DI, SRP, Agile, even Kanban.

-