Three Things I Have Learned About Software School

Scott Hanselman asks about "...three things, learned both IN and OUT of college" in response to Dare Obasanjo's post about "Three Things I Learned About Software in College". Well, I have been writing software for a little over 12 years now, and there are certainly many things that I have learned about software development - and I never once stepped into a collegiate classroom to learn computer science. So to answer Scott's question:

1. Learning to write new software isn't nearly as important as learning to modify existing software (especially considering that once you write a line of code, its now in maintenance mode).
2. You can't fix Stupid - not even with Agile/XP/<next year's trend>/.
3. If there were no clients, and infinite money, we could build amazing software.

Now, with that in mind, I would also like to share some things that I have learned over the years about what a Computer Science degree is worth in the real world:

1. By the time you actually find a use for all the stuff you learned about building a compiler, you probably won't remember it anyway.
2. In the real world, you're rarely writing software to control multiple types of ovens, all of whom will need to implement an abstract Cook() method.
3. You spend 4 years getting a CompSci degree, but then you get out and you still have to learn how to write software.

Now, before I get a flood of hate mail (as if anyone is reading this :P), I don't think that a CompSci degree is worthless. I just don't really think that a 4 year degree is worth more than years of writing software. By the time I graduated high school, I had already written my own compiler, a small OS (oh, how I miss x86 ASM and the A86 assembler), and I had a fairly good knowledge of most data structures, algorithms, and everything else we now call design patterns. For me to get a 4 year CompSci degree would have been (mostly) a waste of time.

Does this mean I think everyone should choose to make friends with a computer at age 10 instead of human beings? Of course not. But, it really bugs me that we don't have any better way of narrowing the field of good job candidates other than certificates. I have been in hiring positions in the past, and I have found that are just as many ignorant programmers with a 4 year degree as there are with out it. But, I have not been able to even get a call back from places like Google, Microsoft, or Yahoo over the years because I don't have have a degree. I can say that with some certainty because any other place (without the degree requirement) I send my resume to will give me a call or some response fairly quickly.

Now, why not go and get a 4 year CompSci degree? I have better things to do than to pay $1000 to have someone test me on whether or not I know what a linked list is. I do plan to go back to college - but for a business degree. At least that way I'll get more learning per dollar :)

I would like to know from anyone who happens across this blog that graduated with a 4 year CompSci degree - Do you think your collegiate experience helps you in your job, or does it only help to get a job?

SVG vs. XAML

Jon Galloway has a post comparing SVG to XAML. SVG - for the uninitiated is Adobe's standard XML file format for vector graphics. Jon mentions that SVG and XAML are very similar and that Microsoft seems to have ignored SVG (which, they may very well have).

However, one thing Jon didn't mention is that XAML isn't just for vector graphics. XAML is a fairly powerful declarative programming language. It just so happens that you can store vector graphic data within a XAML file. SVG, on the other hand, is only for vector graphics. As I understand it, you can manipulate SVG renderings via script, but its definitely not a programming language in its self.

Now, XAML and SVG are fairly similar - I am going to steal Jon's example to demonstrate:

SVG:
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 105 95">
  <path fill="#7B4" d="M106,13c-21,9-31,4-40-2l-10,35c9,6,20,11,40,2l10-35z"/>
  <path fill="#49c" d="M39,83c-9-6-18-10-39-2l10-35c21-9,31-4,39,2l-10,35z"/>
  <path fill="#E63" d="M51,42c-5-4-11-7-19-7c-6,0-12,1-20,5l10-35c20-8,30-4,39,2l-10,35z"/>
  <path fill="#FD5" d="M55,52c9,6,18,10,39,2l-10,35c-21,8-30,3-39-3l10-34z"/>
</svg>

XAML:
<Canvas xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
  <Path Data="M106,13c-21,9-31,4-40-2l-10,35c9,6,20,11,40,2l10-35z" Fill="#7B4"/>
  <Path Data="M39,83c-9-6-18-10-39-2l10-35c21-9,31-4,39,2l-10,35z" Fill="#49c"/>
  <Path Data="M51,42c-5-4-11-7-19-7c-6,0-12,1-20,5l10-35c20-8,30-4,39,2l-10,35z" Fill="#E63"/>
  <Path Data="M55,52c9,6,18,10,39,2l-10,35c-21,8-30,3-39-3l10-34z" Fill="#FD5"/>
</Canvas>


The only major difference besides the Canvas tag and the svg tag is that SVG is all lowercase, and XAML is title cased. Now, why wouldn't Microsoft just make Path start with a "p" instead. Well, in XAML, each tag represents a class that is going to be instantiated and added to the controls logic/visual tree. Since in .NET, all classes are Title Cased, obviously their XAML counterparts are going to be title cased as well.

Jon mentions many different ways to convert SVG to XAML, but here is my idea (not implemented, just thinking): create a new path class in you local namespace that starts with a lower case p (sorry VB'ers, this can't work for you) and then just create a real Path instance behind it. Don't know if that will work - just a thought.

Aaron

A Better Diff?

Eric Sink (founder of SourceGear) announced today that they have released a new free tool: SourceGear DiffMerge. I am a huge fan of free tools, and this one is definitely one to take a look at. For the past 3 or 4 years, I have been using Beyond Compare and it is an awesome tool for diffing files and folders. However, Beyond Compare does not have merge capabilities*.

I downloaded DiffMerge and played around with it for a bit. Its merge capabilities are spot on (well, I created a fake merge scenario - we'll see what happens later with a real one), and the interface is easy to use. One thing that Beyond Compare has that DiffMerge is lacking is context menu support in Explorer. Beyond Compare will let me right click on a file - Select Left Side to Compare, and then right click on another file - Compare to x. Or, I can highlight two directories/files and right click - Compare. That simple. Since I do all my source control operations in Explorer, this is a handy feature. In fact, I can't remember the last time I opened Beyond Compare via the Start Menu or a Desktop shortcut.

Another great thing about DiffMerge is that there is a version for Windows, as well as Linux and Mac OSX. I haven't had a chance to fully evaluate this tool, but it was good enough for me to change TortoiseCVS and TortoiseSVN to use it as the default for diff and merge operations. So, in the coming weeks I'll see how this FREE tool stacks up against the competition.


* Scooter Software has said that Beyond Compare will have merge capabilities in the next version. When that's coming out - who knows... towards the end of this year (per Chris from Scooter Software)