My first month-and-a-bit as an apprentice at endjin
I had the pleasure of joining endjin as an apprentice engineer on the 1st September. This is my first ever blog post and in it I will be sharing my experience from this past month-and-a-bit (for those who are interested), it is also a means of helping me to reflect on these early steps of my journey in the world of work in tech, and to help me look to the future.
I studied Physics at University College London, graduating with an MSci degree in the midst of the pandemic in the summer of last year. Throughout my studies I became increasingly interested in programming and data science, this lead me to take up a couple of summer research internships at the end of my second and third years, which I thoroughly enjoyed. My fourth and final year was completely customisable, I had control over all of my modules and choice of masters project topic, which I took advantage of to continue pursuing those interests. By the end of my final year at uni I was set on a career in tech, with a leaning towards data science.
Despite having some programming experience through my studies and those aforementioned summer researched internships, I was conscious that my skills and experience were quite limited for beginning a career as a developer. I was therefore keen to find a company who placed a strong emphasis on the training and development of their graduate employees, but also one that felt the same way as me about the enjoyment of learning new things and the desire to continue doing so throughout one's career.
What this first month-or-so has involved
This opening chapter at endjin has been centred around onboarding-type activities and getting us apprentices up to speed so that we can first of all start to have the faintest idea of what's being talked about day-to-day, and later begin engaging in those conversations, and eventually start doing something useful. This means our training has to be somewhat front-loaded, so that we can meet some sort of minimum threshold of knowledge in order to begin engaging and contributing.
endjin is a technology consultancy firm with expertise in the Microsoft Azure ecosystem, which, consequently, is where most of our work is done. As such, a large portion of my training has been focused on getting to grips with the behemoth that is Azure. To this end I am using a combination of Pluralsight courses, Microsoft Learn materials, and experimentation in the Azure portal. A quick scan through the huge list of Azure solutions and services will likely make your head spin, but once you start exploring the core components things become more coherent and you begin to realise the enormous power of the cloud.
The other core tools/ technologies used at endjin, and which I have also been focusing on, are the C# programming language and the source control tool git, along with its cloud-based counterpart GitHub. All of my programming experience up until endjin has been with Python. For me, C# feels a lot stricter than python. For example, unlike Python, in C# you have to specify the type of a variable when declaring it (known as static typing). You also need to place semi-colons at the end of statements in C#, and it uses curly braces, as opposed to the white space of Python, for organising blocks of code – which feels less clean to me. With that being said though, I am really enjoying learning C# via the excellent C# Fundamentals course by Scott Allen on Pluralsight. Also, learning a new programming language is forcing me to think of things in different ways, and to ask new questions of Python – giving me a better picture of what's going on underneath it all (watch this space for my next blog post on learning C# from a Python perspective).
Git is one of those things you constantly read about at university but never actually use it. However, recognising that it must be important, I did take some time to learn it at the end of my studies. But without the proper environment/ context where you need a certain tool to get things done, you never really understand how to use it, and so I quickly forgot most of git. Now, in an environment where source control and collaboration tools are absolutely essential and used every day, I understand the why and how of Git and GitHub.
This is a common theme when comparing programming in an educational environment to a business one, at least from my experience. My experience of programming at uni was purely interactive; there was no end product to be put into production, there wasn't any users to worry about. Programming in a commercial environment, on the other hand, is all about the end product and the people who will use it, and so there are different considerations and tools to help with those considerations. Testing, for example, is a major consideration in commercial programming. How do you know if your software will work like it's supposed to when in production? Will it break when used in a way that it wasn't meant for?
This last week-or-so us apprentices have been gently let loose on an internal development project, where we can experiment and make mistakes without risk of destroying the company – a great learning environment. Testing has been front-and-centre in what we have done. At first, test driven development, where you first write the tests to validate whether your code meets the requirements of the software and then write the code to pass those tests, seemed back-to-front to me. But when you view it from the perspective that the developer's job is to produce software that meets the requirements of the user – and nothing more – it makes complete sense.
The development process we have used for this particular project is behaviour driven development (BDD), which is a natural extension of TDD. Its aim is to bring about a shared understanding of the needs of the users, which are then mapped to requirements of the solution, which are subsequently mapped to tests of the code. This way the developer is forced to work in such a way that each unit of his/ her work is optimised to delivering the needs of the users.
As well having technical capabilities, endjineers are expected to get involved with the business side of things, such as business development, engaging with clients, understanding legal aspects of the business, and project management. This workload is spread across all endjineers – there are no specific job titles for any of these responsibilities at endjin. And in this area I have sat in (remotely) on a number of business development calls with potential clients and on calls with current clients. This has been a very interesting experience and is definitely not something I expected to be involved in so much at this stage in my career, which I think is indicative of endjin's quite distinctive approach to things. A noteworthy takeaway from my attendance at these meetings, and which is also supported by the many stories about previous clients, is that there is great diversity in the companies that come to endjin for help. This makes me look forward to working on varied and interesting projects in the future.
On working from home
endjin is a fully remote company and before officially starting on 1st September I was certain that I'd rather work out of a co-working space than at home. I was mainly concerned about missing out on much of the social aspects that you would expect from working out of an office.
However, I haven't been working out of a co-working space as I am quite enjoying working from home. Working from home allows me to quickly transition to outside-of-work activities, giving me more time in the evening to spend as I wish. With that being said though, I sometimes find that this transition doesn't happen, resulting in a well-documented criticism of working from home: a weak separation between work and home life.
Despite the many upsides of home working, this is a real (potential) downside and I can definitely see how it can be problematic for people. From my - admittedly brief - experience, this situation can be avoided by forcing yourself to move away from your desk, go outside home and do something. In my case this usually means walking my dog for half an hour.
And as much as I'm currently enjoying working from home, I'm conscious that I have only been doing so for 6 weeks and that things may change. Perhaps in the coming months (especially considering the short days that winter brings) I may want to get out of the house more, be around more people, etc. That's fine, there's a multitude of cafes and co-working spaces to discover and try out. I think it's about discovering what's best for you, your situation and preferences, and I guess I'm still figuring that out. I'm glad I've got the flexibility to do that at endjin.
Looking ahead
My immediate and near term focus is on continuing to get comfortable with the core tools, technologies and concepts. As I do so and become more able, I can progressively move into more project-based learning, which is something I'm looking forward to. I think this is likely where the real learning starts, it also means collaborating more with other endjineers and learning from them, which will be great.
I'm eager to attain a better grasp of the services in Azure, so that I can start building some interesting things in there; I'm particularly interested to explore the AI and machine learning offerings. For C#, I'm looking forward to exploring web programming and particularly the power of it when combined with Azure.
More generally, I'm hoping to explore all the different areas of endjin's technological aptitudes, and to start to figure out the ones I'm most interested in. Right now I'm like a kid in a sweetshop – I want to try everything. Also, going forward, I intend to blog regularly, as a way of helping to consolidate concepts and to produce content to look back on in the future.
Overall I'm feeling very fortunate to be at endjin and I'm excited about getting stuck into these next weeks and months.
