Things they wouldn't teach you of in college

I had an interesting conversation with one of my colleagues, a couple of days ago, about the best way to coach the newly hired developers who just graduated in university. He was doubtful about what to teach, since some of the technologies used in the project were new for him too.

Well, it's not about the technology, at all. A young, smart developer, can learn a new technology faster than I can do. He's probably already learned a couple of fashionable technologies for the thesis, still he desperately needs to learn all of the things that university doesn't teach (sometimes, doesn't even mention) but that are vital for becoming a good developer, or a good IT consultant.

So I started thinking about some posts, hoping that they could be meaningful or useful for the case...

The test of time
A student can write code. Can also solve difficult coding puzzles. But writing good code is another stuff. The main reason for this, is that coding for an exam is a pretty simplified job compared to coding for production (which is the typical developer's stuff).
Think about the context:

• you are given a task (sometimes you can even choose it)
• you are given some constraints
• you can work alone, sometimes in a team
  

But the most important question is: "What happens after I deliver the code?" and the answer is ... nothing. Well, nothing, unless you fail the exam. But the point is that in the university there is no such thing as the maintenance phase. Your code lasts the time of an exam (it's like a butterfly, in a way...) and then it's gone. Will you ever need that code again? I bet not.

So you're missing a big part of what the code is for, which is users and colleagues. The former will ask you to change how the code works, the latter the way the code is written. More about this in the next posts.

Tags: OOP, Software development, Coaching