RTFM and the Software Dummy

Developing software is a rewarding career, but at times it can be tedious and very frustrating. The ability to debug your own code and that written by others is crucial.

As those of us working in IT know, from the outside we are all bunched together, but within the industry the skillsets today are extremely diverse. The pace of change is incredible and organisational change is a given, not something that occurs every now and then.

One thing that remains the same is coding syntax. It seems every year another language is deployed. It all conforms to logic, but blimey it can do your head in.

In the deep past of my career I had experienced significant protectionism of skills outside of work teams but today sharing and mentoring seem to be mainstream.

The IT Crowd, Episode 1, Series 1, featured Moss wearing a custom tshirt with the acronym RTFM. I first heard this one uttered in 1991 by Graham K in response to me asking one to many questions. It expands to Read The F#*k!ng Manual if you weren’t sure.

The second half of my post title, the Software Dummy, came to my attention whilst working on the Y2K bug (yes it really happened and was not a conspiracy). I was part of a team of 4 Tandem SQL / COBOL analysts developing a large star schema decision support system and we were coding for weeks on end. Frequently one of us would sidle over to an associates desk and start describing an intractable problem. So in this scenario you have the coder with the issue they are struggling with and the listener, the “software dummy” (or peer, mentor, sounding board etc).

Now many of you will know that resolving your own software bugs is a tricky business. Helping someone else resolve their software bugs is altogether another thing.

Firstly, you are most probably very busy with your own work. Secondly, even though it’s likely you have similar skills you probably aren’t familiar with the specific business logic or requirement. Thirdly, there is the matter of sustainability; do you catch them the fish or show them how to make their own rod (see RTFM).

What we observed during that Y2K project was the software dummy effect. It’s just human nature to ask someone else for help rather than picking up the manual and working it out yourself. And frankly the manual is often no use when you have a team of similarly experienced programmers and it’s a bug and not a matter of technique.

So what tended to happen is the software dummy would acknowledge the petitioner (the frustrated coder with the software bug) but continue to focus on the monitor in front of them. The coder would continue describing the bug in detail, relaying the events and conditions that have led to the current impasse. The software dummy might occasionally ask a question but usually it was enough to make appropriate noises giving the impression that we were actually listening to the problem description. Invariably we were not. We were trying to hold onto the thread of what we were immersed in.

However, in most cases the coder would have a eureka moment and exclaim “that’s it, I haven’t initialised the host variables for the …” or some other mind numbingly boring detail and return to their desk, grateful for the assistance.

We discussed this as a team and quickly realised we were all guilty of not really listening. However the results spoke for themselves. Clearly the coder with the bug was working out the problem through the process of describing it to someone else. The software dummy was born.

Many years later on and I have to admit I have tried this at home on my wife. I resorted to describing a coding problem to her (she is not an IT person) and she made all the right noises. If I had checked I am sure I would have seen her eyes glazing over, but I was on the hunt for that elusive bug. Eureka, problem solved. Careful with this though. It could shorten your prospects or those of your genetic line.

Back to the 21st century and I found myself software debugging once again. Recently I have begun coding ETL processes using SSIS and adapting Andy Leonard’s (@andyleonard) SSIS framework for deployment at a client site. I was grappling with the subtleties of defining flexible connection managers using expressions & variables and design time versus batch execution time.

Consequently, I had loads of questions. I read the blog posts that Jamie Thompson (@jamiet) and others had made on the topic of parent child operations. However I was really stuck on grabbing parent variable values from the child package. One minute I had it working and the next nada. The cause turned out to be simple but I burnt many hours getting there.

As I was working alone on this and often remotely from my home office, I had no one to bounce my issues off. Enter the internet, forums and bloggers. The support network available now has become distributed across the planet, rather than a bay of office cubicles. It’s very powerful, but at the same time there are new challenges.

Everyone still has their own workloads, but now its very likely your potential software dummys have different employers or work for themselves. @andyleonard & @jamiet were extremely helpful and gave plenty of initial assistance but I could not nail the issue.

Contribution to the SQL community is a mainstay of the SQL MVP ethos. It appears to me that maintaining the balance between supporting the community, reputation, earning money and family time & free time would be very challenging; especially in an age where many people in your network will be working and needing peer support across multiple time zones.

Forums have been around for a long while and I posted my issue on SQL Server Central.com. This is a great resource, but either my problem was too complicated or too obvious for anyone to address.

And I need to apologise to Andy and Jamie here, because it was all to easy for me to fire tweets and DM’s at them when I could not get through this issue.

However, this is where Twitter and to a degree forums have parallels to the software dummy process. I expect Jamie and Andy made appropriate noises whilst getting on with their own business, perhaps thinking, “I hope he works this out soon”. But for me knowing these guys would respond with a quick answer if there was one and the act of writing down the issues, especially the long dialog I had with the sqlservercentral.com forum, helped me work out the problem. It made me review and examine my testing method (remember I had it working and then lost it). It is this methodology of being able to repeat a process in a controlled manner that is essential to debugging.

So whilst the internet and always on exposes the mentor to potentially more and potentially constant interruption, the virtual team relationship can be managed, kept at arms length. The mentor can dip in and out of the work environment to suit their own needs. The coder needing help has a virtual sounding board with many people listening and I am willing to bet that the software dummy effect is alive and well and a member of every software developers team.

Tags: , , , ,

Comments are closed.