This article is no longer listed, please search the site for up to date articles

  • Role: System Developer
  • University: Cambridge
  • Degree: Maths

Luke Dennis

A day in the life of a System Developer

As a system developer my role involves coding, maintaining and fixing our market leading solution for life and pensions companies, administrator. As you would expect from a market leading solution, the software is highly functional and covers a vast array of business areas from member administration to annuity quotes to investment strategies to pensioner payments.

Initially, I would focus on gaining a broad understanding of the full system capability but then specialising on just a few with a view of becoming the “owner” of that part of the system. This is a big responsibility since any enhancements or changes that need to be made to a part of the system you own will need to be approved and sanctioned by you.

Once I had identified the areas of the system that appealed to me the most (the member self service website) I set about learning all the details surrounding that part of the system. There are extensive internal training courses that cover all the coding languages needed to work in this area and this would be my starting point. Once the internal training is complete, the company encourages external training and I am currently half way through working towards my Sun Certified Programmer for Java 6 qualifications.

The role is demanding and challenging due to the complexity of the solutions required and the fact that the pensions market is constantly evolving means that more advanced solutions are constantly required. However, my colleagues are extremely supportive and accessible so my questions are always answered. It is very satisfying when work I have done gets used by clients to help millions of pension scheme members.

A typical day

09.00 – 09.30: Check emails

The first thing I do when I get in is check my e-mails for any code quality changes I may need to make. These can come from two sources; the automated checker that checks for minor mistakes or efficiency improvements and code reviews from other developers who test the functionality of my code as well as checking the comments written within the code to make sure that the code is understandable to other developers.

09.30 – 10.00: Team meeting

The development department is split up into five teams who work on different areas of the system. Once or twice a week my team will have a meeting to discuss any issues we are having with regard to the enhancement we are currently coding and to determine how to divide up the work. Here at aquila, graduates are encouraged to put forward new ideas and if we see a better way of doing things.

10.00 – 12.30: Coding

The main part of my job is writing the code for our product administrator. For me this is the most challenging part of my job as it requires you to implement complex requirements and ensure that the functionality you are adding to the system behaves as you expect it to in every possible circumstance. This includes updating an advanced error reporting system to help our clients use the program and notify them if they are doing anything incorrectly.

Once I have finished writing the section of code that I’m working on I check it into the main build. By doing this all the other developers will now be able to access my code and the automated build that runs constantly will check that my code compiles and hasn’t caused any of the tests within the system to fail.

12.30 – 13.30: Lunch

Everyone within the company is extremely friendly and at least once a week we go out for a group lunch. On the other days I generally go down to the local sports centre either to play in the local squash league or to play five-a-side football in a friendly development verses the rest of the company match.

13.00 – 15.30: Writing Unit And Integration Tests

For every bit of code that I write there needs to be at least two different automated tests for it. Both these tests I will write and will be checked into the main build so that if any further changes are made to my code we still know that it performs the functionality that it is supposed to correctly.

The first type of test is the unit test, which tests the logic of the code you have written. Every line of code must be accessed by at least one test and this is often much more challenging than it sounds.

The second type of test is the integration test which takes some sample data, runs my part of the system and then checks the resulting data against the expected outcome. The challenge here is to provide data that will test all areas of my code and hence prevent any data that a client has causing the system to error.

To help ensure that every piece of code is covered by an integration test there is a second layer of integration tests in the form of an automated test pack, these run a large amount of data through an entire process to ensure all the different pieces of code link together as expected. If you were creating new functionality one of these would need to be set up, otherwise the existing one just needs to be maintained.

15.30 – 16.30: System testing and fixing

There is a strong emphasis on quality here at aquila so all new code will be system tested. This process involves another developer or business analyst taking the requirement from which you coded, devising a series of tests to make sure the area of the system fully meets the requirement and then systematically carrying out these tests after the code has been completed. Any errors will be sent back to the coder to fix, through an internal tracking system.

Additional testing will be carried out by a benchmarking tester, who designs a series of tests to check the performance of the program across different networks. A developer is required to carry out any suggestions made to improve the efficiency of their code and to code with efficiency in mind.

A final series of tests will be carried out by a consultant during the quality assurance testing period (or QAT) just before a release. Any errors they find will then be given back to the coder during this period to ensure the quality of the product.

16.30 – 17.00: Requirements meeting and demonstration

After each area of code has been completed feedback will be given by consultants during a demonstration. This highlights any areas that can be improved and provides a chance for developers and consultants to discuss the most cost effective solutions.

The meeting also provides a chance for the consultant to explain their next requirement, presented in the form of a document and answer any queries that the developer will have.

17.00 – 17.30: Update documentation

A key part of building and maintaining a large program such as administrator is providing high quality documentation explaining what each area of the system does and how it can be used. This is in addition to the comments left in the code to help other developers have a quick understanding of its logic.

Working at Aquila

I had several offers when I graduated from university but I chose Aquila because of its strong reputation and position as market leader. The first thing that struck me when I started was the quality of the staff employed.

Everyone has lots of developing experience and knows our product thoroughly. This makes it easier to ask questions and also contributes to the high quality output the company produces.

Also, being a small company, all the staff know each other which gives a personal touch not necessarily available in the bigger companies. A benefit of the small open plan office is that your hard work is noticed and your achievements recognised.

I was also assigned a mentor for the first six months of my time at Aquila. This was also a great help because I had a direct point of contact for all those questions when one is new to a company. There were also monthly appraisals for the first six months which are designed to give you positive feedback on your progress at the start of your career. My colleagues are extremely supportive, accessible and ready to help me when I need them.

I have thoroughly enjoyed my first year at aquila. I have learned an incredible amount and met some fantastic people. I have been given extensive responsibilities from an early stage and I can see that I have had an influence on company performance.

Back to Top