I came into the profession in 2015 as a brand-new, self-taught developer. I had lots of experience, only none of it was in dev. I had spent the last six years teaching English in a high school. I thought I would be tearing up everything I knew and starting again but it was only a short time into my first role that I realized I was going to need to lean on the things I’d learned while teaching a good deal.
Those early weeks were full of cramming. Pluralsight tutorials, product documentation, wiki-wormholes where one term’s explanation included another, which included another, ad infinitum. I found solace in sub-Reddits like ‘Explain Like I’m 5’. I knew I was fortunate to be learning to code in a landscape that was full of information, much of which was entirely free. I didn’t, however, have a defined path as to how to become the developer I wanted to be.
At this point, I decided something which would have shocked me if I’d considered it after accepting my first dev role. I was going back to school.
The thing about tech
We work in an industry where our business is innovation. We might know something today but in six months, that skillset is already beginning to feel kinda old school. In another six, you’re going to start noticing that those acronyms make a little less sense to you. We have to keep learning.
Much like teaching, this work is not something you do between 9am and 5pm. You might be building prototypes on your weekend afternoons, you might spend evenings at meetups, watching the latest tech being demoed – either way, you are likely to be learning outside of working.
Back to school
One of my most rewarding experiences as a teacher was in teaching children about their learning. I was trained by professionals whose philosophy was that anyone can impart knowledge, but if you wanted students to understand any subject, you needed to teach them how to learn. We based our approach on the following four skills that make us good learners:
- Resilience. If we are knocked down, do we get back up again?
- Reflectiveness. We’ve finished that awful project, must we revisit it? Yes.
- Resourcefulness. How strong is your Google-fu? How far will you go to find your answer?
- Reciprocity. Are you working in a bubble? Collaboration will help you more than you know.
As a brand new developer, I needed all of these skills to become the experienced developer that I wanted to be. I looked at the ways I worked with my team, the learning I was attempting outside of my workday, the events I attended, and I had a complete overhaul of my approach.
It wasn’t always easy, neither was it fun, but that time in the trenches taught me so much about the ways that as devs we can, and indeed must, continue to grow, learn, and (sorry for the pun) develop.
Style
We all have different learning styles. Some of us love to watch and others have to get stuck in. Some can learn by listening, others need to talk things through to really understand them. As a team lead, are you able to account for each of your colleagues’ learning styles? Probably not. What you can do is to help them to uncover what theirs is.
In schools, we actually have students sit tests to discover their own learning styles. We group kids into one or more of three categories: visual, auditory, and kinesthetic. Each category has different learning strategies associated with it and few of us are wholly biased toward just one of these styles, despite what we might think of ourselves. Visual learners learn best from diagrams: they might take notes or color code things to aid recall. Auditory learners do well to hear things said aloud so conversation is a fantastic way to aid learning. They might record their thoughts or ask people to act as sounding boards (rubber duck debugging for the win!). Kinesthetic learners move around plenty and learn best with shorter blocks. Their trips to the coffee machine are not just for the caffeine, they process information best while they are moving about.
How does this work in the real world? If your working groups have shared training plans, encourage them to have similar outcomes but with entirely different paths to that destination. You don’t need to dictate the ‘how’ of the learning to your team if you’re confident that you’ve communicated the ‘what’. Let them choose their tools. For example, I recently joined a working group where we got started with .NET core. Some of us watched videos, while others hacked prototypes. We met weekly to discuss our learnings and our chats were so much more fertile than if we had all sat and viewed the same material. We achieved the same things, but our journeys were not at all alike.
Encourage your teams to find the route that works best for them and attach no judgment to those choices. I can guarantee that your get-together at the end will be a dynamic one.
Mindset
At times in my career, I have tried to make use of the incredible work done by Dr. Carol Dweck on the difference between a growth mindset and a fixed mindset. While it is not easy to boil down many years of research into a few paragraphs, what I have to say to developers on this topic is that we need this more than we know.
In a profession where much of our days will be spent solving problems, concentrating on cultivating habits that promote a growth mindset will be our key not just to thriving, but perhaps to staying sane. What’s the difference between the two? In short, where a growth mindset welcomes criticism and sees it as an opportunity for learning, a fixed mindset takes this personally. People with a growth mindset tend to believe that ability is a consequence of effort rather than potential being predetermined. Create an environment where your team feels that they can learn anything they wish to and they really will stand a better chance of doing just that.
Studies conducted by Dweck’s team have shown that while none of us are fully one or the other, encouraging people to think about their mindsets and interrogate some of their own beliefs around learning and achievement can have an incredibly positive effect on their thinking. The more we challenge our thinking, the less prone we are to falling into those traps.
Language
I won’t be the first person to tell you that language is powerful, but I might well be the first to tell you that even praise can have an adverse effect on our learning. We’ve all worked in teams where there is a standout developer, a real rockstar, total genius, and so we probably know that at times it can be pretty demotivating to be reminded of someone else’s innate intelligence and aptitude. That’s not the reason I’d urge you to mind your language though.
The right kind of praise can make our teams hardy and resilient. Research by Carol Dweck on adolescents saw students organized into groups. Both groups were given moderately difficult tests to sit. Both groups did well and were praised upon receiving their results. The praise, however, differed in its content. One group was told that they were very intelligent; they were talented students. The other was praised for their effort alone; they had worked hard.
The next test was more difficult, and the students were all told afterward they had done poorly. How did they respond to this setback? Overwhelmingly, the students who had been praised on ability in their first exam were inclined to see this setback as a failure, while the others saw this as a learning experience.
I was astonished by these results and it began to inform how I spoke to the people I worked closely with and to those I admired. If praise feels good, why should it harm us? Any praise that encourages us to creep back into that fixed mindset state can bring with it all the pitfalls of fixed mindset thinking. If I’m a rockstar developer, how do I reconcile the experience of encountering a problem that I cannot solve without help? If it’s my effort you appreciate, I can shrug off my ego and look for the support I need to get to that place without shame. Praise might not be the motivator we need.
The last finding from this research that resonated with me was in what happened with these children next. At the end of the study, the students were offered a choice: they could read about how to do better on the test next time or they could see their peers’ test scores. The ability-praised students were far less likely to choose to do the very thing that could help them improve, opting to see the other students’ scores, while those that were praised on effort and keen to improve, often opted to learn how. If we are to keep learning and growing, it’ll take a team that acknowledges what matters when they single out an individual for praise.
Communities
We love communities. Even the more cynical of us can see the value in building networks of experienced people. For those of us who call tech communities our home, we know that they help us to grow in our careers; I’m going to tell you some of the reasons that your instincts here are correct.
No two workplaces are exactly alike, and while some of us will work in large and diverse teams, others might live in a team of one. However, all of us will be more successful in our learning if we can see others like us. For many years, it has been widely understood that representation matters, but how can we identify with others if our teams don’t offer us that opportunity?
I have been known to claim that I grew up in the Umbraco community and by that, I mean that I learned more from people I didn’t work with than those I did. At work, I was ‘the junior developer’ for many years. It was at a meetup that I met my friend Imran who was also starting out. We provided support for each other that was not available to us inside of our teams. A supportive senior could show me the ropes but I could see myself in Imran and he in me. It helped me to feel I belonged in this world.
Carole, a senior developer, provided me with a vision of what it would be like to be a senior developer who wore striped dresses, and Lotte showed me what life looked like as a female business owner. I saw myself in all of these people, and while that felt reassuring, there’s compelling evidence that it does more than just that.
Stereotype-threat is a term coined by Claude M. Steele and Joshua Aronson in a piece of research that aimed to show how reminding students of a negative stereotype that involved their demographic before they were asked to sit a test had a significant effect on their performance in that exam. In work by the aforementioned researchers, along with Diane Quinn, the results showed that this effect could be triggered by simply reminding students, for instance, that men perform better than women in mathematics. Conversely, it could be removed by telling participants that the test does not show gender differences in outcomes.
We don’t just need communities to feel good about ourselves. Our communities provide opportunities for us to see ourselves as juniors, seniors, founders, engineers, and leaders. The more we are reminded that we belong here, the better chance we have of avoiding the pitfalls of stereotype threat.
Learning to learn
I’ve often wondered who we would bring to the industry, or indeed keep in, if we had a comprehensive approach to supporting learning in our technical teams. We see an astonishing number of women leave the industry within five years and while I know that there is a myriad of reasons why this is the case, what I have shared above are the things that have kept me progressing in my own career when I have been tempted to look at alternatives.
My journey as a learner is not over and never will be. In my new role as a Developer Advocate, I work diligently to ensure that others are given opportunities to grow their understanding of their arenas using the tools I picked up in teaching. What attracted me to this career path in the first place was the understanding that there is no ‘finished’ in our line of work. We can be writing books on one technology and complete novices in another. Our tech skills are, of course, transferable and my most experienced friends tell me that once they were able to work with one technology, the others came easier to them. This makes perfect sense to me – we learn first how to be learners. And then? Then the world is our oyster.
