Since forever, geeks who take themselves seriously have loved to brag such things as, "I use Notepad to edit web pages". Carrying this over to actual programming, "I never click into the designer when editing my ASPX", or "I never design a database using designer tools, I always design it all using raw T-SQL," or "I always update my SVN from the command line". (Someone in a local tech user group bears the post signature, "Real men use Notepad.")

Puhleeze. I'm not impressed, and frankly I think anyone who brags like this should get a swift kick in the pants.

IMO, there are three levels of elevation to guruism:

1. Awareness: Discovering the tech and the tools (like the WYSIWYG web editor .. "I'm a WEB MASTER, and you can, too!").
2. Intelligence: Swearing by Notepad and proudly refusing to use the WYSIWYG editor.
3. Wisdom: Knowing when to use the right tool at the right time in order to either save time or to produce the best output. Yes, that means being fully capable of staying away from the WYSIWYG editor or the designers, but it also means being completely, 100% unafraid of such tools if they serve the purpose of helping you write better code, more productively.

I get really turned off when co-workers smirk and look down their noses at me when I mention that I'm a tools collector, as if their refusal to use anything but the textual view of SQL Query Analyzer, the C# plain-text editor, and the command prompt somehow made them superior. The fact of the matter is, these are the people who produce output that share predictable characteristics:

• Web pages are thrown together without thought to design.
• Web page markup is excessive due to hit-and-miss browser testing rather than design-mode utilization.
• Code is disorganized and messy.
• Class libraries and databases are designed ad hoc and without thought towards the bigger, conceptual picture.
• Databases lack indexes and referential integrity.
• Buggy implementations take ages to be debugged due to refusal to fire up a debugger.

Yes, let's look at that last item. I don't know about you, but I am, and have always been, an F5'er. (F5 invokes the Debug mode in Visual Studio.)

Learn how to debug. With a debugger.

At a previous job, I discovered for the first time in my career what it was like to be surrounded by hard core engineering staff who refused to hit F5. Now, granted, the primary solution that was fired up in Visual Studio took literally over a minute to compile--that means F5 would require a one-minute wait for the simplest of changes if it wasn't already running in Debug mode. But even so, it's such a straightforward and clean way to get to the root of a problem that I don't see how, or why, anyone would want to do without a solid debugger to begin with?

Re-invoking code and then reading the resulting error messages is not an acceptable debugging methodology.

Instead, set breakpoints and use the introspection tools. Here's how I debug:

1. Set a breakpoint at the top of the stack (where the code begins to execute). If using browser-side Javascript, add the line "debugger;" to the code.
2. Hit F5.
3. If the user (that's me at this point) needs to do something to get it to reach the breakpoint, do it.
4. Once the breakpoint is reached use F10 (Step Over) or F11 (Step Into) to follow the execution path.
   • Always watch the value of each and every variable before proceeding to the next line of code. I can monitor variables by monitoring the Locals window, or if some method needs to execute to fetch a value or if he variable is in broad scope then I put it in the Watch window.
   • Always watch the values of each and every source property before it gets assigned to something, by hovering over it with the mouse and letting the tooltip appear that exposes its value. For example, in "x = myObject.Property;", only myObject will appear in the Locals window, and I won't see the value being assigned until it is already assigned, unless I hover over ".Property" or add it to my Watch window.
5. If a nuisance try...catch routinely occurs such that it becomes difficult or tiresome to find where in the stack trace the exception was thrown, I might try commenting out the "try" and the "catch", or find the option in the Exceptions dialog (to find that dialog you'll have to right-click a toolbar and choose Customize and find the menu item to drag it up to the menubar and add it, as it's not there by default) that stops the debugger on all exceptions.

90% of the time, I can catch a bug by careful introspection in this manner within a couple minutes.

What the "raw skillz" folks would rather do is go backwards. Oh, it's puking on the data? Let's go to the database! Fire up SQL Query Analyzer! SELECT this! F5! SELECT that! F5! (F5 in SQL Query Analyzer, or Query view for SQL Management Studio, doesn't debug. It executes, raw. SQL doesn't have much debugging support.) Hmm, why's that data bad? Let's clean it up! UPDATE MyTable SET SomeField = CorrectValue WHERE SomeField = WrongValue ... Now, why'd this happen? Why's it still not working? I dunno!!

Oh just kill me now. That's not fixing bugs, that's fixing symptoms. If roaches ate all the pizza, this would be like replacing the pizza where it sat. Feast!!

Worse yet is when the whole system is down and the fellas are sitting there doing a code review in the effort to debug. Good lord. Shouldn't that code review come before the system went live? And, once again, F5 can and should save the day in no time at all.

Use SQL Profiler and the management code libraries.

In the SQL Server world, the closest equivalent to Visual Studio's F5 is the SQL Profiler. If you're seeing the database get corrupted and you're trying to troubleshoot and figure out why, use the Profiler. There's also the management libraries, which might provide some insight in the goings on in database transactions, from a programmatic perspective.

Ironically, shortly after I joined the team at my previous job, I introduced SMO to the database guru. Nearly two years later, after I had put in my resignation, the same fellow introduced me to SMO, apparently forgetting that I introduced it to him to begin with. But in neither case did either of us actually do much, if anything, with SMO.

SQL transactions are a tool. Use them.

There's nothing like watching a database get corrupted because of some bug, but it's despicable when it stays that way because the failure didn't get rolled back. Always build up a transaction and then commit only after doing a verification.

Don't hand-code database interop with user views. 

Let's look at ORM tools. Put simply,

• If it saves coding and management time, it's an essential utility.
• If it performs like mollasses, its crap.
• If it is always dispensible, it's accepable.
• If it gets "rusty", needs routine maintenance, or was built on a home-grown effort, it's junk.

Code generators are iffy. They're great and wonderful, if only there are enough licenses to go around and they're always working. I was recently in a team that use CodeSmith, but the home-grown templates broke with the upgrade to a recent version of CodeSmith, so everything died out. Furthermore, all of the utilization of CodeSmith revolved around a home-grown set of templates that targeted a single project, and no other templates were used. And last but not least, there were only two or three licenses, and about four or five of us. So between these three failure points, it was shocking to me when my boss got upset with me for daring to want to deviate away from CodeSmith and consider an alternate tool for ORM such as MyGeneration or SubSonic when I began working on a whole new project.

Later, I met the same frustration when LINQ arrived. Hello? It's only as non-performant as one's incapacity to learn how it ticks. And it's only as unavailable as our willingness to install .NET 3.5, and, by the way, .NET 3.5 is NOT a new runtime, like 3.0 it is just some add-on DLLs to v2.0.

Writing code should be tools-driven too.

Do basic designs before writing code. Make use of IntelliSense (for SQL, take a look at SQL Prompt). Use third party tools like Resharper, CodeRush, and Refactor! Pro. Mind you, I'm a hypocrite in this area; I tried Resharper and ran into performance and stability issues so I uninstalled it. I have yet to give the latest version a try, and same is true of the other two. But some of the most successful innovators in the industry hardly know how to function without Resharper. It doesn't speak well for them, but it does speak well for Resharper. There are lots of other similar tools out there as well.

UPDATE (8/26/2008): I've finally made the personal investment in Resharper. We'll see how well it pays off.

Don't be afraid of the ASPX designer mode.

I like to use it to validate my markup. Sometimes I accidentally miss a closing '>' or something, and the designer mode would reveal that to me much faster than if I attempted to execute the project locally. Sometimes it also helps to just be able to drag an ASP.NET control on the page and edit its attributes using the Properties window; this is purely a matter of productivity, not of competence, and fortunately the code editor supports InteliSense sufficiently enough that I could accomplish the same job without the Designer mode, it would just be a little be more work and, being manual, a bit more prone to human error.

Automate your deployments.

Speaking of human error, I have never been more impressed by the sheer recklessness of team workflow than the routine manual deployment of a codebase across a server farm. At a previous job, code pushes to production would go out sometimes once a week and sometimes every day, and each time it took about half an hour of extreme concentration by the person deploying. This person would be extremely irritable and couldn't handle converations or questions or chatter until deployment completed. Regularly, I asked, "Why hasn't this been automated yet? You can bump those thirty minutes of focus down to about one minute of auto-piloting." The response was always the same: "It's not that hard."

To this day I have no idea what on earth they were thinking, except that perhaps they were somehow proud of going raw--raw as in naked and vulnerable, such being the nature of manual labor. Going raw is stupid and dangerous. One wrong move can hurt or even destroy things (like time, sanity, and/or reputation). There's nothing to be proud of there. Thrill seekers in production environments don't belong in the workplace. Neither does insistence upon wasting time.

Design like you care.

Designers aren't just good for web layouts. I've particularly noticed how supposed SQL gurus who don't design database tables using the designer and prefer to just write the CREATE TABLE code by hand tend to leave out really important and essential design characteristics, like relational integrity (setting up foreign key constraints), or creating alternate indexes. Just because you can create a table in raw T-SQL doesn't mean you should.

The designers are essential in helping you think about the bigger picture and how everything ties together -- how things are designed. Quick and dirty CREATE TABLE code only serves one purpose, and that is to put data placeholders into place so that you can map your biz objects to the database. It doesn't do anything for RDBMS database design.

I used to use the Database Diagrams a lot, although I don't anymore simply because I hate the dialogue box that asks me if I want to add the diagram table to the schema. Even so, I'm not against using it, as it exposes an important visual representation of the referential integrity of the existing objects.

Failing that, though, lately I've been getting by with opening each table's Design view and choosing "Relationships" or "Indexes/Keys". I then use LINQ-to-SQL's database diagram designer, where inferred relationships are clearly laid out for me, assuming I'm using LINQ as an ORM in a C# project. If I see a missing relationship, I'll go back to the database definition, fix it, and then drop and re-add the objects in the LINQ-to-SQL designer diagram after refreshing the Server Explorer tree in Visual Studio.

vi is better than Notepad.

If you must edit a text file in a plain text editor, vim is better than Notepad. No clicky of the mouse or futzing with arrow keys. The learning curve is awkward, but NOTHING like Emacs so count your blessings.

I'm kidding, but the point is that there's nothing "manly" about Notepad. Of course, for the GUI-driven Windows world, better than vi or vim or anything like that, these two free Notepad replacements are pretty nice, I use both of them.

• Notepad2
• Notepad++

In any case, there's nothing wrong with using Notepad or some plain toolset to do a job, but only if you're using the simpler toolset out of lack of available tools. You might not want to wait for two minutes for Visual Studio to load on crummy hardware. You don't want to wait for something to compile. Whatever the limitation, it's okay.

But please, don't look down on those of us who opt for wisdom in choosing time-saver tools when appropriate, you're really not helping anybody except for your own rediculously meaningless and vain ego.