Project Zen

If you've read my previous posts, you would know I started off my career as the standard developer:

"I like to code, I like new technology, I have a weird fear of documentation and I do everything in my power to avoid the politics of management"

The first few projects I was on were awesome. I was learning so much! Over time, I become more aware of the various properties a project had, and learned to place a project on a spectrum of good/bad:

"I get to use the latest technology? I love that, so let's nudge the needle to the "good" side, please! Oh, but I have a complex, 30 page requirements document I have to follow? I hate documents, so we'd better put the needle back where it came from..."

Most developers I have talked to do this, and it's normal. Nothing wrong with it, just the way it is. I do the exact same thing myself.

...Except, I'm trying to become a consultant. I'm somewhat dissatisfied with the projects that I'm getting, but if I want to complete my transition to consultant, I must learn to work on any project, in any environment.

The Process

Let's examine the process a bit. When evaluating a project, I collect information about it. Each piece of information becomes a property used to describe that project ("VB6 app", "agile", "highly contentious"), and then pass those properties through a filter where I determine how to feel about them ("boring", "easy", "honorable"). I weigh the values I get and assign a blended score that I assign ("good", "bad).

When the client asks "what's it going to be like to add some extra functionality?", I bring all those feelings and opinions to the table. Sometimes, who does the work tends to determine the solution, since I might try to minimize the amount of time I have to spend with VB6.

The Real Issue

So what's at issue here? The issue is that I'm making this about me when it's really not. I'm not paid to hold opinions based on personal beliefs and desires. In fact, I'm paid not to. Objectivity is why a company brings in consultants. By holding personal beliefs about a project, you are, by definition, violating that objectivity.

What If?

What if we instead, when evaluating a project, stopped right before we passed the properties through our filter. Isn't the project in a much more "real" form? Aren't the properties more objective?

What if we listened to those properties? What if we inferred knowledge about the client from the project? What if the fact that the project is in VB6 means something about the organization? What if we made that a statement about the people themselves?

What if we passed those properties through a filter, but not one of our own making? What if we painted every property as "valuable", or "necessary"? What does that say about the organization now? What does it say about the people?

Project Statements

If we can modify our evaluation process, playing with the filters we put a project through, it really becomes something new...

I feel this has gotten a little too rhetorical, so I will state some opinions on this matter, ignoring the irony therein:

• A project isn't good or bad. A project is. 
• A project exists because it results in a net increase in value. If it did not, it would not exist. 
• A project has the attributes it does because those attributes are the ones that serve the organization best. 
• A project is a mirror of the organization and the people that make it up

Bringing It Home

So how does this relate back to my satisfaction? Quite simply, it's important to not judge the project or the organization, but instead realize that you are in the position you are because you are an observer to the problem. If you want to truly help an organization, you must be able to see past your own thoughts and see the problem you are trying to solve as it exists in reality, which includes how it fits within the organization. Once you do this, you are better equipped to provide help. Helping the client in a more real way is, so far, the best way I have found to bring satisfaction to my life. Help them, help yourself.

What I've Learned From Corporate IT Consulting

Background

I hesitate to call myself a consultant, because really, I don't do much consulting. Most of what I do is coding. Instead of doing it in an office for my company, I do it in a client office for a client. I only call myself a consultant because every once in a while someone will come to me and ask me what I think we should do, and I give them an opinion. Also, my company told me I was a consultant. Since I like having a job, I figured it would be prudent to just go with it.

My current company is a consulting firm. They cater to "enterprise" clients, which really means big companies. Oil and gas is big in Alberta, so anyone that services that sector is also pretty big, like construction. And since everyone needs services, there's also government and various other things.

I've been doing this for just shy of 3 years. Before this, I worked for a year in an IT department of a remanufacturing plant as a co-op student during the summer break of my diploma and the last year of my school. I was attracted to my current job because I wanted to make sure my skills stayed current, and it's hard to do that when you work in a company that doesn't focus completely on IT. The company was also very young, and being there while a company grows has benefits. Because it was so young, it was also very small, and I prefer to work with a fewer people that are of a higher caliber than to work with lots of people.

