Retrospecting on my career at endjin
I joined endjin's apprenticeship program nearly four years ago after finishing my degree in Physics. Now, as I prepare to move on, I wanted to take a moment to reflect on what I've learned, what I've enjoyed, and what I will take with me.
When I look back to the beginning, what I remember most was the feeling of being completely clueless. I'd sit in on conversations and understand none of it — Azure service X, C# feature Y, design pattern Z. It was all a mystery. Over time, though, things gradually started to click. I asked loads of stupid questions, I picked up knowledge through online course, hands-on experience, endless googling of unfamiliar terms and acronyms, and just generally soaking things up through osmosis. Bit by bit, I learned things and it all started to make sense.
Learning might be the main theme of my time at endjin, so I'm going to start with that.
Learning, learning, learning
One of the reasons I joined endjin was because it was clear that they genuinely valued learning and development. And as a recent graduate with a tiny bit of programming experience, that was by far the most important dimension for me. So, I was coming in super keen to learn — and learning was what I got.
As I have described in similar retrospective blog posts, the first year of the apprentice programme is training intensive. Apprentices are given a training backlog of materials and instructed to spend 50% of their working hours on training. There was what felt like a huge amount of content, covering both foundational topics and the specific tools and technologies we use day to day at endjin. The backlog including material on C#, ASP.NET, programming design patterns, Azure, Python (particularly PySpark and Pandas for data engineering), Power BI, DevOps, PowerShell, developer tools (including git, GitHub, Azure DevOps, Visual Studio, and Visual Studio code), Azure Bicep, and probably a load of other things that I'm forgetting.
I remember being excited about discovering a load of new and interesting stuff to learn. I also remember feeling a bit overwhelmed; there was so much material, and I struggled trying to plot a course through it. endjin are big fans of code pairing, and I remember feeling mentally exhausted after pairing sessions early on; it felt like being on the receiving end of an information firehose for a couple of hours, and that was tiring.
There was a strong emphasis on learning the fundamentals. The earliest online courses I took were on C# and ASP.NET. I wanted to understand how the internet worked, which lead me down a computer networking rabbit hole, on which I wrote a blog series. We're big proponents of testing at endjin, particularly the Behaviour Driven Development (BDD) style of testing, so that was also something I learned early on.
Looking back, the steepest learning curve was probably .NET. When I joined, I had a little bit of programming experience with Python from university, but only in a data science/analysis context. Python is beginner-friendly; C# is less so, and it felt very different to me as a complete newbie. Python is also an interpreted language, so you can write some code and just hit "Run". With C#, it's compiled — which immediately raises the question: "What does it mean to compile code?". From that question you're quickly led into a new world of .NET runtimes, how computers actually execute code, and what it really means for a language to be interpreted. That was all great fun to learn, it was just quite a big jump from Python, where all of that was hidden away from me. However, I soon got really into and started reading Ian's programming C# book.
Despite being super excited to learn lots of new stuff, when I look back on that training intensive period, I can't help but feel as though I could have gotten more out of it. I remember reviewing my progress through the training backlog at the end of year one and being disappointed. In retrospect, I think one of main reasons for that is that I was not a very effective learner at work.
Before studying physics at university, I studied maths and physics at A-Level, so when I joined endjin, my approach to learning was firmly shaped by the academic style from those subjects. That meant a very bottom-up mindset, where you start with the fundamentals, and gradually add increasingly complex layers onto the existing base. I think it's a method that works well in academic contexts, but not so well in engineering-focused work, where the goal is to apply knowledge practically. And so, when I was trying to learn something like building a web app with ASP.NET MVC through a Pluralsight course, I found myself frustrated. I was hesitant to move on unless I'd completely understood every single detail in the current chapter, which really slowed me down.
Fortunately, I've since learned more about learning and how I learn best. I now see the value of a more top-down approach — especially when it comes to practical skills like programming. These days, if I'm working through a Pluralsight course, I'll typically watch an entire chapter at 2x speed to get a feel for the content and identify the parts worth digging into. Then I go back through it, video by video, focusing on those key areas, writing the instructor's code for myself, and writing notes to capture my understanding. I've also found that testing yourself — by using flashcards, for example — to be really effective, and ultimately, the best way to learn is by applying the stuff in a project of my own.
As well as learning more about how I learn best, I've also learned more about how I work best. I'd noticed before that I tend to be sharper and more productive in the mornings, but I hadn't really considered the implications. Once I started working, it became obvious: if you want to be productive, you need to align your day with how your mind works. Since I'm sharpest in the mornings, I now reserve that time for the most mentally demanding work — things like coding or writing. In contrast, I tend to push less demanding work, like admin and meetings, into the afternoon, when I'm usually slower.
Actually, my feeling about this has only grown stronger. The biggest takeaway for me has been learning to recognise and embrace the importance of the morning period. That's when the valuable stuff gets done. If I squander that period, it's unlikely I'll get much of substance done for the rest of the day. And if there's a challenging task I really want to complete, I know I need to complete it — or at least most of it — in the morning, or it probably won't get done. It follows that, if I want to do valuable work, then I must protect my attention in the mornings from distractions and the pull of lower-priority work. And that's something I have become much better at.
Another soft skill area I believe I have improved in during my time at endijn is communication. As I have written about before, there's an expectation at endjin that you write and talk about the useful and/or interesting things you have learned or been working on — especially during the apprenticeship period. Thanks to that pressure, I am now a better writer and speaker. Speaking was an area I felt particularly weak in when I joined endjin. Thinking back to the early show & tell sessions, I remember feeling very nervous about speaking in front of the rest of the company. But I got better and less nervous with continued practice. I am by no means a great public speaker, but I'm a lot better than I was.
Through doing much more writing and speaking, I have come to realise that they're kind-of superpowers. A valuable insight for me has been in recognising the value of communication for developing your own thoughts understanding. When you write something non-trivial down, you're not simply transferring information from your brain onto a page or into a document. The process of writing forces your brain to wrestle with the ideas; it highlights your assumptions, where you're lacking information, and logical flaws. This has been enormously valuable to me. And not only for writing intended for public consumption — the vast majority of the stuff I write doesn't appear in messages or blog posts. I now write all the time. After a meeting I capture my thoughts in writing; when I learn something new, I capture my understanding in writing.
One of the most effective uses of writing I've found is when I'm working through a problem or task. Just writing the problem down is incredibly helpful — it's often the very first thing I do, and it usually helps me get over the "getting started" hump. I also like to capture the broader context and any assumptions I'm making. Often when developing, you're trying to troubleshoot an issue or figure out why a system behaves a certain way. When that's the case, I usually write out hypotheses and small experiments to test them — it's a way of probing the system and gradually building up an understanding of what's going on. You can use writing as a tool for more deliberate and clear thinking.
It's fair to say I have learned a lot over the last 3.5 years, but I think the learning didn't really happen by reading and taking Pluralsight courses (that's not to say they were not an important part of the picture, but…), the learning really happened through working on real projects. Also, after my first year, my training was increasingly shaped by project work. So, next I want to talk about my project experience.
Projects
I think my project experience breaks-up into roughly three distinct periods. In my first year, I worked on multiple projects doing a variety of different things — TypeScript development, ASP.NET web app development, UI & load testing, Power Automate, among other things. The next 1.5 years were spent mostly in the data engineering world building data platforms and reporting solutions for clients. During this period, I spent a lot of time inside Azure Synapse writing data pipeline code in Python, and inside Power BI building analytical reports that consumed data coming out the ends of those data pipelines. And finally, the last year I have mostly been in the application development world, spending most of that working in TypeScript/React and C#/ASP.NET.
In terms of project work, the part I enjoyed most was the final — app development — period. There are a few reasons for that. Firstly, they were the most technically challenging projects I worked on, and I enjoyed the challenge of stepping outside and growing my technical capability. Furthermore, they involved working with technologies that I enjoy using and wanted to learn; I learned React and TypeScript in this period, and I really enjoyed bringing a web app frontend to life with React. One aspect that made these projects distinct from others was that they involved building something from nothing — I now realise that I really enjoy that process. And finally, I think these projects came at a point in my career where I started to be able to make real, tangible contributions, and do so mostly independently. In other words, I felt like I was pulling my weight. And that's a nice feeling.
Company, culture and people
Beyond the projects and code, what makes endjin great is the people and culture. As I mentioned, one of the main reasons I wanted to join endjin was because I thought they cared about learning and development. And that has turned out to be true. The people here have genuinely cared about my growth. In addition to the generous training time commitment during the apprenticeship programme, I have had weekly 1-1 access to two of the most senior technical people in the company — Ian Griffiths & James Dawson — in which I could ask them anything I wanted, and from which I have learned a great deal. I have also had regular 1-1 meetings with the company's head of engineering, James Broome, with whom I have had many enlightening conversations on various topics, like time management, project management, communication & writing, and others.
endjin has a culture of deep curiosity, honesty and technical rigour. I've worked alongside people who constantly strive to get at the truth, understand things more clearly, and build the best possible solutions. That mindset really resonated with me — it's a big part of why I've enjoyed my time here.
Key takeaways
If I had to distil my time here into a few key lessons, they would be: always stay curious and communication is as important as code.
While I've learned a great deal over the past three and a half years, I'm constantly reminded of how much more there is to know — and I suspect that feeling never really goes away in this industry. With such a vast and fast-moving landscape, it's clear that curiosity and continuous learning are essential.
The importance of communication is a key takeaway for me because it's the skill that I have come to value far more than when I started. At the start of my career, I would have ranked technical ability above communication in terms of impact — but I have since changed my mind. Clear, thoughtful communication is just as critical.
Looking ahead
As I move onto the next chapter in my career, I do so with deep gratitude for everything I've learned here. I am sad to be leaving but also excited about what's next. To anyone considering joining endjin: you should do it! To my colleagues: thank you!
