Debuggers are just another tool

OK, admittedly I have gotten caught up with a discussion that caught my eye. It caught my eye because I have been holding a post on the topic of debuggers for some time now and it has provided an excuse to go back and finish it, so here goes.

Debuggers are just another programming tool to be utilized when needed and as needed. It is my opinion that programmers starting out should avoid them like the plague and here is why:

Debuggers are like a crutch when it comes to figuring out what is going on in code. Debuggers are amazingly detailed allowing line by line inspection and manipulation of items in mid flight while the code is bing executed. This power, when you are new to programming, is enticing. However having this ability is akin to the draw of the dark side of the force, wild power with no control is a problem. (Note: This crutch can also be abused by people that have been programming for a long time - so please don't think I am singling people out here.) Debuggers as a tool are great, as a learning or teaching practice, I believe them to teach the wrong things.

Debuggers bring about a certain complacancy that I think hurts the programmers and the people they work with and for. Some programmers get to thinking that they can solve the problems they run into by simply saying "Oh you are having X problem, well we'll just attach the debugger and see whats going on..." when in fact there are a fair number of situations where that can not be done. The large for instance is companies who are large enough to have a "production" environment are not inclined, in most cases, to just let a programmer "connect" in such a powerful way to a running production application. So what do you do in this instance? Lets break out the swiss army knife and see.

1) Utilize TDD up front - use your tests to ferret out as many of the bugs as you can find. In some cases this testing my actually help you locate things like race conditions and so on (assuming the test was written to do that).

2) Effective Logging - NOW here is a topic that people so often skip over. So many times in my life I have said "I wish the person who wrote this had logged something in this location where this very important state changed because of X" that I would be rich if I got a penny every time I said it. This is also a topic that is rarely covered in any learning or teaching in school. In fact I don't believe that ANY class I have attended or heard of teaches this as a topic. IT SHOULD BE, even if it doesn't cover it in depth the topic should be discussed.

3) Cleaner code - This is hard to quantify, but one could pose the argument that cleaner, simpler code would have less bugs simply because it would be more straight forward to understand.

Is there a black and white in the use of debuggers - probably not. Like I said above it is just one more tool in the arsenal. Since we already know there is no one tool for all jobs it should be safe to say that debuggers should be used when appropriate. Finding those appropriate times is hard however given the ultimate power debuggers can provide.

In the end just because you write tests doesn't make you ignorant of a debugger(s) nor does using a debugger mean that your language of choice at the time can not run tests gracefully although it may be true in some cases. Debuggers are also certainly no silver bullet, but then again neither is TDD, but doesn't mean that I should abandon one for the other. Each person is going to use the tools that they think best fit the bill. In some cases they may also choose to sharpen their saw with a blunt instrument. Now while using a debugger is not my first choice I can recognize that it is a tool I can use to help solve the problems I have, point out where I need to add logging to legacy applications, or even write tests for things I know nothing about when I start my day. Debuggers are bad for learning, and can be bad when used improperly - but I would certainly shy away from a black and white statement that says ALL debuggers are bad in ALL situations.

As a side note on reading Giles Bowkett's blog post on this topic I noted in his comments about the vile nature of the posts on his blog. We are a community folks, the community is what makes us strong and in my opinion strong opinions make for wonderful debate and make us all better at what we do. HOWEVER: when we loose our respect for others be them users or fellow programmers we are doing our selves and our community a large disservice.

Programming and Community

So my last few blog posts got me thinking about how I personally approach programming and the job I do from day to day. In fact a sermon delivered by my Unitarian Universalist minister this morning solidified for me how I think about my approach to programming. The sermon was on Big P and little p politics. What struck me about the sermon was how well a conversation about our little UU community fit with the programming communities that we all work in (assuming that we do not work for ourselves or alone).

The sermon described Big P politics as things like espousing to vote for certain people, or telling people that they should think a certain way. While little p politics, our minister goes on to describe, are the things and actions that we take in our community. The important part of this second "little p" politics to me was how she described what was vitally important to the topic, the ideas of D and P.

In this case, she joked, she was not talking about Democrat and Republican and by using it I am not talking about Theory D and Theory P but rather she was speaking of DIALOG and RESPECT.

These two ideas should be one of the corner stones of what we do as programmers. We should all be capable of entering into a dialog with our fellow programmers in a mutually respectful way. How does this translate into the world? Any and all of us should be willing to have our minds open and be able to enter into any conversation about programming being willing to change our minds about a particular topic that previously we may have taken for granted. i.e. we should treat our community of programmers with respect and always be prepared to have our pre-conceived notions challenged and overturned by someone else.