I started working for my company with the title "Solutions Developer", coding stuff for clients. I would leave the office very rarely. As the client list grew, however, so did the size of the clients. They started requiring that we be on-site, so I was sent out. Over time, it became obvious that client-site work was going to be impossible to avoid. Instead of risking my job trying to fight it, I just chose to embrace it and start educating myself on consulting as well as technical stuff.

Lessons Learned

So now that you have a brief idea of how I got here, I believe you have the necessary context to understand where I'm coming from for the rest of the post. I am going to assume that you are familiar with the job of a developer. If you aren't, then someone else's blog is probably the best place to find a breakdown of what that's like. I wanted to bring a consultant's perspective, since I believe it's very under-reported.

So what have I learned? Very few things are either good or bad. They are what they are, and you must decide for yourself. Here's the list:

• New things - Your world will constantly be changing. You will be exposed to new things all the time. It may be hard to handle such constant change, but at least it's constant, so you can rely on that... You won't really have to deal with a problem for more than a couple months at a time, but you will also not be able to settle down and enjoy any benefits for too long. The best thing about this part is that you will get experience with both, and more, over the course of your career. You will see awesome solutions to problems and be able to take those to other companies. Probably the ultimate benefit of this point (for me, at least) is the chance to see past the individual attributes of a company and see the roots. Every company is like a person, with its own personality, likes, and dislikes. It's seeing those characteristics that make a consultant so valuable. It just takes time.
• Change is slow - Change takes (what seems like) forever in an enterprise. I have come to believe that if change is quick, something is wrong (or soon will be). Large groups of people need time to adjust properly. Working in an enterprise presents a chance to chill out, since there is only so much change an organization should make within a certain time period. It also means that not every idea, even the good ones, will be implemented. It can be tough to sit idly by while good opportunities pass by, but it's for the best. Every company must choose which opportunities to grab. So sit back and take it easy. There's very few times I've been called on to work overtime, which means I arrive and leave at the same time. So use the in-between times to prepare for the next move, or learn something new. I prefer to read a company's manuals and other training material to absorb the knowledge they offer. Just remember to respect any NDAs ;)
• Clients aren't friends - Clients don't really see you in the best light. You really have to earn trust, especially the trust of the employees. Managers see your credentials and have chosen you based on your skills, which means they already trust you enough to hire you, but employees see you differently. Most of them probably don't understand your value, and see you as an omen of change (which most people resist), as well as the guy who makes solutions and then leaves them to maintain it. So be prepared to be disliked. You will get a chance to hone your ability to win people over quickly as you move from engagement to engagement, but it's going to be a constant effort. Once you can get into the good graces of the crowd, things get easier. It just takes time and practice. Also be sure that you are making friends outside of work. A lot of developers tend to make friends through work, and being at client sites means you can't rely on the employees for socialization. Over time, however, you will build a network of people you keep in contact with. It's just not as seamless compared to being a developer.
• Deep knowledge is key - Keeping your skills up-to-date is key, but it's hard to invest in a specific skill-set when you are constantly moving around. Becoming valued as a specialist takes time, too. So it's important to study the concepts behind technologies. Yes, you should also be aware of specific technologies and what they can do, but a lot of your time will be spent learning background info. This has the side effect of making you look like an idiot to some people, as you become a generalist. It will become harder to explain your job, and any attempt doesn't work that well. You must motivate yourself to learn, or you will find yourself without work. Still, it's a great way to keep your skills up to date.
• Strangers are good for work ethic - Your typical office isn't a labor camp. There's always time to fool around and take informal breaks to relax your mind. Today's developers are creative and need time away from the keyboard to recharge the juices. It's easy, however, to forget the time and goof off for an hour, which also makes it really hard to get back to work. Being forced to sit down and code under the eyes of budget-conscious managers and judging employees is a great way to develop the ability and desire to sit down and work for hours on end. It's a skill that takes practice. That level of work ethic isn't cultivated in every organization, but will be valuable in all of them. It's also essential when you want to 

