Don't Virtualise Everything

There seems a need in the dev and the ops world to virtualise everything. Everything!

People talk of it as the second coming. We can scale. We can spin up any environment without over-preparing or extra investment or asking permission.

Like the cloud, talk of virtual machines solving every problem imaginable is all the go.

Like all new technologies, they bring you benefits but they are not the answer to everything.

Good engineering and common sense must always be applied, especially in times of wonder.

One place that you can not 100% virtualise is in testing.

Twice in the last four months, I have had to walk in to situations where the issue was testing an app in an updated SOE that had only been tested in a purely virtualised test environment.

One had issues with drivers and the other with an out of date BIOS version.

When you are running in a virtual machine (VM), it is an emulator. As much as possible is handled inside the emulator but one thing that makes a VM so portable is that it is piggybacked on the host operating system. One thing you can count on is that when it falls back to embedded calls to hardware that it falls back to the native OS and its drivers.

Underneath that is the BIOS and although you can mostly count on that, nothing is guaranteed.

In the two cases I saw, the problem happened under load and pushed the boundaries that would never have been tested because it was impossible to simulate in a non-native environment. Although operating systems were tested, bespoke applications were assumed to pass all tests if they did so inside the VM.

There is no need to test everything outside of a VM though but you should at some point in the testing journey. My suggestion is...

Unit test in a VM.
System of Integration test in a VM.
Functionally test in a VM.

At least Performance or Hardware Integration test on the native hardware with the native operating system.

Nothing beats reality.

Nothing.

Agile Explained

Why I'm an Engineer and Not a Pastry Chef

On the Internet, people joke about First World Problems (FWPs) when they stub their toes on their BMW run-flat tyres while wearing their new Louboutins, in an attempt to avoid stepping on their Paspaley pearl earrings.

On my team at work, we have PFE World Problems (PWPs). They make an FWP look like torture. As a job, it isn't so bad. I'd go as far as to say it doesn't suck. It is time I reminded myself of that.

My latest PWP was hitting what in Microsoft is called the 7 month itch. No jokes about antibiotics please. It is a point when after being at the company for a while, you are passed the honeymoon period and straight in to the everyday work ritual.

When people told me I would hit this, I sniggered. Well, it was probably more of a giggle but now I find myself sighing mostly and realising that Monty Python was right in the Life of Brian...

Brian: No, no. Please, please please listen. I've got one or two things to say.
The Crowd: Tell us! Tell us both of them!
Brian: Look, you've got it all wrong. You don't need to follow me. You don't need to follow anybody! You've got to think for yourselves! You're all individuals!
The Crowd: Yes! We're all individuals!
Brian: You're all different!
The Crowd: Yes! We're all different!

Truth is that joining a big company with so many possibilities is awesome to start and keeping that momentum going is up to you. In this case, it is up to me.

I identified the two things that are not Mana-friendly and now I must find a way to fix them or get out.

They are...

The Lack of Team (the journey)

PFEs work mostly on their own. What I do is called transactional work. You go in and provide knowledge or a solution or give someone a hug and then you move on to the next client. Those who are lucky like me, go back to the same clients and sometimes the same systems.

If you've met me IRL then you know that I can build rapport with anything and anyone from a CIO to a dev to a grumpy crocodile to a brick wall in under 3 minutes. All of that comes from genuinely caring about what clients want and how to help them achieve that. My work is not about me being a superstar or about credit or acclaim. If I wanted that, I wouldn't be in PFE. I'd be a pastry chef.

Anyway, you build rapport and you like the cause. You work towards the cause and you actually add value. Then you leave and start all over again. It is fun but it isn't the same as being part of a dev team building software.

This means that I have to find a way to belong. A way to feel part of something without being in the middle of a dev team slaving over the coals. That's my first action item. I must find a way to enjoy the journey that satisfies the way I like to work... with people.

No Finish Line (the destination)

Ask anyone who identifies as pragmatic and they will tell you that delivering something from start to finish is more satisfying than gold plating or talking about it for ages.

In my current day to day work, there are very small blocks of work that I have to complete. People often say they like the work but not the wrap up report or presentation at the end. I love it all. I love the start, the middle, the race to the finish, the wrap up and the bloody post mortem.

