Visual Studio comes with TODO markers where you can mark sections of code with little comments to indicate that you need to do something. However, TODO sometimes becomes too generic. You start to mark tasks, features, futures, (bugs have their own by default) with the same tag. Fortunately you can add custom ones. If you have Re-sharper installed, you get additional benefits since it allows you to create filters, identify the tags inside comments and highlight them on the right margin.

One tag to add is SMELL. A code smell is a piece of code that works yet it just isn't right, and you know that the longer it's left in there, there worse it can get. It can lead to an unsustainable situation where the whole project can start to smell like a dump site. Other times it's just a small section that is isolated and won't have immediate side-effects, but would be good to get it cleaned up.

Now, I know the purists would probably scream and say that any smell should be eradicated then and there. Snap back to reality. Both you and I know that that's not always viable. Having said that, If it's a bad smell that can lead down a spiral of stink, then yes, it should be, taking into account schedules, etc.. but even in that case, you're not going to do it all at once, so you still need to identify the smells as you go cleaning them up.

Here's some screen shots of smells with Resharper

To define them, use Resharper's To-Do item entry

You can also see on the To-Do Explorer

I've found that many of the things Jeff Atwood posts about, most of us think about. The difference is that some are so blatantly obvious that you would never even consider blogging about it. But each to his own.

However, there are some things that just blow my mind. His latest post about programmers are typists first is one of them. Let me first say that I'm a firm advocate of annihilating the mouse from a developer's toolbox. Ok, that might be a little extreme, but point being, you are more productive if you learn keyboard shortcuts and don't have to reach out so much for the mouse. However, I wouldn't say that developers are cats first, then programmers.

Initially one could understand Jeff's title as expressing that being a fast typist is important. If that were the statement, to a certain degree I would concur, and I say to a certain point because at least on my team, we don't measure productivity in terms of keys pressed per minute.

So Jeff comments:

We are typists first, and programmers second. It's very difficult for me to take another programmer seriously when I see them using the hunt and peck typing techniques. Like Steve, I've seen this far too often.

Well let's think about that for a moment. If you're not a professional typist or never taken courses, the only way to improve is through practice. As a developer, the more you write code, the more you practice your typing skills. People also tend to say that you really can't be a pen and pencil architect unless you've got your hands dirty with code, and that I do believe. So to a certain point, the previous statement makes sense, but I don't think it's black and white thing.

He continues to say:

Steve and I believe there is nothing more fundamental in programming than the ability to efficiently express yourself through typing. Note that I said "efficiently" not "perfectly". This is about reasonable competency at a core programming discipline.

What has the rate of keys per minute (KPM) got to do with efficient expressiveness of code?Efficiency can be an indication of how expressive or clear your code is, or how fast it executes where speed matters, not how fast you type it into a text file. I would say efficiency is more about coding if statements correctly or using LINQ where it makes sense. 

This next comment blows my mind:

What I'm trying to say is this: speed matters. When you're a fast, efficient typist, you spend less time between thinking that thought and expressing it in code. Which means, if you're me at least, that you might actually get some of your ideas committed to screen before you completely lose your train of thought. Again.

I really don't have much to say about this other than it's utter nonsense. In fact he tries to justify it somewhat in the next paragraph:

Yes, you should think about what you're doing, obviously. Don't just type random gibberish as fast as you can on the screen, unless you're a Perl programmer. But all other things being equal -- and they never are -- the touch typist will have an advantage.

Advantage over what? Over thinking faster? Over beating the next guy on the team on expressing his thoughts?

I'm also a self-taught typist, and I've learnt through practice, spending years writing code. My wife is a great typist also. She didn't take courses either, she's worked with computers for many years. She suck at programming, but she's great at Office. Get the point? You become a good typist by practicing and using a computer. The more you use it, the better you become. You don't need to take a course on typing before learning how to program.

Place your cursor on the class declaration

Press Alt+Ins to get the code generation menu up from Resharper. Select Overriding Members. Select from the list, the members you want to override

Hit Finish!

Question has been asked on some mailing lists recently, but I'm curious as to what music/thing (if at all) do you listen to while developing? As I'm asking the question, I'll give the first reply: nothing.

Years ago, I used to listen to a variety of things, including Phantom of the Opera, Guns'n'Roses, Pearl Jam, Pink Floyd, Pink Floyd, Pink Floyd, Roger Waters and some early Pink Floyd. For the past couple of years however, unless I'm doing mechanical coding, I don't listen to music, or anything for that matter. I find, especially when I'm thinking about design, that it distracts me. I've even tried music with no lyrics (except Kenny G.)

Maybe I'm just getting old...

Become a more productive [computer user] (insert Developer, Excel Programmer, Word User, Internet Surfer....).

Every time you want to do something that involves taking your hands off of the keyboard and going for that damn mouse, see if what you're about to do has a keyboard shortcut. Use the mouse if you have to to find the shortcut (sometimes they are displayed next to the item in the menu entry), but don't use the mouse to perform the action, use the shortcut instead. Next time you want to do the same thing, you'll remember the shortcut instead of the reaching for the mouse.

Result: you'll be much more productive without the mouse.

It's not a question of getting 3 minutes more out of the working day. It's about not breaking your flow of concentration and at the same time improving your memory, and none of us are getting younger...

I was having a conversation with a developer the other day about working on different areas of a project. The subject came up after I made a comment about how the person that breaks a build should be the one to fix it. His immediate reaction was that he shouldn't be responsible for fixing something that wasn't his "area". And that it would be much more productive if the developer working on that specific area were to fix the problems. This isn't the first time I've had this conversation. In fact I've had it many times with many developers.

