I'm a highly experienced senior developer with 19 years of investment banking experience (and 24 years in the IT industry) working for various Tier 1 banks in both the City and Canary Wharf. I've been coding Java since about 2001 and have contributed to a variety of projects including low latency high volume trade processing, core technology, regulatory reporting, timeseries analysis, credit submission and workflow.
I'm highly delivery focused and a natural problem solver, and I bring both a deep technical understanding of the technologies I use and also an enthusiasm to get the job done. I'm also an experienced technical mentor and greatly enjoy helping others understand how best to use technology.
I have a degree in Computer Science (2.1) from Portsmouth University and sat the very first Object Oriented Design course as part of that degree. I passed that with a 1st.
Quality software design is absolutely vital to producing applications that fulfil business objectives and I'm a firm believer in quality architectural and technical design being the key to becoming a successful software engineer. I'm also passionate about code being well designed, maintainable and fit for purpose and put great emphasis on best practice design, readability and comprehensive testing.
Outside of work I have varied interests. I'm a keen runner, competing in ultra distance races which demonstrate my focus and commitment to achieve a goal. My long team goal being to run 100 miles in under 24 hours. Some would say insane and I would struggle to disagree at times. To balance all that running I also enjoy playing computer games and building PCs. I always have some kind of side-project going on which is usually focused on learning some new technology. The rest of my time is filled with all the things that a married man with 3 gorgeous young children demand.
I've always enjoyed gaming and although I'm rather time limited I do try to make time to play. I built a decent gaming rig a couple of years ago, which was great fun in itself, and have played lots of games since. I've settled on a game called EVE Online which is basically internet spaceships. It's a highly complicated game though to the extent that it has its own University to help teach new players. My favourite part of the game is that its highly sociable and you play with hundreds of other players in a sandbox universe. If you have the time I highly recommend it - click here for a free trial
Over the past 14 years I've been a very active runner and event organiser. I train hard and like to keep very fit. Weekly mileage often exceeds 50 miles and somehow I manage to fit that in given my busy schedule. Luckily I don't need a great deal of sleep so getting up early and running is my normal plan. The point of the training is to allow me to race ultra-distance events; my current favourite distance is 100km which seems an awfully long way to most people. On top of my training and racing I'm also an event organiser. For many years I was the Entries Secretary for the Halstead & Essex Marathon and although I've stepped down from that role now I still help out where I can. I've seen that event grow over the past 10 years to be one of the top-rated marathons in the country.
Having tests and ensuring they run and pass is important. Very important. Whilst you're pushing new features in you have to know that existing functionality works. Testing, and in particular testing first is an obsession of mine and one I encourage in others.
My default workflow when adding features to a system is as follows:
It's no good having great test coverage and not run those tests. You can't leave it up to the devs to run every test before checking in, the most I think you can require is that the devs run the tests that they believe will be affected by their change. Continuous integration is the act of running all those tests automatically on every code in. It's also the process of building those changes into a working deployable artifact.
I see continuous integration as a phased process that occurs every time a dev checks in a change:
Should any of those stages fail then that change has broken the build and the dev responsible should get informed of that and should prioritise fixing it. Having a working build is critical to ensuring that incremental changes all result in a working system.
After 19 years of working in investment banks I've worked in plenty of business areas; Prime Brokerage, E-Commerce, Trade Processing, Fixed Income, Flow, Credit & Market Risk, Reference Data. I'm not going to profess to be an expert in any of these areas but I am generally familiar with them. I'm primarily a technologist and I've focused less of the acquisition of business knowledge but rather on honing my skills as a software engineer. I do enjoy working in finance though and welcome the opportunity to learn new business areas.
Designing RESTful APIs is an art and not a science, there is simply no "right" way to do it. There are plenty of wrong ways though. I've spent many years studying the pragmatic ways to design these APIs may the job of the developers who use them a more joyful experience.
Microservices are a subset of SOA (Service Oriented Architectures) and are gaining an awful lot of traction at the moment. Monolothic systems are being re-envisioned and a set of coordinated services that provide a scalable and adaptable solution.
I like to think that over the past 24 years I've got rather good at it. I take pride in producing high quality, well tested, functional code that is easy to maintain and add features to.
I'm also a pragmatist and I try to balance my desire to create a beautiful code with actually getting the job done. A good example would be if I were adding a new feature to some code that had a coding style that I didn't particularly like. I'm not one to start converting it to how I like it. Sure, if I have to comprehensively refactor the class then I will do so to my own style but if I'm adding a feature I'll adopt the style that the code is written in. Having two styles in one class is just ugly and I'd rather see consistency.
Every codebase has areas that you honestly don't want to touch and that's dangerous. Understanding your application and being able to change it is critical. There is a solution though; Step 1: Get decent test coverage. Step 2: Refactor. I'm very good at both.
I've worked on system were it's been almost impossible to add new functionality because the engineers who built it have left and no one really understands how it works. Eventually of course something does need to change and then it's time to try and get it under test. Rarely is it possibly to spend the time developing a full set of tests, often it's difficult to tell what it's even doing. The trick is to isolate the parts that need to be changed and get those parts under test. Often it's possible to find seams in the existing code where you can can extract code into seperate classes. Then the job of testing gets easier because you can test that part in isolation. Finding seams is a skill though and knowing whether the extraction of that code is safe is a matter of experience.
My definition of legacy code is simply code that hasn't got appropriate test coverage. Put the tests in and it's not legacy code any more, it's code that can be modified, flexed, and enhanced. Let me help you turn your codebase into place that you don't fear to tread.
Does processing time matter to you? In most applications it does and I'm experienced in finding bottlenecks and eradicating them. You have to design for performance. I can help with that too.
Systems are built from both new and old applications, integrating them reliably can be hard. One of the key aspects of my current role with Nomura has been learning and using Apache Camel. If you're not familiar with Apache Camel, it's a framework which allows you to implement enterprise integration patterns. It's configuration based and treats interactions between system as interactions which form routes. I wont go into a ton of details here as there's lots of information on the internet about it.
One short example though; say to want to create a process that watched a directory for a file and when it is created, read it, write a new file and then FTP it over to a file share on a different machine. That's a totally common requirement and one that the implementation in pure Java would have a surprising number of intricacies. IO issues, directory monitoring, charsets, stream handling, the list goes on. What Apache Camel provides is some building blocks that allow you to define this process in just a few lines of configuration. Exception handling is handled and you get to get on with thinking about adding value to the project rather than debugging low-level Java IO implementations.
One of the focuses on my blog is going to be Apache Camel so look out for more posts about different aspects of this excellent framework.
Software engineering isn't just coding, there are many other aspects and an important one is the abilityto take a problem and find out what is actually needed. Say for instance that a user requests that a new button is added to a UI. You might take that at face-value and just add it in. Then you find out that the new button forms part of a new business workflow and it affects some of the other functions of the system. OK, more changes required and you put those in. Then the user thinks some more and decides the button needs to do something slightly different... This is not software engineering. This is just hacking. Fine for a little prototyping but it's too iterative and you end up wasting a lot of time. This is amplified when you are also having to code up tests.
A better approach would have been to actually talk to the user about what that button did. Why do they need it. What new business logic is actually required. That's analysis. Armed with knowledge about what the business are trying to acheive you design something that fulfils it. That may or may not be the button they requested initially, it could be something thoroughly different that the user never thought of.
I don't advocate the creation of huge specifications up front before coding a feature. I like to work in an iterative environment but one in which I've spent the time and effort understanding what is actually required.
I'm not an advocate of staying on the bleeding edge, but you have to know how far from it you are. Are your third-party libraries up to date? Are you using libraries that are no longer supported? Is there something better available now? I can help answer these question and dig you out of technical debt.
Hiring is hard. There are many ways to judge whether a candidate is right for a role, one of critical ones is "Do they know there stuff?" I've conducted a large amounts of interviews and I can spot a lemon from a diamond. It's not all about asking questions though, pair programming in an interview can let you know whether the candidate can communicate and deal with problems.
When you need to know whether a developer knows his Java you need a technical test so that you can see the depth of knowledge and also allow you to compare one interviewee from another. Most companies have their own internal Java technical test but I wanted something that I could use anywhere. That led me to create Javonical - the canonical Java technical test. It's on GitHub and it's open-source so if you want to use it go ahead and if you want to change it then just ping me a pull request.
I like to think I know where the pitfalls are in multithreaded code. It's an area that people tend to get pretty rusty at and it helps to adopt some practices that mitigate the issues. Is it thread-safe? I'll help you find out if it is or not.
One of the most rewarding aspects of my career has been helping other developers to improve their skills and gain in knowledge. In many of my roles I've worked with recent graduates and junior developers that are still in the process of learning the software engineering trade.
I can help developers to take a step back from their day to day work and look at aspects of software engineering which can improve the quality of their code and increase their productivity. That might be how to design an immutable class, or perhaps how to use their IDE more effectively. Unix and Windows tricks and tips, class structuring, refactoring, the list is endless. I really enjoy helping others to improve.