Just a Thought...

In my transition to learning C#/.NET I’ve run into what is my biggest hurdle: culture shock. The technology behind Java and the JVM and the technology behind C# and the CLR are becoming more similar than different. However the culture behind the technologies are like night and day, oil and water. I supposed if we were going to liken it to eras gone by, the Java culture would be more like the 70s hippie culture and .NET would be like the 80s yuppie culture.

One of the things I liked about Java was the share and share alike mentality. There are thousands of open source projects in Java, many of them with free integrations into your IDE. If you needed help with anything, there was someone with a clue that could help you—and they would. Much of what I expect out of an IDE came from the Java world. The concept of refactorings included and automated in the IDE was a major breakthrough, and now no Java IDE wanting to be taken seriously can exclude that feature. Thank you JetBrains for introducing the world to the way it should be. When .NET first came on the scene I don’t think Microsoft was ready in this regard. When the MS peddler came to my company I asked about refactoring tools in Visual Studio (this was around 2003), and the guy looked at me sheepishly. “But with .NET you can design one interface and use it on the web or on a desktop…” he fumbled. When I said I don’t do that every day, and I need something that helps me do my job better every day he wrote it down. I don’t think I was the only one to raise that objection because by the next release of Visual Studio they had the beginnings of refactoring tools included.

The Java culture works well with venerable organizations like the Apache Software Foundation. In some ways the Java culture mirrored the meritocracy already ingrained at the ASF. However, the one thing that hurt Java in the long run is also the one thing that made it better as a first language to learn. It’s that just about every major infrastructure piece has been freely distributed under open source projects. Sure, you get what you pay for in terms of set up and configuration, but even that got better with time. The free aspect is what undermined the ability of companies to make money. Why spend tens of thousands of dollars on a license when the free option was there? Just put an intern on it and it will cost less than the commercial option. Of course, that meant that it was equally easy to play with these tools yourself and make yourself more valuable to the company.

The .NET culture is a pay and share alike mentality. While there are a number of open source projects, they are fewer and farther between. Even so, plugins we expect to be included with the IDE like JUnit integration or ANT/Maven/Boost integration for builds either are non-existent or require you to pay a hefty fee. There’s an NUnit for .NET projects, and by the looks of it is a bit better off than the JUnit 4 equivalent. However, unlike JUnit 4, Visual Studio doesn’t have a plugin for it. In fact, it never will because Microsoft has its own testing features it’s wanting to push. You can incorporate NUnit, but it’s a bit more involved. Or you can use TestDriven.NET, which is not cheap.

The pay and share alike culture extends to the community surrounding .NET as well. When you need help, it’s hard to find what you want online. The only people volunteering free advice shouldn’t, and I’m not convinced that I’d be getting my money’s worth if I paid someone either. While the MSDN has gotten better, it still has a long ways to go before it is truly usable. Part of the problem is that it is so big, trying to find the answer you need is quite difficult. Even when you find it, there’s rarely enough depth to be able to put it to good use. Many .NET books are well in excess of 1000 pages. Rather than focusing on one corner of the technology and bringing the user through the process of solving a problem, the books focus on comprehensively covering all of the API and assume that the reader has more knowledge than they do. Or they are written down to a third grader, and the happy medium is no where to be found. I’m sure the Head First book is good, as they usually are.

Bottom line is that there are obstacles in the .NET world that impede self learning. It’s not insurmountable, and many of the obstacles are cultural in nature. The Job market for Java still doubles .NET, but enough key customers insist on the technology you can’t completely ignore it. Additionally, any new languages you learn can open your eyes to new and better ways to solve problems. I’m still hunting for my go-to resources in the .NET space. It’s going to be an interesting ride, and I’m actually looking forward to it.

Whether you are new to a spoken language or a computer language, the principles are similar. There is so much to learn and it can seem so foreign to you that you can easily get overwhelmed. You can always start with survival phrases: little conversation swiss army knives that can get you a long way. They are really designed to get you to a point where you can find someone who speaks your language to finish the conversation, so it’s not like you are going to understand what many people are saying back to you most of the time. There are three major parts to understand a language: the vocabulary, the grammar, and the writing system.

Programming languages are usually easier to learn than spoken languages primarily because the vocabulary is intentionally kept small. The grammar is also kept consistent and simple to keep the parsers sane and predictability high. The writing system usually entails what can be typed from a keyboard and a few rules for mathematic symbols. There is some punctuation that you have to worry about, but not that much. So what makes a language so difficult? In my short experience, it has to do with translating the simple rules into something useful. You need to learn the libraries that come with the language to help you get something done with the operating system. A more subtle problem is more akin to dialects in spoken language, which is finding the standard idioms for doing things.

