A few things i have learned in my first 90 days working as a full time programmer

As some of you may know, I started work on a development team about 90 days ago. This is the first time i have worked full time (on the clock, inside a building owned by the company, for 40 hours a week) in a long while. Things have changed somewhat since the last time I have done this: answers are now a google search away, and there is an incredible amount of useful and valuable free and open source development material out there. Yes, those are all different, but this time, I am working on a team. I am inside the same room with everyone, and have probably learned more about the art of development than I ever have. I thought i would take a few minutes just to solidify some of these ideas:

1. Write tests first – This is not just a good idea, it’s the law. For the past few years, I have been very interested in test driven development, but have not put the time aside to learn it. Starting to work on my current project was trial by fire. I need to quickly learn to use the tools, and learn to think about tests correctly. Without getting too extensive, I can now say that I am finally a TDD convert. While my first few weeks (months?) at it seemed very much unnatural, it is finally starting to sink in. I will probably write more about this later, but suffice it to say that; in software development, as in life, satisfaction is much easier achieved when your expectations are clear.
2. Coding standards are a good idea – I have worked on several teams where, after just a few weeks, you could tell who wrote a block of code just by looking at their style. I always thought this was just how the world worked. I thought this was just another way that we humans expressed our individuality. This actually makes code harder to read and messier for everyone involved. Memory and hard drive space are cheap. You don’t need to name a variable: tds, when total_dollars_spent is much easier to understand. Most modern IDE’s will do all the typing for you, which leads to another point:
3. IDE’s are not evil – I have used emacs for a million years. I have never really used any IDE extensively in the past decade. In talking to old school developers, most will cringe and whine if they were told that they were required to use an IDE. I decided to approach the adventure of learning a new IDE as, well, an adventure. I could write a whole article on this, too, but suffice it to say that using an IDE (RubyMine in this case) made my productivity surge. Sure, you have to learn a few other keyboard shortcuts, but it took less than a few hours. Sure, there are things that textmate, emacs, et al do better, but no system is perfect. IDE’s have come a long way in the past decade. I won’t bust your chops for using one.
4. Just because it works, doesn’t mean it’s submittable – If your code works, but it’s ugly and fragile, it’s sub par. You know that blob of code you wrote. it works. Even though it works, you pray that the day never comes where you have to edit it. When that day comes, it will drop like a house of cards. When you have this in your codebase, it is not acceptable. Fix it before you submit it.
5. Refactoring is not a luxury, it’s your duty – There is always a balance. A project has to be done. It has to work, and it has to be delivered on time. That is still no excuse to submit code that has repeated itself or that is downright ugly. Again, you know what this code looks like. It’s that messy, twisted pile of shart that you are hoping nobody will stumble onto. Chances are, they won’t. If they do, they are gonna be pissed (if they have learned any of the above lessons anyway). So, refactor your code. It will make you a better developer.
6. Developing really has nothing to do with language semantics – Anyone (within reason) can write code that works. Working is not that big of a deal. There is much more to learn than bending a language to your needs. Learning to model what is going on in the real world effectively and concisely is a much more important skill than anything else. Learning how to understand when someone explains the above, then explain your ideas to someone else is even more important. Noodling out complex ideas, then learning to model them and explain those models is the crux of the entire problem.

Okay, I have prattled long enough. I think in the next few weeks, I might expound more on each one of these points with some real world examples. Not snippets of code, but sight sights, smells, and flavors. A whole different world than I am used to. Rather than banging out code that works, learning to bang out code that is sexy.

My goal for the next few years? Learn to write code like a world class chef, rather than the grill jockey at the local burger joint.