My Path In Software Development
I love working in software. How can you not love a creative endeavour unconstrained by physical limits?
I’m lucky to have worked for some of the largest companies in my vertical, at reasonably senior positions: yet I hold no formal qualifications in programming. In an age of code camps, online tutorials and courses I wanted to outline my much less structured path. There’s always more than one way to get to where you want to be!
1987–1992: Playing and Learning
It all started with the ZX Spectrum 48k. Consumer level home computers in the 1980s all came with a BASIC interpreter built in. Games magazines, as well as reviews, had listings of BASIC games you could type in and try and run. Trying to get these listings entered accurately with only the runtime interpreter error messages was difficult (well, it was if you were 9!): I can’t remember whether we ever got one 100% working. But you could take the concepts and apply them to your own programs too, of course. My friends and I gradually improved, using various different computers, having lots of fun.
Primary lessons: Play is the best kind of education. If you love something, do it as much as you can.
1993–1996: Hiatus
Busy being a teenager, no coding. I did once hack Minesweeper.exe to give myself an impossibly fast time, much to the bemusement of my victims.
1996–1997: Opportunism
I began working in the call centre of a bank whose head office happened to be in my home town. Initially employed to answer banking and credit card enquiries, I stayed late into the evening, using the free in house training centre to get qualifications in various useful things.
At some point, it became apparent that the call centre had no way to forecast call volumes and optimise staffing levels. So, I volunteered to build a tool in my spare time. Through lack of knowing any better, I did this in Microsoft Excel using the worksheets as a kind of Heath Robinson RDBMS and Visual Basic for Applications for the logic. Users had to be extremely careful with this tool, as errors in data entry could have wide-ranging and curious side-effects. In short, it was a fairly insane (if novel) design and far from a professional product. In spite of all that it had genuine business value and was used in the two call centres which between them handled all the UK calls for retail banking for the bank.
Primary lessons: There is no direct relationship between the technical quality of a tool and its business value. Seeing something you have invented making a positive difference to its users is very satisfying.
1998–2001: Semi Professional
Spurred on by my crazy tool and burnt-out from the call centre environment, I applied for a programming job in the IT division of the bank, specifically the ATM management division. I somehow managed to do enough at interview to secure the position, and saw at once that being a programmer was where it was at: autonomy, respect and a culture of learning.
My first task was to build a system to manage the data being generated by the chip and PIN trial at the bank. Now that I was in the IT division, I had access to more tools, including the desktop database Microsoft Access.
Access is a hybrid RDBMS and forms designer which could have been used to build the whole product, which would have been the usual approach to such a small-scale system. Having explored it, I decided that I could offer a better user experience by using only the RDBMS part of Access and developing a custom user interface in Visual Basic. So, that’s what I did (thanks to the support of my boss). At this point, I was still learning how to implement basic control of flow structures, and improving my understanding of data structures, both on disk and in-memory. I was still quite bad, really.
Nevertheless, the flexibility afforded by my choice to go with custom code, and the time I spent driving to meet the users and understand their needs, means I end up building something much nicer to use than a standard Access product, and hence the tool is a success in the eyes of those who matter most: its users.
I also get my first experience of debugging someone else’s code. Excitingly this involved:
Working on code which was actually running on the ATM network.
Calling the tape library to get code loaded from and to the mainframe.
Working in a different language: COBOL.
For personal reasons I chose to leave and move to London. I still have very fond memories of this job and the team at ATM Systems, Shenley Wood.
Primary lessons: Spend as much time with your users as possible. Have the confidence of your convictions and don’t be afraid to argue your case.
2001–2005: Professional
The dotcom boom means that any half-decent (a generous appraisal of my skill at the time, no doubt) programmer can go freelance. With my youthful financial mismanagement putting me into debt, it was an easy choice to make. So I put the feelers out and after a few weeks have a position paying me triple my permanent salary.
My first contract is with a company who are building an e-commerce platform and want to use my card payments background to sort out their payment gateway integration. The company is mad and brilliant, but their product is too far ahead of the market, and they spend their funding and go pop.
I get involved in many other interesting things, the vast majority of which are in the asset finance sector. By the end of this period, I am fairly and squarely specialised in entity-relationship design and databases.
Primary lessons: Fake it till you make it. Data is the foundation of all business programming, and luckily understanding data is fascinating.
2006–2012: Programmer++
Once I was capable of expressing myself well in code and had developed not only programming but analysis, communication, documentation, debugging etc. what should come next? I imagine every person’s answer to this question would be different, and I’m sure there is no right answer. My answer was to continue developing my commercial awareness in asset finance, so I could bring more to each project than just my technical skills.
This enabled me to have a richer and more varied career than staying entirely within the technical function. I helped to deliver some very large projects, did a law degree in my spare time (amazingly useful), and learnt what non-technical factors are important when trying to get projects delivered.
Early on in this period, I ensure a 4-hour daily commute by train. This is unpleasant, but it gives me lots of dead time to fill. I decide to fill it by building some software.
Primary lessons: There aren’t many people who want to bridge the commercial and technical sides of projects. If you want to do things that few other people do, you’ll always find interesting things to do. If you have dead time, fill it with productive activity.
2013 onward: Founder
The software I started during my commute continues to develop, and eventually gets to the point where I consider what it could be used for, so I start a company. After a couple of years searching for product-market fit, we find it and now my amazing team and I spend our time serving our hundreds of happy users.
Our product is never going to have a million users, or make me a billionaire, but there is still great satisfaction in walking onto a customer site and seeing something you’ve invented being used. All of the lessons I’ve learnt at every stage have been vital to getting this far, and I can’t wait to see what the next 30 years bring!
Primary lessons: If you can find yourself a niche with a need that isn’t being served, and you can write some software to address that need, you should be able to get a small company off the ground. Niches are good, because large competitors aren’t interested in them.
Summary
I consider myself so fortunate to have a career that I love, and so grateful to all the people who have made it possible: from my mother who let me play on and program my computer for as long as I needed, to all the colleagues who have helped me learn, to my wife for being there when the stresses of a startup get too much, and to my team for just being all round incredible.
The resources available today were unimaginable when I began — whether that’s a good thing or not I don’t know. I do know that the lack of a formal background in computing shouldn’t stop anyone: so if you’re thinking about how to get into software, find yourself something to play with and just go for it!
