Five concepts that completely changed how I write code

(Note that the dates in this post are approximate and are when I discovered said concepts – they may have been around for a while by then, but it may have taken me time to learn about them)

Every developer has these “a-ha” moments where he or she learns something new. Something that completely changes how they perceive code, architecture or design. I am not talking about the “important” bits of realizing that it’s more important for your code to be readable than for it to be “witty”. I am also not talking about the moment you realize how critical it is for your code to be testable or scalable or maintainable.  Each developer has these.

My path was heavily influenced by Microsoft technologies it shows in my five. I am sure other people have their own five that are influenced by other paths.

I am talking about those moments in time when you learn of a new language, a new architectural element or a new language feature that completely changes how you think about the pure code you write or about how you design it. Often these things go hand in hand with the other important things in coding (maintainability, testability and all those other really important but sometimes less than exciting things). These are those “a-ha” moments where you think to yourself “this changes everything!!!” and you are actually excited about it. Can’t-sleep-because-I-am-thinking-about it excited. So excited that you go back and change existing code you have already written – even though deep deep inside you know that’s probably not the best use of your time. Even though you know you are going to be struggling to get the code back to where it was before you decided to futz with it. But you just cannot stand to see your precious code standing there wearing last year’s fashion. Crying. In the rain. While its mascara runs in black rivulets down its white pasty cheeks.  I may have pushed the metaphor a little. My point stands though.

I am talking about GOSUB.

1985 – The year of the GOSUB

I got my first computer when I was about 7 and started learning BASIC. It was the most fun I’d ever had in my short short life. I had some great booklets that I went through one by one. They taught me a lot – from how basic code flow works (in BASIC :)) to how to POKE around and change the character set to do your bidding. When I was around 10 however, I stumbled onto GOSUB.  GOSUB is GOTO’s smarter, more civil relative. In BASIC, you would GOSUB to a line (GOSUB 1000), moving the executing line (just like GOTO), but when calling RETURN, the executing line would return to right after the line that called GOSUB.

It changed everything for me.

I could suddenly reuse code. My mind was blown. I could literally write pieces of code that would do something and MOVE CONTROL BACK TO THE CALLER.

It was amazing. I started using variables to parameterize what these calls did. I used GOSUB all over the place. I had little pieces of paper that would keep track of what lines did what. This is when I actually started using REM (comments) quite a bit so that I could remember what variables each GOSUB was using.

1991 – The year of Objects

In ‘91 (I was about 16) I already had a PC (I believe it was a 386, but I am not 100% positive) and I was knee deep in Pascal. Being able to write code that would compile into an EXE w/o having to use an interpreter was great. I had these massive Borland Turbo Pascal books my mom somehow found and brought to the house. These books explained this concept of Object Oriented programming which I was having a hard time grocking. It seemed very similar to stuff I was already doing. And I just didn’t get what the point was. Everything it was showing me I could already do with Pascal RECORDS. Big deal.

Until one day I was lying in bed, again reading the book and it “clicked”. It made everything SO MUCH EASIER. Stuff I’ve been struggling the get working just happened magically. I no longer had to maintain tables of function and procedure pointers with that awful Pascal syntax.

It changed everything for me.

I used objects for EVERYTHING. Whether it was warranted or not. Operator overloading? Don’t mind if I do! I calmed down over the years… But man oh man. My code never again looked the same.

Later on, when I got on C++ and learned how C++ did OO, I was again blown away, but not like that day when I was in bed and had that “click”.

1996 – The year of COM

By 1996 I was in the army, writing code like a grown up. Creating software people were actually using. It was exhilarating. I have been using OLE and COM for a year or two by then, but more out of necessity than anything else. However, that’s around when VB4 came along and allowed you to create ActiveX’s (or OCXs back then). And suddenly…. Everything changed again. I could write pieces of reusable code and fairly easily utilize them across language boundaries.

Now.. I know what you are thinking… DLLs..

Not the same thing.. While DLLs were certainly usable for just this for a long while by then, they always felt so kludgy. There were no clear rules on how to use exported functions. There was no concept of objects. There was no “discovery”. COM changed all that. It allowed you to define a set of interfaces and let languages as low level as C and as high-level as Access or VB5 use them. Without having to figure out if a string was passed one way or another.

