Reflections on my last gig…

I have just rolled off of my project of the last 8/9 months, and thought it was a good point to reflect on my time there.

Once again I had an awesome time. I learnt a lot, met some great people, made some good friends, watched people grow, and most importantly contributed to a great product. There were a lot of highlights, too many to name them all, but here are 5 I picked out.

Non-hostile atmosphere.

The whole team was respectful of each others ideas and skills, open to change and new ideas and a lot of fun. One of the first projects where change has not been outright resisted and refused. As consultants I can see that it’s natural that our presence on a team can cause hostility, but we’re here to help, honest! This lead to a much more productive and more pleasant working environment, allowing people to try new things and bring their ideas to the table.

From the moment that I got there I felt like there was space for my ideas and people were ready to listen to them and give them a go. Wonderful feeling.

It sounds like a small thing but its really not. When a team is willing to change the way it thinks and embrace new ideas, everyone can contribute to that success, it’s not just the persistent, rebellious people (which is often the role that ThoughtWorkers have to take) who can make change happen but there is space and support for everyone to have ideas and change the way things happen.

Feature Leading. Our tech lead was comfortable letting some of us lead a few of the features, which was great. I got to look after the online sales feature we added and an emailing piece. It wasn’t so much as an official thing but more an organic thing. As well as being involved in writing the code, I helped with analysis, spent a lot of time talking to the teams that we were integrating with, kept an eye on and helped out with testing and deployment and generally provided a consistent technical vision for the whole feature. It’s great experience for people who are moving towards becoming a tech lead, without the pressure and responsibility for being the actual tech lead. I found it really energising to have such focus on one feature.

Coaching / Mentoring.

I went to a leadership academy event recently where one of the speakers said that you are not a great leader unless you have pulled people up with you. That has really stuck with me. What kind of leader can you claim to be, if you haven’t helped other people learn and grow?

The client had a female developer on their team who had never met another female developer before she met me. She is also very talented and passionate about technology with some great potential. I spent a lot of time with her coaching and mentoring, and this relationship will outlast the client engagement. I get a massive amount of satisfaction helping others reach their goals and look at the world in different ways. Also being able to provide the support that people need to grow.

I also tried quite hard to make sure that I was giving “in place feedback” i.e. immediate feedback in a situation, mostly whilst pairing etc. One of the other TW Developers on the team commented that he heard me doing this often and learnt a lot from just listening. Need to do this more though. Especially when there are more “heated” pairing situations.

A positive attitude can go a long way.

Generally I’m a pretty positive person, and I got a lot of feedback about how this changed the whole atmosphere of the team. It only takes one consistently negative person on the team to start bringing the entire mood down. Remember this and try and look at situations positively and with energy.

There is more to being a developer than just writing code for the story you’ve been given.

As a developer, you are responsible for getting features that help the people using them into the hands of the people using them. It is your job to push back if you think requirements don’t make sense. It is your job to ensure that the software you are producing is of a good quality. You should not just be coding whatever you are told to without questioning anything. So as well as writing code, be part of the requirements definition, the testing, the conversations with stakeholders, with the people that are deploying your code if it isn’t you. Software that is not in the hands of the users and being used is useless.

As well as advocating the above, I spent some of my time on the team championing and facilitating the retrospectives, launching lunch and learns, being part of the inception, and countless other things that weren’t strictly in the remit of a typical “developer”. For me this is normal as they are things that I enjoy, but I don’t think this was the kind of developer that many of the client devs had met before! I hope that it has influenced them a bit.

Technical highlights

No-SQL datastores (Dynamo DB)

JavaScript testing (Jasmine)

JavaScript frameworks (KnockoutJS)


In process browser testing (Plasma)

Feature driven development (Starting with high level feature tests and build down)

Analysis of logs (Stash)

Releases every week with blue/green deployments

Our tech stack:

Written in:

C# .Net, Javascript (KnockoutJS, JQuery), Razor, MVC4

Dependancy Injected with:


Package Managed by:


Tested with:

Moq, Plasma, Selenium Webdriver, NUnit, JMeter

Data Stored in:

SQL Server 2012, Dynamo DB

Deployed on:

Amazon EC2, IIS,

ORM Layer:

Linq to SQL, Dapper

Deployed and Built using:

DBDeploy, MSBuild, Team City

Monitored with:


Coded using:

Resharper, Visual Studio 2012

…..and probably others that I can’t remember off the top of my head.

Bringing visibility to code quality metrics

It’s often hard to measure whether or not the quality of your codebase is improving. It’s also very easy to become overwhelmed by software quality metrics. With so many, you stop paying any attention.

One of the metrics my current team has been paying a lot of attention to is a “duplicate count”. It’s a measure of how many lines of duplicated code you have in your codebase, both in the test code and in the production code. Team City, which we are using as our Continuous Integration server, has a built in duplicate count, so that every time you check in you can see whether it has gone up or down. (The way that it counts is sometimes a bit strange… but I won’t focus on that!) You can make sure that the build fails if it goes over a certain number.

We were trying to focus on “improving the quality of our test code”, especially our high counts of duplicates within our test code. As this one was easy to measure, we thought we’d focus our efforts on a single metric and consciously reduce the number with each check-in.

Feeling particularly arty that day, I decided to create a physical counter that we could use to measure how we were doing. I created one counter that I put in front of the build monitor. Leaving the numbers to be coloured in as people got to them. This would then be flipped over as people reduced the numbers.

I also created a summary of the numbers to put on the story wall, so that at standup we could always check on progress. Noting what the number was at the start of the week and then what the number of duplicates was for that particular day.

It worked amazingly well. Suddenly this group of grown men were enthusiastically running over to the build monitor to change the counter as they reduced the duplicates. Cheers would go up when a pair checked in code that reduced the number. Turns out “gamification” is a real motivator. Before I knew it, people were getting shout-outs at standup for being particularly good duplicate reducers that week.

Having the additional counter on the main story wall meant that people outside the developers were aware that we were paying attention to the quality of our code and actively trying to improve it. It has now become part of our daily standup routine to talk about it.

The counter worked so well, that we then introduced one for the number of warnings in the code base. Pick a quality metric and try it!


Git for Beginners – A Sample Workflow

So here is my *very* happy path sample workflow, using local branches, with explanations for first time users of Git. See here for a worksheet with useful git commands and their uses and a sample workflow. This covers only what this post covers.

You will aslo see references here to “git tf”. This is not an alias but a cross-platform, command line tools that facilitate sharing of changes between TFS and Git. The commands are the same as the regular Git ones. But slightly different for pushing and pulling. See here for more information.

A familiar workflow:

  • Get the latest code
  • Create somewhere to put the changes you are about to make
  • Make changes
  • Make sure you are happy with them and want to integrate them back into the main repo.
  • Check for any more updates
  • Push your code into the remote repo

Now broken down into the Git steps to achieve the above.

1. Get the latest code

Make sure you are on master. Use git status to check.

Pull down the latest changes onto master git pull

2. Create a new branch for your story work.
Name it after your story so you can remember it later. git checkout -b [branchname]

If you do a git status now you will see you are on your new branch.

3. This is where you code as normal, running your tests etc.

4.Commit your changes to your branch.
When you are a point where you are happy with your changes and you want to pull in everyone else’s changes… You can commit as many times as you like to one branch but try to keep them small and in a working state.

A git status will show you your changes.

You will see the files that git is tracking and has staged and those that it has not. git add . Or git add -A will add any untracked files.

Next commit your files to your branch. git commit -am "[message]"

When you do a git status now, you should see no changes.

If you do a git log you will see that your commit is now part of the branches history.

5. Get latest code on master

Move back onto your master branch git checkout master

If you do a git log at this point, you will notice that your commit is not yet on master, and the latest commit will be from when you last pulled.

git pull will bring down any more changes.

6. Update your branch with lastet code

Move back to your story branch git checkout storyname

Next you are going to rebase your branch. When you originally created your branch it was based on point in time x, since there have been additional changes (time y), you want to tell your branch that you actually want it to be based from time y and you want your changes on top of that. So now git rebase master will update your branch with all the changes that are now in your master branch. As you watch the output you will see that git pulls out your change, fast forwards to time y and then replays your change on the top. Now you may have conflicts at this point if two people have changed the same thing but will assume things are all good.

Now run your tests and make sure everything is good.

7. Get your changes back into the main repo.

Move back to your master branch git checkout master

Merge your branch back into master with git merge storybranch

