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.
|
|
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:
|
|||||||||||||||||||||
|
|
The importance of 'soft tasks' in a work environment. Things like:
|
|||||
|
How To Use Google EffectivelyI 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" |
|||||||
|
|
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. |
|||||||||||
|
|
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. |
||||
|
|
|
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. |
|||
|
|
|
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. |
|||||||
|
|
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. |
|||
|
|
|
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. |
|||
|
|