Teacher and student statue by Paul
A few months ago, I wrote about how to introduce new programmers to your project. Back than, I was the one introducing new programmers. This time, I am in the learning seat.
Since the beginning of September, I have been mostly dedicated to the knowledge transfer for a current project at my new job. This is quite exciting to me since I have been learning a lot in that process. Today, I have reached the close end of it.
The project is a big one. It is mainly based around Microsoft technologies, the current deployment process involves multiple different quality environments, there are multiple dedicated system administrators for it, it has to work with many different data stores including more than six databases located in many geographically different places and it is used in more than five countries in different time zones with different languages. It is a great work of architecture and design.
I have been thought on how to develop, debug, find and correct bugs for it since I will probably be maintaining it for a while. My coworker who has been my mentor in this process already had a draft list of what should be done in order to get me going. That included the software I had to install on my computer, the order in which I had to install them, any potential shortcomings with the installation process and the general sections of the application which he had to show me around.
In the last weeks, my coworker showed me the way in the application. I had to learn quite much in each days of his training. While doing this knowledge transfer, I completed his draft list to include more details and more points about the whole thing. This document will form the base of the next knowledge transfer whenever there will be a new member joining the team.
Between two sessions where he would be sitting at his computer or at mine and teaching me how to find the important configuration files or how to debug a remote web service, I was assigned a few change requests to complete. They were all quite easy to do. What was more interesting is that I learned more about the application by completing those tasks than by listenning to my coworker. I still have some great respect for him but working directly to develop a new feature or a client request for the application had a tremendous effect on my capacity to understand and learn about the application.
I do not know if this is related to my personality or my abilities, but it seems to me that learning by doing is way more efficient than learning by observing when it comes to software development. Reading back my first article about it, I am coming back to the same conclusion.
Post a Comment