
Journal Journal: The status quo
It's been awhile. Quite awhile to be honest. Well, since my last entry, I've started another job. Due to money loss in a major market, IT was restructured. I've since gone back to contracting, which, by all means, is a great way to earn experience and merit in IT. As opposed to the Windows application end of .NET, I'm now observing the web application front of .NET. It's slightly different than the windows application asppect, but more simple in my opinion.
During my first Developer job. I was easily overwhelmed with the coding style of my co-workers. All of them had more experience than myself, and were either much farther along in college, or have already completed their degrees. During this time frame, I did learn some new syntax, but what I really learned was Code organization; further embracing the object - oriented thought process. When I started my current job, I came behind another developer. We worked together for a few days before he left to pursue another job. While he was still with the company, I went through his code with him. One particular piece of work was a 3000 line beast. Now, I understand that 3000 lines isn't much in comparison to many of the projects out there, but if a web application needs to do nothing more than create a query to send to a single table in a database, and then return the results, it makes one wonder. After spending a good day stepping through the processes of the application, We were asked by the manager to make changes to the functionality of the page. These changes took hours to implement. Not because the changes were major, or numerous, but because each time a change was made, the compiler would return errors in the build, and we'd have to troubleshoot in order to get things running again. I told the co - worker that we should sit down, and possibly look into restructuring the application. He was hesitant at first, but then conceded, saying that since he wasn't going to be working on it anymore, I should go ahead and make the changes I needed. I spent the next 2 days refactoring his work. Reducing his application to roughly 800 lines of code. He requested a copy of the source as 'reference' before leaving.
I've been here a month so far. it's the only real significant thing that I've done, as far as I'm concerned. Red tape has kept the application from being used widely, so I'm currently working the channels to possibly remedy that.
I never realized how important architecture was, that is, until I had to deal with someone else's code. Which is always a bit of a challenge in itself, but even worse if things aren't organized in some form. A book that really helped my attain a better grasp on OOP was The Object oriented Thought Process by Matt Weisfield. It's a good read for anyone at any level of development. it may confirm some things you've always thought, as well point out some of the things you've been doing, and different ways to do them. Well, that's all I got.