An introduction to my talk at JAX 2013 - also published here.
Back when I first started my career as a developer following University I was unleashed with little training in best practices, development methodologies or what to expect from the uncertainties in real world development. Before I could start to learn all these things I was quickly placed in my first job. The type of role I was placed into was fix problems and develop new features - with only guidance relating to the specific tasks at hand. There was no training on industry best practices, which underpin the quality of the software as professionals we strive to deliver - my own development languished.
Several years on, in my own time and through quizzing various industry leading technologists like Sandro Mancuso (at JAX London 2012) and Martijn Verburg (at numerous beverage centric establishments) I started to discover my personal points of improvement. I realised that there were steps I could take to improve the approaches I had in my toolbox for software problems. I took a look at my peers and people that were applying for job roles. Many listed Test Drive Development (TDD) as something that they used on a regular basis. I very quickly realised that a lot of people claim to practice TDD, but either don't do this at all or write integration tests rather than unit tests, as well as other ideas about what TDD is.
My talk at JAX London 2013 is designed for developers who have been too busy to appreciate the less obvious benefits of TDD, particularly the side effects and task breakdown from a cognitive perspective. The session will cover the basics of TDD, the use of mocking and how this helps break up the coding complexity using code and architecture examples. I will also convey my own experience of converting to TDD along with the benefits I have realised and how to convince developers who don't want to test the approach has merits outside of just high test coverage. The talk does not aim to sell TDD, but instead present facts and experiences that I have gained over the last year so developers can form their own opinions.
From taking these steps myself I produce code closer to the requirements, more maintainable code that is able to respond quickly to changes and my colleagues can look at the code and tests and quickly understand what is going on. Conferences are often the catalyst for personal improvement, and people interested in this space but haven't had time to explore it themselves will get some good practical advice on how to get going and what to expect.
Back when I first started my career as a developer following University I was unleashed with little training in best practices, development methodologies or what to expect from the uncertainties in real world development. Before I could start to learn all these things I was quickly placed in my first job. The type of role I was placed into was fix problems and develop new features - with only guidance relating to the specific tasks at hand. There was no training on industry best practices, which underpin the quality of the software as professionals we strive to deliver - my own development languished.
Several years on, in my own time and through quizzing various industry leading technologists like Sandro Mancuso (at JAX London 2012) and Martijn Verburg (at numerous beverage centric establishments) I started to discover my personal points of improvement. I realised that there were steps I could take to improve the approaches I had in my toolbox for software problems. I took a look at my peers and people that were applying for job roles. Many listed Test Drive Development (TDD) as something that they used on a regular basis. I very quickly realised that a lot of people claim to practice TDD, but either don't do this at all or write integration tests rather than unit tests, as well as other ideas about what TDD is.
My talk at JAX London 2013 is designed for developers who have been too busy to appreciate the less obvious benefits of TDD, particularly the side effects and task breakdown from a cognitive perspective. The session will cover the basics of TDD, the use of mocking and how this helps break up the coding complexity using code and architecture examples. I will also convey my own experience of converting to TDD along with the benefits I have realised and how to convince developers who don't want to test the approach has merits outside of just high test coverage. The talk does not aim to sell TDD, but instead present facts and experiences that I have gained over the last year so developers can form their own opinions.
From taking these steps myself I produce code closer to the requirements, more maintainable code that is able to respond quickly to changes and my colleagues can look at the code and tests and quickly understand what is going on. Conferences are often the catalyst for personal improvement, and people interested in this space but haven't had time to explore it themselves will get some good practical advice on how to get going and what to expect.
No comments:
Post a Comment