Just over a year ago, when I received the phone call with a job offer, I was delighted. My four years of Computer Science at Uni had paid off and I – well, my mum – could tell everyone I was going to be a “Graduate Trainee Software Engineer”. But when a friend soon asked me, “Well what exactly will you be doing then?”, I suddenly realised I couldn’t really give a proper answer. What would I be doing on a day-to-day basis? Would I just be sitting in front of a computer coding all day? Would I be working in a team? Would I enjoy it? Would I fit in?

So now eight months into the job, I wanted to set out answering that elusive question “What is it you actually do?”. I’m finally ready to give my friend – and hopefully a few others too – a proper answer!

First things first

First things first, a bit about Kainos and the specific project I’m working on. The majority of Kainos projects essentially go like this: client asks us to build something, we build it. Some projects we take charge of the complete software lifecycle, from user research to development to testing. Other projects are more “supporting” roles where we lend a hand to an existing client team. Kainos has a particularly strong reputation in the public sector, working on projects with various government departments – notable success stories include overhauling the mainframe-based MOT system and transforming the online register to vote service.

The project I’ve been on since starting is more the “support” kind, working alongside a public sector client’s existing team. That makes the team on our end fairly small – four developers, a tester and a scrum master. Without getting into the politics of it, the software being developed is essentially an online user registration and account management system. It’ll allow businesses and individuals to register and manage a “single sign-on” account for multiple digital services. It looks much like many online government systems you might be familiar with, such as for paying your road tax or applying for a passport. The technologies we’re working with are the usual web dev suspects – HTML/CSS/Javascript with the backend running on Node.js.

If I’d thought I was going to be just sitting in front of a computer coding all day, I couldn’t be more wrong! There is quite a bit more to the job than just that, with lots of variety to our everyday activities. A big chunk of time is simply communicating with the rest of the team. That may be working together on a task (occasionally ‘pair programming’), discussing/designing a solution to a problem, having meetings, shadowing others to learn more about something, or simply catching up with what everyone’s been up to.

‘Doing Agile’ vs actually doing Agile

Most fundamental to the way we work as a team is agile. And this time it’s not like a group project at Uni where you just pretend you’re doing agile without understanding what it really is ?. We do agile properly. We have a dedicated “Agile Team Lead” – a scrum master who’s an expert in all things scrum and agile. And our entire way of working is built around a number of scrum “activities”. The most important of these is our daily stand-up. Every morning, as a team we all stand around our scrum task board and each answer three questions: (1) What did I do yesterday? (2) What am I going to do today? (3) Do I have any impediments? We move any tasks across the board if their status has changed since yesterday. This is really useful for self-organising the team’s work as well as holding yourself and others to account. It also provides a daily opportunity to raise any issues to discuss with the team.

This ties in with us working in two-week “sprints”. At the start of each sprint, we have a team “refinement session” where we plan which “user stories” we’re going to commit to from the backlog. A story is just a description, from the perspective of a user, of a feature to be implemented in the system. This could be as simple as changing the wording on a page or fixing a bug, or something more interesting like pulling in some text from a Sharepoint document. To try and quantify the “size” of a story, we assign it a number of points. Then, after making sure we all fully understand what’s wanted from each story, we commit to a number of stories that we believe we can deliver in the sprint.

After this we organise ourselves as a team to work out who’s going to work on what. This team “self-organisation” is something that took me a bit of getting used to. When I first started, I felt like I should be waiting around for someone to tell me what to do, expecting tasks would be delegated across the team. What I soon realised is that this is not how an agile team operates. Instead, it’s generally up to you to choose the tasks or stories you want to pick up. Nobody is dictating what you do, so you can decide what you’re best working on and negotiate this as a whole team to everyone’s advantage.

Another big chunk of our time is spent liaising with the client. We do our story refinement with our “Product Owner” on the client’s side, so we can ask questions and work out exactly what they want doing. And then throughout a sprint, as stories are completed, we arrange demos via screenshare so that the Product Owner can approve what we’ve done or ask us to go back and make a change. We also take part in a fortnightly ‘Show & Tell’ where all the teams on our project each demo their work on a big conference call to different stakeholders (including some scary “higher-ups”). This is what makes the job more than just technical skills and programming – soft skills like writing, demoing and presenting – the horror – are equally important. There was a big emphasis on this during our 7-week training course which all trainees undertake when starting. As well as all the technical stuff, we had to do practice presentations and even a mock phone call with a pretend client!

