Adventures of a wannabe geek!

Ranting within

Looking for a New Role

EDIT: I am no longer looking for a new role. Thanks to all for the suggestions

TL;DR: I am looking for a new role. I am an infrastructure developer who has a passion for metrics, monitoring and alerting. If you feel that you are interested in me coming to help your engineering team, then get in contact with me

I love working on infrastructure!

Over the past few years, I have helped transform a team who worked solely in the manual sysadmin space into the configuration management world. This has reduced the time taken to provision a server and get an application into production from a number of weeks, to a number of hours.

Metrics are a key part of my day to day work. I believe that if we don't measure it then we cannot improve on it and learn from it. I also love to know what is happening with my systems before getting a call from an end user telling me there is a problem.

I have a real drive to make the lives of the engineer teams I work with easier. This means that by helping to create better infrastructure practices, I am helping them and ultimately helping deliver more business value

What type of company would I work for?

I have learned over the past few years that being part of a good company is the key to a happy work life. Culture, to me, is absolutely everything. I deeply care about what I do and I really want to be part of a company that holds these same values.

Remote work is something I am interested in, as long as the company is set up for it. I worked remotely a lot in 2014 and found it to be hugely productive as well as beneficial for my previous company because it allowed me to interact to a greater scale with the wider engineer community learning and sharing best practices to keep at the forefront of the industry. I therefore don’t mind where in the world a company is based, but that company must value treating remote employees as importantly as those who are office based

What about the role?

I want to be part of a team that care about the systems they create. Working on challenging problems brings out the absolute best in me, and being successful in this means the team I belong to is hugely important because every single person has a role to play in finding and implementing solutions. Working with a team of engineers who always want to improve themselves, their work, and support their colleagues, is what drives me and helps create a supportive team dynamic. Therefore I want to work with engineers who have a good work/life balance and love what they do as much as I do.

What I definitely don't want to do

I don't want to be a ticket filler. I want to be involved in helping to shape infrastructure systems and helping to drive decisions going forward. In my opinion, automation is key to helping deliver great systems and I really want to be part of delivering those systems

So hire me!

If your company is looking for passionate infrastructure developers who always want to improve or If your company has a need (and the willingness) to drive their infrastructure forward and improve then I could be the right person for you.

IT Recruitment Is F**ked

We get inundated with job specs in our inbox. Each email is filled with buzzwords in order to try and entice us to take the new role. I have not, nor will not, take a job spec filled with buzzwords. I join a company because of a culture. Having recently read Simon Sinek's book, Start With Why, I really started to see how recruitment in IT is ~~f**ked~~ broken. The book talks about manipulations in modern society. This sounds bad and that it's not something we are used to. It's something we are very used to. We see it everyday. Supermarkets offering 'buy 1 get 1 free' on products. Car companies offering us '£500 cashback' when buying a new car. This is all manipulation to get us to buy things. How many of us have bought a second item at the supermarket as it is buy 1 get 1 half price?

IT recruitment also has a lot of manipulation in it. In the past, I applied for a job by giving my details to a recruiter. I have turned up for that specific interview to find I was interviewing for a job I didn't know about. A job I had no experience for. My CV had been changed to fit the spec the company had asked for. The recruiter was manipulating the company to get someone in the door. These types of things happen every day. I get emails in my inbox offering me 'John Smith' at £250 a day. I am not a recruitment manager and I have never spoken to these companies. They are effectively fishing. Would you be happy knowing you are being used as a carrott for a recruitment company to get into a company?

It is because of this that I have a mistrust in most recruiters. Not all are bad. It feels as thought they manipulate us (companies) into working with them. I understand they are just trying to do their job. I just try not to use them. I would rather hire someone based on a referral from someone else. But even that can have manipulations to it though. How many of you get a referral bonus for bringing someone to your company? Are we doing it for the right reasons? I like to think I am and not for money

Consider the following, fake, job spec:

Job Description:
Do you have strong experience in X and Y technologies? Are you interested in joining a strong team who do A, B and C?

Skills & Requirements:
* 5 years experience in X
* Deep understanding of Agile
* 3 years experience in a technology only released this year
* Buzzword 1
* Buzzword 2
* etc.

If interested, then please contact,

This doesn't interest me in the slightest. I have no feel about what type of work I'd be doing or who I'd be working with. It stipulates the technologies I'd be using to try and eliminate people up front.It doesn't tell me anything about the company or what they are trying to achieve. This type of advert is never going to entice me to join this company. I mentioned above that I would only join companies now because of culture. Culture is very important to me. I need to be working with smart people who challenge me or I get bored. I don't want to be bored.

In the book Start With Why, Simon Sinek continually reiterates 'people don't buy what you do, they buy why you do it'. The example advert, above, would be from a company who can't sell why they do something. Maybe there don't understand it themselves. Not many companies can sell their 'Why'. A few companies I know can do this are Etsy, Tretton37 and Github. The structure of a job spec from Etsy starts as follows:

We build tools that enable our engineering team to safely deploy code to the Etsy website. These include the Continuous Integration (CI) system, xUnit frameworks, and functional testing suites. Everyone in the Product and Engineering teams can deploy code into production, on their own. We do this over 30 times every day. Release management is a role in which everyone on the team plays an active part, starting on their first day of work

Straight away, before I read more than 1 paragraph, I understand what the values of their engineering team is. They then go on to talk about the team:

The technical staff at Etsy believes that code is craft, good software and systems designs are works of art, and that the work we do is part of larger creative culture represented by the hundreds of thousands of inspired makers who make Etsy such a wondrous marketplace

This helps solidify the culture they are telling me about and the engineers they hire to make this happen. They go on to say the following:

Our current systems run PHP, Java, Python, Ruby, Solr/Lucene, Postgres, MySQL, and more.

I could go on with the advert. It summed up the perfect job advertisement for me. This is the type of advert that would really get me interested in a job. I would join them for that culture. It isn't a job spec, it is an introduction to life at Etsy.

Are skills / technologies the most important thing to me when I hire someone? I used to think so. But now, it really isn't. If someone doesnt have passion or buy into the same values my company does then all the skills in the world may not help me fit in and work well. Skills can be taught. Communications, culture and passion can't (in my opinion).

It is important to say that not 100% of blame sits with recruiters. Companies, themselves, need to be much better towards their employees. After reading Remote, the 37 signals book, I really started to see how somethings are being missed by companies themselves. Remote working is definitely 1 of them. I was never a fan of remote working. I would not want a remote worker in my team, until I started travelling a lot for work. Being remote from my team has really get better at communication and focus. I often will go to a conference and work remotely now. I am actually quite productive. I am writing this blog post on an 11 hour flight :).

To me, I don't think we, as compnaies, should care where you are based. We should allow our team members to work where they are most productive - if that happens to be in their home in the Swiss Alps then so be it. I understand there are legal hurdles when hiring remote workers. These are not insurmountable. It's important to say that companies like Github and Etsy have staff all over the world. American companies with staff in UK, Australia, New Zealand etc. Nothing is impossible.

Staff benefits are another piece of the puzzle required to help recruit people. Too many job specs say things like 'subsidised gym membership' or 'healthcare' included. What if I have my own gym membership or my own private healtcare? Can't I choose something else to help me during my time at that company? Again, the Remote book helped me to see that this is important. At 37 signals, staff are offered a family holiday or cooking school experience etc. This becomes part of their benefits package. That is much more useful to someone who has healthcare and gym membership already. It also helps the employee feel really valued

Everything I write about here is the result of creating a good culture and a sense of understanding of Why we do things rather than what we do. Culture is a tough thing to breed but when you do get there it seems as though it's really worth it. We need to keep hiring people to vreed that culture, people who buy into it. It's 2014, we should be better at hiring people. There are a lot of skilled people out there - it's time to tap into that resource pool. It can help you create truly special products. Look to companies like Etsy, Github, Netflix, Puppetlabs etc. for inspiration on what we can do better in this space.