As an agile dev, breaking down big things in to small achievable parts is a talent I have. I can deconstruct any requirement and put it back together, while holding the holistic view and goals in my head.

There is my second task, to find a way to take on bigger chunks of work that let me satisfy my need to build awesome stuff.


It took a lot of sulking to come to this realisation. It also took a colleague to give me a good slap and tell me to step up and do something about it. I am often that person to others but oh so famous for not taking my own wicked advice.

Thank you, unnamed colleague. You are lucky there is a continent between us :)

Now to make it better or get the hell out.

Team Players Are Worth More Than Superstars

A lot of time, I am involved in putting teams together and getting them to mash.

Sometimes, I am given the raw materials and have to make the most of what is given me.

Other times, I get to pick and choose and use excuses like "we need the best combination to deliver what the client wants."

Often when we hire developers, we look for technical skills and client facing skills and design skills. This is all well and good as long as we also look for collaboration skills.

The environment that I play in is full of superstars who really do know their stuff. The thing is that when I'm choosing a team that knows my stuff, I want one thing in particular. You have to know how to collaborate.

A developer can know an API front to back.
A developer can talk about the intricacies of their technology stack.
A developer can describe everything they have ever built and impress you.

However, I want someone who can work with others.

I am not fussed if they are a member of Mensa or can recite 6 digit primes by heart. That doesn't make a useful developer.

What is most important is that you can work with others. You must be able to say what you have done. You must be able to describe your intentions. You must be able to write code that doesn't identify itself as yours but instead mold with the team.

Yes, there are so many average devs but a good dev who can communicate and collaborate will wipe the floor with them.

Be a good team player.

A superstar is worth nothing alone.

Be Mobile or Be Cloudy

There are two spaces in the dev world for a dev to touch on right now that can not be ignored. If you do ignore them, you are accepting legacy status within a year.

Be a mobile dev OR Be a cloud dev.

Cloud: A visible mass of condensed water vapor floating in the atmosphere, typically high above the ground

Everyone is talking cloud this and cloud that. If you aren't at least having a play in this new world at home then you are already falling behind.

This should be something additive. It will work with what you know and be a logical progression, just as classic client server gave way to the storm that was web development.

Everyone has an offering. Amazon was first and they did ok. Google wants all your data and pretty much has it. I work for Microsoft so you'd expect that to be why my suggestion for a starting place is Azure.

In actual fact, it is Azure but not because I work for them.

If you are a .NET developer and you want fluid transition in to this new buzz word filled world of cloud then there is no better option than Azure.

Moving to any cloud is not just a matter or spinning up a few servers and copying your code over. Designing for this new environment is key. Take what you have and move it to a truly scalable model with infrastructure as a service and advanced app monitoring.

Stay tuned and join me on my 90 day adventure to build an Azure based application.

Mobile: A decorative structure that is suspended so as to turn freely in the air

There are also a bunch of major options if you go down this path. Google has Android. Apple has the mainstream iOS platform. Microsoft gives you Windows 8.

Having written apps for all of these players, there are good and bad things about all of them.

My bet is on line of business apps that don't appear on app stores at all but get consumed inside businesses to do everyday work.

Designing for a mobile platform is as distinct and must be as purposeful as designing for the cloud. You don't just move code. You don't just swap out your presentation layer. There are considerations made for user experience on such portable but tiny devices. Then there is how you handle data down and uploads across 3G+. There are many restrictions to grasp but these strong guidelines can be used to quickly build for these platforms, if not fought at every turn.

.NET devs again will find the Win8 app leap more of a small step.

Whatever mobile experience you bring with you or gain in the adoption of this kind of programming and design, it will help you in building leaner and friendlier applications.

My posts on getting started with Win8 dev are here.

There will always be legacy apps. Just don't be a legacy software developer.

The F in PFE is for Fisherman

Four and a half months ago, I started at Microsoft as a Developer Premier Field Engineer (PFE). That means a few things and has a bunch of meanings that will emerge over time.

The main thing I do is problem solving for, educating and motivating people who have bought the Microsoft experience and are dealing with it post-sales or even post-implementation.

That's a fancy schmancy way of saying that I work in support.