Considering the overhead of everything else we get up to, the time I get to actually knuckle down to some proper coding is often a smaller proportion of the day than you might imagine. But to give a simple example of a bit of something I’ve worked on, we had a story to implement an autocomplete widget for a ‘country’ form field. When filling in their address, the user is required to pick a country from a fixed list of countries defined in our database. Now, this could just be implemented as a dropdown select box, but that would mean scrolling through a list of around 200 items – not the best user experience. The ask was to convert this to a normal text field which shows suggestions as the user starts typing. My job was to integrate this new feature, making use of an existing autocomplete plugin to save implementing it all from scratch. Still, there was a lot of work to do in terms of matching the sass styles to our project’s styling, implementing validation to stop the user leaving the field blank, and pre-populating the field with the current selection if the user revisits the form. In addition to this, it was essential that the boring non-JS dropdown still worked as a fallback for users who have Javascript disabled for whatever reason.

While this story was mostly a front-end JS exercise, on other stories I’ve worked on a range of different things. There’ve been stories centered around doing back-end work in Node.js, working on front-end HTML templates, writing code to call our external database API, integrating code to produce usage and performance logs, and writing unit and integration tests (yes these actually mean something in the real world ?). More recently I worked on a story to show a landing page to the user if the privacy policy has changed since they last logged in and then updating the record of the version they have accepted (this one was tougher to implement than it sounds!).

Another different but interesting task was tracking down the source of a memory leak one of our performance tools was reporting, which I paired on with a senior developer. It definitely feels like I’m being exposed to all kinds of technical tasks, not just working on the same stuff every day. At the same time, this is only my first project – my trainee friends on other projects are working on all sorts of different stuff in different languages such as Python and Java. I don’t think I’ll be getting bored anytime soon!

Everyone helps each other out

Something else that we fill our time with – albeit not out of choice – is bugs of course! Just running into errors and problems becomes a constant and inevitable time-consumer. As any programmer will know, it’s too easy to understate the amount of time swallowed up just from dealing with what turns out be a very simple issue. There was one time when we spent nearly an entire day trying to work out what we were doing wrong – only to discover that a simple initialisation setting had been changed on the client’s end. The nice thing is these are often the times when the team comes together to help each other out, meaning everyone learns from the experience.

Developing ourselves too, not just a codebase

As a team, we also agree to set aside an afternoon a week for working on our “personal goals”. These are of our own choosing, intended to further our personal development, and are agreed with our manager. We have a fortnightly “one-to-one” with our manager to discuss these goals and any other issues. One of my goals is to do a presentation to the team on a NodeJS topic, as a “knowledge-sharing” session. And my other goal is actually writing this article! This is a really great opportunity to step back a bit from your day-to-day work and focus on your long-term self-development which, after all, is as much an asset to the company as it is to yourself.

The job in a nutshell

So there you have it. The job in a nutshell. It has certainly proved more varied and interesting than I could have imagined. Before starting, I remember thinking how we trainees might just be given some menial tasks or have to shadow senior devs for a while. But even as a trainee, I feel like I’ve been given a lot of responsibility from the get-go. I’ve had the opportunity to get stuck in to some really interesting work and even take the lead on development tasks, while also being able to do things at my own “trainee” pace and get help when I’ve needed it. At the same time, it’s not felt like we haven’t been ready to make a proper contribution – the bespoke 7-week training course prior to starting in the office put all us trainees in a great position to hit the ground running. On top of this, there is a real sense that everyone in the team is treated equally regardless of your position. So even as a trainee, I feel like my input is valued as much as more senior developers. All this adds up to a fulfilling experience where you feel like you’re a worthy team member making a real difference. And most importantly of all, you’re not just a robot churning out code 24/7 to no end – you do get involved in much more than just code!

Find out more about careers in engineering as a grad here.