It was somewhere between September and October of this year that I realised that my IT skills were outdated, and needed to be brought back up-to-date. Historically, I have been a back-office (batch) developer and support team member / leader and so most of my experience has been gained with Unix, shell-scripting, C, Oracle, etc.

Batch processing is not very glamourous, not least because it tends to involve overnight support.

So, whilst there are benefits, I really wanted to try to see if I could learn a little bit more C++, and maybe start a move towards Windows – or at least front-end / GUI development. I started playing with Visual C++ v6.0, basic edition, though for the most part I have to admit that I programmed it in much the same way that I would have done had I been using C. OK, I took advantage of a few C++ niceties, like localised declaration of variables (e.g. in a for loop), but I did not learn a great deal about classes, inheritance etc. Though of course, I did learn a thing or two. The project I was interested in was very logic intensive (solving a Sudoku puzzle), and because I wanted to concentrate on what I thought would be a fairly straight-forward task, I decided to keep it command-line only to start with. I came up with a program that could solve many puzzles that were input to it, using logic alone (i.e. not brute-force processing).

Then, I started to hear good things about Visual C#. It appeared to offer an easy transition to Windows programming, and far better integration in the development environment than I had ever seen in Visual C++. (A side note here is that I have done some very minor Delphi programming in the past, and I loved the way that it was very straight-forward to understand how to get code to run when a button was clicked, or whatever). So, being something of a cheapskate, I found that Visual C# 2005 was available as a Beta version from Microsoft. I downloaded, and started to try to convert my Sudoku code to C#.

So, ‘Hitchhiking’, in the sense of this article title, is getting a free ride on the back of beta trial software release.

Mistake #1: Trying to convert a program design intended for one language into another without first reconsidering the design implications. Of course, I could not consider the design implications, because I was trying out C# for the first time… but even so, it was a mistake.

I had many fun adventures realising that much of what I had done in C++ was now redundant or just plain wrong in C#. My simple class in C++, making use of bucket loads of structs and pointers, was nowhere near compiling cleanly at first, and I was most certainly held up because of incomplete documentation with the development product, and also a large dose of being blinkered to the act of learning C# in the best way possible, but instead ‘finding out how to make my struct compile’ – or something like that.

Mistake #2: Working on a development product means incomplete documentation. It’s not that the documentation with C# 2005 Beta was bad, it’s just that somehow I managed to find tens if not hundreds of empty topics that were incomplete simply because it was a beta tool. That probably affected me considerably when it came to looking for things that I would have found had I looked properly – but I think it almost became an assumption for me that the documentation I needed wasn’t there yet.

I forget now how many wrong turns I took. My structs rapidly lead me into using ‘unsafe’ code, as my pointers and references required that. Eventually, my structs were converted to classes. I thought I was doing a ‘Good Thing’ – surely using classes meant that I was being really Object Oriented? Now, a lot of my functionality had to be shifted from my one catch-all class into these classes that were members of my major class (this was not inheritance, remember, but associating behaviours with data). Moving to classes was a good thing from the point of view of being able to readily store references to data in a multitude of different ways; but possibly bad in that some of the classes, e.g. that one which held data about a Sudoku ‘Cell’ (which at it’s simplest, needs only to store a single digit, or something representing empty which can conveniently use zero); and this small data size suggested to me that a struct would have been better. Ah – the confusion!

And all the while, I was extremely reluctant to buy a book on Visual C# because I knew, that if I bought into the software, I would be buying the 2005 version for which there were no books available.

In the meantime, I found that the complete Visual Studio 2005 was available free of charge in beta form too. I ordered it, and on it’s arrival quickly got my code up-and-running within its development environment – which lead to:

Mistake #3: For some reason, I sort-of thought that the Beta product I had was the equivalent of the ‘Professional’ level product. In fact, it was the Team System’ product with its static code analysis, integrated Test suites, etc etc. Being an inquisitive type, I managed to find those features. Static Code Analysis, for example, provided all sorts of useful tips about my naming standard and warning about my slack use of public data members, and all sorts of things about Globalisation, exposure of List<> elements etc that I currently believe will only be useful in the very long term. Simply put, I wasted a great deal of time trying to get Testing to work before finding out that possibly what I was trying to test was not implemented in the Beta product, and in fact might not make it into the live product either.