In Microsoft, there is not a lot of glam around being a PFE. Everyone loves Evangelists. Sales is king of the hill. We kind of sit at the bottom of the hill dodging falling stones. Sometimes, falling monoliths.

Don't get me wrong. We have a great technical depth so we dodge falling stones like ninjas dodge... falling stones. We are much better at our given technical field than metaphors.

There is a lot of satisfaction in what we do. Technical people who love to do technical jobs will understand that. We are not driven by the cheers of the crowd or the mega bucks. That isn't part of a normal day for us.

Working with PFEs around Australia over this brief time has confirmed for me that like me, they get out of bed every morning to solve difficult problems and to teach others to solve them or avoid getting in to them to start with.

Microsoft has its motivators and its merchants. PFE are its fishermen.

A colleague of mine put it best when he said this is what PFEs do...

1. “I went fishing today” – Sometimes when things go bad, we have to go in and fix whatever problem has occurred.
2. “I taught someone to fish today” – This is where we want to be, teaching customers how to effectively operate and troubleshoot Microsoft environments.
3. “Someone showed me the fish they caught today” – These are the best stories, where a customer has resolved a difficult issue on their own using knowledge they’ve gained from PFE.

So far, I like it. I'll certainly be here until the end of the month :)

Preparing for Win8 App Excellence Labs

While running Win8 Application Excellence labs, I have seen developers hit similar situations each time, that take time away from the labs that could be used for more user experience (UX) and technical feedback.

These labs are sponsored by Microsoft Evangelists and executed by Microsoft Premier Field Engineers. We are trained and experienced in what a Windows 8 application built in the New User Interface should look like and behave.

The purpose is to enable developers as they prepare their applications for submission to the Windows Store.

You will hear people say that the labs are there to grant early access via developer tokens but this is not the case. Our primary purpose is to communicate a common understanding of the design guidelines (both technical and user experience) that make up the new Win8 user interface and underlying technology.

Over time, I have built up a list of useful links to help developers get their apps in to shape so they are most of the way there when they hit App Excellence labs or for when they submit to the store themselves.

Here are some links to help devs on their way to a well built and well design Win8 app...

• Win8 Product Guide for Devs
• Learn to build Win8 Apps
• Creating and Deploying App Packages
• Packages and Packaging for the Store
• The Seven Virtues of Modern Applications
• From the guys who built Windows 8
• Going from iPhone to Win8 Design
• Testing Win8 Apps in Visual Studio
• Designing UX for Apps
• WinJS Controls and Styles

Thick Skin and Deep Knowledge

The Internet is a funny place full of contrasting experiences - from friends made in virtual places that one day become great real life moment makers to ugly trolls who fit the bridge dwelling cliche to an uncanny point.

I've been blogging for a while now in many forms. I have an online presence and a persona that is purely my own. In fact, it is so well established that I have met people for the first time who read my writings, and had them tell me that I don't think that but would express it much differently on my blog.

Blogging and technical blogging in particular can be an interesting experience to the new comer. They have read blogs and participated in online forums that are all about being constructive and helpful. Then they hit a world where expressing their opinion or even stating a solid fact is attacked, poked, ridiculed and salted with personal insults.

When that first happened to me, I took it very personally. I wondered why someone would attack me so cruelly and unprovoked. Why a statement that I'd made resonated so deeply in them that they threw acid in my face.

Then I realised that it wasn't about me.

Those who produce content and express a view or share knowledge may go out intending to share what they know and learnt but may not always be received that way. People can disagree with you or you may be incorrect but if the feedback you get is insensitive or purely mean then it says more about the giver than the receiver.

I love feedback. I go out seeking it. I want to know what people I respect and care about think about me. This however is my soap box and if you want to get on it then you must be constructive in some way or go out and start your own blog with a weekly dedicated post to how much you dislike my thinking. I'd link to you :)

If you blog, you must develop thick skin. You must trust in yourself that you are putting out there what you understand and what you believe to be right at the time. You must trust yourself and ignore the haters. You can put just raw facts or express your own opinions. Whatever you choose is fine. Try to add something with each post.

Don't worry too much about those who come up to poke you. Happiness is intrinsic. Kindness is deliberate. Nastiness is a sign of a deep insecurity or self loathing. It isn't your problem.

