June 13th, 2021 by admin
The below network diagram is intended as an outline of the skill set required for a financial software developer.
Note:
- Most individuals should aim to have a strong core. Think of it like a pyramid, where the height is the strength of a skill. Core skills like general computing principles, probability, communication should be built “tall” and very strong. peripheral skills such as python/monitoring will be weaker. An individual will typically only learn 1 or 2 niche areas strongly (T shaped)
- Notice the rough relative sizes of the areas. 55% computing, 10% math, 15% soft skills, 20% finance. This is intended to represent the rough allocation of effort.
- If you only bring 95% techinical skills, you are going to waste time building the wrong thing, build something no one wants or build something useful but no one will know as you haven’t the soft skills to sell it.
- The management branch on the bottom left is optional.

Computing
Skill |
Topic |
Sub-Topic |
Links |
Requirement |
basics |
|
|
|
|
linux |
|
surrey |
Change Directories, edit config files, kill processes, copy/move files, check disk space. |
bash |
|
tldp.org |
Write a script to periodically sync a directory between servers and schedule it using cron. |
git |
|
git-scm |
Checkout, branch, commit, push code. |
Common Tools: jira/jenkins |
|
user-stories |
Write a good jira, assign owner. Kick off a build on a common CD platform. |
|
|
|
|
|
Programming Language |
|
|
|
Knowledge of 2 different programming paradigms. |
kdb |
|
kdb-tree |
Write efficient selects for pulling back a subset of data. |
python |
|
|
Download data from a REST api, calculate average/mean/median for certain metrics. |
java |
|
book |
Write a java program to count the number of words in a file. |
|
|
|
|
|
Databases |
|
|
|
Be aware of the major types of database available and when to use each. |
kdb |
|
kdb-tree |
|
mysql/postgresql/oracle/ms |
|
|
Know standard SQL. |
|
|
|
|
|
Software Engineeering |
|
|
peopleware |
How to grow good software. |
Good Software |
|
|
Properties of good software with examples. |
Architecture |
|
|
Common Enterprise software patterns. |
Distributed Systems |
|
Difficulties with distributed systems and common patterns to solve them. |
Data Processing Pipelines |
|
Common processing Pipeline Patterns |
Site Reliability Engineering |
|
SRE |
How reliable should software be? |
Metrics |
|
Ccommon metrics used to measure reliability and when to use each |
Monitoring |
|
What monitoring systems/tools are available? What are monitoring best practices? |
Releases |
Accelerate |
|
Support |
|
Handling outages. Engaging with users. |
Software Concepts |
Testing |
|
Testing Methods and knowledge of one test framework |
|
|
|
|
|
User Interfaces |
|
|
dont-think |
What makes a good user interface? |
|
|
|
|
|
Networking |
|
|
|
How computers connect. Expected latency/bandwidth. |
TCP/IP |
|
|
ports, switches, racks, data centres, windows. |
Middleware |
|
|
Messaging midddleware: solace/JMS/kafka/MQ. |
|
|
|
|
|
Software Development |
|
|
|
|
agile |
|
|
|
scrum |
book |
Sprints, iterations, standups, restrospectives, story-time. |
Lean Development |
lean-startup |
When, why and how to develop lean. |
Code Reviews |
|
pragma |
Code review best practices. |
Soft Skills
Skill |
Topic |
Sub-Topic |
Links |
Requirement |
IT Skills |
|
|
|
|
excel |
|
|
Create a table with conditional formatting, calculate sum/average of column, use vlookup |
outlook |
|
|
Filter emails, create meetings. |
|
|
|
|
|
Communication |
|
|
|
|
Emails |
|
|
How to write an email to users, team mates, managers, senior management. |
Meetings |
|
atlassian |
What is a meeting meant to accomplish? How to achieve that. |
powerpoint |
|
|
Prepare a presentation for management. |
visio |
|
|
Draw an architectural diagram of your system. |
|
|
|
|
|
Sales |
|
|
|
|
Marketing |
|
Traction |
How to get your software used and appreciate by more users. |
Support |
|
|
|
|
Networking |
|
|
|
Building a network to get things done. |
|
|
|
|
|
Management |
|
|
Grove |
|
Building a Team |
|
Dysfunctions |
|
One to Ones |
|
|
What makes a good one-to-one |
Interviews |
|
|
How to evaluate cnadidates effectively. |
Quality |
|
|
How to ensure quality of product. |
Organizational Structures |
|
phoenix |
Different structures for management. |
Project Management |
|
|
|
Roadmaps |
|
|
Decision Making |
|
Which approach to decision making to use when. |
November 25th, 2018 by admin
First Derivatives Shares have fell back to a price last seen in February 2017:


