Hi, everybody. We're almost there. It's nearly the end of the day. Wow. There's a lot more people than I expected. You don't get that sense when you're sitting amongst everybody. Thank you so much to Kevin for organising, and to Scary for emceeing and the other speakers today. It's been a heck of a lot of fun, and I've learned a ridiculous amount.
I've filled up whatever remaining programme memory I have in my work Mac with cool and useful information. Is everyone able to hear me? Nice. Can you give me a little wave if this is your first engineering conference? Sweet. This is freaking amazing. The very idea of having a conference of people at the early point of their careers is super, super cool.
There are going to be two main parts to this talk. The first bit is I feel kind of suspicious about the term "junior" and I would like you to feel suspicious about it as well, so I'm hoping by the end of that, you will feel kind of suspicious about it.
The second part is mostly aimed at people who are in what I think Tara referred to as the "supporter" category, people who mostly work with people in their early careers, and that's also going to be all of you some point soon, probably learn in about six months or so. Hopefully, it will be useful for you as well. Also, it is a framework of sorts that you can drive your own learning too. So I will try and crack through it as quickly and I possibly can. If you want to shoot me questions, I'm on Twitter in an extremely tiny font over there.
Okay, let's talk about this term "junior", and let's talk about this what it means. Here's the connotations this kind of "junior" has to me. First of all, it suggests to me that learning is not for everybody. The second thing is that places who make a lot of references to juniority seems to be a self-proclamation of being super old school. Thirdly, they undervalue what actual skills people have, because junior like a brush you tar them with is inaccurate to the actual skill set of the people I've worked with who have worn this title.
Let's ask the question about who has permission to learn in an organisation that makes heavy usage of the term "junior". I think that what "junior" says about a learning organisation is that you have to be young to do it - juniority and youth are intrinsically tied together in the language we use, and this cuts out anyone who is making a switch later in their career later in their life.
I think it also says that you have to be early career in order to learn in an organisation. If learning is the prerogative of juniors and you're mid-senior part of your career, good luck, I hope you've learned everything that you need to. It also sort of sets up this weird tension between delivery and learning that I'm going to hopefully prove is not necessary in the second part of the talk where we look at how to build a sort of structure for learning into your life, and into an organisation.
I think "junior" says these are the people who have had the permission to learn, young, in their early career, and we are not expecting them to deliver. The second part about being old school, I would ask who else looks at this idea of juniority? Who else uses it? The first category is dads which, actually, it doesn't seem that surprising when I looked into it more. There's about 10,000 Donald Trump Jrs for every one Michelle Obama Jrs, embedding patriarchal lineages into family structures. Second is paranoid colleagues, basically. If you base your entire idea of who you are based on how it is relative to somebody else, that's already suspicious as a thing to do - it's not exactly a great indicator of self-esteem.
The idea that senior are people are senior because they're not junior sets up a weird dichotomy and is problematic in various ways. The last is archaic work places. It might make sense on these. We're talking about the political profession, or legal profession, or some parts of the medical profession which rely heavily on this idea of stability, need to be stable places so need to squash down people coming in who might accidentally have new ideas to disrupt stuff. I'm not being sarcastic about that, I think those places places need to stay stable and use the term junior.
Our industry, though, is based on problem-solving, as we recently demonstrated. The last part is about hierarchy. What do you value in your organisation? I think that junior says that, mostly, maybe you value the idea of years of service. You're in a meeting, someone's been there for five years. The person with eight years, they've got total say of what happens. Maybe job titles: again, it's very difficult if you're in a junior position with a bunch of seniors in the room to get yourself heard. It puts up a queered barrier in that situation.
Really, what I'm going to suggest is that we can build hierarchies around the skills and skill sets that you want to have. This is one of my problems with the idea of junior is that it puts people into a position of learned helplessness. When you come into this industry, you have a heck of a lot of skills that you can already bring in.
I've worked with juniors who have been investment bankers, and nurses, yay, and lawyers - er. And they previously, six months before they joined this organisation, were charging hundreds of pounds a day for the same services they could well render in their current function. But because they've decided to become interested in code, all of a sudden, they're being devalued in terms of had a they can contribute within the organisation. I don't think that's fair. I've worked with many, many juniors - actually, let's turn round the technical skill set.
I've worked with plenty of juniors. I've been working in software development for 11 years. I've done lots of programming, I really like it. I will regularly meet people who are new to this who are better at me about deployment, know way more about functional programming and they have a include how to handle microservices which is a thing that everyone is doing, and I don't. I'm like double the day rate of these people. I'm like, but you're hiring us to solve the same problems. I don't understand why I get that cache, and they don't.
I find this idea of junior suspicious. I would like to think of an alternative term and what are the alternative terms available? I don't know specifically about terms - maybe "early career engineer". I like the term "developer". I think it forces somebody to ask the next question, what kind of developer? What skills as a developer? What skills don't you have as a developer. You can start treat problems one by one.
The real core problem with this idea of juniority is that developers love systems. When people hire developers to work on systems, they think about this in terms of a code base, or maybe React which are all systems. Really in the hidden, scary thing, your business is also a system, and developers, just as they will develop opinions on your codebase, comfortably will develop opinions on your business. We're talking management systems, decision-making systems, performance-review systems, and so on, and so forth. The question I think should be asked of junior developers, or early career developers more frequently is: would you build a management system that worked like this? All of us hate inefficient systems because it takes time away from coding. So, is this the way that you would go ahead and build that? So I would love us to dispense with the idea of juniority because I think it loses a heck of a lot in the field. Let's get on to the actual talk.
The idea of this talk is to talk about learning structures and how to build them in. We're going to cover three sort of main areas, which I've heavily divided into six individual pieces. First one's context, second one's goals. Third, tasks and resources - how we do those tasks. Assessment, how we know we've done the things. And feedback, and how those are built in. I think that kind of like covers all the angles that you might want to take when thinking about how to build app quick system of learning. I will make this all available as a PDF. It comes out in this sweet format. It looks good, you can get it printed out, tattooed on your chest, whatever.
Let's dive into context. Let's start here and please always start with context. When a developer arrives at your organisation, they're normally presented with a spaghetti mess owned by 100 different teams, and somewhere in there there are a bunch of user segments which benefits somehow from all this stuff that you are doing. It can be very, very hard to figure out the value and meaning of your work in amidst all of this complexity. And so, when I work with people who work with early career developers, I encourage them to spend far more time trying to help a developer figure out the context of the work that they're doing and helping them to actually go ahead and do the work, because the truth of it is that people are pretty good at going downwards in a map.
They're good at taking problems and solving it and figuring it out for themselves. They get better strategies as they grow throughout their careers. What people suck at, and it's pretty general throughout their careers, is building a map upwards of how this fits in with the whole thing. The sort of questions that people ask that I think end up getting not answered is, "How does my system fit with our systems that are out there? Where is it that I'm doing my work right now? I understand that I'm working on this Java class name which takes 30 files in and of itself but what value does that have to captain Perry who is consuming it at the end of the process?" Useful tools that I found for demonstrating and helping people to map their work into what is going on in the system, a are diagramming sessions, getting people around a board saying this team which has a cool name is working in this department on this particular thing.
If you work in a start-up on a small project, or on a green-build project, you get this picture overall. This is probably more applicable to larger systems. Another useful thing is to constantly link things back to the domain. If you're working on a ticket and it doesn't have any reference to a user, maybe that's a business suspicious. Maybe you could spend a little bit of time how the user ties to whatever it is you're actually doing. That's context. Let's talk a little bit about goals. We're going to mostly make reference to a paper by a guy called Edwin Locke, the theory of goal-setting and task performance. The idea of a goal is a thing you can say about yourself that is true. And that's kind of a rubbishy definition.
Let's go into it a bit more: a good goal, if you're going to set it, is specific enough that it can to make sense. I'm going to be a great programmer. Crappy goal - how do you ever know? I'm going to be able to build a node system that does these 15 things. Good goal because it's specific enough. Aspirational, which is a goal which seems impossible when you set it initially, or requires a large amount of clarification on your part before you know how to get there. One that requires you to sit down and, as Violet mentioned, sit down and actually plan out your route to that, spend a decent amount of time, planning before you attack it.
The next one is that it is expected. We will talk more about the role of expectations in a moment. And the last thing is that it believes. There is nothing more powerful than a peer sitting down, "I believe you can do this," and demonstrating that continuously with the way they interact with you. It's empowering, and also free. In terms of expectations, this is a great paper, Pygmalion in the Classroom. Weak links that we think will improve outcomes and may or may not. Expectations are pretty much the gold dust of this sort of stuff. The gold standard as far as it goes. Higher expectations, especially from peers around you tend to lead to higher educational outcomes. If you're building learning systems, pitch those things aspirationally, and just expect that people will be hitting them.
Let's talk about tasks. Everyone gets frightened about tasks, because, when they say, "I need to build a course or a learning system into my company," they think, "I'm going to need 200 various exercises that they go through. It's going to take me 14 months to build it, and the new stuff will come in and we need to iterate it." No, it's not necessary, the second thing is that every single thing you to is an exercise, a learning experience, and all you need to do is tune it slightly and you can use it for more memory-retention stuff, try and remember what you did so you can use the pattern the next time you try something similar. There are some pretty easy rules of thumb to build this in. Put a time limit on something. That's a great way to turn something into a little benefit an exercise.
Make something available for minimal unblocking. That's not necessarily demonstrating how to do it and going ahead, but being there to help people get unstuck when things go wrong. Give people key words. We don't talk much about terminology and language in this industry, but it's a pretty major problem. We have a lot of jargon, a lot is hidden away and seems super technical and hard to access, and no-one would think to come across it until they read the right work at the right time. If someone is doing an exercise where they try to deploy something on AWS and they're using Docker drop in the exercise the word "containerisation" so you give them power. Key words, it's great to attach, you probably do this, and this, and this as part of this exercise. The last part is encouragement.
Development is surprisingly hard to people new to the field. It never gets any easier. Overwhelmingly developers spend most time fixing the mistakes we made. Encouragement is absolutely necessary to push people through. It's hard, painful, and annoying. Okay, last thing within this section is about resources. And that is, okay, I've got a bunch of tasks to do, how the heck do I get them done? The truth is, if you're working with people who are trying to learn, this particular thing that you're doing, then you are the best resource that's available for that. There's also reading and not entire books. If someone comes to you and says, "I'm trying to refactor this particular thing, how do I do that?" Don't dump Refactoring Volume 2. It's two weeks of their life and they won't get much from doing that at that particular point. Small bullet points, something you skimmed off the internet that's an image. Reading straight, prep exercises, I did say you don't want to be making loads of exercises.
At the same time, when you're engineering, there are things that you do, like hundreds and hundreds of times. And it's pretty much like the same thing each time. That's a good prep exercise. Strip the domain out of it, give it to somebody with tips on how to get it done quickly, and you can save them almost literally days of their life simply by making a swift prep exercise out of the work they're doing. You can give that for free. I've asked people that I work with who work with learners to really focus on being Socractic. For me, as a rule of thumb, it comes town to basically asking questions instead of giving answers. This is extremely annoying for anybody who has had Socractic learning happen at them. It's also frustratingly useful, because, when you answer somebody's question that becomes - that they come to you with, you rob them of the opportunity to find that out for themselves.
That opportunity will never come again because they have the answer now. And, instead, what you could do is sort of frame the problem that they have so that they start asking better questions with better terminology, increase their power, and can then ask more relevant questions later down the line. Like a cumulative combo effect on the points score of your knowledge of development. The next thing I suggest when working with resources is building a library. If you are handing out bits and pieces of information in response to common questions, save them somewhere, and you will instantly become a better educator, and, over the course of a few weeks or months, you will see that you've built up this incredibly useful library that you can hand to anybody interested in a career in development. It will be useful to them.
The last thing is to keep things focused. Keep any questions focused. Part of your job when working with somebody who's learning is to stop them spiralling off into this mayhem scenario of trying to understand everything at once, because software engineering is this huge, terrifying field full of hundreds of different topics. And so helping people to ask the right questions that focuses effort is very, very useful.
The last thing about resources is please to avoid tutorials. This will be a very, very unpopular move here because I know that a lot of people like really, really need tutorials, but I can't express how much I'm on a crusade against the idea of tutorials. They're like the equivalent of "insert your addictive drug of choice here". They give you a sensation of being able to do something that happens, and then it's done, and then you can never apply that again in any other situation without the tutorial there. And it's like super disempowering just to have that happen again and again and again, and you think, like, doing all this work, but I can never use any of it in any other situation. Super annoying. It's tutorials' fault. It three days leads you through how to do the thing. Like exercise, I guess, the only real way to build in this is face a hard thing and then grapple with the hard thing, and solve it on your own. Oh, please avoid tutorials if you can. Sometimes, we need a boost, and just getting something up is worth it, so a tutorial is fine. Generally, I avoid them as soon as I can.
The last two bits and pieces which is, at the end of that learning experience, what happened? Let's talk about assessments. When I think about skills, I think about four different bits: concretes, concepts, skills, and behaviours. Concreting are when people say, "How do I write a JavaScript function?" I would normally be annoying and say I don't answer the question. I know the internet will answer the question better me, and with write a Python, Perfectly, and Haskell, whatever. So, I don't normally tend to care too much about concretes, and I don't think you should either, because there are infinite concretes in programming, and, if you can't do one thing, then it's virtually meaningless.
It's no indication of your skill level whatsoever. Concepts, however, are quite useful. If someone says what is a function, we can have a cool conversation about that. I will probably learn something, I can learn something, and we can have a meaningful chat about that that applies across all sorts of problems. Way more bang for your buck in that interaction. The next one is skills. Skills are like the doing things, the sitting down and writing a set of functions that implement a programme of some sort. That's a really cool thing to do together, and it's also a really cool thing to help out with because we can focus on a process that will last throughout all sorts of problems.
Again, something that Violet was describing was in terms of having a process for attacking and solving problems. You can use that in any situation, not just when programming, either. You can use it on business scenarios, customer scenarios, anything. Behaviours are kind of, I guess, like how you comport yourself, value-set stuff. Maybe using it in the functional example, you talk about inputs and outputs describing it in terms of systems. Great if you're doing.
How do I actually assess these things? Concepts generally speaking are asking people. Talking to them and say what is a function? Where are you at the moment in your model of that. Trying to help people if there is a next step I see, and saying yes, that sounds pretty much right, or yes, that is, hmm, interesting idea. Skills are useful to assess through observation. I've got to see someone doing stuff in order to make it work. Most interviews for developers generally tend to combine some combination of skills and concept evaluation, and it's usually this way, watching someone and asking questions. Okay, let's talk about feedback.
Last part of this. Right at the beginning of the day, Jo talked about how painful it can be to ask for feedback from peers, and how anxiety-inducing that entire experience can be, and it absolutely can be, because you feel like it has to be perfect because you're showing yourself up, and then you're showing yourself to be a junior, and this person's a senior, and the whole thing is very related. But it's hard to ask for feedback without some sort of structure.
I advise people to put some sort of structure in place. It doesn't need to be heavy and overloaded. You can go with something pretty simple. If you're using pull requests to review code, then you've got an in-built feedback structure. If you've got stand-ups in the morning, then you have an opportunity to discuss more generally how things are going on with a particular task. If you're using retros at the end of the week, you can do feedback about all that crucial stuff around, I guess, deployability-style thing, emotional intelligence, how you comport yourself professionally. Building in feedback structures with authentic tools is very useful. When I offered an opportunity to give feedback, I will sometimes push back against it. And this is.
How you milk feedback for maximum effect. And the things that I demand people do when they ask for feedback, are that they're really intentional in it. They say I'm getting feedback for this and not for this. When I used to work at a Stipe agency, we would show people the page that they were going to get, say ignore the Latin, it's not going to be Latin on the real thing, and there would be photos of your team rather than animals. Please no feedback on that. Do give us feedback on the header sites. Is that right? The brand colours right? The same kind of thing when you're asking for feedback, it is perfectly okay to say I know I've fucked this up completely but I'm interesting to know what I'm nailing this right.
It's okay to say here's the thing, ignore this, please give me feedback on that. That might enable you to ask for feedback on things which aren't ready yet, which means you get feedback sooner. Requiring intentional is really handy. Keeping feedback responses tight. This is tied together with intentionality. If someone asks for feedback on a piece of code, I will try to give them one more piece of feedback, ideally the one they ask for, rather than ten different things in ten different areas which are hard to marry together.
The last part is to demand iteration. It's bonkers to me that, in most learning systems, we do things once, and then we get some feedback. It's like, cool. I would normally expect people to implement the feedback and come back for more feedback. It's a way better way to juice something from memorable and learned experiences because we forget a large amount of the feedback otherwise. That's all I have pretty much to say about learning and learning systems. I want to say one last thing about transformation. Learning is my favourite system to talk about, but I want to talk about the power of junior developers more specifically, and that means the power of us and the power of you. I want to ask you a question, and I want to pose you a challenge which is how are you going to transform the business's work ethic?
Over the next few years, you're going to be the people who, in your heads right now, are probably people who have not hands on the power strings way more than you. So Jo talked about imposter syndrome and anxiety. How can we build structures in our work places that help everyone overcome the dangers of perfectionism? Sascha talked about how much you really know, and how can we build structures, how can you build structures inside your workplace to share, showcase your knowledge, and prove that to your worst inner critic?
Paula spoke about money management. How can work places help us do this better? What can we build to improve our relationships on the money we are spending. Tara's talk was about levelling up. How can we help juniors become supporters? What systems can you craft that make this journey easier for those entering the industry right now or in a year's time?
Taylor spoke about self-care. How can we share our tool kits and build our rituals into the very fabric of the work places that we work in? Sam spoke about building ethical software. What power do we have as individuals to define what our work places will and won't do? What systems can you put in place around your work and your network to safeguard a future that we all want? And in which we can all participate? And Violet talked about developing independence.
How can we make it easier to access the right support and make sure that it is support that builds people rather than breaking them down? Transforming change and transformative change and building it in a whole industry while you're now is obviously not easy. There will always be people who push back. It will be people whose power is based on the very things that are currently there, on the way that things are. And they won't want to give that up.
But, if it doesn't happen, then wherever we go in the next ten years, where are we going to be. It might seem impossible but it also seems pretty rational that you and we are the only people who have the power individually and collectively to shape and define this industry.
And so, I would ask you, when you came in, what kind of industry would you have wanted to join? What are you going to give to people who have yet to take that step? So, thanks very much for coming.
Thanks very much for listening to my TED Talk! [Laughter].
Go out there and change things. You got this! [Cheering and Applause].