Three years ago I joined Kyan as a Developer, straight out of a 12 week coding bootcamp, Makers Academy. Prior to this I had been a Restaurant Manager before becoming a Maths Teacher and then Assistant Principal. I was never 'into computers' and IT was not a something I would have listed as a skill. It's fair to say that Kyan didn't employ me based on my technical ability.
The Directors were taking a gamble that I could transfer the drive and success I had shown in two previous industries into this one. And why not? I told them I would in my interview, hell, I pretty much guaranteed it. I can't speak on their behalf, but I don't think their gamble paid off…at least not initially…and certainly not because of anything that I've done.
At the time I joined Kyan, they were still a relatively small agency of around 16 staff. I was thrown into a project with a steep learning curve and onto a team that didn't have the time nor resources to take a complete numpty and teach them everything in the world ever. Because realistically I knew nothing. You complete a coding bootcamp that is extremely intense and think you know the basics…but in truth you don't even know that.
After about 4 months at Kyan I moved into Project Management. It was a skill I could offer Kyan and which kept me employed. It was not what I wanted to do and it is not why I left previous management careers. I wanted to be a developer.
Throughout the next 20 months I continued to play around with basic development in my own time and tried to dabble as much as I could at work — text changes, bug fixes and the occasional small feature on the projects I worked on. Then, at the start of my third year I requested a switch back to development, hoping I had learnt enough to at least be able to start from the bottom.
Now, after a full year, I finally feel confident to call myself a Developer. I'm actually starting to feel like I'm getting good at this too. I love my work and I look forward to each new ticket I pick up. I get to do a lot of refactoring which I really enjoy and learn a lot from. But was it my drive and my apparent level of intelligence that got me here? Was it hard work and determination? Or did it all just magically click one day? Nope. And that, finally brings me to the point of this article…it was because of Alan. Yup, Alan. With a side of Karen, a sprinkling of Wake, a dash of Paul and slight dip into Stack Overflow. Because I would not have got here today without the support of what I consider my Mentor and these other key supporters.
Everyone is different of course. We all learn in different ways, at different paces and have stronger and natural inclinations to certain skill sets more than others. It turns out that one of my issues is learning how to learn how to code! Maybe i'm not alone? And if i'm not, and if you can identify with this, or if you have developers in your company that present in a similar way, then maybe I can help unlock something here.
I find reading textbooks dry, dull, complicated and to be honest boring. Tutorials are usually pitched very low and are very slow. README's and Documentation tend to presume a level of knowledge that I don't have.
When I think back to working in restaurants or in the classroom there is a large part of the training that involves shadowing and watching others. You spend hours and hours during your teacher training observing other lessons and staff and when you do start teaching your own lessons, you're being watched like a hawk and you receive detailed and very critical feedback. That support is fantastic, if at times a little suffocating and patronising, but it is absolutely essential. Whilst, of course, teaching does require elements of personality, common sense and the ability to think on your feet, there is a lot of pedagogy to learn. Plus there are many situations and scenarios that you are likely to encounter which, without having seen them handled, are likely to leave you speechless or ready to throttle a student…neither approach being the right one I might add.
Back in the restaurants, similarly, you learnt from those around you, usually with more experience. But there is also an element of learning from your experiences. We've all eaten in restaurants and we all have our own opinions on how we like to be served and what we come to expect from the establishment — from the booking process through to the state of the toilets!
Development is different. At least it feels that way when you haven't come from an IT background and when you didn't grow up playing around with computers. I might know what I want an App or website to look like, or even how I would like it to work. But that doesn't mean I know anything about how to build one, or deploy one, or how to version control my source code…!
Now I'm not for any minute suggesting that developers need to observe other developers and jump through a lot of government training hoops for a year before being let loose on the master branch. But we should not forget the value that this can have on individuals. Not every organisation is able to offer pair programming, and when this is the case, it is vital not to let a new developer be left to their own devices for long periods — even if they think they are able to. They need support. And I'm not talking about code reviews. Because by then it's too late. The work has been done, the mistakes have been made, and 9 times out of ten there is a deadline that needs to be hit, so picking their code to shreds and asking them to start again just isn't an option. Instead, you make a few comments about double quotes or the latest syntax and feel like you've ticked the box. And when there is time, some people just don't have the heart to be critical to someone else…worried they'll offend or upset. Supporting other staff is a skill in its own right. Approaches to a problem should be discussed before, during and after they take on a piece of work.
New developers need support, but they also need to hear criticism. They need to pair, they need to be reviewed, they need to hear other developers think out loud about how they might solve a problem. You see, there are many ways to achieve the same result when programming…but hearing the pros and cons of each method is invaluable. And sure, there are a lot of opinions out there and maybe they will be exposed to some of the 'wrong ways' to do things…but this will help them form their own opinions and strategies and approaches.
When I was a PM, working mainly with Alan and Karen, they would include me in their discussions, share PRs with me to read through and encourage me to pick up smaller tickets. The exposure to the development process allowed me to ask questions about DB architecture and observe from a safe distance good strategies for building new features.
There was one final element to this recipe. Asking questions. I was fortunate enough to find some developers who were happy, or at least appear to be happy, when being asked questions. Lots of them. Dumb ones, simple ones, repeated ones and occasionally stupid ones. Accessibility to this resource was priceless. I'm very lucky to work for Kyan, they provide a lot of perks and look after their staff…but their greatest strength and best benefit they offer me, is the staff I have been able to work with. I'm currently working on a long term project with Alan. A developer I consider to be my mentor. He challenges me, but more importantly he teaches me. He answers a lot of questions and has probably told me on more than a dozen occasions about using the Ruby splat. And it's his persistence in examples like this that are perfect for me. Sometimes, when starting out, we're focusing on other elements of the feedback, we can't take it all in. That doesn't mean we think we know better or are being lazy but we're just a little saturated. Alan will keep mentioning examples like this and then one day the time will be right for me absorb it. He must feel he repeats himself a lot and at times it must be very frustrating to watch me make the same mistakes or not pick things up a faster pace, but I appreciate his patience and owe a lot of my progress to him, as do the Directors!
According to this article, '65% of recruiters claim talent shortage is the biggest challenge in hiring'. If this is the case, then developing talent in-house will become even more important; and empowering and encouraging staff to become Mentors could prove to be one of the most cost effective and powerful recruitment tools available. Kyan certainly weren't employing 'talent' when they took me on, but under the right guidance I think I've become a useful developer for them. And perhaps accidentally too…I'm not sure Alan would have considered himself a Mentor when we were first thrown together, and maybe he wouldn't have wanted to be one if asked, but it's worked out ok!