git push will then send up changes to the remote repository.

Next time… Merge conflicts…..

Git for Beginners – Team Lunch and Learn

Our team has just embarked on “Lunch and Learn”s. (A time for the team to get together over lunch and learn about something new). For the first one, my colleague Tom and I volunteered to teach the team to use Git…

Our development team was previously all located in the UK, but we are about to go distributed with teams in both India and the UK.

We are working on a .Net stack so of course, (shudder) we are using TFS. Due to the team changing to be distributed we are having to look at more distributed friendly source control systems, and thankfully Git is on the table.

Now I am definitely still a relatively Git noob. I was introduced to it on my last project, and we used it pretty extensively for a year. Now, I hate working without it. I think it’s changed the way that I work, so it’s hard to go back to the TFS dictated way of working.

We are planning on doing two sessions. This first one being just on the very very basics for someone who has never used Git or another distributed Source Control System. Literally, this is how you get stuff out, change stuff, and get it back in. Hoping nothing goes wrong.

Anyway, we bought pizza for everyone, to keep them happy, and quiet.

The first part of the session we did in a meeting room with whiteboards. Tom talked about some of the high level concepts of distributed source control systems. Along with a brief description of how it differs from TFS ***. Tom also talked through some of the key terminology that people would need to get used to. i.e. working trees, remote repository, the index/staging etc.

My job was guiding the team through the workflow that we’ll be encouraging. I chose to first explain the workflow we would be using, away from the computers using pictures, to ensure that everyone listened and understand why they were doing each command. I was worried that everyone would be distracted and race ahead without considering what they were doing with a shiny new toy in front of them.

Now I know that there are two different schools of thought out there. Local branches or committing on master. I was taught to use Git using local branches so that’s what I’m more comfortable teaching. Plus it means that your master branch is always clean, gives you a bit more of a safety net, but also it forces you to change the way that you are working, not just doing the same workflow you did in TFS or SVN. It forces you to start getting used to the concepts that really make Git powerful.

It went surprisingly well. I was expecting a lot of fear and resistance, but actually it create a great new energy around the team. Everyone rushed back to the computers to try out what we had been showing them, and it started a lot of good discussions.

See the following post for my detailed description and walkthrough of a sample workflow with Git.

*** to keep the “but in TFS…..” To a minimum, I asked everyone to keep an open mind and if anyone who wasn’t presenting brought up TFS they’d have to do star jumps in the corner.

GHC 2012: How to Influence without Authority, and Why It’s Important

These are some notes and thoughts from one of the sessions that I attended at Grace Hopper this year.

Dictionary definition of Influence. – The capacity to have an effect on the character, development, or behavior of someone or something, or the effect itself.

Inherently, you don’t need authority to influence.

What do you need to be able to influence?

– Relationships – Get out into the hallways and meet people… Learn what their goals are and figure out how you can help them advance those goals. Do your job well and build a reputation for yourself.

– Trust. Takes time to build, very easy to break.  You get this by doing what you say and saying what you do. Be consist in your approach to things.  Reciprocity is important. Give as much as you ask. Takes time. Not a one off thing you try to achieve.

How do you influence?

Become good at summarizing, be concise, make sure your ideas are based in fact. Consider your audience. Change the length and depth of your data depending on who your talking to.

What’s in it for them? If people find nuggets of their ideas in your plan, they will want to be bought in to it.

Ask questions. Ask short questions, give people a chance to tell you what they think. Make an emotional connection and find out shared values. Ask open questions, avoid leading questions, not yes/no questions.

Now i’ve always had a bit of an issue with session’s on how to influence people. We had one when I first start at ThoughtWorks at TWU. I’ve always thought there is a very fine line between influencing someone and just plain manipulating them. In my rose-tinted world I hope that you don’t need to consciously try to influence people if you are leading by example and have everyone’s best interest’s at heart. If you are genuine and achieve great things, it will change the way people around you act.

Thankfully someone in the audience asked just this question: How do you make sure you’re not coming across as being manipulative?

Avoid one sided conversations.  Present your idea and ask for feedback.  Focus on what is in it for them.  Respect “No.”, but try again.  Make sure that you are “perceived as trustworthy”. (<- shouldn’t you just BE trustworthy?!)

