The Pseudo-Realistic Subversion Experience
| Posted on Wednesday, October 08, 2008 |
0
commentsAdd comments |
This week provided me the opportunity to get the feel of a true configuration management experience, and the introduction to a new peer programmer, Anthony Du.
The objective here was to experience working on someone else’s project, and also, having someone else work on your project, but with the understanding that we are both team members on each project responsible for the improvement and advancement of the project. I call this a pseudo-realistic experience because the projects both Anthony and I collaborated on are our trivial stack implementations.
Getting Started
Anthony and I had a rough start when we paired up. I had not worked much with Google Code or TortoiseSVN at that point during the week. I had been focusing my attentions to the assigned configuration management readings for the week, and had foregone any testing or experimentation with actual process of subversion control prior to class. Anthony on the other hand had been experimenting with trying to host his project remotely. We spent the majority of our lab getting to know each other and experimenting with hosting my project, since we were limited to using my laptop.
I think this actually paid off for us in hindsight, as we met later on Wednesday evening and both seemed much more confident having progressed further with our understanding of the hosting of our projects.
Working Our Projects
Once we both got our projects hosted, I did not encounter any additional obstacles. I made minor changes to Anthony’s build, which failed to pass the verify check due to some tabs in the code which broke the CheckStyle quality assurance test. Anthony added the
Growing as a Developer
I’m confident in my skills as a developer. I’m not saying I’m a great developer, and definitely not a perfect developer. But, I don’t get intimidated by code or put off when approaching a new project. I think I try to approach code objectively and with a sense that whatever I want to attempt should be possible, even if at first not elegant. For many years my personal mantra has been “If there’s a will, there’s a way!” So, why then does my heart beat faster, my adrenaline start pumping, or perhaps I even give a slight cringe at the thought of others working on or reading my code?
I think this is because as a developer putting my code out there for others to see is tantamount to flaying my chest open to expose my beating heart. I would rather have a paper I have written critiqued than have my code criticized. But, I need to become accustomed to this to grow and improve as a developer.
I think this is the most valuable lesson I will learn, having just started the journey, in leaving the single-developer lifestyle behind and joining the world of team project development.
The objective here was to experience working on someone else’s project, and also, having someone else work on your project, but with the understanding that we are both team members on each project responsible for the improvement and advancement of the project. I call this a pseudo-realistic experience because the projects both Anthony and I collaborated on are our trivial stack implementations.
Getting Started
Anthony and I had a rough start when we paired up. I had not worked much with Google Code or TortoiseSVN at that point during the week. I had been focusing my attentions to the assigned configuration management readings for the week, and had foregone any testing or experimentation with actual process of subversion control prior to class. Anthony on the other hand had been experimenting with trying to host his project remotely. We spent the majority of our lab getting to know each other and experimenting with hosting my project, since we were limited to using my laptop.
I think this actually paid off for us in hindsight, as we met later on Wednesday evening and both seemed much more confident having progressed further with our understanding of the hosting of our projects.
Working Our Projects
Once we both got our projects hosted, I did not encounter any additional obstacles. I made minor changes to Anthony’s build, which failed to pass the verify check due to some tabs in the code which broke the CheckStyle quality assurance test. Anthony added the
bin directory to my project, and I was able to check it out and sync my local copy with the changes he had checked in to the remote repository.Growing as a Developer
I’m confident in my skills as a developer. I’m not saying I’m a great developer, and definitely not a perfect developer. But, I don’t get intimidated by code or put off when approaching a new project. I think I try to approach code objectively and with a sense that whatever I want to attempt should be possible, even if at first not elegant. For many years my personal mantra has been “If there’s a will, there’s a way!” So, why then does my heart beat faster, my adrenaline start pumping, or perhaps I even give a slight cringe at the thought of others working on or reading my code?
I think this is because as a developer putting my code out there for others to see is tantamount to flaying my chest open to expose my beating heart. I would rather have a paper I have written critiqued than have my code criticized. But, I need to become accustomed to this to grow and improve as a developer.
I think this is the most valuable lesson I will learn, having just started the journey, in leaving the single-developer lifestyle behind and joining the world of team project development.