One cause of the fall has been a damning article by ShadowFall. Their main arguments are:
- First Derivatives was being priced highly as a software company
- It is not a software company but a consultancy.
- Previously good years were due to outside factors (property prices and government grants)
- They have made a significant investment in KX which may itself have stopped growing
The 47 page report goes into a lot of detail, to give an idea here’s one of the charts:

He shows numerous statistics for FD compared to it’s peers, operating margin, gross margin, revenue, headcount. It’s worth a read if you have an interest in kdb/KX/FD.
Related Links: Shadowfall tweet, Independent.ie.
January 14th, 2018 by Ryan Hamilton
The structure of banks and finance firms are constantly changing as they evolve towards the structure best for todays environment. The trend over recent years has been for less traders and more engineers as expanded in this (article. (thanks Zak). In these posts I’ll describe the current state and where I think fintech, in particular market data capture and kdb are going.

(Newer firms that are) “Tech savvy, led by quants and data engineers rather than the expensive traders sitting on the scrap heap of most banks’ inferior tech, the new entrants now just need people with the skills to win over large numbers of customers.”
Banks as a Stack
Think of banks as a stack of services sitting ontop of each other [1]:

Communication within the system is mostly between the layers. Top layers rely on all the services of the layers beneath. e.g. A trader relies on a trading application, that relies on an internal web framework, that relies on a database, that relies on hardware. If we get more traders that need additional software changes, that could transmit down the stack into a request for more hardware. Communication outside the layer model, e.g. Sales asking for additional SAN storage is exceedingly rare.
Within the stack, I’ve highlighted in bold where market data capture sits. I believe most the points I’ll make can be applied wider to other areas within the stack but I’ll stick to examples within the area I know. Sometimes the “market data” team will include responsibility for Feeds, sometimes there will be a core team responsible for the database software they use, sometimes there won’t, but it captures the general structure.
Issues with the current Stack
Note each box on the diagram I refer to as a silo. A silo may be one team, multiple teams or a part of a team but generally it’s a group responsible for one area, looking after it’s own goals.
- Communication between silos is slow – Currently communication between silos consist of meetings, phone calls and change tickets. Getting anything done quickly is a nightmare. [2]
- Duplication of Effort – The simplified model above can often be heavily duplicated. e.g. FX, Equities, Fixed income may have separate teams responsible for delivering very similar goals. e.g. An FX Web GUI team, An equities Web GUI team. Losing all benefit of scale. [3]
- Misalignment of Incentives – Each silo has it’s own goals which often do not align with the overall goals of the layers above or below. e.g. The database team
may be experts in Oracle, even if an application team thinks MongoDB is the solution for their problem, the database team are not incentivised to supply/suggest/support that solution.[4]
- Incorrectly Sized Layers – At any time, certain silos or layers within the stack will have too many or too few resources. The article linked at the top of this post suggests the layers should be a pyramid shape, i.e. Very few sales/traders to meet todays electronic market needs. We should be able to contract/expand silos dynamically as required.
Possible Solutions coming in 2018
There are a number of possible solutions to the issues above available today, unfortunately I will have to expand on that in a future post. I am very interested in hearing others views.
Do you believe the stack and issues highlighted are an accurate representation? Solutions you see coming up? Either comment below or drop me an email.
I will hopefully post [part 2] shortly, if you want notified when that happens, sign up to our mailing list.
Notes:
- For some reason this reminds me of the OSI 7 layer model.
- Amazon try to escape this communication overhead by making everything an API
- Customers may prefer a bank that supplies all services but divisions within banks are too big to enforce conformity. Both limitations likely due to Dunbar Number
- Even within a single team, the modern workplace may create conflicting loyalties.