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...