Stay strong and keep blogging.

Measurement and Sentiment

A good friend of mine and former colleague is working in an environment of legacy applications, with legacy developers who don't want to take part in any development practice change. He is charged with moving all of their pre .NET apps to a later and greater version of Microsoftness. They are encouraged to come along on the journey but are not really interested in changing their ways much at all.

While thinking of advice to give a friend, I came to these conclusions.

The first thing with change is to understand that it is human nature to resist it. The ones that push back are not the freaks, those of us who chase the mutations are. We are the minority but we are the ones who shape the world around us.
That is why buy-in from your team members (the pigs, not the chickens) is extremely important.

Rigorous practices is what makes an agile team. Those practices are determined to work based on two things - measurement and sentiment.

Measurement is the data that proved that a practice applied rigorously achieved a measurable increase in quality or quality or clarity or whatever your sliders are set to.

Sentiment is the buy-in to the practice by the team members. That is devs and BAs and testers and business reps and anyone else involved in using that practice to get the best results. Without buy-in, the practice should be dropped after trying it for one or two iterations.
On a new agile team with people who are feeling consciously incompetent and not believing, you can fail to gain buy-in or lose what little you had.

Without sentiment, measurement is unsustainable. Without measurement, sentiment is unjustifiable.
When I teach engineers or any member of a team a new way of doing something, I explicitly ask for buy-in. If they don't give it then I sit with them and try to understand what the pain point is that they are experiencing. Then I address that concern, beit with understanding or a different practice or explanation or discussion.
Try do this at an individual level if you have relationships already or think the discussion will build rapport or technical respect.
If it is the whole team you need to address then use a retrospective that allows everyone to air what doesn't work in a constructive setting. Self organising teams must decide what is best for them with some guidance but they must choose for themselves. If they choose then they commit as part of the deal.

Often those who suggest the ideas are the outspoken ones and the leaders of the descent anyway. Use them as a force to encourage change.

Presenting at the Premier Field Breifing

Today was a day for Canberra Premier Field Engineers to share their knowledge with an open house, at our second Premier Tech Briefing for this financial year.


My colleagues were out in technical force and dressed like Microsoft ninjas. I got to wear my Swarovski crystal Microsoft shirt which was I admit, a highlight.

Jimmy Fitzsimmons presented on Windows 8 Dynamic Access Control as Steve Moore, the Lync genie spoke in an opposing room.

Imtiaz Khan then gave a SCCM 2012 Tech Overview, while Grant Holliday and I did a joint session on Agile Development with Visual Studio and Team Foundation Server 2012.

There were wild cheers; huge amounts of delicious food; virtual graffiti of another engineer's face as a demo; and a free autographed book from our local published TFS guru.

We had a fantastic turn out with attendees from 25 organisations from across Canberra.

The immediate feedback has been very positive.

Next time, we will have a full dev stream. Stay tuned.

A Lifetime of Events

Last week, I sat with a developer in an effort to solve an issue with broken Suspend-Resume handlers in Metro. The developer told me that he was getting inconsistent behaviour with his Suspend handlers and that he suspected a bug in the Metro framework.

When I got him to repro the bug, showing me how the error was caused and what the resulting output was, I found that he was not suspending and resuming but instead, suspending and on-launching.

He was exiting the application.

Metro triggers the suspend handler at that point. Suspend handlers run when you exit the application. Exit can be either suspending and leaving for a bit or quitting the application forever.

Now, one thing you should know about the Suspend handler is that it is paired with the Resume handler. If you can not see the Resume handler being called subsequently, after you add code to the Suspend handler then you are putting it in the wrong place.

The developer I was helping was putting his code in the wrong place. He was assuming that if he told Application.Current to persist something then it was so for as long as he waited to relaunch the application. He was wrong.

Web developers don't seem to hit this learning point but desktop developers do. It happens because they don't live inside life cycles. They have never been forced to understand that objects have lifetimes and you have to interact within the rules of that world.

When this developer called the Suspend handler and traced the persistance back to a file that stored the serialised version of his data, he assumed that it would be there when he started the app again.

That is an incorrect assumption.

