In late July a message dropped into our company-wide chat:
“I’m in touch with someone who is about to start studying Computer Science at A-level and would benefit from real-life experience. Anyone got anything appropriate for them to focus on?”
We had often expressed a desire to support young people in our industry by offering internships or work experience but had yet to pull it off. Now it was happening.
A few days later, the call came to plan a week of work experience that was fun and useful for their career. I raised my hand and jumped straight in. We devised a rough plan based on what we knew:
- Our new colleague’s name was Ben
- Ben had just finished his GCSEs and would soon start A-levels
- He was interested in a career as a software engineer
- He studied Computer Science at GCSE
- And he will continue to study Computer Science at A-level
A quick scan of the GCSE curriculum gave us a rough baseline of what Ben would be capable of, but we didn’t want to make too many assumptions. We devised a plan with enough latitude to be able to adapt to suit Ben’s capabilities and interests.
We knew that whatever we asked Ben to tackle it had to be relevant, fun, and most importantly make a difference. Most people that have written software have felt the joy of seeing something work for the first time (10 PRINT “Hello World”; 20 GOTO 10; RUN) but there is a deeper joy in seeing something that you have created making a difference to people’s lives.
We asked Ben to create a chat bot for Surevine employees that would make it easy to start, stop, and otherwise interact with, the business systems that support our day to day work. To help bootstrap the work and make the most of Ben’s short time with us we created a bare-bones system consisting of a simple chat command and a single API endpoint. The scope of this work had the flexibility we needed for Ben to explore a wide range of disciplines and technologies including systems design and architecture, user research, operations, coding, testing, API interaction, authentication, cloud computing, and more. We were all set for Ben to start. I was to be Ben’s buddy and I couldn’t wait to get started.
Getting started with work experience
To give Ben an appreciation for how a software development team operates the whole team got together at the start of each day to check in and discuss plans. Remote working comes with its own set of challenges, something that I’m sure many people now relate to. The good news for Ben was at Surevine he was working with experts, having been a purely remote company since day one.
As Ben’s buddy, I made a point of calling Ben every day after our team daily. This was partly to break the ice and start the habit of video calling (people are more likely to call you if they’ve already spoken to you), but also to give him the opportunity to chat and seek support if he wanted it. Some days those calls would last a few minutes while others sparked pairing sessions that lasted hours. When we weren’t paired it was encouraging seeing Ben’s messages in our group chat, with general updates and requesting help.
It was great to see how quickly Ben dropped into Surevine’s way of working. His dedication, maturity, and consideration for the wider team was exceptional. It was easy to forget that a few months earlier Ben was studying for exams (congratulations again Ben!).
“Just FYI I have to collect my GCSE results Thursday morning 9-11am, so we’ll have to reschedule Thursday stand-up meeting.”
It was important to me that Ben experienced an unfiltered version of life as a member a software development team. I wasn’t going to hide my workings, or clear down my sprawling collection of browser tabs earned during countless searches for language or library details. I wanted Ben to see that software development isn’t about knowing everything. There is no shame in not knowing and searching for answers is a key skill to develop. Shiny new headline techniques and technologies are exciting though, so we didn’t spend all of our time searching Stack Overflow. Over the two weeks Ben spent with us (he stayed on for a second week) we covered serverless systems and architectures, asynchronous API interactions, logging and tracing, message signing and authentication, continuous integration, secrets management, and more.
Refactoring
Another aspect of software development I wanted Ben to get to grips with was refactoring. The flow we established followed the strategy: make it work; make it right; make it fast.
Ben would take a feature or problem from our board and implement it to the point that it worked. We would then review the code and look for ways to improve it. Often we would extract methods, simplify conditionals, and remove duplication. These sessions were a great opportunity to learn and discuss the merits of our changes. When we were happy with the implementation, we then considered performance. This strategy worked well for us. When we needed to make performance improvements, the structure of Ben’s code made it simple.
The end of the placement
Towards the end of Ben’s work experience he was asked to prepare a presentation to showcase his work. I was apprehensive, I feared that this might consume too much valuable time that could otherwise be spent building something. Of course, the workflow that we had spent practicing worked just as well for honing Ben’s presentation and demo as it did for creating good software. It was heartening to hear that the process of writing and delivering his presentation helped to bring everything that he had achieved into focus.
The two weeks I spent with Ben reminded me how fulfilling it is to teach and support young people. It also made me reflect on one of the qualities I love about Surevine, generosity. We build systems that encourage others to be generous. We are generous with our skills, knowledge and time – for the benefit of our colleagues, our customers and our industry.
Check out Ben’s blog to find out how he found his 2 weeks of work experience at Surevine!