As you can see, consulting is very different from being a developer. Corporate consulting even more so. I hope you got an idea of what a consultant's life is, and saw what it offers compared to a developer position.

Binding To Event At Runtime In Windows 8 Metro

So I wanted to use the MVVM pattern in Win8 Metro WPF, but was without the classes and functionality I would use in WPF4. So I decided to create my own, but I got the error:

Adding or removing event handlers dynamically is not supported on WinRT events.

I found a blog post on the MSDN where some guy posted about using the WindowsRuntimeMarshal to get around that, but he didn't post a code sample. So, I decided to figure it out, and let everyone know!

So here's the code:

var eventName = "Click";
var myButton = new Button();
var runtimeEvent = myButton.GetType().GetRuntimeEvent(eventName);
var handlerType = runtimeEvent.EventHandlerType;
Func<RoutedEventHandler, EventRegistrationToken> add = (a) => { return (EventRegistrationToken)runtimeEvent.AddMethod.Invoke(myButton, new object[] { a }); };
Action<EventRegistrationToken> remove = (a) => { runtimeEvent.RemoveMethod.Invoke(runtimeEvent, new object[] { a }); };
RoutedEventHandler handler = (a, b) => Command.Execute(b);
WindowsRuntimeMarshal.AddEventHandler<RoutedEventHandler>(add, remove, handler);

So that's how we can add an event handler to an event at runtime in WinRT. Pretty simple, really. The one limitation of this code is that if you are trying to bind to an event that isn't a RoutedEvent, you're going to have to re-do the code. But I'm sure this is able to become a generic function with a little bit more work.

Video: Tools For Unit Testing And How To Use Them

Code and slides can be found here

Implementing IDisposable Properly

I just found out that I haven't been disposing correctly. Here's my newest IDisposable implementation:

        //Stores whether everything has been disposed or not. It's possible
        //to call .Dispose() on an object and then try to use it again. With
        //this field, you can check before trying to access a resource.
        //Default is false (as per all booleans)
        private bool _disposed;
 
        //This is a C# finalizer, called when the garbage collector is going
        //to clean up an object. This is kind of expensive, but we need to
        //make sure we are disposing of objects. Having a finalizer makes
        //sure we dispose of our resources even if we forget to call .Dispose().
        //Finalizers force the garbage collector to keep track of who has them
        //and makes the garbage collector require two passes to erase an
        //object: one pass to call the finalizer, one pass to release memory
        ~SampleClass()
        {
            //Calls a private method we have made, telling it to only release
            //unmanaged resources. Managed resources will have been cleared out
            //already, since the CLR keeps a reference count.
            Dispose(false);
        }
 
        //Implementation of the IDisposable interface
        public void Dispose()
        {
            //Calls our private method, letting it know that we need to let
            //go of both managed and unmanaged resources
            Dispose(true);
            //Tells the garbage collector that we don't need to run the
            //finalizer for this class, since we are going to clean up
            //ourselves. This prevents the costly running of the finalizer
            GC.SuppressFinalize(this);
        }
 
        //A private method just for us. The parameter determines whether
        //we clean up only unmanaged resources, or if we also include
        //managed resources
        private void Dispose(bool disposing)
        {
            //Checks if the disposals have been done already
            if (_disposed)
            {
                //No disposal done? OK. Fair enough. Are we disposing of
                //only managed resources?
                if (disposing)
                {
                    //We take care of only managed resources in this block
 
                    //If the resource is still around, dispose of it.
                    if(_managedResource != null)_managedResource.Dispose();
                }
                //Unmanaged resources need to be cleaned up for sure, so
                //let's do that here. Call the code to clean up the
                //resources here. In this case, let's pretend we have a
                //COM object to be cleaned up.
                Marshal.ReleaseComObject(_unmanagedResource);
 
                //We set everything to null to remove this object's
                //references for certain.
                _unmanagedResource = null;
                _managedResource = null;
 
                //Set the disposed flag to true to let the rest of the class
                //know.
                _disposed = true;
            }
        }