Can We Fully Trust Online Training Courses?

NOTICE: This post is not written to pick on any specific person or service. This is only my thoughts from speaking to people in the past few weeks

The online training industry seems to be a lucrative thing. I have heard rumours (unconfirmed! ) of authors earning 6 or 7 figure sums from training courses they have made and delivered. While part of me thinks, "I really want a part of that", the other part of me thinks that I don't have the level of expertise to do it.

I (used to) blog a lot. I speak at a lot of conferences. I have even been known to ramble on a podcast or a screencast. In my opinion, I suggest others get involved in doing things like this. It creates a culture of sharing and exchanging information. I don't earn money for these activities. I feel like I can talk about what I am passionate about. I also feel as though I can talk about new things.

I also run training courses on continuous integration and delivery. I am paid for these. Since I am paid for these, I feel that the level of information I put into these courses needs to create value for the attendees. In order to deliver information that is useful, I really need to understand my subject matter. By no means do I consider myself an expert in continuous integration or continuous delivery. I do feel as though I have enough experience building these systems that I can pass my learnings off to other users.

The courses that I run are very much face to face. I listen to the attendees to see what they want to achieve and I tailor the content to give them that information. Online training courses do not do this, in my opinion. I have considered trying to record some material but I don't know if the information would be of use. My pet hate is when people record training material on subjects that they know very little about or have little understanding about.

I have seen places where individual people record lots and lots of courses. Of course, they get paid to do this. To me, this feels wrong. What gives those authors the right to disseminate information on a topic that they don't have a deep understanding of? The information they give may not be accurate - does the user get their money back if they watch a video on API design, follow it and causes a production outage?

Is the issue with the authors themselves or the training companies?

The same issue happens with books. I reviewed a lot of books in 2013. A lot of the books were excellent. Some of them were not very good at all. Book publishers are spamming potential authors trying to get them to write. This is a source of income for them (albet it low). But it's extra income all the same.

In my opinion, publishers have a contract with people who use their services. Get the best possible trainers for the subject. Don't put metrics above the level of service you give to your customers. Good training makes us all better at what we do. It's important we don't give developers / operations / managers a false understanding of topics. It can cause issues in a team and it can cause issues in our systems. I'm not looking to name and shame people / companies here but I do expect a good level of service if I pay for something


I just learned that Hadi Hariri wrote a post on the Journey of Teaching.

Thanks to thefringeninja for making sure this wasn't too ranty :)

Changing My Focus

For those that know me, you know that I am very passionate about infrastructure and DevOps. Infrastructure is something that we, as developers, don't really give a lot of thought to. DevOps is something that will make our businesses more successful. So, I am changing the job role that I have.

From now, I am no longer focusing on writing application code. Instead I am going to spend my time focusing on the following areas:

  • Be the facilitator to help our engineering team be much better by creating a DevOps culture
  • Writing code to control our infrastructure
  • Learning about the weird and wonderful ways of operations

DevOps is very important to me. When a company has a great culture, things get done. Operations work is smooth, software delivery is smooth and the teams are truly focused on achieving the goals of the business. Without a DevOps culture, things are not as smooth as they could be. In order to allow our developers to more faster, we will be building better systems (e.g. provisioning, configuration management, monitoring, logging etc.) to allow them to really achieve 'situational awareness'

I heard the term 'situational awareness' just over a year ago. It was defined as 'knowing what is going on around you'. Putting this into context, do you know what is going on with your applications in production? I certainly didn't. This is essential to understand how your software is performing. I will be trying to help our engineers to try and solve this issue by helping them build better infrastructure management systems.

Operations is something that I know very little about. By exposing myself to this world, I feel it will help me understand the continual frustrations that operations and development staff have towards each other.