Spoken languages are usually tougher to learn because of the volume of the vocabulary and the different grammar rules you have to learn. Sure there is a basic grammar that is consistent throughout a language, but there are always exceptions you have to learn. After all that, you’ll invariably get stumped at some phrases and slang. For example if you translate the Arabic phrase for “How are you?” literally into English you would get “What color are you?” For someone who has grown up using the language its as natural as breathing, but for someone else it’s not that intuitive. How should you take it if someone wishes you to “be enlarged with fatness”? Should you be insulted or flattered? In many languages and cultures it’s a compliment.

Even though the two types of languages have very different challenges and end goals, there are a few strategies to help you in the process. Surprisingly, these strategies are the same for both endeavors. As someone who has learned Spanish and Classical Greek in a classroom environment, and everything else by self-study and pestering people, I can say that the classroom only gets you so far. This is what I’ve found to be helpful to me:

1. Use it. What good will a language do you if you don’t use it for something? Even if you don’t know a lot, use what you know. You’ll find out more about what you need to know by stealing Nike’s advertising slogan and Just Do It.
2. Develop a system or schedule for how you are going to expand your vocabulary. You can only take information in so fast before your brain overloads. It needs time to process what you’ve learned so far.
3. Review constantly. You’re making mistakes, you just don’t know it yet. Go back over what you’ve done in the past in light of what you know now.
4. Immerse yourself in the language. Do what you need to do to see and hear the language used properly. Watch shows, listen to podcasts, get involved in an open source project, read books, whatever you can do, do it. You’ll eventually find a good support group that will help you with the difficult stuff, and find new friends in the process.
5. Learn the slang. Textbooks and classrooms teach you the “correct” way to do things, from an academic standpoint. That might be all well and good for some situations, but the real world is different than the classroom.
6. Don’t strive for mastery. Strive to be better than you are. Mastery comes with a large amount of personal investment in the process. You’ll get overwhelmed if you try to master what you are studying. Just try to make incremental improvements and you’ll be more productive and happy with the progress.

Ok, so considering everything, how can I make these general guidelines? After all, what have I taken the time to learn, and how good am I with it? Even I’m surprised when I look at the list:

• English—fluent, my natural language, 14 years of classroom (grade school and college) plus being competent in the idioms and slang.
• Spanish—somewhat conversant, my second language, 2 years of classroom and a few years of talking to Spanish speaking people. I can speak, read, and write, but I’m still really slow listening. My vocabulary has wained a bit from lack of use.
• Classic Greek—1 year of classroom, some self study using the Bible and study helps. It’s no longer a spoken language, but I can read and write the characters and I know where to look for answers that I need.
• Japanese—I just started learning this language mostly out of curiosity. I’ve got some cultural ties to Japan both from my wife’s family and from mine. I’ve got martial arts, culinary, and cultural interests. Imagine my delight to find Japanese Pod 101.com to aid in my endeavors here.
• There are some languages I just picked up a smattering of phrases, words, etc. Hardly useful more than to break the ice: Arabic, Punjabi, French, German, Russian, Swahili, Finnish.
• BASIC—My first computer was a Commodore 64, which came with BASIC and some other language options. I learned BASIC well enough to work on some toy programs. I also learned the IBM and TRS-80 variants.
• LOGO—I didn’t do more than turtle graphics with this one, but I’m dating myself aren’t I?
• 6502 Assembly Language—BASIC was too slow, so I figured out how to make things happen at a lower level. Graphics were the same either way, so I found Assembly much more powerful and even expressive than the limited BASIC that was native to the Commodore machine. BTW geoProgrammer was excellent (more later).
• GameMaker—Game making infrastructure, including sprite editors and rule editors.
• COMAL—I had a class at school with this one. I never used it for anything more the classroom. However I did learn some cool tricks to use the modulus operator to handle certain corner cases with leap year handling.
• C++—I skipped C because I believed that C++ had more of a future. By this time I left my C64 behind, and I was working with PCs. I first learned with GCC, and then with Microsoft Visual C++. When I started, neither were standards compliant (although I don’t think any where). One of my first personal projects involved CORBA. I’m very well conversant in this language, and if I need to I can get right back into it.
• ColdFusion—I try to block this experience from my mind, but it did drive home the need for a good MVC architecture.
• Java—I started by developing a data migration tool, which was actually well constructed even for a first project. I then got into Cocoon and Avalon as an answer to the ColdFusion fiasco. I’m fluent and still using this today.
• D—The first of the languages I explored for sheer curiosity. It touted itself as a successor to C++ , having enough influence from Java to correct some memory handling snafus and binary compatibility across machines, yet enough C++ to be able to use local libraries natively. Obviously, binary compatibility has to do with how the methods are bound together, which is something that was left undefined in C++. That means it doesn’t matter which compiler is used or what machine the binary was compiled on, it will work if all the supporting libraries are present.
• C#—While I was never really sold on anything that is born from Microsoft, ignoring it completely is more of a mistake. I wanted to find out where the utility began and the hype ended. Sadly, it was nothing more than a language very similar to Java. Sure it had some nice conveniences which were adopted fairly quickly in Java, so as an evolution it had some value. Nevertheless, I can’t entirely trust a culture which does nothing more than to parrot one voice. Java at least has a diverse world of opinions which provides a healthy base to gain experience from. It’s probably because of my firm cultural bias from C++ and Java aesthetics that make me think that C# code looks ugly. C++ had some tools that would extract specially formatted comments into docs, a system that Java took wholesale and extended into the JavaDoc system. C# ignored the precedence and decided to do things different from Java just to be different.
• Lisp/JESS—I had to introduce myself for a project where we were using the Java Expert System Shell for a part of it. It’s based on a dialect of Lisp, so it took a lot of getting used to for me. I barely developed a working understanding of the tool.
• Smalltalk—The second of the languages I explored for sheer curiosity. I wanted to get back to the roots of object oriented programming, and see how these guys did things. It had a profound influence on me, even though I don’t use it everyday. I highly recommend introducing yourself to the language even if you have no intentions of using it.
• Ruby—I’ve heard so much about how nice this language is to use, and I have to say it is a shear pleasure to use once you’ve caught on to the Ruby culture. Remember how one of the keys to learning a language is to immerse yourself in it? You’ll be rewarded. Of course, now I love Ruby on Rails which has greatly influenced how I think web applications should be developed.
• Perl—I can’t say I’m fluent, but I am conversant enough. I was hired to migrate an application to a more modern architecture (with newer versions of Perl and DBI libraries).

