The Transition...

Jonathan Paulin — Mon, 16 Jul 2007 17:09:46 GMT

For the last 7 months, I've been working at a company that makes accounting software for the construction industry. Fresh out of the womb of one of those Universities in California, I’ve had to transition from the academic world to the business world. I’ve had quite a few unexpected challenges. Back in college, I felt confident in my understanding of what a "Software Developer" was, yet I was quite mistaken. As it turns out, the "Everything Is Perfect Computer Science World" and the "Make It Work Before This Deadline Business World" are quite different. While I scratch my head looking at my CS degree hanging on the wall, I'll recap a few of the surprises I've found along the way.

1.) When you are coding in a software company, you might not be spending 99% of your time trying to make a complex algorithm work.

This was a shocker. I always figured the hardest and most time consuming part of programming was writing complex yet elegant algorithms. Albeit, in some fields, I'm sure this is a large part of it, but the deeper and deeper I fall into this software development world, the more I find that writing hard algorithms is a very small piece of the puzzle. Managing a large code base between multiple programmers, writing maintainable code that will make sense tomorrow, and realizing that adding more features does not necessarily make something better are some of the day to day challenges I face. A large amount of the complexity I thought I would deal with just isn't there.

2.) Maintaining code: Round One...

Data Structures and Algorithms.....Check.
Operating Systems and Compilers.....Check
Networks, Security, Database..…Check
Graphics, Animation, Artificial Intelligence…..Check
Billions of math courses.....Check
One simple class on code maintenance........Priceless

I never had any idea how big code maintenance is. In college, almost every project I worked on involved me sitting down and coding something from scratch. I did the design. I did the coding. I did the testing. I never worried about others looking at the code. But now, everything is different. Sometimes I deal with legacy code that is over 9 years old, and other times I'm dealing with someone else’s code that is only half complete. Learning how to look at a piece of code that you know should be rewritten from an academic point of view but should not be changed from a business point of view was difficult for me to accept. Once you realize changing something can (a.k.a. will) introduce a million new errors, you start to think twice about the change. In the business world, not every block of code can be an elegant masterpiece. There is definitely an art form to maintaining code. I think a good first step in the right direction is to follow the Good Enough principle (design software to fully satisfy the current requirements and nothing more), and to realize that the purpose of the code is to make the company money, not be put into a code museum.

3.) Doing things right the first time around is awesome.

I remember back in college, I would be sitting there, writing some code, and then think to myself, "I should abstract this piece and put it in a function. Eh, I'll do it later." Of course, I'd never get around to it. Other times I knew that if I would just spent 1 hour learning some programming tool, my life would be a hundred times easier for whatever I was working on. Alas, I wouldn't do it. These little lazy tendencies can end up costing me enormous amounts of time. I found that if I have to work with some code that employs a technology I'm not familiar with, I'd best go Google it and spend a little time reading about it. Playing this guessing game of "It should work this way" sucks since it usually never works exactly the way you think it does. I found that there is no reason to be intimidated by new technologies or new ways of doing things. I use to think learning a new language or a new tool was this huge deal, but it really isn't. When I first had to learn ADO .NET, I thought it was going to be this enormous beast that would take me months to learn. Within a single day, I was able to use it comfortably for what I needed. Many times I've been faced with having to do things the quick and easy way (but not maintainable or scalable), or the more advanced correct way. I've found over and over again that when you spend extra time doing something correctly, you end up saving massive amounts of time when you have to come back to it later, and you can just assume that'll come back to it, because you will.

In conclusion...

There are many other things I could write about that I learned from my academic to business world transition. I could write pages on the things I've learned concerning just the social dynamics of this place. But that would be for a different type of blog :)

Till next time...

And so it begins...

Jonathan Paulin — Mon, 02 Jul 2007 05:59:52 GMT

Like many others, I've been challenged to become part of "The Brotherhood of Becoming Better Developers" by George Clingerman. I'll gladly accept this challenge, and see how far I can take it. Here are the 3 goals I aim to accomplish in the next 6 months...

I will put time aside every week specifically for game programming. Whether it's 1 hour or several hours, I'll continually make progress on a project. In addition, I'll set deadlines on my projects to help me finish them.

I will pick a certain programming construct or idea and blog about it every week. The concept may be new to me which will require me to do some good research or I may already be familiar with it which will still require me to do some good research. Whatever the case, I will be doing research, thus learning.

I'll start jumping head first into sites like Gamasutra.com and GameDev.net to stay more current on what's going on in the gaming world.

If I come up with any other goals, I'll make sure to post them. And so it begins...

Jonathan Paullin's Blog

The Transition...

And so it begins...