It was tough choosing a first essay topic, but I figure attitude is the one thing from which all other attributes and habits flow, so that's where I am going to begin. The most solid development practices, best development tools and intimate knowledge of every library call in five different programming languages and frameworks related in some way to the problem at hand don’t amount to anything without the right attitude.
What kind of attitude? The kind that simply says "I’m going to get this job done". No whining about how bad the code is and how impossible it will be to fix. No complaining about how Larry and Paula get to work on all the cool Web Service stuff while I’m stuck with an overarchitected monolithic library of DLL’s written in C++ that is really just poorly veiled C.
If you read the introduction to this site and said, "That’s me. I get harassed all the time to work on these evil projects", you likely have this sort of attitude on some level. You are a goto guy. Being the goto guy can be hard. It ain’t pretty. Sometimes you may not like it. It may make every part the decent developer in you recoil in horror. Alas, the job must get done. Generally speaking, you should do your best to minimize or avoid the recoil in horror moments because they will make you, well, bitter. At times, however, it becomes necessary to suck it up and just get the job done. If you are reading this and thinking, "The guy three cubes over from me gets harassed with a lot of these issues. I’m glad nobody is bothering me with them.", chances are he gets things done and people would rather work with him than you. Chances are also good that during the next round of layoffs he will still be in his cube collecting a paycheck and you will be updating your resume.
I’ll be the first to admit that I complain a bit, probably more than I should. I’m sure my manager would agree. At some point, however, you need to stare down the problem and get going on a solution. The problem is that many people only get so far as seeing all of the things that are wrong with a given implementation, which really doesn’t do anybody any good because at the end of the day all you’ve got in addition to a broken implementation is somebody who needs a box of tissues. Some kind of action is needed to get the problem solved.
So you have a problem and you have to do something to solve it. The next step is to do something. Anything. As you are sitting in front of your monitor contemplating all of the wonderful and intricate ways you can attack this problem, there is a very powerful force at work known as Newton’s First Law of Motion. "An object at rest tends to stay at rest and an object in motion tends to stay in motion with the same speed and in the same direction unless acted upon by an unbalanced force." I tend to simplify this and state it as inertia’s a bitch.
It would be remiss to interpret this as promoting sloppy practices. Regurgitating whatever garbage you have been handed and adding a couple of small fixes or spitting out a prototype that "mostly" works and saying "I’m done" is not the answer. One would hope that as a developer you take pride in your work. While premature optimization may be the root of all evil, copious cluelessness runs a very close second. And cluelessness is A LOT more rampant than premature optimization. Fight the cluelessness and find out what you need to know in order to get the job done correctly. You need to ask "If I don’t do it correctly now, when will I have time to fix it?"
Be the kind of developer that takes ownership of projects. If the code you inherit a piece of garbage, take it personally. Be insulted that your manager would demean you by making you work on such a shoddy piece of software. Then fix it.
Continual improvement is a necessary component of the Janitor Programmer Attitude. This applies to yourself as well as your current projects and codebases. The Pragmatic Programmers recommend learning one language per year. I would expand on this (or relax it depending on your view) and say either language or methodology. One of the reasons to learn new languages is to learn new ways of looking at and solving problems. How you perform a particular task can vary greatly depending on your language and the variety of techniques you have in your toolkit. How you do something in a functional language is different from a procedural language is different from an OO language. There are a variety of techniques that game programmers would be familiar with that are different from the techniques used by somebody who spends a lot of time writing parsers for context free grammars. That skill set is different from the skills folks who are familiar with embedded systems have which will vary from the methodologies used by people who write kernels and device drivers. While most people will tell you that you can’t possibly learn everything there is to know about a language in 365 days, the goal of learning a new language or programming methodology every year will be a great boon to your ability to solve problems efficiently.
In addition to working on new languages and new programming methodologies take the time to read. There are a variety of websites such as the Pragmatic Programmer, mentioned above, Joel on Software, artima, Paul Graham’s website and many others that contain a variety of viewpoints on developing and maintaining software. There are many books such as Code Complete 2nd edition, Peopleware, The Mythical Man Month and so on that are practically required reading for anybody who considers themselves a good software developer. There is no requirement to suck up these books and assimilate every item in them. You will likely find points that you don’t agree with or think are just plain wrong. The purpose is to look at what others are doing and use it to think critically about your own processes and practices. Chances are if you have a question, problem or idea, somebody somewhere has had this same thing occur to them. Learning from other’s mistakes is a lot less costly than learning from your own. Read all you can. Assimilate what makes sense. Throw out what doesn’t.
Continually improve the code and projects you are responsible for. On the code level, the Extreme Programming folks refer to this as Refactor Mercilessly. Periodically review your code base and clean it up. The next time you are working on a project and are in a bad area of the code, take some time to work it over. Code evolves and takes constant vigilance to keep it from degenerating into a great big pile of spaghetti. It is hard to get management to buy into projects solely for the technical health of a piece of software, as these projects usually do not have a direct impact on the bottom line. However, all developers instinctively feel that clean, robust code is a necessary part of software development. The fact that it works is not good enough. Developers should strive for elegance and stability in their work. You can make this happen by refactoring old code as you are working on new features.
One of the best ways to get things done is to help others do the same. Take some effort to document your work. I am not just referring to commenting code, but also to documenting processes at a higher level. If your product uses a custom query language, create a document that describes the language. If you are working on a tricky piece of code, document the assumptions and steps you went through to get it working. Write the documentation as you are working. Most developers I know think documentation like this is a good idea, but they make the mistake of thinking they will get to it when everything is done. There are two problems with this. One is if you wait until you are done and go back, you will likely have forgotten one or two important steps along the way. The other is that something always comes up when you finish a project. Documenting what you just finished is a much lower priority than the new work in your queue.
One very useful tool for doing documentation in this manner is a simple wiki. A search on wiki on your favorite search engine will turn up many alternatives to use with your favorite operating system. Wiki’s allow you to easily update entries, kind of like an always available notepad. In addition, you can share it with others and they can add to it. I did this recently with adding a new object to a COM dll that is used in one of our company’s products. There are a variety of classes that any object in this particular DLL needs to inherit from, but the only way to figure that out was to look at other similar projects. As I was going through this I thought it might make sense to use code generation to create a base object. Given the intricacies of IDL for hooking up the interfaces to their implementations in C++ I abandoned that idea. I decided to take the tedious yet safe way of using the wizards to add methods and properties. This along with some other decisions and discoveries I made along the way are all documented for the next person (likely to be me...) who comes along and has to add another object. This document will make it easier the next time around. It also gave me the opportunity to explain what was going on. I firmly believe that you don’t really know what you are doing until you can explain it to somebody and documentation is one means for doing that.
Having the desire to pull things apart to look at their innards is a valuable trait for a developer. Most respectable software developers I know spent a good part of their youth taking apart games and toys and then reassembling them. They played with legos and erector sets and bristle blocks. They took programming classes in high school and did all the extra credit assignments and then some. They hacked on a computer at any opportunity. I know I’m not the only one who saw a Commodore 64 in my local department store and did things like
10 ? "I’m so cool!"
A couple of years ago, when .NET was shiny and new we had a training class that focused on web services in .NET. One of the points they drove home was that you could just stick the WebMethod attribute on a function and it automagically got exposed as a web service call. While working with a certain level of abstraction is nice, my first thought was "Ugh. That stinks". A guy a couple of seats down let an audible "That’s cool" slip out. While getting your feet wet without worrying about plumbing can be nice, if you work with any technology long enough at some point you will need to figure out what goes on behind the scenes. Abstractions occasionally leak, no matter how hard libraries try to cover them up.
The reason this is important is similar to the reason for learning a variety of languages and programming methodologies. If you see an abstraction you would like to carry over to another project, how do you do that without some knowledge of how it works? I am not suggesting you memorize every specification for every piece of technology you have ever worked with, but I am suggesting that for any technology you will be using seriously that you get more than a passing familiarity with it. One of the most useful ways to do this is during one of your new project/refactoring stints, go through the code that your code wizards generate. It's ok. It's just text, really. At least get to the point where you can make heads or tails of the code. The point here is not to figure out that the code generator didn’t quite get chapter 7, article II, section 3a correct from the spec, but to get to where you can figure out what the generated code is doing and why. In this day just about everybody works with pre-packaged libraries and generated code. This is useful for getting work done, but it is important to know what has been abstracted away in case any problems come up down the road.
Taking action, fixing as you go, helping the next guy and tinkering are four traits necessary to doing a good job on any maintenance project. Given that most work is maintenance of one sort or another, as a developer it behooves you to nurture these traits. Make them a part of you if they aren’t already. Funneling these four qualities through sound practices will allow you take whatever is thrown your way and turn it into something that you can take pride in and will delight your customers.