In part 1 of this series of blog posts we explored some of the setup and strategy of the process of taking on Steven as an intern. In this post, we'll explore more of the day-to-day working as a development team.
Introduction to the task
Steven had previously worked with us as a short-term (1-2 week) work placement student. In the past, tasks we had tagged as "easy pickings" were generally picked up. But for the time he was with us this summer, we wanted to give him a challenge and let him get into a feature. We wanted him to get an experience with seeing it through from start to finish. From feature kickoff, through implementation and testing, peer-review, user acceptance testing, and finally deployment to production and post-deployment monitoring.
Our kickoffs are an open discussion to ensure that everyone surrounding a feature understands the scope, impact and goal, and everyone can ask questions to ensure they're on the same page.
If you are not sure of what a task is about, make sure that you ask, even if you have not got a slight clue do not feel embarrassed or pressurised by it. This also applies when you begin a task and do not have an idea of where to begin.
- Steven
Through the kickoff, it was identified that the feature was going to cover a number of areas:
- API endpoints (with request parameters)
- Talking to a database
- Data / entity serialization
- A separate product which would retrieve the data from the API
- UI to display the information returned by the API
(As well as unit, integration and end-to-end tests for the feature)
The task wouldn't be as simple as others Steven had completed in the past, however we were confident from what we'd seen from him before, and knew he'd be up to the challenge!
Good things we found
We assigned a single point of contact for Steven. Kane stepped up to the task and he was who Steven would go to if he had any day-to-day problems or questions about the tasks he was working on within the feature. This gave Steven a clear way to request help and built a good relationship of trust between them. It also meant that the rest of the team would be there to help if required, but could for a large part continue with their work without as much disruption.
We all felt that communication improved within the team, with less reliance on assumed knowledge. We generally try and avoid acronyms and abbreviations as a part of not relying on assumed knowledge. But we found that we were more verbose in our task descriptions and kick-off notes.
The challenges we faced
A single point of contact was also brought up as a potential risk during this time. Kane had felt a little burned out having to manage his own workloads, as well as support Steven, and Steven felt that constantly having to ask one person for help was disruptive for Kane.
I had many challenges to overcome during the internship. This included working through tasks when I was unsure of how to write some functionality. The first feature I worked on included having to write queries to a database to pull out the data I needed. When I hit these roadblocks I had to make a decision. I could either struggle or ask a developer for assistance. I asked for help from the developer and they provided me with the information I needed to know to continue with the task. This often included how to write some functionality (writing queries, object-oriented code) or what some existing code does.
- Steven
There'll be something covering managing workloads in part 3, where our project manager, Luke, will address things we can change in future to factor in the need to be able to provide support to an intern or apprentice. As during this time, a mentor can't always be expected to maintain 100% on their own work, and we hadn't factored that in properly at first.
Takeaways from the Development team
Can you give me 10 minutes?
Initially with the internship, (and previously apprenticeships in the past) developers mentoring and helping found themselves jumping to help as soon as they were asked. In the beginning, this is required so Steven knew he had someone they can go to and that he has the support of those around them.
However, over time that reliance on someone immediately helping can become disruptive for the person jumping to help. Asking for 10 minutes to wrap up what you're working on as a mentor meant that Kane had the chance to put the things he was working on into a state where they were more easily picked up later. It also meant that Steven would have 10 minutes to think about the problem he was facing. Which over time turned into him taking initiative and searching for information around the problem - which often meant that he could solve the problem himself - leaving Kane free to continue with what he was doing.
When it comes to debugging. Even if you do not understand what an error is telling you. Always put the error into Google. If you do this then you may find a solution just by trying what is on Google, this can save you from asking another developer so they don't have to context switch.
- Steven
Alongside this, we have a copy of "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems" in our office library of books, so we'll ensure that this is on our list of recommended reading to help build skills in debugging.
Don't do the work for them
This factors into the first takeaway too, when helping, don't touch the keyboard, and let person asking for help remain in control. It can be tempting to grab the keyboard, start typing and fix the problem for them, but patience is key. Allowing the person asking for help to find their way (with the mentors guidance) is the best way to ensure things are better remembered and lessons stick much better.
I would take 10 to 15 minutes to investigate the issue. This sometimes allowed me to solve the issue without needing to ask another developer. If I then still had not solved the issue then a developer would then guide me towards a solution.
This meant the developer did not have to leave their work to help me when I could work it out for myself boosting my confidence
- Steven
Further to this, asking the question "what would you do?" helped with letting Steven know that he had the authority to make a decision on what path to take. Over time, this helped to reduce the reliance on others to prompt for steps to solve a problem. Rather than calling for help immediately, we found that Stevens confidence grew and he realised he had the autonomy to solve issues, whereas at first he needed the support of another developer sat with them in case anything goes wrong.
Takeaways from Steven
Ask questions and speak up
It is vital that you ask if you have a worry. If it is holding you from working then you must ask the question otherwise the work will not complete and you will not learn as much if you ask no questions. If this is your first interaction with industry work as it was for me, you need to go in with the mindset that you should learn from all the developers in the time you have there.
- Steven
We try to keep a culture of openness and sharing here. After all:
There are naive questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question.
_- Carl Sagan, The Demon-Haunted World: Science as a Candle in the Dark
We very much believe in this! Trying to better understand the environment or scope of a task is something that might take a little time now, but can save a lot of time in the future.
From this we've implemented an internal handbook for coding standards and guidelines across the languages we use. As well as add some information on development at Viva IT in the public handbook mentioned in the previous post.