Once we implement IDisposable like this, we are guaranteed to have our objects cleaned up properly no matter how our code is being used, which is the goal of even using IDisposable :)

Any tips to improve this code? Leave a comment!

Priorities And How They Can Get Away From You

We all prioritize. We have to. The demand for us as a person is strong. People demand our attention, our money, our time, and our brainpower. They all are asking for something from us, and we ask for something in return. We find something we can do easily (think, speak, lift, lead) and we offer that service to others, prioritizing to get what we want. You can spend your time on an open source project or you can stare at the sun. Both bring benefits and both have downsides. You probably would like to see a great tool for X technology instead of damaged retinas, but that's only because you're a developer and I am assuming that you don't want burned eyes. We do this trading all the time, and most of the time we don't even know it.

Our output is measured in how much we can finish in a period of time. If Guy A can do 3 things a week, and Guy B can do the same 3 things plus 2 more, Guy B is considered a better guy. Whatever the skillset they possess, that's typically how it works. One's ability to do something is much higher the more motivated they are, and intrinsically motivated people are not swayed easily from their motiviation. The challenge a lot of employers face is how to motivate people enough to make money off of them.

So when we sit down and think "What should I do?" (as those who are self-directed tend to do quite often), we tend to think about our highest priorities and act on those. Now, most people have a obstacle where they haven't established priorities or they aren't clear, even to the person setting them. If you are looking to be continually improving, I have noticed that there are a number of people who have the energy and want to advance their interests, but they still aren't able to move forward. One thing I am still learning is that almost as important as having priorities is keeping that list small. A large list of priorities that isn't written down can distract you from your goal. Similar to a software project, if your priorities are always shifting and never nailed down, you will suffer from having 30 half-finished goals at a time, which really lowers your output.

I got a tip from a mentor once. He told me that every decision you make to advance a specific priority is an automatic decision to not advance a different priority. Additionally, you might not know exactly which priority is going to suffer, but it's going to happen. And that's because we only have 24 hours in a day and only so much energy. So by reading a good book, I am investing time in my career, but that also means that I won't be investing in my skill of Internet trolling. It's always a tradeoff.

So what do you do? How do you beat the system? The key is in making sure you are prioritizing correctly. Because really, if your priorities are not clear to yourself, then you are liable to make the decision that invests time in the priorities you want less than the one(s) you sacrificed for. So make a list! Write down all your priorities. I have such lists for all sorts of things. I consult a list when I want to decide what I should do to become a better developer. I also consult a list of things when I would like to furnish my bare apartment with. I consult a list when I'm trying to decide where to eat (I have prioritized a list of places I want to try). I tend to have lots and lots and lots of lists, all meant for a specific mood. I even have a list when I'm not in a particular mood! And it works. I find my top 10 choices laid out nicely and it's just a matter of maintaining that list and then acting on it when the time comes.

The reason this works is because we tend to forget lists like what we want out of life. We can't keep track of what to get on the way home from work as well as the 3 things we want to work on to become better devs. Something has to give, and we forget something in there. As well, lists can help you focus on a goal. Consulting a list is really taking the time to decide where to put your time (or money or whatever), and taking a couple seconds and thinking about a decision is typically a good idea. God knows I could make use of doing that more often :P

So make some lists! Get everything down and out, and get used to using the lists. Phones are a great place to stash lists, and there's some neat ways to share them with the people you need to.

Video: Introduction to Moq