Learn. Reflect. Repeat.
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 133 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/48815 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
ComputerLattice (order)Inheritance (object-oriented programming)Computer programmingGoodness of fitComputer scienceDecision theoryState of matterFormal languageBitComputing platformBit rateDifferent (Kate Ryan album)Universe (mathematics)MereologyProcess (computing)FreewareTrailMultiplication signCodeSingle-precision floating-point formatObservational studyPoint (geometry)SpacetimeSoftware bugBlogCASE <Informatik>Software frameworkSoftware developerSelf-organizationDampingMathematicsUltraviolet photoelectron spectroscopyExpressionDegree (graph theory)JSONXMLUMLComputer animation
06:23
SpacetimeSoftware developerEvent horizonType theoryComputer animation
07:08
Software developerEvent horizonBasis <Mathematik>Computer animation
07:57
Software developerMultiplication signObservational studyMereology
08:43
Software developerSign (mathematics)Software bugGoogolMessage passingInterpreter (computing)SubsetProcess (computing)Software developerMereologyState of matterOnline helpSoftware testingMultiplication signBinary decision diagramFreewareGoodness of fitHoaxArithmetic mean
11:19
Software developerDecision theoryOnline helpCASE <Informatik>Right angleComputer animation
12:02
Software developerRight angleDecision theoryRule of inferenceFocus (optics)Multiplication signFront and back endsDifferent (Kate Ryan album)CodeCommitment schemeFeedbackConfidence intervalSingle-precision floating-point formatSoftware developerProcess (computing)Ultraviolet photoelectron spectroscopyData structureVideo gameComputer animation
14:42
Software developerLibrary (computing)Group actionE-learningShared memoryBlogVideo gameData structureLibrary (computing)FeedbackMathematicsLevel (video gaming)Data conversionEvent horizonContent (media)Multiplication signReal numberLattice (order)SpacetimeMedical imagingVideoconferencingConstructor (object-oriented programming)TouchscreenArithmetic meanCommitment schemeComputing platform
17:48
Software developerDisk read-and-write headRadio-frequency identificationConfidence intervalDifferent (Kate Ryan album)Hacker (term)Type theoryPresentation of a groupBasis <Mathematik>Subject indexingBlogCodeContent (media)Bounded variationDatabase1 (number)Level (video gaming)Event horizonMultiplication signBitLatent heatSoftware developerCASE <Informatik>Shared memoryComputer animation
22:15
Software developerUniverse (mathematics)VideoconferencingDifferent (Kate Ryan album)Multiplication signOnline chatBasis <Mathematik>Event horizonType theoryField (computer science)Office suiteQueue (abstract data type)Ultraviolet photoelectron spectroscopyRow (database)Level (video gaming)Insertion lossLecture/Conference
24:00
Software developerBlogModul <Datentyp>Product (business)Basis <Mathematik>Data managementBlogMultiplication signProcess (computing)Scaling (geometry)Level (video gaming)Range (statistics)CASE <Informatik>Mathematics
25:32
Software developerWebsiteMultiplication signProjective planeSimilarity (geometry)TrailRow (database)MereologyIncidence algebra
26:24
Software developerMereologyEvent horizonControl flowControl flowDisk read-and-write headMultiplication signMereologyOnline helpEvent horizonProcess (computing)Computer animation
29:15
MereologyEvent horizonProcess (computing)Computer animation
29:40
Reflection (mathematics)Software developerWeightImpulse responseMathematics
Transcript: English(auto-generated)
00:07
Okay, hello everyone. So I'm Melinda Seckington, and I'll be talking about learn, reflect, repeat. So, the year is 1992. I'm eight years old and my parents have just moved from Australia to the Netherlands.
00:25
So before this, I'd only ever spoken English. So when I started school in the Netherlands, it basically meant that I had to learn Dutch completely from scratch. Now, I was a really smart kid, and within a couple of months, I basically picked up the language at a much faster rate than anyone else was expecting.
00:47
My teacher, though, he was still translating every single thing for me, and I didn't know quite how to break it to him that actually I could understand him, and that he didn't really need to translate stuff for me anymore.
01:03
So I kept quiet. And for about a month, I pretended that I still couldn't understand and speak Dutch. And this was all because I couldn't deal with the assumptions that people made about me. So, skip forward another 10 years, and
01:24
it's 2002, and I'm 18 years old, and I've decided to study computer science. And this is a bit of a weird decision for me at the time because I haven't actually ever done any coding or programming. I just know that I'm good at math, and I think I might actually be good at computer science as well.
01:43
And it turns out I am, but the rest of my classmates, they seem way more confident than I am, and some of them have been coding for years and years and years. Some of them have said that they started coding before they even could walk and talk. Anyway, this basically meant that I massively started doubting myself,
02:03
feeling as if I didn't really belong, and feeling as if I was kind of just faking it, and that one day someone would just call me out to say I'm not good enough to be there. Skip forward another 10 years. It's 2012, and I've been living in London at this point for a couple of years, and I've done a ton of different things in those years.
02:25
I've started my own blog, Ms. Geeky. I've attended lots of meetups and started organizing them with a company called Geeks of London. I finished my master's degree. I started my own company, get investment for it, and despite doing all these different things,
02:42
I still had that feeling of not being good enough and not belonging. So skip forward to now. It's 2016. I'm almost 32 years old, and I'm at this conference giving a talk. Am I nervous? Yes, but am I scared? Not as much as I used to be.
03:03
But do I think I'm not good enough or that I don't belong here? No. So what changed? So the main difference in those years was that I started working for a company called FutureLearn, and I started wondering why. As someone who experienced a lot of not belonging and kind of that feeling of imposter syndrome,
03:24
I was really curious to know what was it that we were doing differently here that made me feel differently? So as developers, we are constantly learning. We're expected to keep track of new technologies, new languages, frameworks, and we're expected to work with all the old frameworks and languages.
03:49
We're expected to be able to solve really weird bugs that we've never seen before. We're expected to solve problems that don't necessarily have one unique solution.
04:01
So there's this overwhelming amount of things that we could learn, things that we could know, and everything that we do requires us to adapt and to learn. So when we experience what we call imposter syndrome, that feeling of not belonging and thinking that we don't know enough,
04:21
I think it's caused by the assumptions that we make about the rest of the world. We make assumptions about how we think the world expects us to be, expects us to know and to act on things. So part of this is a personal issue. There are things that we can all do to not feel that way.
04:41
But quick show of hands, who here has felt imposter syndrome before? OK, so keep your hands up, keep your hands up, and now start looking around. So quite a lot of people have that feeling. And I think it's an issue that we should be dealing with as a community rather than having it as an individual thing.
05:04
I think it's something that we as a community and as teams and companies should be dealing with. So I think the best way to deal with it is to think about what we can each do to help others not feel that way. So how do we remove these assumptions that people make about what they're expected to know?
05:26
And I think this can be primarily solved by highlighting the state of not knowing. So starting off by knowing nothing and making mistakes and learning as you go along, it's all part of the process. And especially as developers, having the space and the time to do all this, that helps us to make new assumptions of what we think we should know.
05:50
So I think this comes down to having a culture of learning where people can learn and can feel. So how do we create this culture?
06:01
So as I mentioned before, I now work for a company called FutureLearn, and as the name hints, we are basically focused on learning. It's a social learning platform that offers courses from universities and cultural institutions, specialist organizations, and anyone in the world can just do a course for free.
06:22
So our mission is to pioneer the best social learning experiences for everyone, anywhere. So unsurprisingly, this does mean that most of our team is very passionate and an advocate for learning more and for learning in better ways.
06:41
And basically giving people the space and time to fail and to learn things has really been essential for us to create a development team. And as our company has grown, our cultural learning has evolved to what it is now, basically embodying all the ideas and values of everyone that works with us.
07:04
And I think it's caused by two things. So the way we act and work together, and the different types of events and activities and stuff like that that we organize internally to support learning. So first up, how we act and work together.
07:22
Now, I want to talk about six values or principles or whatever it is you want to call them about how we deal with others. Now, we've never made these like explicit values in our team, because we kind of believe that these are things that everyone should do, no matter the team.
07:42
These aren't something that are unique to just us. We don't think that's what makes us, that sets us apart. Although there are things that we try to do and uphold on a daily basis. So first one, embrace failure.
08:01
So from a very early age, we are told failure is bad. Failure means that you didn't study enough or you were lazy or maybe you're just not that smart. You're taught that failure is something to be ashamed of. And that's just wrong. Making mistakes and failing, it's all part of learning something new.
08:24
And we should all accept that it will happen. So just think about the first time you learned to read or learned how to play a new instrument or how to ride a bike. Did you do all those things perfectly the very first time that you tried it? Most likely not.
08:44
So this is a quote from Ed Catmull, and he's one of the founders of Pixar and is now basically the president of both Pixar's and Disney's animation studios. And his book Creativity Inc is all about how they created their culture at Pixar.
09:03
And it's a great book with lots of interesting examples and anecdotes. But I love this quote about embracing failure from him. So many people think it means accept failure with dignity and move on. The better, more subtle interpretation is that failure is a manifestation of learning and exploration.
09:23
If you aren't experiencing failure, then you are making a far worse mistake. You are being driven by the desire to avoid it. So every mistake, every failure, it's part of the learning experience. So this shouldn't be a surprise to those of you that do TDD or BDD.
09:42
You don't just want to make your test pass. You need to see them failing as well. So this isn't only just about embracing and accepting failure, but also about actively seeking it out and making sure it happens. So two, there are no stupid questions.
10:03
So this is something that I struggle a lot with. I always thought that asking questions and admitting that I don't know something was basically a sign of defeat. A sign that I was a fake, that I didn't belong. I kind of thought that I needed to know everything.
10:23
So tied up with this is also the fact of Googling something if you don't know it. I always thought that good developers had just memorized everything there was to know. And that's just not true. Actually admitting that you don't know something is way more valuable. So again, another quote. Every question is a cry to understand the world.
10:44
So as I said before, the state of not knowing, it's all part of the process. So there will always be times when we look at a bug or a new feature and we'll go, I have no idea where to start with this. So good developers, they know when to ask questions and when to ask for help.
11:01
But this also means that we should never look down on questions that other people might have. So we should never stop asking questions. But more importantly, we should never stop answering them.
11:21
So three, trust people to do the right thing. So we believe that everyone that we've hired is working to the best of their abilities. Nobody is actively working against us and trying to destroy everything. At least we hope not. We trust that people and our team members are working towards a common goal
11:44
and that they will make sensible decisions. And in some cases, the sensible decisions is deciding not to work on something or to ask for help with something. You trust that people know their own abilities and will act according to those abilities.
12:03
So again, another quote from Ed Catmull. Trusting others doesn't mean that they won't make mistakes. It means that if they do, or if you do, you trust they will act to help solve it. So the right thing isn't about not making mistakes. It's not about failing.
12:22
It's basically giving people the trust and building their confidence to make the right decisions. And it takes time to do it, to learn how to make good decisions. But you end up with much smarter people rather than mindless drones that just do what they say.
12:41
So four, treat people like grown-ups. So this goes hand in hand with the previous one, but it's much more focused on permissions. So we don't require anyone to ask permission to do things. Since we trust that they'll be doing the right thing, we shouldn't need to put any rules or restrictions in place to stop them from doing things.
13:09
So one example of this is how we deal with committing code and with pull requests. So we don't require pull requests for every single thing that somebody commits. We rather leave it up to each developer
13:21
to decide whether they think it requires it or not. Are there any specific questions they want answered? Do they want feedback on it? We trust each person to know whether or not the code that they're committing is good enough to go live.
13:40
So five, don't focus on job titles. So we think it's important that people are not confined by the job title. We don't want anyone thinking, well, I can't do X because I'm only a developer, where X could lead a team or run a retrospective or manage our infrastructure.
14:01
Everyone on a team is encouraged to work on the skills they want to have. So we also try to not make a difference between front-end and back-end developers within our team. We just want everyone to be able to work on the things that they want. So another quote, if I keep on saying to myself that I cannot do a certain thing,
14:22
it is possible that I may end up by really becoming incapable of doing it. So you don't need to be the best at something to be the one to do it. But as long as you know who to turn to and who to ask questions to, if you get stuck, you can do whatever it is you want.
14:43
And six, give constructive feedback. So giving feedback and helping others improve themselves is obviously a good thing, but it needs to be constructive. So give feedback that allows people to understand the changes that they need to make.
15:01
So here's a simple example. So rather than just say, I don't like your commit message, actually give examples of what you don't like about it and how they could change the things to make it better. So these are just some values that I think help us all learn better and become better developers.
15:24
So next up is how we support learning. So what are the explicit events and activities that we organize to enable learning within our team? So we kind of structure it in this way. Grouping it by actions of level of involvement of others.
15:43
So starting with learning on your own, all the way down to learning for teaching. So first, learn on your own. So what activities can we promote to encourage individual learning?
16:02
So first is start a library. So this doesn't have to be just books, but think also about blog posts and articles, screencasts, videos, basically any content that you think is worth sharing among your team. It's very much also about highlighting what type of content your team is interested in.
16:23
What are the things that each member of the team values? Obviously, this also means giving people the time to read or watch and do all these things that are in your library. Actually make sure that people don't feel as if they're not allowed to use the time that they have to learn something new.
16:45
The second one is take online courses. Now this is an obvious one for us at FutureLearn because we create online courses, but everyone on our team is encouraged to take them, be it on our own platform or elsewhere. So beyond learning new things, we also get exposed to other companies
17:01
and how other companies might do things in the same space as us. So a couple months back we started a thing called Breakfast Club, and this was pretty much just a breakfast meeting where people could come along and take the course together. The courses we have are very much about learning through conversation.
17:22
So actually having a group of people together to have conversation in real life was something that we really wanted to promote. So while taking an online course might not be directly applicable to everyone here, to every company here, just think about what are the things that you're currently working on, and are there other resources out there that you can be inspired from,
17:43
that you can learn from. So the second layer is learn from each other. So what events and what activities can we arrange to allow people to learn from each other? So the first more obvious one is pairing.
18:04
So we pair a lot on code together, but that's not the only thing that we pair on. We also pair on writing blog posts and creating presentations together, coming up with workshops. It's basically just allowing people to work directly with someone else
18:24
on a specific problem or a specific goal. And it means you get to see and learn how that other person did it. So the second thing we organize is a weekly learning hour.
18:40
So this happens every Friday, and basically it's just one person that hosts it, teaching something that they think other people might find useful. So they tend to be much more hands-on and workshop-like. And again, these can be about anything. So past learning hours have been about command line tools,
19:04
how to run retrospectives, how to understand database indexes better. It can be pretty much about anything that somebody wants to teach and what people want to learn. And we've also started repeating some of the ones that we've done in the past so that new people to the team
19:21
can kind of get the same sense of, well, things that are important to the team as they go on. So the third thing we organize are lightning talks. So these happen every four to eight weeks, and basically anyone in the company
19:41
can give a five-minute talk about anything they want. So it's a great way to get people to recognize that they have something worth talking about, and it helps them gain experience and confidence to do more talks. So these six are all examples of talks that were given recently.
20:02
And I think it's great to just get people also talking about the things that they might not necessarily talk about on a day-to-day work basis. You get to see the things that your colleagues are also passionate about. Then the fourth thing we organize are hack days.
20:21
So we've done four of them now, basically doing one every four months. And our hack days are a little bit different than the kind of community type hack days that happen. So for starters, ours aren't necessarily just for developers and designers. We try to get every single person in the company involved,
20:43
including our CEO and financial director and content team. It's pretty much every single person that we try to get involved. And our hack days aren't necessarily about shipping things quickly. It's much more about collaborating and learning from people
21:01
that you normally wouldn't work with. So we try to create our hack day teams also based on people that you might not necessarily work with. So it's all about working together with new people and creating ideas with them.
21:24
So the next level is learn from the community. So there are always lots of meetups and conferences like this one going on. So how can we learn from those? So the first step is reporting back from conferences. So whenever someone attends a conference or an interesting meetup,
21:43
we encourage them to share what they learned with the rest of the team. And it's completely up to the individual how to do that. So it can be through a presentation internally, through an internal or an external blog post, or through a workshop, or in my case, what I like doing is making sketch notes.
22:03
So as long as they share in some way or another what they learned with other people among the team, they can go to conferences. So a variation of this is talks we love. So we try to organize these,
22:21
well, whenever someone has an interesting talk, but we basically watch a recorded video of a talk that some person on our team has watched before. So something that that person thinks us as a team could benefit from and make sure that we all watch it together.
22:42
And it's most of the time followed by the discussion about what are the things that we might want to change, what are the things that we might do differently. So another type of event that we organize are future learn talks.
23:02
So in this we organize, we invite an external speaker to basically give a talk or do a Q&A for the entire company. So these can be people from other startups or from our university partners, or just from completely different fields, as long as we can learn something new from them.
23:26
And then finally, we also arrange knowledge exchanges. So these are with startups and other companies in London. And basically, we just have a couple of people from our team spend an entire afternoon at another company's office, basically getting a tour and having chats and discussions with different people
23:44
and exchanging with them how we do things. So we get to see firsthand how other teams go around on a day-to-day basis. And they, in turn, get to see how we do things.
24:03
So the final level is learn by teaching. So if you've learned from each other and from the community, how can we give back and help the community learn from us? So again, I wanted to mention the learning hour that I mentioned before, because obviously, there's the people that are learning from the learning hour,
24:23
but somebody else has to host it. So there's teaching involved for whoever is the one that decides to run a learning hour. So in the past year, we've started writing blog posts on a much, much more regular basis. So they range from how we write CSS to how we do product management
24:42
to how we do modular design. And it's all about sharing what we know and what we've learned, but on a much wider scale than just our team. And finally, there's giving a talk, like what I'm doing now. And both of writing blog posts and with doing talks, it's basically the process of creating them
25:02
and figuring out how to frame your thoughts and ideas that gives you a better understanding of your subject matter. Actually having to sit down and think how you might explain something to someone else is one of the best ways of learning something new.
25:24
So just learning new things, though, is not enough. We need to take the time to reflect on it as well. So the most regular thing that we do are sprint retrospectives. So at the end of each sprint, in our case, that's every two weeks,
25:40
we look back at how those two weeks went. What did we learn? What went wrong? And what could we change next time? We then do similar things for incidents, like the site going down or something going wrong that affects lots of our users. And then we also do a similar thing for longer-running projects.
26:02
And finally, not everyone on our team does this, but I also try to do personal retrospectives. So what are the things that I've learned? What are the things that I could change? And what are the things that I could do better? And also keeping track of these and writing them down means that you have a much more tangible record of the things that you've learned over time.
26:26
Sorry?
26:45
So what do you mean?
27:06
So I think it's just something that you decide to do in your... Or spare time or like lunch break or whatever. I tend to do it every two weeks around the same time as kind of the main sprint retrospective,
27:21
just because I try to come up with what went well and what went wrong before going into... No, no, no, it's not a team process. This is just something that I do personally. And I've spoken internally about how I tend to do these things.
27:43
So other people, I think, have picked it up as well. But it's not something that, as a team, we promote everyone to do. We don't say go and have your personal retrospective in this one hour chunk now. It's more just something that we try to do in our one-on-ones and stuff like that, if that helps.
28:05
So carrying on. So this is another quote from Ed Catmull. And I realize I don't have any notes for this one. But again, it's all about what we're talking about.
28:24
Retrospectives, sorry. So there are two parts to any failure. There is the event itself, with all its attendant disappointment, confusion, and shame. And then there is our reaction to it. It is the second part that we control. Do we become introspective, or do we bury our heads in the sand?
28:43
Do we make it safe for others to acknowledge and learn from problems? Or do we shut down discussion by looking for people to blame? So this is very much about retrospectives, but it's also about how we approach these retrospectives. Rather than looking at people to blame, as the quote says,
29:03
it should be much more about looking at what are the things that we can learn from each other, and what are the things that we can actively change, rather than just pointing fingers. And finally, we have repeat.
29:21
So there's no use to any of these activities or events if they just happen as one-offs. You need to keep doing them and turn them into habits for your entire team, and make sure that learning becomes part of your everyday process. So that's how we support learning within our team.
29:44
So I hope that gives some examples of the things that you might want to do with your company and your team. So it's 2016, and you're sitting here in the crowd, listening to me about creating a culture of learning. And you've also had to deal with imposter syndrome in the past,
30:03
and you like the sound of all these different things that you could do with your team. So what do you do? So skip forward a year. So are you the same person that you are today? Is your team the same as it is today? Or have you made any changes?
30:21
So it's 2017, and I'm sitting in the crowd, listening to someone else speak. Is it you? So thanks for listening.