There is a general tendency in believing that distributing up a team of developers and have each one focus on one area and only one area during the lifetime of the project is a good thing, that it is more productive. If Jack learns everything there is to know about WPF and handles all the user interface during the whole project, whereas Joe works on all the back-end, that is good. Each know their part inside out and can fix a bug before someone else from a different area can even reproduce it.

I mean it makes sense right? It's pretty reasonable thinking right? Well not everything is black and white.

Productivity can vary based on surrounding circumstances. Let's say a project is delivered to a customer and after three months, a bug is reported. Jack can fix it fast. Productivity is high since Jack works fast. However, Jack is on holiday. Customer is waiting for a fix. It's hurting his business. Jack will be away for another two weeks. There is only Joe left, and now needs to get up to speed on what Jack's been working on and try and fix a bug. Productivity has dropped to an all-time low.

In principle, that doesn't seem that bad. The productivity ratio can still be better than having everyone know all the system from day one. If a bug comes in and Jack is away, Joe will learn. And once he's learnt, he'll know it. If it ever happens again, he's already learnt it. Sure, it takes maybe 2 weeks instead of 2 hours to deliver a fix to the customer, but it's still ok. Problem is that it's not that simple. We're looking at a two-man product with two areas. As the system grows, the numbers grow.

The problem gets worse when we're not talking about a bug fix, but delivering a project. That's where the bus number commonly comes in: how many members of your team would have to be run over by a bus, for your project to fail? The higher the number, the safer your project is [This is a metaphor, not some cynical sick project manager that cares more about the project than his team members being run over].

I've been on both sides of the fence. I've been the stakeholder behind a project that has a very low bus number, and I've been a developer on a project with a low bus number. And I can tell you, neither of them is a good thing.

From a stakeholder's perspective, it's risky. If you have a project with three guys, and each has his/her area of speciality, you can suffer and your business can suffer if one of those guys decides to leave.

From a developer's perspective, it's bad also, and the longer the project, the worse it is. Working on one area and/or with one technology can cause stagnation, which in turn can lead to lack of motivation.

Coming back to the initial paragraph, as developers we should not be afraid to work on any part of a project. If you are working on a user interface screen and you need a certain piece of functionality that does not work or is not implemented yet, you should be able to work in it. If you don't have enough knowledge of the project/l.o.b. to be able to work on it, that is another problem waiting to surface. Solve it. The later you leave things, the worse it will be, both for you, the team and the project.

I can understand that people that are not "software orientated" find it hard to understand. They assume it's like anything else. In most industries, if one of the members of the team leave, and they are specialized in a certain area, it's not hard to find someone else to replace them. Soldering steel, fitting steering wheels, etc. have pretty much non-existent or very low new learning curves (you can pick up how to fit a steering wheel in a Ford in a very short time if you've done it for a VW or a Toyota). With software it's different. You not only need to know the technology, you need to get learn the domain of the project and get up to speed with the architecture. It's not as simple as pulling one guy out and putting another one in his/her place.

Knowing this, the best thing we can do on a project is have the ability to temporarily replace one person with another. It isn't so much about being agile, but about having common sense.

Get it here: http://www.jetbrains.com/resharper/download/?41nl

They've been working on improving performance.

If you haven't been running the nightly builds and have been waiting for a beta, here it is. Not much you can say about R# except that once you try it you can't live without it.

I frequently get e-mails from people that have been at my talks about the theme I use in Visual Studio. Instead of continuing to reply individually, I've decided to point them to this blog post from now on. As a long-time Delphi user I've been used to the dark background (Twilight is it's name in Delphi) and find it much easier on the eyes. In Visual Studio I'm using a variation of Rob Conery's theme which in itself is a variation of Jon Lam's theme.

My font is "BitStream Vera Sans Mono" size 11. You can download the theme from here

During my talks, people normally ask me about specific tools they see on my system. About a year ago I posted about a bunch of things I use. It's time I update it to the year 2008. Some have dropped off the list. There are also a few I realized I had left out that I've been using for years (some I left for an alternative solution and came back to later). So anyway here's the list:

1. Launchy. It's Vista's Start menu search done right. It's amazing. Must-have. And if you can, make a donation to the guy developing it.

2. Google Desktop. Still there. Still finding my stuff.

3. Beyond Compare. Nothing "compares" to it. Ok, bad joke, amazing tool.

4. TextPad. Was using it before. Switched to Notepad2, then to ConText, now back to TextPad. The Find in Files feature it has cannot be beaten.

5.SnagIt. Still there. One complaint. It's become a little feature-bloated.

6. Finalbuilder. Since the first beta!

7. TinyClip. Eat your own dog food I say.

8. Console. Throw cmd out the window.

9. TrueCrypt. If you own a laptop and travel or have a desktop and carry it around, or for that matter, even if you don't, you have to keep your info safe. Been using it for years, no problem.

10. KeePass. In combination with TrueCrypt, try getting to know my passwords! I don't even know half of them myself. Keepass types them in for me

11. Acronis TrueImage. Only way to make decent backups and not worry about open files. And it works. I've restored many times from it.

12. Resharper. Cannot work with Visual Studio without it. It's just so unproductive to do so.

13. TortoiseSVN. I hated explorer-based VCS's initially but now I love the fact of not having to start an app to checkin/out a file.

14. FoxIT reader. Dumped Adobe a long time ago for this lightweight alternative. Only issue, it doesn't  register the correct MIME type with browsers (or maybe it's something else, haven't investigated that much) and some stupid web sites, for example www.iberia.com try to be smart and won't issue your boarding card if they think you don't have a PDF reader installed (maybe it's just Iberia looking for Adobe specifically?)

15. TaskSwitchXP. You don't need Aero with this.