I started working for ThoughtWorks in June 2012, so my project experience to date is limited to the project work we did as part of TWU (ThoughtWorks University) and the billable project I’ve been working on at Springer since returning from TWU.
TWU was an incredible opportunity to experience the ThoughtWorks culture and get stuck into a real project in a safe environment where there isn’t the pressure to deliver something because the focus of the experience is very much placed on the learning aspect. If you want to know a little more about what TWU was like, I wrote a previous blog post about my experience that you can read here.
After TWU I was given my first project assignment as a developer on a delivery project at Springer in London. Springer is a well-known publisher of books and journals for the academic and professional science, technology and medical communities. ThoughtWorks have been engaged with them since the middle of 2011 to rebuild SpringerLink, their web based content delivery platform. Although this is primarily a delivery project, where we were brought in to work alongside Springer’s own team in order to build and deliver a software product, we are also there as consultants, advising the team on agile practices so that they will be able to continue with this approach after we have left.
I joined the Springer team in August 2012 when the project was in full swing and everyone was focused on delivering the application by the end of that year. Although we had a very large team (around 30 ThoughtWorkers and 15 Springer team members), there was a great sense of camaraderie amongst the team and I was made to feel really welcome. A typical day for me would involve pairing with another developer to implement a feature, which could have involved writing code in Scala, Java, JavaScript, MarkLogic or MySQL. As developers we would work very closely with the Business Analysts (BAs) to understand the details of what we should be implementing and what business value the feature was supposed to bring, as well as with Quality Analysts (QAs) to make sure that we had considered the implications of how our feature would interact with the rest of the system and that all test cases had been covered.
My favourite aspect of the project was having the opportunity to work on interesting development tasks with a variety of people who made me consider problems in a different way, opening my mind to different approaches and teaching me a great deal about test driven development, design principles and writing clean, readable code.
It’s hard to think of something I didn’t like about the project as I really enjoyed my time there, but with this being such a long running project, once we had reached our end of the year milestone and delivered the core product, the team started to lose that drive and focus that had made it such an exciting project to begin with. Although it continued to be a great project, it just wasn’t as awesome as it had been the previous year!
A computing study/work diary 