Meanwhile, my development continued. I’m quite certain that I am still paying for some of those early decisions made when I had no idea that C# differentiated between struct types as values and classes as references. I finally gave in and bought a couple of C# books. I learnt a lot from both, but still managed to find a remarkable number of places where my area of interest was quite obviously one of those areas that was being changed in the new version of the software.

Mistake #4: In certain simple circumstances, my lack of knowledge of the product Visual C# meant that I was simply unaware when something ‘obvious’ was going wrong. For example, the Beta 2 product had a bug where tooltips ceased to update automatically if AutoEllipsis was turned on. So, my code rapidly spawned updates to a certain label field, followed by an update to the tooltip. It shouldn’t have been necessary, and had I had better knowledge, I would have seen the warning signs of a possible bug. In fact, although I can not say for certain, I am sure that the bug was far more problematic than the bug-reports I finally found. The tooltips were not just not updating automatically, they were not emptying when set to be an empty string, and even resetting them (I forget the exact method call, but the one that should empty them of all related tips) failed to resolve the issue. After many hours looking for the cause of one bug related to tooltips, I came to the conclusion that my code was right, and that something else was wrong – and a search only at this point finally revealed that there were bugs in the system itself. Summary: When learning a product, you have less knowledge to know the way that some things should work, and have a lower confidence in the way you yourself are working.

Finally, the Visual Studio 2005 Professional product became available, and after struggling to understand Microsoft’s upgrade schemes and such like, I decided to buy the Visual Studio 2005 Professional with MSDN subscription. After much effort with a very helpful supplier, we found out that all the competitive upgrades that would have been available to me if I purchased the boxed-set, were not in fact available to me if I bought the one with MSDN subscription. Frustrating. In this case the mistake was not major, but the simple fact of being on the ‘cutting edge’ when resellers themselves had not had a chance to fully understand a complex upgrade and transition policy wasted a bit of time.

Mistake #5: Because I was not fully aware of exactly which parts of the system were going to be part of my purchase, I quickly came to rely on the Static Code Analysis tools to help point me to areas where I should improve my code… and as a double-check that I had not introduced new issues when adding a new class. By the time I bought the full ‘Professional’ product, I was aware that I would not have that feature; but perhaps more significantly, I had learnt a lot of things that may not be quite such fantastic ‘rules’. For example, the code analysis told me that MS standard was to have private variables prefixed with a lower case latter, using upper case to delineate new word (camel-case). And never, ever, use underscores. Meanwhile, many books use variables prefixes with underscores to indicate a private member variable. Static code analysis also suggests against using short variable names, with occasional exceptions. Several sources of material later, I can confirm that I now hate to see short variable names with little implicit meaning, even though it is all quite legal code etc. The point is, where the Editor preferences are seemingly mature enough to allow you to select ‘auto-formatting’ of code to a variety of standards, Code Analysis as a tool is not. I would have learnt a lot more if the Code Analysis tool was a touch more mature in offering a variety of naming standards, perhaps with documentation describing the benefits of each. I was certainly not capable of making informed decisions in this area myself!

Overall, the biggest mistake I made was this:

Super-Big Set of Mistakes: I did not have any sensible idea of the size of what I was trying to achieve when I started the move of some code to C#. I didn’t start with ‘good, well-designed code’. It wasn’t even complete. Had I thought about it, it was really quite an extensive project, and although I realised that I would get good broad experience of C# with such a project, I certainly never anticipated the amount of effort just to convert my poor start-point into a working poor start-point in a different language. Simply put, I didn’t know what I was doing!

Having said all of the above, I am quite pleased to have gone through this whole process. I’ve been really lucky in that I have been able to dedicate time to this without having to worry about ‘real work’ or have any real deadlines (which may, in fact, be a problem!) I may have done myself a service by getting an older version of the development software, getting a good introductory book to go with that, and just spend a week or two going through exercises step-by-step. However, my route did totally avoid the risks of boredom from stepping through exercises that seem to have no relevance to me – and I like having a target that continually allows for improvement etc.

I’ve learnt a lot about C#. There is much more for me to learn about good, or even great C#… but I am well on my way. I just would have preferred not to have had some of the hassles I faced because I chose to learn using Beta software.