Application lifetime lasts for the a the amount of time that the application is current. That means that when you launch it and when you exit it, the application is live. Outside of those boundaries, Metro does not guarantee anything. Files persisted to storage by the Application object are not always there and not always called the same thing. If it goes to disk, it could just as well go to memory and it is then just as fleeting.

There are matching pairs when it comes to exit-entrance handlers. With Suspend, you can count on Resume. With Exit, you can count on Launch.

Don't assume anything will be consistent, outside of the lifetime that your event belongs to.

If you want to ensure data or state persist then you must explicitly handle that persistence when it does not obey Application lifetime.

Metro Design Anti-Patterns

Metro app development is young compared to other environments.

It is not a browser app.
It is not a Windows desktop app.
It is not an iPhone or Android app.

Although it isn't one of those well-known environments, it is built on two solid presentation layers. XAML from Silverlight fame and HTML+CSS+Javascript from well, everything-that-is-useful-on-the-Internet fame.

The technology space underlying Metro is not hard to adopt. It's the world from a Silverlight or web perspective with design constraints.

I have reviewed around 30 Metro apps in the last month and I keep hitting the same learning hurdles from the early adopting developers.

To start, developers that are early adopters are quite fearless. They march in, sometimes as canon fodder and sometimes as knights leading a rush. With this comes an exaggeration of all the things that could happen. An amplification of the mistakes and an enlightenment of the amazing successes.

Here are the patterns that I have seen so far in Metro application development and what you should think about when you build apps in this brave new world. This also applies to mobile devices in general.

Obey the Rules

Stay within the bounds of your framework and design constraints. If you have to exert enormous amounts of effort to achieve something that you think should be available then you might be doing it wrong. The guide lines are there to ease your progression, not counter it.

Some developers have a tendency to solve the same problem with every solution. They change languages but still write code that looks like their default language. They construct interfaces (programmatic of visual) that satisfied a past problem domain but don't satisfy the current one.

If you are going to change then change. If you don't want to leave what you know then stay with it. Concepts and constructs can be taken with you. Concrete implementations can not.

Metro is a new presentation layer but its strong guidelines are walls that don't entrap you but instead hold you up.

Don't Isolate Yourself

In a world where there is one dominant thing on their screen, users do not want to be locked in to that one thing. A feeling of isolation within an application is a major reason that users dump your app.

Often a screen shot is the only way to share out information from a mobile based app and there is often no real way to bring data in to the application.

Metro has the idea of Share Contracts. You can implements different interfaces quite simply that let others treat your app as a Share Target that can pull data in to your app or as a Share Source that lets you push data out of your app.

You can provide a multitasking operating system but without enabling easy sharing, you might as well promote isolation.

Move in one direction

Working with phone apps really restricts the dimensions in which you let your users scroll. Often returning to the larger real estate of a tablet makes people lazy or 'laxed or carefree because they forget the rules of touch and fall in to their old desktop ways.

Think about how you use a touch screen or watch a child and you will observe flick motions and movement in one dimension. Introduce another dimension and watch the confusion.

Google considers a link unvisited if you follow it and then click the back button and then click the next search result. Navigation is bad if a user moves in a direction and then moves back quickly because they didn't mean it.

Consider all of this when you build mobile apps.

Metro won't stop you from using multi-dimensional scrolling but the design principals discourage it.

If content is your primary navigation mechanism then don't distract from your content and purpose with confusion due to scrolling.



Let the guidance guide you.

Windows 8 and Metro Development

Before we go any further... oh wait, let's start first. So before we start, let's get one thing clear:

Windows 8 and Metro are not one in the same thing. Windows 8 is an operating system. Metro is a tablet focused environment that runs on top on Windows 8.

When we talk about Metro development, we are talking about a set of design principles that are primarily focused on tablet and ARM devices and the powerful set of development tools that .NET now offers.

In the same way that iOS dictates that you will live inside it's pome ecosystem, Metro is guiding its developers through tools, libraries and UX guidance how to easily produce an application that is friendly to the touch world and still plays well with mouse and keyboard.

One thing I love about iDevelopment is that Apple has pulled the level of developers up again in to a world where you can wield the power of your respectable language with the aid of the brilliant Cocoa framework.

