Software industry is full of geeks, and due to the speed of innovation we need more to continue building great software.
Finding the next ‘pool’ of geeks is not easy, as they usually hide in dark corners not wanting to speak to anybody — so the earlier we start the quest for the ‘next generation’ the more chance we have of success. Most companies generally view ‘work experience’ as a pain in the a**e (PITA), as it’s too short and the student is not interested.
The big question is, what motivates a 15 year old to do work experience at a software company?
Being an avid FIFA player, they think they are going to be sitting around playing games all week…
Photo by JESHOOTS.COM on Unsplash
The truth is all companies allow staff to play games all day, but they call them ‘metrics’ — in the software industry some of these ‘magical’ metrics are:
- estimation poker
- code complexity
- code coverage
- build lights
- managing the backlog
Gamification is nothing new, it just been very well hidden for many years with business ‘lingo’.
I’m gonna spend a couple of days ‘coding’ and come up with a mobile application I can sell for millions – so that I can spend more time gaming.
Amazon are deploying code every 11.7 seconds
Etsy deploys to its production servers 50 times a day
Seems cool, I get a stress free day coding away listening to my favourite twitch.tv/youtube channel.
Okay, overview of my day — ride 15kms to work, shower, coffee, work, lunch, work, coffee, work and ride 15kms home. Sounds pretty straight forward and fun (to me at least), lets look a little more in detail what the day may look like:
Key questions at Daily Standup — what did you achieve yesterday, what you going to achieve today and is there anything stopping you achieve your goal?
What is required to build the feature? Is the feature user facing? If so, get your UX team involved. What non functional requirements are there — scalability, extendability, security etc?
Planning for future Sprint/Release needs estimation — how long will feature ‘x’ take to design/ build & test? How many features can we do in a sprint? How many developers in the team? So many questions before we have even started.
Scheduling the development of the feature is critical, making sure we spread the workload across your team — as we need to share the knowledge. Time to begin your journey — plugin you earphones and start moving into the /coding zone’.
Whilst coding is in progress we need enforce building of maintainable code, following common coding style and having great automated test coverage.
After completion, transferring the knowledge of the features is critical, so having code reviews is really important. Try to pick a different team member each time.
Sharing information with other team can be as easy as inviting them to brown bag sessions and sprint showcases.
As a team we constantly want to get better, by retrospectively looking back at the last release and reducing (or removing) ‘noise’.
Without our customers, we have nothing — so customer/production support is something we always need to improve.
So how can we plan for work experience?
Start early and create a ‘schedule’ for the week, print it out and give it to them on day one.
Once teams are onboard, explain role of walking through the job, expectations and ‘geeky’ tech they use daily. Show them cool stuff, show them the cryptic stuff – but remember they are very unlikely to take it all of it in!!!
Make sure you treat them like any ‘new’ starter — give them some on-boarding, a desk, machine and sufficient access to your instant message service (#slack). Also at the end of the week make sure you ‘off board’ them too.
Let them talk and listen to them. What are there expectations for the week, have the built any software in the past — what do they want to build in the future. If they are interested in mobile ios development — little value in pushing them towards a three day project on your backend billing system.
Show them how to use the cloud, it’s very powerful and addictive.
Find them a really, really small ‘suitable’ technical spike they can have a crack at. If your company uses CI and CD pipeline give them a stretch target of deploying something to PROD (will need a little help from a couple team members ) This is an amazing experience seeing your FIRST code (with test coverage I hope) being deployed and used in production.
During a recent work experience placement, we kicked off a project to extend the =AWS Alexa skills for one of our products. The student managed to implement a number of new ‘skills’ which were pushed to production on Friday, the following week when back at school he pulled out an Alexa device and gave a live demo :-).
If you feel you may have unearthed a ‘next generation geek’ — don’t forget to invite them back for an ‘extended work experience’, maybe over summer holidays. Both parties will benefit in the short and hopefully long term.