As you can see, I am truly trying to be a DevOps advocate. I want to be the person that helps the teams talk to each other and help each other rather than (traditionally) having silos. I will still be trying to talk at developer events / conferences. I feel that I can really help developers understand more about DevOps and how it can be successful.

This is a very exciting change for me! Let's see how it goes….

Why Delay the VS2012 Release, Microsoft?

The date is 1st August 2012. Developers have been wondering for weeks when the release of VS2012 and ASP.NET 4.5 will happen. Somasegar, cvp of dev div in Microsoft, has just announced that the final build version of VS2012 is complete.This means the product is ready for release. Dot net developers all over the world are eagerly waiting for the immortal words, “it’s available to download on MSDN”. Unfortunately they haven’t come. Instead, the download will not show up for another 14 days. This seems wasteful to me.

Tell me if I am incorrect, but I believe the delay is that the product has gone to tool vendors to make sure that their tools / plugins will work with the application. This to me seems a very strange thing to do. This product has technically been in the making for 18 months (since the release of VS2010) so giving it to vendors in the final 2 weeks is crazy. What will happen if the vendors report it doesn’t work with their tools? Would Microsoft stop a release for this considering it is so baked into the windows 8 release? I don’t think there is any possibility of that happening at all. Therefore why the delay? I understand that 3rd party vendors are customers that Microsoft have to satisfy, but technically so are we – the users of the product.

My ethos on software delivery is ship early, ship often. I hate when a feature is complete that it has to wait around for 2 weeks before release. Get the product out there, start gathering feedback and get planning to deliver more value to that customer. I understand that VS2012 is not easy to release often. Its a rather large download and there are pricing models around it. But changing the shape of the product to delivery in small chunks that are updatable more often would allow the product to get shaped by its user base. Faster feedback means delivering more customer value. It seems that other departments within Microsoft are now following this model (MVC team, EF team and Nuget team). Delivering like this is becoming more popular (and hopefully will become the standard). Its time to embrace this ethos Microsoft. Its certainly how I would be looking at things in the future if I were the product lead developer.


Survival of the Fittest – Fluid Teams?

In traditional, waterfall organisations, a development team follows the organisation hierarchy. The development team can be split into smaller sub teams and each of those teams can have their own leader, but ultimately the hierarchy still exists. Developers usually stay in that sub team for most of their time in the organisation and they know exactly who their line manger is and who is responsible for their reviews and can act accordingly. The organisational structure is rigid and embedded into the process of the team and organisation.

In more agile teams, the organisational structure is less rigid meaning that developers do not need to stay in a single sub team for their time at the company. They can be organised (or organise themselves in more advanced agile cultures) into teams based on skills. New developers are hired with a view to how they can benefit the wider team and not towards the skills needed for a sub team in a waterfall environment. Even though there are less restrictions on people moving between teams, it is not always guaranteed. It can happen when required, e.g. when a new member of staff is hired and the skillsets need to be spread evenly. This can evolve further.

Can agile teams be formed around projects?

Simply, yes. This is actually how projects work at Facebook. When a developer joins the company, they can request what team they want to join when their ‘boot camp’ is over. Each developer has a desk and that desk is on wheels. Their office is completely open plan. When a team’s project is finished, the developers simply break up as a unit and wheel their desks to form the next team for the next project.

I’ve talked to a few people about this fluid team structure. All responses seem to follow the questions:

  • If a developer continually moves around, who is the manager responsible for the developers review?

At school, I was part of a form group and I had a form tutor. This was the class I was part of each morning between 0900 and 0910 and where registration would be taken. I didn’t study all my subjects with that class or that tutor. Each teacher had their own area of expertise. I moved around when I needed to go to a class. The same can happen in the workplace. In an agile team there should not be any need to micromanage members of the team. Just because you don’t sit beside your line manager doesn’t mean they cannot manage you. They need to form a trusting and communicative relationship with each other – characteristics of an agile team. This will allow the manager to know exactly how the developer is progressing and any obstacles in their way.

  • What happens if a project ends up with all the weakest developers in a development department?