Metro is offering you the same thing but with the benefits of living in the Microsoft universe with access to a pool of technology, consumers and a development framework that is proven in all environments from the enterprise world to small teeny systems.

For developers, there is so much noise around Metro that it's hard to know where to start.

Start here...

Metro dev == (all things .NET) + WinRT + WinJS

Do not be overwhelmed. It's easier than walking in to a new language; going from desktop to web development; or learning graphic design skills. There are simple starting points that allow an attainable entry point.

Download Windows 8 Release Preview (Win8 RP) and Visual Studio 2012 Release Candidate (VS2012 RC) and choose any first class .NET language.

Create a default project and then make changes to it and see how simple it is to start and produce a good looking, easy to use and robust application.

After running Microsoft Metro App Excellence Labs for over 2 dozen applications, I can only say that the less you fight the world presented to you by Visual Studio and the easy-to-interpret design principals, the better your app will be. As with all new interactive experiences, you may try to make it act like something you know better but it actually works better to let it be itself.

This is an echo of the advice I gave about writing iOS apps. Work with your environment. Learn what it does well and use it. Reinventing the wheel is self-validation for hackers.

Go forth and Metroply!

Premier Tech Briefing 2012

Premier Tech Briefing 2012 – Friday 15th June

Come and join us for the Mid-Year Premier Tech Briefing 2012. Learn from the best as Microsoft Premier Field Engineer’s (PFE) show you their tips and tricks learnt from the field.

Arrival/Registration and Breakfast – 08:00am to 09:00am

Please arrive at the venue with enough time for registration.

Session 1 – 09:00am to 10:30am

Option 1 - Windows 8 Dynamic Access Control

Presented by a Microsoft Premier Field Engineer. A first look into Windows 8 Dynamic Access Control – Everything you thought you knew about securing a file system is about to change!

Option 2 – Deploying Lync 2010!

Presented by a Microsoft Premier Field Engineer. A deep dive into how to get the most out of a Lync 2010 deployment.

Session 2 – 10:40am to 12:10pm

Option 1 – SCCM 2012 – Introduction to SCCM 2012

Presented by a Microsoft Premier Field Engineer (PFE) A deep dive into the new features of SCCM 2012 – All your questions answered!

Option 2 - Agile Development with Visual Studio and Team Foundation Server 11

Presented by a Microsoft Premier Field Engineer. We will take a ride through an example project and show you how an agile team can efficiently prioritise, plan, and deliver high quality software. We will also take a look at the valuable set of new features and capabilities that Visual Studio 11 and Team Foundation Server 11 bring to agile teams.


Venue: Microsoft Canberra - Level 2, 44 Sydney Avenue, Barton

Registration

To register, please emails damadden@microsoft.com

For any questions please contact me. I hope to see you there!

A Specialising Generalist

Firstly, what is a generalist? The dictionary says: "A person competent in several different fields or activities."

I've called myself many things in my career, from polyglot to geek diva but one thing I know I have always been is a generalist.

Don't get me wrong, I know many things well and with great depth and understanding but there is not one thing that holds my attention over all other... ooooh, sparkly lights!

My talent is the ability to learn very fast and articulate and implement concepts in any technology.The good developers that I know are very much the same. They understand concepts and ideas and learn fast by putting those building blocks together.

Of course, there are those who can recite APIs to you. There are those who champion their language over all other lesser languages. There are the ones that dive in to every new shiny technical topic with vigour and a dizzying sense of intoxication. I say... to each, their own.

My job is an interesting one. A Premier Field Engineer (PFE) possesses amazing depth of knowledge in an area. They are the go-to girl for Item X. It is impressive.

What I've realised is that the developer space is massive and as a Developer PFE, I'm expected to know something very well. That worried me earlier this week as I sat and wondered what I knew really well.Then I stopped.

I am great at being a developer. Any language. Any concept. Any layer of detail or abstraction, I can understand with little effort. I've built big things and small things. I have watched the software development world mature from cranky tots to pimply teens to a kinda cute 20 something and now a talented 30ish year old.