It changed everything for me.

I started designing interfaces to components – even for things I was sure would never have to be used across technology boundaries. Because they might. One day. And while I was a little sad that COM was not as rich as C++ Objects, I understood the trade offs. It was great.

2002 – The year of .NET

By 2002,  Java has already been out for 7 years or so. It has been heavily used for at least 4-5 years when I finally joined the managed languages bandwagon. Very late to that particular party.

When I first encountered Java back in 1999 or so, I think I “got it”. I got how it can be transformative and I also understood that it would change a lot in the industry. However, because of the particular work I was doing, it was never “good enough” at that stage to use. The UI it produced was terrible and I ended up spending more time on Borland Builder and then MFC/ATL than on Java. And so I came in pretty late to the managed scene.

When I started using .NET 1.0 for a server project (and then very quickly to 1.1), I again was blown away.

It changed everything for me.

I was able to write code so much faster. I was spending more time on stuff I wanted to do and less time on stuff I had to do. It was exhilarating. I always thought of myself as a pretty decent C++ developer and knew I could get X amount of work done fairly quickly. However, with C# and .NET (the combination of a managed language and a very rich set of well defined libraries), I could get the same X amount of work done twice, three times and in some cases 10x faster than I ever could with C++.

I still used C++ regularly, but not nearly as often. I would use it only when I absolutely had to – either due to performance (which was rarely the case) or because of some tech that was not really accessible in managed.

2012 – The year of Async

In 2012, with .NET 4.5, Microsoft introduced new asynchronous capabilities into some of the .NET languages. It took some existing concepts and added language support (what people like calling syntactic sugar) to it to make something… Wonderful…

It changed everything for me.

Once I started using these new capabilities, my code transformed completely. This manifested in two ways.

First, code that’s traditionally considered asynchronous (IO such as network or file management) as well as just plain old parallelization techniques became incredibly easy to write, understand and debug. Non trivial IO code shrunk by a factor of 10. And was much cleaner and easier to recompose or reuse.

Second, things that I didn’t originally think of as asynchronous (even though they totally were) took on another form. Things like animation and event sequences were suddenly cast in a completely different light and were utilizable in more ways.

I made the same mistake I did with OO and with COM and to a lesser extent with GOSUB – I overused it initially. But only because it was so much fun.

Easy but magical

In thinking about these five transformations in how I coded, it dawned on me that with one exception, there’s a very clear link between all of them.

They are trivial. But they are revolutionary (at least for me)

Given a day or a week, I could whip up a simple implementation of GOSUB, of OO, of COM or of Async. When you take the concept and hold it very close to your eyes, it is incredibly clear what’s going on. You can understand all the moving parts. It is when you hold it at arms length that it makes everything magical. Managed code is the odd man out here and is far from being truly trivial to implement.

The next five

In thinking about what the “next five” would be to make this list of mine, I am trying to think about what I spend most of my time today when doing actual coding. While I have been doing multithreaded development for a very long while now (15 years maybe), I am far from producing bug-free code quickly. I still find myself placing locks incorrectly, or completely forgetting to protect elements as well as sometimes getting flow incorrectly. I believe that something like a more restrictive threading model (which does not suffer from perf loss) would probably be one of the next a-ha moments for me. Similarly, I still struggle with correctly writing error handling code. I always miss an exception, or misinterpret it.. It can get quite annoying. So maybe something in that area

However, off the top of my head, I can’t think of many things today that I find to be so cumbersome that I would need them replaced. But we’ll see. Maybe in 20 years or so I will post “Ten concepts that completely changed how I write code.” 🙂

What are your five?

I would love to hear what your five (or four or six) transformative “a-ha” moments were.

Honorable mentions

I have been thinking on whether or not I should include Lambdas and Linq in here as another “a-ha” moment. I opted to not do that simply because I feel that, while I rely on them heavily in day to day coding and had they not been around, I would feel the pain, they have not really changed how I write code. They mostly take code that I would have already written one way or another and had made it very compact and somewhat more readable. They don’t really change flow or design.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s