Happy Friday everyone! I’ve really wondered if I wanted to write about this. I’ve wondered so much that it has actually taken me almost a week to write it. For two reasons:

1. Does anyone actually want to read about a five day Apprenticeship project?
2. Do I want to relive that pain over again?

But last weekend a friend mentioned how she joined the “behind the curtains” viewpoint from developers in the industry. And I’m sure that one day, someone will want to need the reassurance that I wanted when I was starting this project.

A quick overview: this five day project is 40 work hours. Before I started I had already needed to select one specification out of three to build over this period. That meant that I had a vague understanding of what I needed to build. And I also knew I needed to try and do a full 360 degree software development lifecycle.

Carry on reading to find out how I got on:

Day 1

Here we go. It’s the first day of the final project for my apprenticeship. I knew the basics; I had already selected my topic out of three. The goal was to set up a Quiz Manager application, but I did not know the specifics until I had my first kick-off meeting with my apprenticeship co-ordinator. 

That meeting rolled around; I got some paperwork to sign and a copy of the specification document.

It was time to start. I knew I had five days, and I knew the criteria which I should be aiming to demonstrate. It was not expected that I would be able to finish everything. 

First, I had to read through the specification and translate those requirements into tasks to add to a kanban board. I used Notion to create this board because it’s my new favourite app and lets me keep everything in one place. 

For each of the tasks, I added several category tags. These explained which day I planned to get each one worked on, along with which criteria each requirement fell under.

Once I had these tasks set up with their tickets on the kanban board, I knew where to start. That was setting up the user stories, data models, and user flows. These initially planning stages helped me get the right to understand how I would set up the application over the rest of the week.

Day 2

On the second day of my project, I committed to working on the database side of things. Initially, I thought I would only need half a day to a day to work on this. The initial setting up the tables, primary keys and foreign keys were simple enough. However, I ran into a roadblock when I discovered that my SQL Server set up did not allow me to use the query builder tool. That meant I had to create each of the queries for my stored procedures manually, and although this was not a complete disaster, it did add more time than I had planned.

Day 3

As I said, the database side of things took longer than I had initially planned. That is how I found myself starting day three by continuing to work on the database side of things by finishing up the stored procedures.

The next stage was to start coding. Which weirdly was wear the procrastination hit me. So I took a long lunch break to help with the context switching from database to code. When I got back to it, it was time to open Visual Studio and launch a new Blazor project.

I also made sure I had set it up to a GitHub repository to save me from having to worry about losing all of my work! Though version control and working with Git are also some of the criteria, which is a bonus.

Then I had to connect the code with the database side of things, which was interesting. Blazor with authentication automatically sets up the Entity Framework side of things, and I would use an alternative – Dapper. But thankfully, Blazor can use those alongside each other, so I added the Dapper code.