My first year as an Apprentice Engineer
And just like that, another six months have gone by, and I have now completed my first year as an Apprentice Engineer at endjin! Before I get sucked into the new challenges that this second year is going to bring, let me reflect on what has happened in the past year, and what I have learnt from it.
Learning new skills, and proving them
Learning the basics
I have mentioned this already in my other retrospective blog posts, but training is the most important aspect of the first year as an apprentice at endjin. This evolved from the most basic concepts of software engineering and programming to web development and DevOps by the end of the year. I started by learning how to use the most important developer tools I now use on a daily basis, such as Visual Studio, Visual Studio Code, debugging, and source control using GitHub, all while trying to get to grips with the basics of C#.
Not only did I learn the basics of the technologies I now work with everyday, but during this time, I learnt the basics of how to learn and work effectively. During the first few months of the apprenticeship I realised how many different things I had to learn and focus on. This can feel overwhelming if you're trying to divide your day into short amounts of time. Instead, I have found I work better if I spend bigger chunks of time on a topic. I usually have other commitments during the day, such as team meetings and project work, so devoting the rest of my time to one single topic makes it easier for me to context switch.
Becoming a well rounded engineer
Once that initial initial shock was over and my use of shortcuts was more acceptable, I had more freedom as to what I wanted to learn next. One of the client projects I was starting to get involved in at that time required me to learn how to use Power BI and DAX very quickly, so that took priority for a while. I discovered the importance of evaluation contexts in DAX and how these affect the output of all your calculations. I was also introduced to the best practices of designing data models. Using star schemas is recommended for Power BI, as it provides the best performance and flexibility. Even if it's not that obvious, you can even filter unrelated tables in Power BI when using a star schema.
However, I made a commitment to becoming a well rounded engineer and not forget all the progress I had made while learning C# in the first few months. With this in mind, I decided that learning more about the .NET framework was the natural continuation of my C# adventures. I completed a few training courses that covered some of the most important concepts of using ASP.NET Core to build applications, such as model binding, dependency injection, middleware, razor pages, the MVC pattern, and others. I also had the chance to delve into NuGet packages and Source Link and understand how debugging works.
Although I was introduced to Visual Studio and Visual Studio very early on, I only learnt how to properly use some of their more advanced functionalities later on. For instance, Visual Studio contains debugging tools that go well beyond setting breakpoints. I learnt about conditional breakpoints, trace points, or how to debug programmatically using the methods in the System.Diagnostics namespace.
I had a similar experience with Git. I learnt about it within the first two months, but I only became more familiar with it through experience. Merge conflicts are annoying, but also inevitable and useful to learn how to deal with them more quickly!
More generally, my first year also involved getting to grips with more traditional IT skills such as Word, PowerPoints, Excel, Teams and Slack. We use Slack as our main channel of communication including all its features, such as huddles. Another two tools I use often are Camtasia and Snagit. Camtasia is a video recording and editing tool, while Snagit is an image and video capturing tool. Often, providing work updates is more effective in the form of a video. I've also found that recording short videos or GIFs is useful to remember how to use a certain tool in the future, as they're easy to play back.
As you can see, the range of technologies we use is very broad, just like the skills required to become a well-rounded engineer. At endjin, apart from being engineers/developers, we are also consultants. This means we need to not only master certain technical skills, but we also need to hone our communication skills, attention to detail, time management, and interpersonal relationships. The skills required to gather requirements and ask the right questions while doing so, develop solutions, provide constant updates and progress reports, mentor clients, test code, and provide consulting services are very diverse.
An introduction to DevOps
The last few months of the year have changed the direction of my training a bit. Truth is, my training will always be somewhat dictated by what's going on at endjin. Lately, I have been involved in a couple of internal projects that have pushed me out of my comfort zone by providing me with an introduction to some DevOps practices, like the use of containers and generating ARM templates using Bicep. Although I had been working with containers for a while when using dev containers to work with Python, I only later learnt what they are and why they are useful. A container is a unit of software that contains packaged code with all its dependencies. Using containers removes some of the struggles that come with running software, such as downloading it, installing it and its dependencies, and running it. I'll leave Liam Mooney's blog post here for a more detailed introduction. Working with ARM templates, however, was completely new. The Azure Resource Manager (ARM) is used for provisioning and managing resources within Azure. Bicep is a relatively new domain-specific language used to define the resources that need to be deployed to Azure. Compiling a bicep file generates a JSON file, called an ARM template. The ARM template contains the definition of the resource and configuration you want to deploy in a declarative syntax, meaning you only need to define what you want to deploy, not how.
The learning process
Learning so many new concepts in depth requires quite a bit of solo studying. With the help of learning courses, either in video or written format, I first build up my knowledge on the basics of new technologies. I then try to put these concepts to practice through learning exercises such as building small web applications.
But training is not always a lonely exercise as it is complimented with plenty of support from others at endjin. Catch ups with different groups are useful in different ways. In my weekly catch ups with Ian Griffiths, I have the chance to ask any technical questions I have. Most of the time, the topic of these sessions is planned in advance and we cover a topic in depth for an hour. Other times though, they can be more spontaneous and we cover a wide range of topics during the session, something similar to an “office hour” at university. I also catch up with James Broome fortnightly, and these are less technical and more management oriented, where I get guidance on how to manage my time and set my priorities, and ask any questions I have. The apprentices have a weekly catch up where we share what we are up to, share learning tips, and update each other on what we are each working on.
Blogging
Blogging has been an essential part of my learning this year. We are encouraged to write blog posts about topics we find interesting or are learning about to consolidate our knowledge. I don't think I generally struggle with writing, but when I do, it's usually for one of two reasons: (1) I am not understanding what I'm writing about, hence I don't know how to talk about it, or (2) I haven't properly understood the purpose of the topic I'm writing about. When that happens, I get the feeling that my post is uninteresting and stop writing. These two reasons highlight how blogging is useful in the learning process – it provides a way to measure understanding.
I have written 14 blog posts in the past 12 months. During this time, I have sometimes written one blog post a week, and sometimes nothing at all for a month. This proves my point above – I struggle to write about topics I find challenging, but I'll easily write about topics I am eager to research and understand. This calls for a change of strategy. Instead of writing once I have understood the topic already, I should try writing to build my understanding.
Regardless, I hope they are somewhat useful for those of you who read them!
Earning a Microsoft certification
I have also mentioned in other blog posts the different ways in which we are encouraged to share our learnings as part of our learning process. This usually takes the form of a blog post or a short presentation during our end of week, company-wide show and tell sessions. I recently had the opportunity to prove my skills in yet a different format – earning a Microsoft certification. After months of using Power BI and learning DAX, I was challenged to pass the PL-300: Microsoft Power BI Data Analyst exam. Preparing for the exam helped me consolidate my knowledge in some concepts I wasn't that comfortable with, such as managing workspaces. I wrote a blog post explaining some of the techniques I found useful when preparing for the exam that could be interesting to anyone else in a similar situation.
Working on projects, both internally and externally
Although my main focus in first year was training, I got a lot more exposure to client work than I was expecting. This involved attending meetings, creating and managing work backlogs, communicating with our clients, and being involved in the development lifecycle. Through this, I have learnt the benefits of following the agile methodology, teamwork, and the importance of the work done prospectively and retrospectively.
The agile methodology
The agile methodology consists of following a set of short iterations during a project. At endjin, we usually work in weekly iterations, which creates shorter feedback loops and allows us to set specific goals for each iteration. Following this methodology, I have also learnt how important planning and estimation is. Overestimating what can be achieved in a week is a common mistake, especially at the beginning of projects. That is also why planning should be an iterative process itself. Reviewing the work backlog consistently lets you update it once you have more visibility on the real complexity of tasks at hand.
One thing we always ask from our customers is honesty in their feedback from the very early stages of the development lifecycle. Feedback, good or bad, is useful. We want to get the direction of our efforts right as soon as we can, avoiding the frustration of having to rethink a solution once it's almost built. The agile methodology helps with this by providing regular checkpoints where everyone has the chance to review the work done.
Teamwork
Quoting teamwork as one of the skills I have learnt by working on projects sounds obvious, but it is not so obvious to know how to distinguish when teamwork is necessary and when it's not. Planning a project, working on one of the elements of the project while taking into account how it will affect other parts, and asking or receiving help when stuck requires teamwork. It is key, however, to also understand how important your individual contributions are. Everything is reviewed before it goes into development, but by being responsible of the quality of your work, this process goes faster. Equally, it is every individual's responsibility to give updates on the progress of their work, or ask for help when stuck.
There wasn't much teamwork involved in my mathematics degree, especially because the one group project we were supposed to do was cancelled because of Covid. That's probably why I desperately tried to be a part of a sports team during university! Now, although I appreciate my own time and making individual contributions, I'm so glad my job involves constant collaboration with others. Although I must admit I felt nervous at the beginning due to my inexperience with the technologies we were using, I found that the key to a successful team is transparency. No one is expected to get everything right from the beginning, but being open about your progress and any difficulties you're facing is essential.
We combine individual work, pairing, and swarming. Pairing typically happens when a task requires more problem solving than usual and brainstorming will help, or when a piece of work requires skills that different people possess. Time boxing the work helps keeping the objectives of the session clear and not loosing focus, as pairing can be tiring. A different way of collaborating is swarming, when one person focuses on a task but gets help from different people throughout the process. Again, this is achieved through effective communication, knowing when to stop doing research on your own and ask for help.
Work continues beyond delivery weeks
The work we produce for a project is not limited to what produce during the strict delivery of the project. There is a continuous backlog of work to ensure we stay on top of new technologies by researching and testing them. That way, we can create our own opinions on what to advise our clients based on our research. Equally, there's work to do after the end of a project. We run retrospective sessions after every project. In these, we review how the project went, and it usually involves consolidating any bits of IP or learnings to make them easily available if needed in the future. A lot of blog posts come out of this process as well – the challenges encountered during a project and the learnings we get from them can be useful to others and help in future situations.
From student to working professional, a smooth transition?
My first year as an apprentice at endjin was also a big change in my life. Transitioning from being a student to working full time has felt both natural and also disruptive. On the one hand, working suits my strengths much more than being a student. I appreciate the collaborative and multidisciplinary nature of being a consultant and I like the balance of learning and applying what I learn to help our clients. On the other hand, it took a while to get used to having a structured working week. It's easy to let your life revolve around work during the week and forget about other activities. After a few weeks of falling into that trap, I started being more deliberate about planning my time outside of work.
Balancing work and your personal life is easier when your work environment provides flexibility. Endjin has been a remote company since 2017, giving its employees the power to decide where they work best. I have chosen to work from a co-working space, as I like having separate spaces for work and my free time. I had the freedom to choose a space that was convenient, which for me meant a space close to home, with spacious facilities. I always know I can stay at home if I want to, or even work from abroad for a few weeks a year.
What can I expect in the next year of the Apprenticeship?
The learning curve in the last year was steep but I have enjoyed seeing how my confidence has grown alongside it. Improving my technical skills has allowed me to contribute in group discussions and express my opinions in an informed manner. I have particularly enjoyed learning about ASP.NET Core and experimenting with it by building small applications to test the different concepts I was learning. It has also been rewarding to see how I have been able to use my technical skills to help clients achieve their goals. I have experienced this when using DAX and Power BI to build insightful reports.
While this year has been a lot about figuring out how endjin works, how our customers work, and how the world of technology works, I expect next year to be about figuring out how I work within this space. As I'm given more responsibility, time management will gain importance. I will need to include planning, estimation, and prioritisation - which are key when planning for a project - to my daily routine to manage all my tasks. Being able to manage both training and project work simultaneously is an important skill not only as an apprentice, but for the rest of my career. Staying up to date with new technologies and mastering new skills is key for staying relevant in the technology sector.
