Tuesday, September 20, 2011

Change of direction and focus

A few blog posts ago I set out a path for attaining an MCTS and blogging about it in the process. I have now scrapped this plan and changed focus. Why? I remembered a post I saw (on G+ I think) about when deciding what to do next you should think backwards from the future - was that a good use of my time? Am I proud of that? I can't honestly say an MCTS answers those questions. So what am I going to do with all this spare time? (Spare time?! yeah right...) 


I have been inspired by an old blog post from Joel Spolsky. It is simply a list of books he recommends (requires) anyone taking the software management course at Fogcreek to read. There are 75 books on the list so reading at the rate of a book every two weeks it will take 3 years to get through all of them. Ambitious though it is, if it took 3 years or even 5 years then what harm? It sounds like a good investment of my time. I'm currently a software engineer and although titles don't matter to me too much, progress and autonomy does. So I see my career going something like senior software engineer (real soon hopefully) and then some sort or form of team lead role. After that who knows? Architect, Product Manager, Software Development Manager? No matter what progress I make and what path I end up on something tells me this will be time well spent. 


Reading (the right) books is one the surest ways to increase your knowledge and with a Safari Books account I can get almost all of these titles for free! All I need now is a decent e-reader. 


I started on the list last night with "The Mythical Man Month" and I'm on Chapter 6 already (reading at night on my Nexus S hurts my eyes so I'm not sure this pace will last). If I got through half the list I'd be impressed!

Friday, September 9, 2011

Returning more than one value from a method.

Reading "More Effective C#" I came across a pretty cool bit (around p.55) about using the tuple type to return more than one value from a method. That's fair enough but the really cool part was the way the author used the using keyword...

For example, in returning a latitude, longitude from a method (you could be returning five or six values etc. with a tuple but lets use two for simplicity) Tuple<int, int> doesn't really tell us too much.
public static Tuple<string, decimal> GetLocation(string address)
{
   int longitude = // get longitude algorithm
   int latitude = // get latitude algorithm
   return new Tuple<int, int>(longitude, latitude);
}

//usage
Tuple<int, int> weather = GetLocation("address");

To give a more meaningful return name you can provide an alias for the return value. 
using GeoLocation = Tuple<int, int>;
public static GeoLocation GetLocation(string address)
{
   int longitude = // get longitude algorithm
   int latitude = // get latitude algorithm
   return new GeoLocation(longitude, latitude);
}

// usage
GeoLocation location = GetLocation("address");

The using keyword continues to surprise me (e.g. as a tidy way of attempting to dispose of something without knowing whether or not it implements IDisposable). Of course if this method was simply better named "GeoLocation" there's be no problem! But it's the concept that's useful to know.