How do I work?

This one came in via email by way of Christopher, and I thought it might be a nice topic to discuss today:

So I was thinking about how other developers think.. I seem to remember a post on the forums a while back along the same lines.. I find others thought processes interesting.. So I thought it might make a good blog post for you when you can't think of anything to write about..

Things like how you start to tackle a problem/project.. Do you jump right in or mull it over? Do you find yourself looking up API a lot or have most of it memorized? Where do you find your inspiration & motivation?

Let me start off by saying: everyone does things differently, and I'm not exception on this. What works for me may or may not work for you. Take it with a grain of salt. :-)

For me, it really depends on the problem I have to tackle. Most of the time, I'm tackling things within my area of expertise, though not always a problem I've seen before. For instance, I frequently have to solve Win32 issues. I've been programming with Win32 APIs for a long, long time and so I'm very comfortable with the problem domain, even if it's an area of Win32 I've not touched before. So the way I go about solving the problem is by starting off with a healthy round of research. I usually have a pretty good guess at what the APIs involved will be named, so I start off on Google looking for answers. The first source I usually turn to is MSDN or KB articles from Microsoft. Then I expand out into other areas. Once I've got a good background on what the APIs are called, then I pop open my copy of MSDN and read through the actual APIs themselves. From there, it's a matter of banging out a test project or two that puts the APIs together in way that works. Once I finally have some functional code, it comes down to cleaning it up and using "best practices" for it (like error checking, good OOP design, etc). This is for new problems that I've never seen before.

A good example of this thought process is: I wanted to know how to use OS services to access the Windows Task Scheduler so that I could programmatically schedule a task. The first thing I did was hop on Google and look up "Win32 API Task Scheduler." The second link on google was to a Code Project example that pointed me to the ITaskScheduler API. Bingo! That's the API I need to look up more information on. The time it took to locate the API was under a minute (I didn't even bother reading the Code Project example as those are bad examples as often as they're good). So then I popped open MSDN and looked up ITaskScheduler, and noticed that I need to call NewWorkItem or AddWorkItem to schedule a new task. I also saw that under NewWorkItem, there was some example code from Microsoft on how to schedule a task. After browsing MSDN for a half hour, I was ready to write a quick-and-dirty example project to get things rolling. It took me about another half hour to get a working task scheduled on Vista, and then it was down to cleaning things up. All told, it was about 1.5 hours worth of work, and while I'm no expert on task scheduling, I can at least hold my own with it if I ever needed to do it again.

That's my general process when I am entering uncharted waters. However, I'm no apprentice cartographer when it comes to programming for Windows. ;-) Quite often I am given tasks that don't require this level of research. In that case, my process is a bit different. I usually don't have to spend any time on Google trying to find the APIs I need. I've been blessed with a knack for remembering APIs, and so I can usually recall what is needed off the top of my head. If it's something I've used very frequently, I don't even bother with a trip to MSDN as I already know the ins and outs of the APIs. But I still use MSDN to ensure that I know the finer points of the APIs much of the time. It's easy to remember that I need to handle the WM_POWERBROADCAST message, but it's harder to remember what wParam and lParam mean. ;-)

That being said, the rest of the process pretty much remains the same. I still pound out a quick example that demonstrates the functionality I am going for, and then I go back and clean it up. However, it really depends on *why* I am writing the code as to how much work I put into it. When I put code out on the forums, or for blog postings, or even the WFS -- that's often "pounded out" code. It rarely has good error checking, or parameter validation, etc. But if I am writing production code, then I ensure that it meets my standards.

So in either case (new concepts, or "old hat"), the coding part is what I want to discuss next.

The initial code stage usually starts off with comments explaining what I'm going to accomplish. Sometimes I write a line of code, and then put the comment above. Other times I write the comment, and then put a line of code below it. Either works fine for me, though I try to explain the "why" and the "how" in the comment instead of just the "what." But once the code is working, I do a little bit of tinkering with it to see how to fit things together better. Since most of what I do externally is toolkit design, I usually try to fit things together with that in mind. How do I make this code reusable? How do I make this code dummy-proof? Etc. I usually go through zero to several iterations of this process unless I'm satisfied that the problem has been solved, depending on the needs at hand.

The final code stage is usually a transition from the inital code stage. After I've tinkered enough, things are in a state where I'm happy with the "external" API (even if it's for internal use only, I still think of every piece of code I write as something external for others to use). Once I'm at this state, it's time to go back over the code and add in all the extras which make code robust. This is the time where I add extensive error checking, parameter validation, and whatnot. It's basically just cleanup at this point since I've already got the code working the way I want to. Then I run it through one last round of testing to make sure I've not broken anything, and voila! It's "done."