Why Email makes you think you are Superman

I have  just finished reading a the latest Coding Horror Blog  Is Email = Efail?, and it reminded me of the lesson I have learnt about Email over the last year.

Email is nothing short of a brilliant communication tool. It has the potential to address the classic issue described in the seminal book Peopleware about phones interrupting not only you, but also all those around you. Email sits politely just waiting for when you are ready to deal with it.

It is also great for those who find face to face communication somewhat harder. 

However, like all good things there is always the other side that comes back and bites you. This is the part that I am talking about. It is quite insidious because it is guised in such good intention.

Its just too easy.

Like most of you I am sure, you have found your strategy for dealing with large volumes of mail,  this is mine here on Stackoverflow. However, and this is the rub, the better you get at this, the more mail you receive.

How so ?

Well, because email allows you to hold multiple conversations at effectively one time, we do! You run through your inbox in your preferred strategy and respond to, and effectively, either start a new conversation or continue one. Again, because you can.

The fallacy lies in the fact, that we are not really able to hold down that many conversations, at least not in any meaningful way. Especially in a work environment, when a conversation is really just the tip of piece of real work to follow.

Email give us the ability to start more things that we can really give our attention to.

What to do ?

The lesson that I have learnt is that you need to just use your email less. If you need to hold a conversation with someone, then just do it. Walk there in person, or pick up the phone or IM,  and get it done! Don’t do anything else, until that conversation is finished. The illusion of multitasking will be alluring, but in truth, the one task you are now addressing will be completed sooner, and you are now in a position to be far more productive in the few things you chose to focus on. 

The others will have to wait, they were going to anyway! The only thing they lose is the progress bar of email they would have gotten as you would have trickled the answers to them.

Just because Email tries to make you believe you are Superman, you are not, well at least I am not!

Hidden Gem of the Debugging Stack

Have I been hiding under a rock, or is there a gem of the Debug Stack that has been sorely unspoken about ?

The gem I am talking about is Source Server , it is part of Microsoft's Debugging Tools for Windows but to understand this you need to know something about the Symbol Server & Symbol Store.

Now since the Symbol Store has had a lot more exposure ( but from my view of the world is still not used anywhere nearly a widely as it should be esp for the value it offers, and how simple it is to set up ) I will not talk to much about the Symbol Server/Store. ( Shout if I should )

And IMHO the Source Store is the more powerful/interesting one.

But first just a quick recap of what these are, for those who do not know

The Symbol Server/Store simply allows you to uniquely stamp and store the debug symbols ( found in the pdb, dbg files ) in a common location so that your IDE can, at debug time, compare the version information of the binaries that are loaded with the debug symbols you have in this common store, so that your calls stack doesn't just have the dll name, but also has the method names too.

The source stuff, in a similar way allows your VS8+ ( vS2005+ ) IDE to figure out for your loaded binaries what revision of your source was used, and with that knowledge will actually checkout a copy of that file for you so you can step into the code.

How Does the Source Store Work

It opens up your PDBs and writes into it the URL or your source repository and the repository number for each of your files, and then further embeds in it the command line required to execute the Get from the repository. This allows the whole thing to be agnostic of which version control system you use.

Now used in conjunction with your Symbol Server, that PDB will now be uniquely tagged and sit in a common location so that anyone who point their VS IDE to that symbol store, will be able to get the source at debug time. Just step in (F11) and the magic will happen, and in you go.

How do you set this up

Some pretty simple additions to your build script, but I wont go into detail, except to give you the command lines template that you should add.

• symstore add /f *.* /s \\{shared location}\symstore /t {Sometag} /v {version} /c {Comment}
  
• call svnindex /Source={path} /symbols={path} /debug

For a step by step guide and deeper technical information read the Use The Source, Luke article by John Robbins ( aka The Bug Slayer ) .

The important thing to note is that while none of the documentation suggest there is support for SVN, it is there in the file svnindex.cmd ( a hidden gem in the hidden gem ).

The Applications of this

This is where the power of this lies for me. If it is not blatantly obvious, it now means that :

• Anyone in your company or group, can debug any binary at any version without having to have the source on their machine.
• This includes your white box testers
• You can step into any internal library you may use without having to build it on your machine.
• You can then put breakpoint in that code

On the softer side, this can grow your developers :

• Developers will be exposed to other code ( typically more mature framework code ). If they can step in they will. This will remove the "black magic" belief that some younger developers have when it comes to code they can't see.
• This becomes another form of documentation and support. There is nothing like stepping into a method ( that you normally have no source for ) and seeing what it does when it does not work, instead of bugging the person that developed it.

So what other technologies gems should I have in my Debugging Stack which I may have missed while under my little rock ?

The Productivity Stack is not about productivity

All the tools, widgets and gadgets that fit into the Productivity Stack are not really productivity tools as might be understood at face value, but rather quality and flow improvement tools.

Have you ever asked why, despite there being more and more productivity tools all the time, many of which even you adopt there is not a noticeable industry improvement in productivity. At face value this appear to simply be the manifestation of Brooks no silver bullet ( which I fully support ), except in this case there is one interesting conundrum, ask anyone who uses these tools, and they will tell you that they cannot work without them anymore! They actually work

So what is going on.

Well as I see it, it is simply that there are 2 views on the word productivity.

Your Project Manager will tell you that if you increase productivity then the project will come in earlier, ( but then again, despite knowing better, and being told repeatedly, they tend to also believe that adding more people to a project will also make it go faster – at least these days the expectation is not linear ).

If however you ask a developer, if they were allowed to use a decent IDE with all the good refactoring and source browsing tools / plugins, is that going to make the project come in any earlier, and they will reluctantly tell you no ( at least not significantly ) , but feel dirty because they know that the tools are definitely helping their productivity.

You see the PM views the world from a high level project perspective, and the developer from a line by line perspective.

What is clear by looking at the classic LOC measurement ( albeit it dodgy ) is that the average developer does not spend a lot of time writing code, in fact we write very little code. We spend most of our time thinking, understanding, explaining but mostly managing all the interruptions that stop us doing those!

So when we do get around to writing code, anything that stops the interruptions of our flow increases our productivity of development. So while we are improving productivity it is only an optimization on a small part of the project time.

However, what is not obvious is how huge that improvement is on Quality.

Good productivity tools allow the developer to concentrate on the problem at hand and not on using the tool. It tortures me to see people have a thought, which means they need to a open a file to explore the idea, and then see them slowly launch the explorer window and painfully click through each folder until they find the file, by which time their thought process has been swopped from the problem they are working on to the issue of “now where is that file again?”, then they have to context switch back into why they were looking for the file in the first place. What is worse, is they don’t even know they are paying this huge time price!

In short the productivity tools, contrary to popular belief, dont meaningfully speed up development time, and even if they did, that is not their real value. Their real value lies in the fact that in the everyday activity of coding ( I am talking at the minute by minute level ), these tools stop the break in flow that happens even when you are not being interrupted by other people, and allows you to work closer to the pace that you think at.

This continued flow in the end leads to better quality, not faster development.

For me the Key Productivity Stack for Developers would be something like this :

* Learn your keyboard shortcuts
* Learn to type ( link to Coding Horror blog by Jeff Atwood )
* Use a decent source browser ( VSK is mine for Visual Studio )
* Use a decent editor