This idea of dialog and respect can be powerful - and transformative (along the lines of Reg Braithwaite's post on blog postings he would love to read), but we must be careful about the definitions. By dialog we are not talking about flame wars (these are dialogs yes but not constructive ones in my opinion) - but rather an open and free conversation between people of mutual OR dissonant intent. This second idea (of speaking to non-like minded folk) is very important to the this topic of dialog and respect in the following way:

If we choose to spend our time only talking to people that we know hold the same ideals as us we are not challenging and we are not learning.

If we only speak to like minded people we are foolishly sticking to our guns and have become logically 'stuck'. We may also have stopped acknowledging that others may have something important and vital to contribute and as such are not respecting them and their learning. Only when we are open to having conversations with both like minded and dissonant thinking people, having our minds changed/challenged, are we approaching any dialog with respect. This is what can make us better, raise us all up a level, make our community stronger - help us All to get along.

The idea that little p politics can play this roll in our every day lives can easily be missed, but I encourage all readers of this blog not to ignore it. Take time to realize what effect you may have on people you work with from day to day. Pay attention to the effect you may have on the organization and community at large. Use the little p politics to strengthen yourself and our programming community - the large and the small - the world as well as the Big Co. programming group you work with.

Learning (revisited) and Transformation

So my friend Reg Braithwaite over on his blog posed that he would like to see people make some posts about:

"1) What I learned from Language X that makes me a better programmer when I use Language Y

2) Something surprising that you probably wouldn’t guess about Language X from reading blog posts

3) My personal transformation about Idea X"

in his post: Three blog posts I'd love to read (and one that I wouldn't). So here I am attempting to take up the challenge, an blog about 1, and 3, starting with 3.

So the transformation that I went through was pertaining to all other languages (i.e. the ones the I am not currently working in) and it was simply that they ALL have something small to contribute when it comes to how I program from day to day. I previously felt about programming like I felt about doctors, it is better to focus in and be specialized then it is to have broad knowledge about a bunch of information about many different languages. When I finally started to gain knowledge in those other languages I finally realized how wrong a path this was. This THEN relates to item number 1.

So this transformation in my thinking (which is a bit of a gunshot in the head if you were thinking in this very one line type of way) brought about all the other things pertaining to what I learned in those languages that I could apply over all. The first new language that I picked up was Perl, and then I picked up Python and Jython. Each one of those languages had a large impact on how I thought about my java programming. Each of those languages does things differently and sometimes better. What I walked away from each one with was simple at first. Things like formatting and the need to document the code with comments (simple but needed). Then other simple things like structure of the code and flow control. Then GRAND things started to turn over in my head like if perl does it one way and it rocks in perl, how can I make my java code JUST as elegantly do the same thing. The transformation was a big shift for me. It then fed back into item 3 in the form of "If these two languages can modify how I think about what I am doing now in such large and interesting ways - what else is out there that can help me?"

So the learning now goes on with a much much more open mind, and a puzzle piece mentality that I think benefits both me and the people that I work for in immeasurable ways. Taking notes and ideas from many places to form a more holistic view of programming.

Why so passionate? Can't we all just get along?

OK, this might seem a little silly but I have now seen at least three separate posts on the very same topic. It all started with this post over on raganwald: Java is the right answer to the wrong question, Ruby is the wrong answer to the right question which opened up with a quote.

"Large code bases are the problem, not the language they’re written in. Find a way to break/decompose big code bases into little ones."

Bill de hÓra, calming a heated debate

Which addresses a topic that comes up a great deal. This quote is used as a jump point to discuss the ongoing silliness that we all seem to occasionally get mired in, which is a discussion of why one language is bad and another good... or in some cases why a particular feature of a language is bad and another feature in a different language is good.

What if There is no One Answer to the question of which language to use, or if static typing is better then good unit testing? Is it really so hard to grasp that one should use the right tool(s) for the job at hand? As a for instance, if you were building a deck on your house you might pick supplies for that project that you like but you would balance that choice with the needed strength to make sure the deck does not collapse after it is built. Why does the discussion of things like Java vs. Ruby and Static Typing vs. Unit testing always have to break down into a feces throwing match?

Lastly Bejamin Stein asks How confident are you, the programmer, that the change you just made will work? In my opinion this is a sub question that SHOULD get asked after the correct tooling has been chosen. As a programmer I have a desire to know that my change isn't going to effect the world, lots of tools can help me with this (not the least of which is a simple grep). I would also hope that my chosen tool for a project can help me with knowing what a change may effect but that may not always be true because of the type of project or type of tool chosen. This question may also only apply to larger (i.e. Medium to Large) projects with multiple people because knowing your change doesn't effect everyone may reduce work someone else has to do making the teams you work on faster as a whole. If I know it is just me writing the code for me and no one else I may not care if I effect the world because in the end I have to fix it anyway.

All I want to do is get along - Choose the right tool for the job at hand, and have some good support as to why that tool was chosen. Be it statically typed, dynamically typed, easy to write a unit test for - or not so easy. Different projects, different tasks, DIFFERENT tools, perhaps even a DSL tossed in for good measure.