What do you do when you are dealing with someone who ‘needs’ to feel like they have that authority over you?

Make friends with people who are friends with them and ask their advice. Ask how can I talk to them in a way that they will listen to? Make sure you are advancing them in their goals as well. “Their ego is their teddy bear and don’t take their teddy bear away from them”.

As long as you don’t care who gets the credit you can go along way.

 How to influence what you are working remotely?

Try to meet at least once. Phone and Skype become easier once you have met face to face. Talk about non work stuff to create a personal connection. Get into a conference call 15 mins early and chat, make it known that that’s what you do.

For more notes on the session see here

GHC2012: Nora Denzel’s Keynote – Tips for staying in your technical career

Go and watch her whole keynote speech here. It’s well worth it, and much better than I could ever attempt to summarise!

See here for Nora’s bio and some of the quotes from her keynote.

Nora’s keynote was funny and inspiring. She’s a great speaker. As well as talking about her own journey she focused on issues of diversity and also retention of women in IT.  Mentioning that once you have got women into IT, you have to work just as hard to keep them there.

Nora talked about her top 5 tips for a long career in the technical industry.

  1.  Your attitude…. Your career is an obstacle course not a path. Obstacles are put in your career not to kick you out– but to see how bad you really want it. Things don’t happen ‘TO’ you in your career, they happen ‘FOR’ you. You are not victim of these obstacles. Don’t run away. You shouldn’t be scared, this gives you tools to deal with things.
  2. Be comfortable with being uncomfortable…. Tech is always changing, you will always feel like you have no idea about something. It’s normal to feel uncomfortable. It’s about how fast you can learn. If you are comfortable all of the time, you are not growing. Comfortable OR growth.
  3. Act as if…. Fill in the blank. Act as if you are confident… Act as if you are a good speaker…. etc. Nora gave a great example of how she met the first lady to go into space. She strutted confidently onto the space shuttle, but when Nora asked her if she was scare, she responded that yes, she was terrified. I knew how the systems worked and all the possibilities of what could happen! What is courage? Master your fear. Easier to act into a new way of thinking than to think into a new way if acting.
  4. Control your career PR agent. YOU! You are your own agent. Be careful about what you say back to a compliment. Say thank you and then stop. Don’t qualify all the things you were terrified about or didn’t do right. Always tell the truth but just not so much of it. Shorten your press release. If you don’t have confidence in yourself how can we have confidence in you.
  5. Maintain your village. People that support you. Have a network that you nurture. It is not what you know or who you know, it is who knows what you know!

You have the chance to change the world. To work on things that will change peoples lives.

Grace Hopper ‘ A ship in port is safe, but that is not what ships were built for. Sail out to sea, and do new things.’ @ndenzel #ghc12

GHC 2012: The Grace Hopper Celebration of Women in Computing 2012

This years Grace Hopper Celebration of women in computing was held in Baltimore, in the US.

I once again got the chance to go and it’s always an amazing event. This year was the biggest ever at nearly 3700 attendees, made up from students, academia, industry and some military.

It was a very busy year for ThoughtWorks there too, each year our presence gets bigger and this year we did a tonne of interviews and assessments. Hopefully we’ll find some great women.

As always the dance party was my favorite part. Not just because I love dancing, which I do, but because it epitomises everything great about this event. The exhibiting has finished so we can all relax, the organizers can relax, you have well over a thousand people dancing like no one is watching, celebrating being who they are. So many smiles, many new friends have been made. And just a great electric, energized, and optimistic atmosphere. I love hearing first time attendees overflowing with excitement and drive as they tell me what an amazing experience it was for them.

I didn’t get to attend as many sessions as I would of liked but I did manage Nora Denzel’s keynote and a sessions called How to Influence Without Authority. See follow up blog posts.

Next year will be in Minneapolis, and I’ll be taking a break from the conference as i’ll be busy getting married over that time!

San Francisco, California

After Napa Valley, we headed back to San Francisco here are some of the shots from our adventures.

The Castro Theatre
Fisherman’s Wharf
San Francisco Hilly Streets


Flower Conservatory, Golden Gate Park
Japanese Tea Garden, Golden Gate Park
Japanese Tea Garden, Golden Gate Park – Pagoda
Ocean Beach
Ocean Beach
Ocean Beach
Ocean Beach – Surfer