My first 6 months as an apprentice at endjin
I am now over 6 months into my software engineering apprenticeship here at endjin. Similar to my first of these reflection-style posts, I will be sharing my experiences from these past 6 months and using this post as an opportunity to reflect and look to the future.
As a reminder: I joined endjin's software engineering apprenticeship scheme at the beginning of September 2021; it's a highly learning-oriented scheme, with half of an apprentice's time in their first year dedicated to training. In my month-1 retrospective post I spoke about the focus of that training being on core topics related to the work we do at endjin, namely C# fundamentals, Azure fundamentals, and working with Git and GitHub.
In that post I also spoke about my expectations and experience of working from home (endjin is a fully remote company), my looking forward to getting involved with real projects, and my intention to work on figuring out my interests across the different aspects of endjin's technological expertise: data, engineering, DevOps, etc. I will share my experience and the developments from the past 5 months in relation to those themes in this post.
The last six months
As I mentioned, the first month of my apprenticeship was focused on onboarding type activities and, in terms of training, getting to grips with the software engineering essentials. Towards the end of month one, us apprentices were able apply some of that learning through an internal development project – partially re-implementing our in-house 'content platform' application used for publishing our two weekly newsletters: Azure Weekly and Power BI Weekly. This was the first time I had come across and participated in pair/group programming, which I initially thought was a strange concept, as I guess I had come to believe that coding was something to be done independently. But it works – one person can type, whilst the other(s) can do most of the thinking, and ideas can bounce around freely.
After completing the assigned courses covering the very basics, my training ventured into more specific topics that I had come across and wanted to study in more depth. For instance, dependency injection (DI), which is a programming model that was littered all over the code base of the content platform we were working on, but was something I couldn't quite wrap my head around. When it did finally click, I began to realise why it was used a great deal and that it is very powerful, and in fact that has served me quite well as it's now obvious that DI is a core concept and is used quite extensively. Also, DI is closely related some other key programming principles, such as the dependency inversion principle, the single responsibility principle, and the open/closed principle, and so, in addition to learning about an important topic in itself, studying DI introduced me to these essentials.
Another more specific topic that I explored was containerisation and Docker. Docker and containers were things I had heard about quite a bit before coming to endjin; it was, and is, clearly a topic with a lot of excitement around it and so I was eager to explore the space.
Blogging and presenting
Around this time us apprentices were being encouraged to write blog posts and present at our weekly 'show and tell' sessions every Friday, as a way to demonstrate our learnings and to practice the basic skills of articulating your understanding to others through talking and writing. On the blogging side, an internal blog site was setup for the apprentices to publish to – removing some of the nervousness associated with publishing content for the world to see. My first public blog post (after the month-1 retrospective) – on containers and Docker – initially appeared there before being tidied-up a bit and moved to the public site.
Presenting, and speaking in front of multiple people in general, are historically things that I have not particularly enjoyed and would have much preferred to not have to do, at the time. However, my feelings are quite different now – after talking at the 'show and tell' sessions every week for a number of months I feel more comfortable, and even find it enjoyable when I have something interesting to talk about. Furthermore, I have found that the process of preparing a presentation, and actually giving it, forces you to understand the topic you're talking about; it highlights assumptions made in your understanding that you might otherwise have overlooked. Preparing and giving presentations therefore helps you internalise concepts, and you ultimately come out with a better understanding of the topic. Writing is much the same, and I intend to continue to use both as tools for learning.
After working on the 'content platform' with the other apprentices, our next involvement with project-type work consisted of shadowing other endjineers, with each apprentice assigned to their own endjineer. I was paired up with Mike, and shadowed him working on a long-running project for around 2 months. This was the first time I got to see how endjin as a team interact with a current client, and how a software development team is managed on a development project. The project was managed on the endjin side with a scrum-style framework – daily stand-ups, weekly retrospectives, maintaining a product backlog, etc.
Scrum, agile and lean were things I had heard about in general conversations within in endjin but had never really seen in practice; it was interesting to see some of these concepts applied in a real project. I got to see the approach to tackling a piece of work whereby it's split up into small programming tasks, each assigned to individuals; each task is approached by first writing the unit tests (or BDD specs), then the code to satisfy the tests, followed by pushing up the code to version control, which automatically triggers a build and test runs in the cloud. I find this process of small iterative, well-tested changes, with continuous testing and building, conceptually appealing.
There are quite a few books on the apprentice training backlog to get through, and I like to read but I never seem to get around to doing it. So, I wanted to develop a daily reading habit - which I did towards the end of last year. The habit was simply to read for 30 minutes of a morning, whilst drinking my coffee, before sitting at my desk to properly start work.
The first book out of the training backlog I picked up, and starting implementing my daily reading habit with, was The Pragmatic Programmer, which is a essentially a collection of tips and tricks for becoming a competent (or pragmatic) developer. It's very informal and approachable - using analogies to explain concepts, and covers a broad range of topics from advice around how to stay relevant within tech by investing time in learning throughout your career, to software architecture concepts and managing teams of developers. I really enjoyed reading the book and learned a lot from it; it kind-of formalised and elucidated many of the concepts and ideas that were implicit in most of the conversations happening within endjin. For example, the concept of decoupling software components and the benefits it yields, or the importance of having end-user requirements which need to be mapped to requirements of the software, or the benefits of having automated build and release processes, or the essence of agile software development, and more!
A pleasing thing about having implemented a reading habit and finished a book as a result, is that it reinforces the validity of the idea in my mind that small regular improvements (or bits of progress) over a length of time yield large results – which I like.
More recently in these calls, me and Ian have been working on an outstanding task for one of endjin's internal pieces of software used for managing project finances – 'conning tower'. The web app had a small issue whereby it insisted on the user logging in twice, as a result of the front-end and back-end of the app authenticating separately. Microsoft has libraries for handling situations of this nature and so it seemed like it would be a relatively straight-forward fix, however that hasn't been the case as those libraries do not a do a good job of handling the specific situation we have. I think that has made our sessions on this more interesting; we have ventured down a number of interesting rabbit holes and, as a result, the process has been very educational for me.
I have been able to encounter things – processes, tricks and shortcuts – that I think you generally otherwise wouldn't without quite a bit of experience of doing, and that's purely a consequence of me piggybacking on Ian's great experience. I'm thinking here of things like understanding and navigating the many features of visual studio, like using function break points, stepping through external libraries, and the many useful keyboard shortcuts of Visual Studio; or inspecting dotnet Intermediate Language (IL) code; or navigating some of the difficulties inherent in debugging asynchronous code. All the while, I've been able to ask Ian questions about these things as we're going through them.
Training - the Web
Coming back to my training activities. Unsurprisingly, technologies and topics closely related to the Internet and the web are plentiful in the apprenticeship training backlog – everything Azure related, web development technologies like ASP.NET, REST principles, and so on.
I think it's obvious that the web is absolutely essential to much of the work we do, and increasingly so. I, therefore, figured that it would be useful (and probably a necessity) to understand what the Internet and the web are, and how they actually work. As such, I spent quite a bit of time to this end – in addition to working through the ASP.NET Core Fundamentals course on Pluralsight – and produced some blog content out of it – one of which is on the endjin website (here), with two others on their way. I recently finished that ASP.NET course and overall I enjoyed it; I'm glad I did go through the effort of understanding the foundations of the web, otherwise I think much of that course would have seemed like magic.
Training - coming back to C#
After finishing The Pragmatic Programmer a couple of months ago, I moved on to Ian's Programming C# 8.0, which is excellent. Doing so was the first time I had focused on a purely C# training item since the "C# Fundamentals" course in months 1 & 2. In between then I was conscious that I didn't have a strong grasp of the language and that I wasn't writing code and experimenting regularly, which (to the point earlier) I thought I should be to keep the learning momentum going - hence starting the book.
The rate of progress through this book, as you can imagine, is somewhat less than that for The Pragmatic Programmer. However, I'm enjoying the book and hoping that there are many blog posts to come out of it!
On working from home
I mentioned in my month-1 retrospective post that I was, at the time, enjoying working from home, but that I may want to get out of the house more. My thoughts on that front haven't changed much. Most recently (probably the last three months) I have worked exclusively from home, and I'm still enjoying it. With that being said, I do sometimes wonder whether it's now purely a convenience and habitual thing, and whether I would benefit from working out of a co-working space a couple of days per week. I'm glad I have the flexibility to do that at endjin, and perhaps I will.
With being more involved in ongoing projects, I'm eager to let the associated activities dictate somewhat the trajectory of my training so that those two main efforts are complimenting one another, I feel it would be a missed opportunity otherwise. At the minute that means some of my training is around using Azure Monitor and Application Insights to understand the performance of applications.
One thing I would like, and plan, to work on is being a more productive blogger. I mentioned earlier that I feel that blogging and presenting are great tools for helping you to consolidate your understanding, however I'm excruciatingly slow when it comes to writing, and I would like to remedy that. On that front, something I intend to try is implementing a habit of regular writing, similar to the reading one.
I mentioned in my month-1 retrospective post that I came into the apprenticeship with a strong interest in data science, and whilst that is still true, I have thoroughly enjoyed getting to grips with some of the more pure software engineering topics, like asynchronous programming and networks. And, although I haven't done much DevOps in my training, I have listened in on a number of endjin's twice-weekly DevOps IP calls, and that's a side of things I also find interesting and would like to explore more.
So, in terms of finding the areas of the business that I'm most interested in, I'm still in the process of figuring that out. I also think it's dependent on what type of project work you're involved in, and so I'll see how my thinking on the matter changes as I get involved in different types of projects over time.
Overall I'm very much enjoying myself at endjin and looking forward to learning more and contributing more to the team.