Skip to main content

Year Review 2013 - Merry Christmas and Happy New Year!

I was reading my good friend Helen Meeks blog on her end of year review, and thought I'd do something similar...

It's been a long year, but an exciting and definitely positive one for me on both a professional and a personal front. As I write this I have been up for 2 hours with a crying baby, but strangely I still see her as a positive!

I'll start with the professional positives, as that's what people come here for, to hear about my views on my profession, I'm not sure they're so interested to hear how many nappies I changed at the weekend etc...

The biggest positive for me has to be my promotion to QA Lead, I've been striving for this promotion for a long time, and to finally get it was extremely exciting for me. It meant that I can influence people more and effect how they work and to try and make them work better and more effectively. It also means I get to work with more technologies and more teams, which I've wanted to do for a long time.

There's also a positive in that I've started this blog, I started in April, and whilst the posts have slowed down a bit, I think that was only a natural thing as I couldn't sustain posting topics once every 2 days, which I had done at the start, especially when you consider the fact that I'm a lot more busy now with the promotion and personal life. I like to think that I've changed how some people think, or even just made them think twice about something, and if people enjoy reading what I write then all the better.

There was also a trip to India, which I enjoyed massively, so much so that it has completely changed my view on how work can be outsourced effectively. The work that they are producing is comparable to the work some teams onshore are doing, and in some cases possibly even better. It was an amazing experience, albeit a brief one, hopefully in the next year I will get to go for a bit longer.

Finally, professionally I met a number of people who have helped shaped my career over the past year and helped me believe I can be whatever I want to be. I think they know who they are, so I won't bother naming and shaming them. They all believed in me and pushed me to better myself. So thanks to them for that. I wouldn't be where I am today without them.

On a personal level, obviously the birth of my daughter Jessica Rose is a massive positive, although it doesn't always seem like it, especially when she keeps me up half the night, she's definitely a driving force in everything that I do, and I love her dearly. On a similar note, I am watching my son grow up into an adorable toddler, he's not a baby no more, but then he hasn't been for a while!

One slight negative for me could have possibly been my attitude at the start of the year, looking back now it was wrong but the main driving force was wanting to better myself, but my attitude suffered at work, and I wasn't really enjoying it. Luckily I managed to get a secondment to work on automation, which I really enjoyed and helped in getting me my promotion.

So, there's definitely been more positives than negatives, and there are undoubtedly still a number of challenges ahead in 2014. Hopefully come my end of year review next year, there'll be more positives than negatives again!

Merry Christmas and a Happy New Year everyone!


Comments

Post a Comment

Popular posts from this blog

What is a PBI?

After my last post, I had the question of what is a PBI... so I thought i'd write a short blog post about what they are and why they are used.

A PBI is an acronym for Product Backlog Item. It is a description of a piece of work that your SCRUM team will develop and deliver. When you have a list of Product Backlog Items, you then refer to that collective list as a Product Backlog.

The product backlog is often prioritised and yourteam will work through each PBI, and release on a regular schedule... I am however going deep into the world of Agile development, which isn't entirely what this post is about, so I will stop myself now.

A Product Backlog Item is made up of the following:

Title - This is often a one liner that gives the team an idea of what the PBI is about, although it can just be an ID for the item and the team work off of that.

Description - Breaks down the PBI in a bit more detail, and can be written in any style, however I prefer it to be written as follows: 



By writin…

Dealing with Selenium WebDriver Driver.Quit crashes (Where chromedriver.exe is left open)

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds.

We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit.

[AfterTestRun]
        public static void AfterTestRun()
        {
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))
            {
                CleanUpProcessByInheritance();
            }
       }

        private s…

Famous Movie Quotes applied to Software Engineering - Jaws

You're gonna need a bigger boat? How can that relate to Engineering?

Firstly, let me ashamedly admit, that I've never seen the whole of Jaws all the way through. It's on my list of films to watch, but whether I get round to it, is another matter!



Anyway, to apply this to engineering, it's almost like "you're gonna need more testers/developers"...

We hear this all too often when trying to push releases out the door, let's throw men at it... However, as we all know, a bigger boat/more men... isn't always the answer, it's not a guarantee of quality, or even a guarantee of getting things done quicker.

If you have a task that will take 2 hours, simply having 2 people work on it doesn't mean that it is halved, in fact often, the time taken to do the task remains at 2 hours, but the maintainability and the knowledge around that area is increased, so it's a price, in my opinion that is often worth paying.