If you are happy to hire weak developers then I suggest a look at your hiring process may be a useful thing to do. If a developer is not hired because they have the correct attitude, skillset and cultural fit for your team or you are happy to hire the ‘best of a bad bunch’  then you may have bigger issues than worrying about the formation of sub teams.

To summarise, you don’t need to keep developers locked to a team or a line manager. A trusting and communicative environment should always allow the team to focus on what they were hired for, the delivery of software. After all, if you are not here to care about the quality and standard of your work, then you should really think about changing career and stop wasting your employers money.


TFS and Continuous Deployment

I am a huge advocate of continuous integration and continuous delivery. I am always cautious about mentioning continuous deployment in my talks. This can, I stress the word can, be dangerous. For me there is a journey in the delivery of software.

  • Companies, traditionally, started slow and go with manual deployments infrequently
  • Continuous Integration was introduced to the team when the team grew and needed to help test the integration of their code
  • The need to deploy more frequently may arise and as manual deployments are time consuming and (or) painful, deployments become automated
  • Continuous delivery was then said to be the better way to develop software (this meaning that code in the master repo is always in a state where it can be released to the end user)

This journey not only required a development teams skillset to grow to support it, but it also required a culture and attitude change as we move through the lifecycle. Developers need to start taking more care in their work and making sure that technical debt is not accrued too fast and that work is tested thoroughly. For me, when a team reaches this maturity point, they have reached the pinnacle of software delivery. The time required to release a new feature (cycle time) is determined by how fast the developer can develop and test the feature rather than worrying about release cycles. A release for this individual can be created and scheduled as appropriate to the needs of the business. The process is almost completely automated.

Lets take the step to continuous deployment. This is where every successful build is released to the end user. For me, things start to get a bit scary here. Continuous deployment is associated with start-ups. Companies that are releasing a new product and need to get it to market fast to get revenue and user feedback. As the codebase is young, it would has accrued less technical debt so the cycle time would potentially be faster than companies with legacy code. I believe that continuous deployment needs to be surrounded by rigorous automated testing (unit, integration, acceptance, system, performance etc..) and also supported by an immune system that helps to notify everyone if key performance or conversion metrics etc. drop below certain thresholds. This would help the confidence in the code being released to be as high as possible. In this type of environment, developers should work with the operations staff to make sure that deployments happen and follow up if there are issues with the release. I cannot stress enough that continuous deployment should not be taken lightly. It *will* come back and bit you on the ass if you are not well prepared.

Imagine my surprise when I read on twitter during the (azure announcement name hashtag) that the new version of TFS will support continuously deploying applications to the new azure portal [THIS NEEDS CHECKED FOR ACCURACY]. Firstly, I was surprised that this feature was added to TFS over something more useful, e.g. DVCS style version control. The lack of the good version control is a major downfall in TFS for me. Secondly, I think that this new feature will inspire a new breed of false bravery. I understand that it is very good to be brave. Nothing is braver than finishing development fast and pushing straight to production. There needs to be a process around these deployments – are they dark deployments, canary releases, have A/B testing etc.? Have you got the performance test analysis incase your feature causes an issue in production that costs the company money. Have you got monitoring around the system to spot potential issues early. There are many things I have set up around my continuous deployment sites.I don’t believe that all software developers give enough thought to what they are doing and will fix it later. Continuous deployment may not be good for these types of developer. A small issue unnoticed, e.g. a missing ‘checkout’ button on the site, can cause the company a lot of money.

I am by no way trying to say my setup is better than other developer setups, I am merely pointing out that a good support network around a deployment is needed. Maybe azure has this good support network but a developer should definitely know how to use it if they are to take advantage of this feature. If you are working on a personal project that doesn’t affect too much then continuously deploy until your heart is content. If wanting to take the giant leap to this in a company with legacy code then think twice. don’t f**k with your users. They potentially pay your salary. I think TFS should focus on making the tool easier to use for developers rather than worry about continuous deployment just yet


