So I lived the Cliche for a while. I commuted to an edgy office in central London and wrote code for a financial tech startup. Why financial tech? Although I had a clinical background, London is a global center for financial tech. Unlike most startups in the NHS that had a few clinical connections, the financial tech startups were getting big partnerships, and the industry just moved at a quicker pace with better tech. Although I love clinical tech and worked on the front line for years, I was at the start of my software engineering career. Coding is transferable, if you’re starting out I’d recommend working for at least a year in a more established field. I still work in financial tech as I have a lot to learn, but I now work as an R&D software engineer on a system that supplies major banks and hedge funds in 40 different countries with data. I’ve swapped the edgy office for a well established one in the center of London opposite the Royal Exchange:
So what have I learned in my time in a startup? Here are 4 things:
The work isn’t in-depth
This clearly varies depending on the startup just like it differs in the field and role of jobs in established companies, however, there are still some generalizations to be made. In a startup, the team is typically small and doesn’t have many resources. The system that you’re working on will most probably not be serving many customers, and there’s a lot of product that has to still be developed. The result, you’ll be covering a lot of ground very quickly. This is great if you want to get a general grounding. One day I was working on back-end algorithms, the next was front-end. However, this also stops you from diving deep into particular fields. Sometimes I read around a field and wanted to optimize my solution only to be told that there wasn’t enough time. This can be frustrating but as a junior, this is actually pretty good. You get a lot of experience quickly in a range of areas. You also end up leading the projects giving you a fast track to responsibility.
Very little formal process
Who likes documenting, following standard coding styles and attending meetings about meetings? ….. Not many people. OK, I’m a little weird for my liking of documentation but the appeal of dodging this stuff isn’t lost on me. This compliments the point of getting a quick all ground grounding. However, it does have its downsides. I realized this when I came across a bunch of spaghetti code that was repeatedly copied and pasted. On top of this, there was no documentation and the guy who had written it had left. You then work overtime, either trying to understand the code and alter it, or completely rewrite the whole base. Rewriting the whole base is a better option if the code is really bad. However, the previous code most probably has multiple iterations, so you’ll be explaining to non-tech people why you’re taking longer. Sometimes the code is so bad, it will be timing out the server when the database scales. So you’ll end up working overtime for no extra pay to put this fire out which leads to the next point.
You will work around the clock
My god you work! There’s a saying:
“entrepreneurs work 80 hours a week to avoid working 40”
A lot of the tasks are reactionary due to corners being skipped earlier on. As a result, you will be working non-stop to patch these whilst trying to develop new features. My shifts in A and E were a cakewalk in terms of hours compared to the time I poured into the startup. You will rarely get paid overtime for those hours. So why do it? You’re part of a tight-knit team. It’s genuinely a pleasure to work with. As pointed out before, you’re also getting a strong all-around grounding. The code you write will be making a big difference to the platform within a few weeks, so you directly see the effect you have on the growth of the company (You get similar addictions when you’re playing a computer game). And finally, you have a chance at equity if the company does well. My social life outside of work took a bit of a hit, but I didn’t regret the hours I put in.
You will not attend many events
This leads on from the previous point. In the startup, we were getting deals with big brands like Vauxhall, Ford, Bently, etc. We were also in talks with a bank to guarantee our cash reserves as a partner, and we were looking at expanding into Europe. The result? Work work work. We didn’t have time to attend multiple events besides, there was no need. I’m mildly guarded of startups that are constantly going to events and pitch days.
So why am I gone? I still need to develop my skills. I want to experience really big data. I want to dive deep into concepts and develop systems that leverage big data. I’d recommend to anyone that they should work for a startup for a least a year in their life. It’s a type of work that I have never experienced before and will stick with me. It’s like one of those action holidays where you go camping, get up early every morning, and go to sleep with aching muscles. Even though a week has gone by it feels like a month, you’ve picked up a bunch of skills very quickly, and you’ve enjoyed every minute of it.
I help clinicians get to grips with coding and tech, I also code for a financial tech firm