Friday, May 11, 2007

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.

1 comment:

  1. My personal favorite job for a newbie developer is 3-6 months of maintenance. Not because I don't like doing it, mind you, but because it's the place where the newbie and the company benefit most.

    The newbie learns about:
    1) the value of working code ("sheesh, look at this garbage! let me just change that loop... oops, why isn't it working anymore ?!")
    2) the importance of updated documentation (as much within the code as outside)
    3) the mess you can create when writing messy code and
    4) the way the organisation works (where to really find the knowledge, the history of things, etc.)

    The company can benefit from a fresh view on (maybe messy, but mostly working!) legacy code and has time to assess the newbie's ability to add value.

    Once the newbie has acquired these maintenance skills, he's ready to write new code, IMHO. And nobody will need to tell him to document his code...

    ReplyDelete