What Is Your Interpretation of Burnout?

I always had the idea that the term ‘burnout’ had a pretty standard meaning in software development. I’m sure each developer have their own way of phrasing it but in essence, I was always of the idea that it meant ‘over working leading to exhaustion and lack of motivation’.

I wanted to see what the exact thoughts of my peers was so asked on twitter “what does burnout meant to you?”. I got a list of varied responses:

@tomasmcguinness: Burnout in terms of software development? For me, it means losing the ability to concentrate and focus,combined with mental fatigue

@mbrit: For me, it’s about ending up at a dead end in terms of stimulation/career progress.

@kristofclaes: “I should have kept this as a hobby…” or something like that. Not sure how to put it into words.

@jcmm33: whatever the cause, its a lack of focus/motivation/drive/engagement within an employee when there used to be

@NathanGloyn: burnout = not able to work any more, nervous breakdown, catastrophic event

These are only a few of the responses, but as you can see the vary a lot. The reason I asked this question is that whilst on a trip to San Francisco recently, I was able to catch a company organised talk from Jay Parikh, the VP of Infrastructure at Facebook. I don’t need to tell you who Facebook are therefore you can imagine I was very interested to hear his thoughts on the subject. Whilst talking to us, Jay spoke about Facebook hack-a-thons. Basically their entire team (product owners, devs, IT guys etc.) get together on a night of the week in the Facebook campus and work on something they don’t normally work on.

One of our developers asked the question, “how do your devs avoid burnout when approaching hack-a-thons in the middle of a work week?”. Jay discussed that development at Facebook wasn’t a strict 9 – 5 culture and that developers would work the hours that they felt quite at home with. He said the developers at Facebook don’t suffer burnout as “burnout is loosing interest in a project or piece of work” and their developers work for a maximum of 12 months in a team before moving to another.

I can see Jay’s point but I don’t feel that working too much and losing interest on a project are mutually exclusive. I think if you work too much then you can become bogged down in feeling a bit frustrated in your work. This can create boredom and make you lose interest and (or) focus. This is where I think burnout creeps in. This is what we need to make sure we avoid when we plan work. I usually associate burnout with long waterfall projects.

TeamCity - OutOfMemoryError

Whilst upgrading our TeamCity server from 6.5 to 7.x, I encountered an error:

Unexpected error occurred inside Alarm task: java.lang.OutOfMemoryError: GC overhead limit exceeded

After a bit of looking around and sifting through some very weird articles I was able to find some good information on this. Basically, the JVM starts by default with 512mb of memory and it was struggling to process our 300+ build configurations with this. In order to fix it I had to do the following:

  • Go to TeamCity webserver
  • Open CMD
  • cd <TeamCity root dir>
  • cd bin
  • teamcity7w.exe //ES//TeamCity
    • If you are on TeamCity 6.x then you need to run teamcity6w.exe rather than ..7w
  • This will open the following dialog:


Go to the Java tab and change the maximum memory pool entry to something other than 512mb


Restart the service and all should be well with the application start-up.

Introducing TeamCityMetro for WP7

After my foray into the work of the TeamCity API, Gary Park and I have written a WP7 app. We are pleased to announce that this app is now available in the AppStore and is FREE to all. For version 1, the application will only give you the opportunity to see your projects, builds types, last 10 builds of each build type and then link to the build on your teamcity server. This is only an initial release and will be followed up with the ability to trigger builds.

The application looks as follows:

Screenshot1 Screenshot2 Screenshot3 Screenshot4 Screenshot5 Screenshot6  Screenshot7

If you want to request a feature or leave us some feedback then please get in touch with us. An application website will soon appear. All feedback gratefully received. Huge thanks to all our beta testers. Without them this application would never have made it past beta.