My career as a software developer started in 1999 before the non-event that was y2k (fortunately!) I was working for a large networking company (3Com now HP), gave me lots of opportunities working in a defects and enhancements team. They had a great graduate training scheme that exposed me to many different aspects of business and finance as well as computer networks and development.
Working in software support provided me with experience of what it is like to take other people’s code, understand it, read any documentation and update it. The organisation was actually really good at documenting designs etc. and there were a good number of experts available to answer questions.
I stayed there for over 10 years, moving from the sustaining group, into new products and then into their applications team, however, I do believe my skills began to stagnate. Basically, I got comfortable working there, it was easy doing the same thing day in day out and although there were challenges we had worked on similar things before so they did get resolved quickly. Redundancy came looming several times and I avoided it a number of times but eventually it hit me!
What I learnt from this was not to get too comfortable in an organisation and to keep my skills up to date.
Redundancy & New Hope
I was very fortunate at the time that I was looking because I found the right company at the right time and they gave me the opportunity to use my existing skills and learn the rest on the job. This was a great opportunity. I was thrown in the deep end straight away and given the task to build a custom migration application in Spring that pulled data from the old database and used all of the new business objects to push the data into the system. There was a short time frame and the fear of migrating the data incorrectly but it spurred me on to learn fast and get up to speed!!!
Whilst working for this organisation I did get many opportunities to expand both my technical skills and my development process and managerial skills. We adopted Agile in the organisation which was a breath of fresh air compared to the previous way of working. The team was much happier working in this way and being trusted to do what they do best; make software. This was great for me however, looking back I realise that this was still only in the specific area of the business. I needed to widen those skills, for example, we weren’t doing TDD there at the time, we were barely doing automated testing etc. It was time to move on again when redundancy hit when the company ran out of cash and they needed to downsize.
What I learnt from this was to keep learning languages and frameworks but also to be a better developer by ensuring that quality isn’t just for QA to own. Automation and TDD give the power to the developer to ensure they are confident that their code will work now and in the future.
Time to try TDD, read more and aim to become a better developer
My next role took me to a small company near where I live where I joined a small development team. Sat in the same room as a collection of servers it was a slightly noisy place to work but I got used to it. A more positive opportunity at this new organisation was that I finally had the opportunity to embrace TDD. It was great because I got to read about it from the master Kent Beck, try it, use it and love it! It made me think about how I was writing my code and how that impacted the ability to write automated tests. I truly understood the impact of tightly coupled code and how that becomes rather irritating when writing tests. I must confess that even though I don’t stick to TDD all the time, what I have learnt from this ensures that the code that I do write enables tests to be written after without needing to change the code.
Once I had experienced TDD, read and practiced the principles in Clean Code it enabled me to talk to others in confidence about the benefits and challenges. This drove a significant change in the development team where more unit tests were being written and people would come to me for advice on how to test components.
In the end though I did realise that the server noise was too much and it wasn’t going to get resolved so I felt it time to move on.
What I learnt from my time in this organisation was to embrace best practices (although these do change all the time) and try to conduct myself in a professional way. I think these days this is possible without needing to join a professional body because it is one of mindset rather than membership.