I'm not supposed to learn a single product. I am supposed to keep being able to build great software. From inception to deployment and on to extension and deprecation.My specialisation is knowing what to build and how to build it, the right way. I see pain points and know instantly how to treat them. I make processes leaner and developers more rigorous and thorough in their craft.

So, the generalist stops and realises that she hasn't wasted her time learning a lot of things about a lot of things. She is more than just competent. She is agile and has aptitude and attitude.

I have specialised. I just didn't realise it because I hadn't attached myself to a trademarked tool.

.NET Versions

I've been setting up a new machine to do a code review of 1.3 million lines of code. I had installed every version of Visual Studio available to woman and hit a point where I had to know what version of .NET that I had.

I have the memory of a goldfish (ooh, a castle) so I Bing'd the command I needed to run in my Visual Studio command console and found that people wanted me to run regedit and check a key somewhere in some place over some rainbow.

No! Stop now!

Just run the Visual Studio command prompt and type: clrver

That gives you all versions of the CLR running on your machine.

If you have to go to regedit, assume something is wrong. It is an anti-pattern.

Think Pink

I have been working at Microsoft for a month now. People talk about starting here and taking it all in as "drinking from the fire hose" and at first I laughed but now I know it is the case. There is nothing as overwhelming as starting a job at Microsoft. It is also overwhelmingly enjoyable.

One thing that made me take the job was this amazing female manager who interviewed me. She was inspiring and had presence, from the second she entered the room.
I never believe that an interview is about them. Do not think that the people interviewing you are there to choose you. You have to choose them back.

Being interviewed by a woman, in a company who has a woman running their Australian arm and had that before, counted a lot towards my positive view of this  company. My friend who recommended me is a female evangelist. My male friends who work there have supported me through my career.

It is true that I didn't post on International Women's Day so I'll make today my IWD. As I sit here blogging today, knowing that so  many women helped me get to where I am.

Thank you, girls. Thank you.

A Babbling Brook

Ask every single person who I have ever worked with, for, lead, mentored or just hung out with and ranted. They will tell you that I believe that I can get anything out of anyone I work with, regardless of IQ or EQ.

Great engineers are built from a high level of aptitude and attitude. Intelligence is good but it is not all there is to making someone a productive member of a team.

Great engineers are taught by other great engineers. For all your were given, you must return.

I sit at lunch with a good friend called Bruce who I worked with in my first job and then again years later, I hired him. He is a brilliant engineer. To work with him is to learn. To talk to him is to learn.

We are both old now. We talk about reason and rigour and the state of our profession. Each time, he talks of a lack of willingness to fight anymore and I say I can't stop now because we are here to pull people up by their ears if they will not rise themselves. I understand his position and he, mine.

There is a developer I work with who is so under par that I make a special effort each day to bring some rigour and professionalism to his skill set. Each day, I put the effort in to him that others won't because they are too tired or just can't see value in him.

Yesterday, I reached a point. A point where his restrictive arrogance was just too much. He can not see that he does not know so he can not see that he has room to grow and learn.

I rant about humility. I speak of rigour and our craft. What we do is part who we are and part what we are open to learn from those around us. Be they young or old; male of female; short or tall; in our skill set or just beside it; or better or worse than us.

Until you can admit you are wrong, you don't have the chance of learning how to be right.

Like Bruce, I'm too tired to try with this one anymore. He is too damaging to be around and I give up for the first time, like everyone else around him has.

I formally apologise to my profession. I wish I could have made a difference.

Idealism based in nothing

A young man at work today told me that anyone who knows how to work within the corporate world to achieve goals and actually thrives is corrupt and has sold out all their ideals.

That is the view of someone who only understands one way to work within a system. They think that the only way they could achieve anything is to break the rules and then extrapolate to believing that anyone who achieves in that world is corrupt.

There are many ways to thrive in a complex social culture without selling out. Being aware there is a system and understanding how it works is the start.

People with a limited view of different systems apply their understanding to a situation, in the same way that a 3 year old will explain politics to you. All within their realm of understanding.

Hopefully, time will teach him that those people who he thought sold out were playing the game and maintaining their integrity. They kept their souls and still had reflections in a mirror.

Be careful not to limit your world by judging too early with only limited knowledge formed at a glance and a distance. There is often elegance found in complexity.