That’s a lot of stuff. I’ve got all these languages, both spoken and programming, rummaging around my head with different levels of proficiency. However, by the time you’ve learned your third language it becomes easier. You start to see similarities between them, and you start thinking about them abstractly. Those notions help you learn the new languages more quickly. When you realize that Greek adjectives are positioned grammatically like Spanish, and that Japanese sentence structure is somewhat like Greek (with the verb at the end) you’re building on concepts you’ve already learned.

I’m not finished yet. There will be new languages I have interest in the future. They’ll likely be programming languages, but I’m not ruling out learning another spoken language—or even expanding my knowledge in one of the ones I barely know. Constant learning keeps you sharp, and the good thing is that you can do it a little bit at a time. I don’t have the time, spare money, or the inkling to sit down in a classroom these days. However, if I can fit a little study in here and there, I’m happy. I’ve learned that there are more similarities than differences in all these languages and cultures.

I have to say that both academia and corporations suffer from taking themselves too seriously. Sure there is a certain amount of propriety that you have to have with your clients, but people like having fun. They want to enjoy themselves. So why is it that science becomes such a fun-sucker? I mean you would think that having subjects like “funology” would be a great topic, but the scientific approach makes everyone stuffy. Then you visit the campus of MIT or something like that and people have robot powered couches and other cool stuff. Why? Because it’s fun!

If you play video games, you’ll invariably have to learn something before you really get into the game. The rules of fighting, how to get around, etc. Some games are better than others about teaching you what to do without making it feel like a classroom setting. Ok, press the ‘X’ button two times really fast… Thankfully the education levels are usually pretty quick. It’s a pity you can’t say “I already played the game, can’t I skip the class?”.

So what does this have to do with “serious” software? By serious I only mean that the software is supposed to do more than just amuse you. No matter how easy you make the software to use, there is invariably a learning curve. The fun aspect is learning what cool things you can do if you get into the app a little more. The reward is that you make your users look good. They get kudos from the people they work with, and you get a loyal customer. Whether you save them time or you give them power they wouldn’t have somewhere else. Does your application accept information automatically through an email address? What if the user wants to set up some things ahead of times like adding tags for a picture they upload, etc.?

If there is one thing that video games can teach us “serious” programmers (you can take yourself too seriously) is that if you properly reward your users for good actions, then they will keep doing it. Whether it was the intention or not, the Ruby on Rails framework teaches us how the writer of the application prefers to do web applications. The naming scheme for tables and the wiring of controllers, helpers, views, and models into one application all have their rewards. The fundamental reward for us developers is that if we do it the blessed way, we have less work to do with configuring and wiring things together. Even the code generators teach by example how to do things like how to do CRUD actions (the scaffolding feature). It now becomes fun to write web applications because we are rewarded for most things. Our imagination will help us overcome those obstacles that are beyond the basics we learned from the framework.

There is nothing that says we can’t use the same model for our applications. If our users learn how to use the app to make their lives better in simple, yet profound ways, they will want to become power users. If the users never get over the “I suck” threshold, even after examples and handholding, you will lose them. Making learning to be a fun activity doesn’t require a hippie teacher standing in front of a classroom with a guitar singing the times tables to the tune of “Gilligan’s Isle”. It just means that you make your users feel empowered, cool, or at the very least useful.