Gabriel began his career working at a small pharmaceuticals firm in Cambridge. His curiosity for deeper understanding led him to complete a PhD, where he discovered a passion for coding that steered him towards his current software engineering role at Cambridge Kinetics. In this blog, Gabriel shares insights into his day-to-day work and practical tips for those also exploring a career in tech.
What is your role and journey?
I’m a software engineer at Cambridge Kinetics. I translate and build client requests into features that also support our longer-term product goals. Equally important is an organisational coordination role: tracking incoming tasks, managing deadlines and distributing work so colleagues aren’t overloaded. Both strands are demanding and require different skills.
I enjoyed tinkering with computers at school, but never saw a clear route into software, the most technical subject available at school was basic IT, not programming. I studied biochemistry because I liked science and maths, then worked in a small Cambridge pharmaceuticals firm on Alzheimer’s and Parkinson’s projects. The work was interesting but often felt like shooting in the dark.
That led me to start a PhD to deepen my understanding. The first year was challenging, but it forced me to consider whether lab life was right for me. I found I preferred problems that involved logic and variable manipulation. A short Python course for data analysis in the PhD exposed me to programming, which I enjoyed far more than lab work, I spent my evenings coding for fun. That experience showed me a different path.
Early in this role, I felt intimidated by how much I didn’t know and hesitant to ask questions. Over time, I relearned an important lesson from previous jobs; it’s not the unknown that’s daunting, but the reluctance to seek answers. Becoming comfortable asking the team and learning incrementally made the transition manageable and the work far more rewarding.
How long have you been at Cambridge Kinetics?
Pretty much exactly a year. It’s impossible to expect to know everything when you move to a new industry, as most learning happens on the job. Projecting confidence helps: if colleagues believe you can pick things up, you start to believe it yourself, and that creates a positive, self-reinforcing cycle.
Walk me through a typical day.
I usually arrive between 8:15-8:30 to get my bearings, plan the day and ensure the dev team has direction when they arrive. This avoids wasted minutes while colleagues wait for guidance.
On a standard day, my day is split into three sections. A large proportion is spent on one principal feature: design, implementation, iterative testing and careful integration to avoid regressions. Secondly, time spent on bug fixes, responding to review comments and conducting peer code review. Reviewing others’ work can feel intimidating, you want to make sure before challenging a colleague, but it’s one of the fastest ways to learn by seeing different approaches and better practices. Thirdly, I appreciate the further responsibility of project tracking, especially as someone new. I monitor progress against client goals and deadlines; if timelines slip, we reprioritise, reassign work or I’ll jump in to lend a hand myself. Coordination demands clear communication and tact, moving work forward without micromanaging or stepping on toes often harder than the technical tasks.
Recently, I have started to go on site with clients to set up their system and show how it maps to their progresses. Our software is versatile, straightforward to use but deeper as you learn it. I enjoy seeing the workflows first-hand on site and the reveal of which features truly matter to clients as this reshapes how we prioritise development: it’s interesting to see that what seems minor to developers can be transformative for users.
How would you describe the team culture at Cambridge Kinetics?
The culture is proactive and mission driven. We move at a supported fast pace that aims to bring everyone along. Compared to previous roles, there’s less complacency: people focus on clear goals and momentum rather than resting on laurels. That atmosphere is intentional: leadership, particularly Jason, keeps the team aligned and confident. The dev side is relatively young and energetic, which fuels collaboration and continuous learning, while other parts of the business contribute broader experience. Overall, it’s a driven environment that balances ambition with support.
What practical advice would you give undergraduates who want to follow the same career path as you?
Don’t assume your degree locks you in. It’s perfectly normal, and common, to change direction. The vital qualities are a willingness to learn and to adapt.
If you can, get experience early: internships, volunteer roles or short-term placements help you understand industry expectations. Employers value evidence of initiative; I was fortunate Jason took a chance on me, as many firms prefer candidates who’ve shown practical interest.
Learn fundamentals, basic data structures and testing, and practice explaining technical ideas clearly.
For software specifically, you can gain experience independently. Build small projects, iterate on them, and put the code on GitHub. It needn’t be perfect: employers look for progress, curiosity and the habit of improving work over-time.
Learn fundamentals, basic data structures and testing, and practice explaining technical ideas clearly. Ultimately, persistence and deliberate practice matter more than a single course: small, steady improvements compound into real capability.