I’m becoming 1337… dammit

Skrevet - Sunday, May 13th, 2007 kl. 18:23 | Kategori - * Coding

For a few months, I’ve been learning C# mainly to support a craving for learning something new. I’m naturally curious and like to know how stuff work. Sort of as a side-note, I needed C# (or something similar) to port our business solution at work from a very old programming language (XAL-Basic) to something new and shiny.

I’ve previously taught myself VBA (now called VSTO) – a subset of Visual Basic for Microsoft Office and this XAL-Basic. Usually the way it goes:

1. I start a project I have no clue how to solve, but I have a few ideas.
2. I read a few tutorials and mess around with a few test-UIs (user-interface) to get a feeling of the language.
3. I read some more – usually a few e-books and support-sites – adjust my coding to this.
4. Discard everything after taking a course or two and start from scratch.

This time around was no different – I had a project from work I could use as a playground, I chose a few courses (since work is financing my hobbies…) and picked up a few e-books. Only thing different was that I skipped part 4…

We just finished the course at work (a colleague, my boss (sort of) and I) and took the weekend to go through what I had made during my self-teaching for our new project. Of course, my solution wasn’t perfect (for some reason, software appearantly has a built-in functionality that makes it imperfect by design…) – I had made a single design-flaw that would have been a problem further on and it was only a skeleton-version of the final product. (For the technical guys and gals out there – I had made a mistake in my UML, making a HAS_A relationship the wrong way around, basically meaning that a child class became a parent class). But other than that – everything was accepted…

Funny thing is… my approach to software has changed a lot over the years. Back in the glory days with VBA – I’d do the quick ‘n dirty solution going: “Well, it works… why bother with all that documentation and yeah… naming is a mess, but who cares about naming? Why use classes when you can make a work-around with variant objects and who the hell is OPTION EXPLICIT and why do I have to delete him at the top of all pages?” This time around, I made a (crude) UML, described basic functionality and basic concepts before writing a single line of code. I then started reading. Being a practical programmer (never attended any kind of college related to programming), I picked up “C# for dummies” and applied the concepts to the solution as I came across them. Then picked up pretty hardcore programming books (Addison-Wesley were in my oppinion by far the best as they are (well-)written for .Net 2.0, covers the stuff I needed and are fairly recent).

And now, I’m picky about code – it has to look good (and function)! Give me your Excel spreadsheet with VBA code, and I’ll rip it apart and have you start over considering what you did wrong the first time. In part my boss has influenced me – our present solution is written in XAL-basic and we have a 64 kb memory limit (go DOS!) so we have to make extremely lean code to fit all the functionality we want. Also, the architecture of the programme means that everything Database-y is handled inside the same program. So, everytime something goes wrong, it can go wrong a number of places – and the key to being a good programmer is knowing when to look where. E.g. when a form crashes after inserting a new line – the form could be faulty, a trigger on the database trigger could be failing or a few other places called from the form…

But the part that has amazed me the most, is how extremely well-fitted Visual Studio is for Extreme Programming which is by far my preferred way of programming. Basically you document and code in tiny seqments – learning as you go and adjusting things on-the-fly making for extremely fast programming and (if you made your UML and design correctly) a nice way of making the skeleton first, see it work – and then flesh it out. Bosses also like that you have something to show for your time early on. It is a really nice way of catching mistakes early on as when you can see your design crumble at the first test of pressure, you know that something is wrong and you have the chance to correct it before writing all the code that depends on this achilles heel.

So, the irony of it all… I’m now at least as 1337 about code as I criticized coding gurus for being just a few years ago… I guess sometimes 1337 actually means better… or smarter…