Transcript
Rees: My name is Robert Rees. We don't have a massively diverse panel today because we're all from non-traditional backgrounds. I studied mathematics and was desperate not to become an actuary and so I have somehow smuggled myself into tech. I'm going to allow the panelists to introduce themselves in a moment. We are quite strict for time so I'm just going to explain briefly the format. After the introductions, we're going to have two questions from myself to the chair, to the panelists, and then we are going to invite you, sorry, to submit your questions. If you can go here and submit a question, then we'll try to pull as many questions out as we can at the end, and then we'll just have a final wrap up.
The basic contention of the panel, I would say, is that we accept that having a diversity of people into the industry is good, that groupthink is bad, and monocultures are bad, but there is a difference between just tearing down the gates and letting anyone in and actually supporting people to be effective in technology from a nontraditional background. With that done, I'm going to allow our lovely panelists to introduce themselves, starting on my right.
Byrne: I'm Anne [Byrne], I'm a software engineer at Deliveroo, and I actually started, my background was in neuroscience. I quickly realized that I didn't want a job in academia, I think during my lab project, I watched one postdoc sleep under her desk for seven weeks and that was a defining formative moment. Then, I ended up becoming a headhunter, just fell into it, as I think a lot of graduates did, just wanted to move to London, and I specialized in finding CTOs and CPOs for a startups that were pre-IPO as well as pure place like Facebook, Skyscanner, Airbnb, and so on.
Gradually, I realized that I love their job more than I love my own. I would spend far more time reading about the technology in order to grill these CTOs, whereas my colleagues were like, "You just need to do the referencing, we don't need to know if they actually code. That's not part of our job at all," but I was fascinated by it. I didn't know whether I was just interested in it or I actually just wanted to be in tech rather than in an agency. I decided to go to Amazon, where I worked as a vendor manager, selling NutriBullets to the nation and taught myself to code at Code First: Girls. Based on that, when the course ended, realized how bummed I was and that actually, as much as I loved working at Amazon, it was a software engineer I really wanted to be.
For the next six months, I taught myself to code and then based on my recruiter background, realized that you need to go interview before you're ready. Luckily, the first place I spoke to decided to give me the offer. I worked at the Guardian for two years maintaining the content API, which is the source of truth. My first professional language was Scala, writing functional programming from the jump was, I think my second day I asked someone what a monad was and they just looked at me like, "This is too soon."
Rees: It's still too soon.
Byrne: I now know, it's good. For the last year, I've been at Deliveroo where I worked in Ruby for about 10 months building tools in order to help users track their order and request compensation when things go wrong. Now I work in the payments risk team, writing in Go, finding out ways that people abuse your systems and policies, all kinds of ways, humans are ingenious, and building services that can stop and mitigate that risk. Everything from payment fraud through to riders running away with their food. Yes, it's been a fun journey.
Fowler: I'm Stephan [Fowler], I am actually a product manager now at the Guardian, but I joined the Guardian as an engineer. I had done quite a few years of engineering before that, different guises. To start with me, I was a painfully geeky kid, at 10-year-old, I built robots controlled by assembly language, and this was pre [inaudible 00:04:21]. I was a bit on the spectrum, then, this thing happened called puberty and I got really into music, I got into being in bands and, you know, electronic music, production, everything. I left computing behind literally for about 20 years, at some point in all that, I gave up on music, I did a degree in Econometrics for some reason, which I have no idea why I did that, it was the hardest thing I could find.
I worked in a few jobs, I worked in the city a little bit then I ended up running a startup. This was back in dotcom Bubble days, which you may not remember when very naive people could get money from very naive people and waste a lot of time and money. I'll come back to that. Then I bounced out from doing that, I moved to Paris, I wrote a novel, it wasn't published. I came back to London, I had to make some money, I started freelancing, making websites, and things built and eventually, I worked in a couple of media companies, ended up at the Guardian, and finally became a product manager. I don't know if that's called a career. I don't think the noun career works there, but the verb career, to career, like a car on an icy road, randomly hitting things. That's been my journey.
Ogura: I'm Misa [Ogura], I'm a software engineer at BBC R&D at the moment. I came to the UK about 10 years ago, I relate to Stephan kind of being a really geeky person when I was younger, I am now as well. Growing up in Tokyo, just video game all the way and, I loved playing around with computers, but hadn't really chance to study anything formal about it. I was "I can get by with computers. I don't need to read four manuals to use a computer." Then I got into biology. My dad was a medical doctor so I got interested in sort of how human works and understanding the way we live. I decided to come to the UK to do a biochemistry degree. I came to the UK with this dream of becoming an international scientists and I really enjoyed the study. After that, I moved on to research and I was doing a research on breast cancer at Cancer Research, UK. That was about three years after the uni.
I love, still love, biology and just knowing what we are and the way we work, but there are some aspects of biological research that was really frustrating for me and it was the speed of iteration. You do your experiments, bunch of experiments, and maybe in three months you might or not know whether you've done things right or not. That was quite frustrating for me, that was the time when I started to join to different careers. Still same places where I can explore my curiosity, but where somewhere iteration was quicker and potentially mistakes weren't that scary, unless you wipe out like the only database, production database or anything, then usually, you make a mistake and you just roll back and no one realized, just get reset.
That's my journey so far. Then I decided to do a coding boot camp because I realized that I hadn't done computer science but I didn't have time and money to do master's degree. I thought, "Ok, that could be a compromise." I did Makers Academy, where I met my partner as well, to whom I'm now engaged. Double win, winning life. Ever since, I'm working as a software engineer and, at the moment, currently at BBC, I help develop a machine learning-based algorithm to really automate the extraction and generation of metadata to really enable us to understand the data, the massive data we have and potentially to use it for better experience for the audience.
Fereday: I'm Charlotte [Fereday], I work at ThoughtWorks. I feel quite boring, to be honest, after all of these stories. Anyway, here we go, I was studying arts and humanities, I was also in research, I was working in Hispanic Studies. I was actually going to be going into research, was interested in languages and in teaching in university. Along the way, I did realize there were no jobs and I also realized that, unfortunately, there's very little funding in arts and humanities. I started being quite pragmatic and exploring other options. I happened to work at an Ed tech startup that a friend started. When I did that, I met some people who were programmers. That was the first time I'd actually heard about programming, even though that might sound a bit shocking to some people in the room.
When I found out that there were these languages, I just found it really fascinating. I started going to meet up groups, I started to going to organizations like Code First: Girls, Code Bar, different organizations that teach people to learn to code for free. Then, I saw a job as a programs manager at Code First: Girls and I joined to do that with a view to finding out more about technology but not really thinking I could ever really join it myself. The long trove is that I was there for a couple of years, and during that time, every day, I would see people like Anne, like Lynn, a bunch of people come from so many different backgrounds and successfully manage to switch into a career in tech, many of whom became software engineers, other people went into other roles. It was really being in that role that inspired me and gave me the drive to learn to code. I applied for a scholarship with Makers Academy also and ThoughtWorks and I was very fortunate to get that. I retrained and then I joined ThoughtWorks. My advice would be fearlessness in the face of confusion.
Lack of Background
Rees: Thanks for everyone who's already getting your questions in. One thing I just want to clarify, Simon said that all of us are from STEM backgrounds, Stephan and Charlotte aren't, just to be clear, so that question about what arts and humanities might bring are referent by them. I'm going to start off with the first question, which is going to be a little bit confrontational because I think it is interesting that we are struggling as a profession in software development to deal with our professionalism. I can't think of many other professions where we'd say, "Oh, you've done an eight-week boot camp. Get stuck in there." If your dentist went like, "Right, this is great, week nine, real patients. Let's get this drill on." You go, "No, I'm opting out."
Have there been any challenges where your lack of a technical background has either blocked the team from doing what they want to do or feel like they've had to spend a lot of time bringing you on board with something?
Fereday: For me, a massive difference was the style of learning, all the sort of learning that I'd done up until then, everything was writing and reading and literature and this actually, the mode of learning was just learning by doing. It really required me to do a lot of digging to figure out how I learn and figure out how I'm going to learn programming because it required a bit of a different mindset.
Another thing that is an ongoing thing I think is figuring out problem-solving. How can you break down a story, a set of requirements, into the smallest parts? How can you write elegant, simple solutions? That, I think, is something that is an ongoing skill that I'm working on, and you've already mentioned that about the sort of maths background. This year, I've been doing Clojure for the whole year, so I've been doing functional programming and there's been times where I wish I had a Maths background. Also, I didn't need it in the end, I could figure it out, but I think there was certain things that would have been more obvious to me had I had more of a Maths background. I think those are the two major things.
Rees: Is there any specific example that you can give or is it just a general feeling?
Byrne: I think generally just some of the concepts, it was just this initial, some of the foundational concepts were totally new to me because I hadn't really done maths at that level. I think those are the two key areas for me.
Ogura: From my first job, for the first maybe couple of months, I was thinking, "Oh, why didn't I do computer science?" I remember one of my first questions I asked was, "What's a server and what's a client?" I can use Internet, but I had no idea what it is. You learn what it is be it at Makers or self-teaching, but I just couldn't appreciate, I couldn't put them, those concepts, into the whole picture of what I was doing.
I agree with Charlotte, these fundamental areas I struggled. At some point, I managed to shift frame of my mind and I just started to think, it's just that I learn things in different order to people who went to computer science, I learned things like TDD first or quality of the code first. That was the point when I started to think that every thing that I don't know is another way for me to learn and demonstrate that I can keep learning. That was the key point, that thing that happened.
Nowadays I'm lucky to have worked in a team or teams where majority of them weren't computer science holders, degree holders. Majority were from a non-traditional background, so there was always safe space to admit that you don't know. If your work environment is not welcoming that diversity, then it's important to be the change, leading the culture change and be open and up front and allowing other people to admit that actually no one knows everything and it works out because we're diverse.
Fowler: I'm going to give you an example of where I wish my lack of knowledge had blocked something. Let's talk about startups - I'm not in a startup now, but rewinding a bit, and maybe some of you are. Startups are often characterized by huge overconfidence married with complete naivety about what's really possible. I was in this situation where I had proposed an idea to some people and they were like, "Great, we're going to give you a load of money," and I put a team together and it was something to do with sharing private information in a network. We had some application ideas for it, it was a sort of platform play. Pretty quickly, it scope creep just accumulated into something that was way beyond our capabilities to deliver, but we had to because we'd started spending people's money in order to make this thing.
Rees: That's just when the excuses start.
Fowler: Exactly. We ended up inventing something that was like pre-blockchain, blockchain public key infrastructure, it was really hard stuff and we learned a huge amount, but we basically shouldn't have done it. We should have just said, "No, this isn't a thing that can be built." The point I want to make though is that the guys I was working with, the tech lead - I was the founder, not the tech lead - the technical people I was working with, a couple of other guys, had computer science background and they were making exactly the same misjudgments as me, we were sharing this error of judgment. It's a distinction I want to make, ultimately, it's not between, you know about CS and you don't, it's about who can make good judgments, good decisions, good choices. That doesn't necessarily correlate to having a computer science degree. I've seen very clever Computer Science people embark on really misguided projects that are very costly. That was my example of I wish it had blocked me.
Byrne: I'm a few years into my career now, having worked in a couple of different places, different teams. In the last six months, I've had two big realizations about things that have held me back that I really wish someone had spoken to me about at the beginning of my career. One of them is language, as much as we don't want to pretend that we're an industry that does gatekeep language, we do. This is not necessarily one workplace and your mileage may vary, there's been engineers with computer science backgrounds that have really supported me in this regard, but because I talk differently, sometimes people assume I don't know what I'm talking about and will attribute my work to other people or think I don't understand what I'm talking about and what I'm trying to convey.
I've had several instances where I've been in a design meeting or whiteboarding something and I describe something we can do and no one pays attention to it until another engineer goes, "Oh, this thing." Just because I didn't know the exact computer science word for it, does not mean I don't understand it. If you're learning a new language, I go to France and I learn how to speak French, and I don't necessarily know what the grammatical clause is that I'm using but I use it all the time and I understand the concept and I understand the tradeoffs.
There are some engineers that are very supportive in this regard. I've had some people message me afterwards and go, "I didn't want to say it in the meeting to take away from what you were saying, but this is the concept you're referring to," and I'm like, "Brilliant. This isn't detracting from what's happening in the scenario. You're not talking over me going, Anne means X. You're helping me learn." Or, they will point out in a scenario if someone goes, "Oh, but this," and they'll be, "No, Anne actually just said that." I think there are some ways to support, but I've definitely begun to realize that as much as we like saying that we're a welcoming industry of lots of backgrounds, we do gatekeep language and that if you don't talk in a certain way, if I went home and I imbibed a computer science textbook and came into work, people would suddenly assume I became way more technical than I am. That's a big thing and trying to reinforce that we should be welcoming about how people express and talk.
The second thing, it's been a massive topic of conversation at work actually recently amongst the women engineers. This definitely happens to women and people of color and other underrepresented minorities in tech, but I've also seen it happen with men that aren't underrepresented but come from a non-technical background. Learned about it through this presentation given by a lead Squarespace engineer, and it's called "The Glue Work." It's the work that is necessary to keep a company going but isn't immediately technical, it's not obviously technical, it's not hammering at code. It's reviewing designs and RFCs, it's being at whiteboarding meetings, it's being on interview panels, running events internally and externally. It's changing cultural processes, it's escalating things, it's managing stakeholders, leading projects. These are stuff that women and other minorities in tech often get pushed into, but also, if you come from a non-tech background, a lot of the time, this is a natural strength.
Then it means it comes at the cost of you getting more technical. When it comes to review season, it'll be, "Brilliant. That's great. You're operating at four levels above you for X, Y, Z, but you didn't do this specific thing from a technical perspective so you won't get promoted." I think for a lot of me and my female friends in work, we suddenly realized that if we had had this conversation several years earlier, we might be further in our career than we actually are.
That was really uncomfortable to realize I had done things that actively harmed my career progression. I think what I'm doing now is I've stopped doing glue work. In November, I run an internal conference for 80 people, I've stopped doing that now unless it's the case of, but you're also going to help me design a system from the ground up that's going to be used by all the teams across the organization. I started actively asking my manager going, "I'm not doing glue work. I'm not getting the data scientist who's going on maternity leave the gift and the present like I always do. I'm not making sure that we're involving all the different teams. Someone else needs to do that."
What we end up doing, I've noticed, is we end up complaining that senior engineers don't have these skills, but we're not helping junior engineers that are forced into these roles. I don't think it's from a place of malice, I just think sometimes it happens. We were actually talking earlier about how we've both heard, in our careers, "You'd make a great product manager," which comes from a nice place, but it's like, "I'm an engineer, let me code. Let me do technical things." I'm now telling any senior engineers I know and managers, have that conversation early on, be proactive. If you spot the same people doing that work, make sure they're not always the ones doing that work and make sure you're actually encouraging those who would rather just code to actually get involved with that too.
Where Different Background Helps
Rees: What do you think you bring to your teams and your work from your background, from the unique experience you've had? Also a follow-up, are there any times that things seem completely obvious to you because of what you've learned in these other contexts where you don't understand why they can't grasp these things? Why is a reverse optimizations so hard to understand? People, come on, get on board.
Ogura: Coming from research background I bring this whole cycle of hypothesis testing. Often, many things at work are done intuitively, "I think that's it and I do it, and I think it's working in a good way, good direction." Whereas, I try to be like, "Ok, let's find something that actually can prove, give metrics and give us direction or indication that we're going in the right direction, or wrong." I try to ask the question that you need to ask first before starting out experiments. Also, because it's more relevant at R&D, we have a mixture of research and software engineering. Even at R&D, not many people are from research backgrounds. You might think, "Oh, BBC R&D, everyone must probably be really old." No, it's not that, we're a quite young team. Frame a question in a way that it can be traceable and you can show that is actually what you think is working or not.
Rees: I think there's something around an engineering mindset that it's quite common. I've been given a problem and my job is to solve it, rather than to say, "My job is to interrogate the problem," and that there is an engineering mindset, which I think the job is just like, if you want to build the impossible blockchain, then we're going to build the impossible blockchain. We just got to figure out how to do it, rather than see if it was a sensible thing.
Fowler: Reverse the question slightly is, outside experience it's a bit of an ill-defined thing. It's quite hard to pin it down and say, "This bit of outside experience is really going to help you." It's easier to answer, what are the risks of being very narrow as an engineer, being a pure computer science engineer. That's easier to address as a risk, there are clichés around that, like, a little bit of knowledge is a dangerous thing. Narrow knowledge can lead you to be quite ideological and to embark on things that people with a bit more perspective, a bit more context, wouldn't go near. This system that works perfectly well and the company's very happy with it must be refracted in Haskell using immutable persistence layers. Maybe not, maybe if you have a wider scope of understanding of the footprint of what we're doing in this company, you realize that's super low priority. Often, the hacks, the people like us might end up doing, from a cost-benefit point of view, much more valuable to a company. You got something quickly done. We haven't achieved perfection, but we've achieved value very quickly. I've seen that definitely at The Guardian, we built some tools that some of my colleagues were quite snooty at at the time, but they were super useful for years, and I don't know if being a purist opens your mind to that loose thinking.
Anne [Byrne] mentioned language, I think there are some things about language and communication that being a purist don't really help with, like saying to non-software engineers, "What you're proposing is an anti-pattern." Most people don't know what that means. It's quite a threatening thing to say, it's alien. That ill-defined thing that you bring from outside of engineering into engineering really is about how you talk to people. How do you listen to people? How do you know what they need? How do you empathize with them? Engineering basically isn't all about engineering. A lot of it is about talking reasonably, I remember a time once when I didn't realize this and I got super frustrated with a project where it felt we hadn't written any code. For months, we've been talking about this problem, trying to solve a problem. I was like, "We must write code. We must program." A more experienced programmer said to me, "This is programming, this conversation, these months of conversation with no code written is programming." Programming is as much about what you don't write and the judgment you use to eventually write something is as much programming as writing code.
Rees: I think there's something interesting as well when you say patterns and anti-patterns. That's something that software development has magpied out of architecture. It's not even an original concept with software development, it's like, “Yes, not only have we taken something out of context, we're giving it a twist that makes it now scary.” Great.
Byrne: I think what you're talking about there, Stephan [Fowler], is I see even further out as being more product and company-minded, and I see it as sometimes, even with engineers that have come from non-traditional backgrounds, but depending on what they did prior, they maybe didn't have. When I worked at Amazon, I was responsible for the strategy of a category within kitchen appliances, so deciding how we were going to make you guys buy a different type of coffee machine this year. That taught me a lot, and I didn't even realize until I started writing design docs in RFC in my current job where I'm trying to sell a project that would take much longer than the hacky thing, but I know that to do it is more sustainable and more scalable, but a lot of people are going to bite shit me.
The first thing I do is I cite our company goal for the next year and I say, "This is the biggest thing that will drive that. I've got the numbers to back that up." Lots of people didn't realize, in my team, why I was adding it in and so I had to have a discussion with them. Essentially, in a workplace, you're persuading people, anytime you're having a conversation, odds are, you are persuading someone, and a design doc in an RFC is a persuasive document. You are selling something and to do that, the easiest way is to say, "This is the most important thing in the company right now and here is the number that guarantees that is the case." That trumps any, "Yes, but if we do this, then we won't be able to do that,” or “If there is an implementation currently over here." I think sometimes, that's regardless of what your degree was in. People sometimes get very narrow and don't think, "Ok, what is the company goal? How can I attach this? How is this the most impactful thing to the company and the product? Then, that's what gallops over the line." I'm quite grateful for all the six-pagers I was made to write in my career in order to get into that place.
Fereday: I'm working consultancy so I'm basically always jumping from project to project. I went from doing some Ruby and then JavaScript and React and Redux into Clojure. Something that I found really interesting over the last year is that I realized that perhaps because of my lack of a background in programming, what I've been able to do is to pick out a tool belt from these different languages as I'm going between them. Because I haven't yet been incredibly entrenched in one specific language and framework or a specific tech stack for a number of years, it's actually really meant that I've gone into learning a tech stack with no prejudice. Over this last year, I've learned functional programming in Clojure, and that's what I write every day, and I've just sort of noticed that actually quite a lot of more experienced programmers who come from a Java background, many of them are still continuing to write Clojure with a Java Lens because I think it's been harder to shake that off. Whereas, in a way, I've realized, actually, I had a bit of an advantage in that, I came to this language and I was like, "Why are there so many parentheses everywhere?" I wasn't questioning it too much, I was just accepting it. I also think it's quite an interesting thing that I see in this industry is people getting very emotionally attached to languages and different tech stacks. I think it's really great to be passionate about things, I'm not dissing that, but sometimes, it can get a little bit harmful in a way. Sometimes, where we're saying, "Oh no, this is rubbish and this is good." I've found that having not come from that background, I just find that I feel I am much more, sort of, neutral to that and I'm learning things at face value, and because of that, I've seen that, in some cases, I've been able to go native a bit quicker with the language.
I've been constantly trying to figure out what is the strand that's connecting this apparently, crazy trajectory, I never would have guessed I'd be here like five years ago if anyone had asked me, and it's been interesting reflecting back. I've seen actually that from when I was doing research, a lot of the things I'd be doing is trying to abstract things to form coherent arguments. When I would do that, one of the main tools I would use would be mind mapping, drawing things out. Interestingly, since I've become a developer, I've realized that is something that I've found really useful.
When I'm having technical discussions with people trying to get to a shared understanding about a complex technical challenge, that skill, being able to discuss abstractions, visualize things to form a shared understanding, I've realized, is a strength. Certainly, I also think this thing around language and gatekeeping is a really good point. I've had discussions with product owners where they say, "I feel stupid." Really, it's because there's been a bit of a lack of awareness in the room with tech leads, people using technical jargon, and that has actually led to key business stakeholders not really understanding what's going on, but feeling embarrassed by that.
Certainly, having come from a non-technical background, having been the person who was like, "I thought Git and GitHub were the same thing," when I started, I can very much relate to that. I also see that that has been important, that that's been something that I've been able to help with, but at the same time, there is the trap of being the glue, which I think is a really good point. I do also see that that is a way that, as a career changer, I've been able to add value by being very aware of what sort of language you're using, including people. Just because you don't know something, it doesn't mean you're stupid or you should never feel stupid about that. There is still a lot of that in our industry, unfortunately.
Impostor Syndrome
Rees: For the rest of the session, I'm going to try and get as many of the questions that you put in as possible until they pull us off the stage. The first one moved on a little bit from what you're talking about. There was a question about impostor syndrome, that feeling of being inadequate in the room. Another question that was quite interesting about the same thing, about the idea of how to admit, what you don't know, while being in a minority or a different background from everyone else and this feeling like, "Oh, well, we've let the barbarians in and this is exactly what would happen now. Now everything's really non-technical and woolly thinking." Impostor syndrome is obviously a general thing, even for people with computer science. Any thoughts about that would be great, but also how that intersects with the idea of trying to be seen as coequal in your groups and your teams.
Byrne: Outside of work I am a poet. Before I became a software engineer, I got accepted onto a program called Barbican Young Poets where they take the top 20 young poets and they put them in a hothouse for a year with the senior poet who helps you build a portfolio and ends in a performance at The Barbican at the end of the year. There was hundreds of applicants and I got in, I'd literally never shown my poetry to anybody before in my life. Though I had built my first website at age seven to host my poetry, so I should have probably figured out then that I wanted to be a software engineer.
I'm in this room full of people that have published manuscripts and they all know each other. They go to each other's nights, a bunch of them are on the nationwide adverts. They get paid to go to festivals, go abroad, they've won slam championships. I'm standing there, I'm probably the oldest person in the room, approaching it, I came from work, and I have no confidence. "What am I doing there? I've tricked this Ford Prize-nominated poet into thinking I'm good. Oh, so I'm Irish. He clearly just likes Irish poetry and I'm the only Irish person in the room. That's it, he just thinks my way with words is lyrical." It felt horrible. I remember I went home and I actually wrote down how I felt because I felt so terrible to be in that room and I didn't want to go back again, and I was describing all these motivations to people, how they perceive me.
My flatmate at the time was a social worker, which was actually really handy. She just applied social work because whenever I was having a problem, she'd be like, "What outcome do you want, Anne?" She was like, "Don't assume or prescribe motivations. That's the quickest way for there to be a conflict. Why don't you just go back again and before you go in, write down all the motivations and put them somewhere that you think these people have and just drop them. Then if you feel comfortable enough, maybe say to somebody else, I felt like this," and it totally changed.
I did BYP for two years, I've been a member of a collective with someone in them, I've performed at the Tate Modern, I've performed at the Stoke Newington Literary Festival. I'm now paid to perform, I have a relationship with a publishing house in order to get a pamphlet out, because I've realized that everyone else felt that too because I just said it to somebody else, I felt, "Why am I here? You all know each other," and they're like, "Yes, but we all feel like that too and sometimes, we went into that room not knowing each other." It meant then, when I became a software engineer, I still had that impostor syndrome but I knew that, at some point, a community can build out of that.
What I do now is I find allies, as mates and I'll just be like, "Oh my God, I'm so dumb. I didn't know what that meant." Or, my favorite GitHub, pull, all the time on my PRs it says, "This might be really stupid, but what does this do here?" That's my go-to comment all the time. Then I now have people saying to me, "I'm so glad you say, "I think it's stupid, but what does this mean?" Now, I'm having to unlearn it. I'm now at the point where someone's like, "Stop saying you're stupid. You know what you're talking about." Finding spaces, asking other people, learning to stop ascribing motivations because everybody else is probably doing that to you. People think I'm some terrifying beast sometimes and I'm like, "No, I cry at cute baby photos too. That happens too."
Fowler: That's not me, by the way. I had a baby, I'm not a cute baby. Just a couple of small things to add, I think impostor syndrome is a healthy sign. It shows that you don't suffer from Hubris and an excess of confidence, we don't know it all. Another point is engineering concepts are super well documented on the web and super easy to Google and you can ramp up on that knowledge very fast, very quickly in a meeting. After someone says, "This algorithm is Time-O, Big-O, nlogn," and you're like, "What the fuck?" You google it, but googling life experience isn't a thing, you can't google that. The CSs and the non-CSs are going to meet halfway at some point. As the CSs forget what they used to know and the non-CSs learn stuff and we all learn about life, we all end up in the same place. I think it's going to be ok.
Ogura: It's going to be ok. I touched on that a little bit earlier, but being really open, even though it feels like you're admitting your weakness, but that's exactly what you want to do. You want to admit your weakness and strengths and communicate that to people. It's most likely that people are feeling the same thing, and I think it's the theme here. It looks like everyone knows everything and I'm the only person who doesn't understand this particular thing and it's just debilitating, but I feel like I shouldn't let that just stop me from showing it. I shouldn't hide it because that will just further, perpetuate the atmosphere of the room.
I have so often this conversation with my colleague who sits next to me and I'm like, "I still feel like I should have done computer science." He doesn't have computer science and he's like, "Yes, I used to think that a lot." He's been in the industry for 15, 20 years. One thing he taught me was that, at one point, realized that, "Look, I didn't know something, I went into it and I understood it. I did that maybe a couple more times or, 10 times. I don't know how many times, but at one point I knew that if I don't know anything, it's fine because I'll understand it." Again, sharing that, almost like a vulnerability, that's really important to create that safe environment to admit and support.
Fereday: I remember being really shocked when I was chatting with a tech lead and he told me he that week or something had had some impostor syndrome, and I was just so shocked. Perhaps this sounds very naive, but I thought, "Oh, but I thought by the time you'd been an engineer for 10 years, maybe that feeling would go away." It doesn't, apparently. I think it’s a constant thing, regardless of what background you come from. It seems to be a common thing that I've heard from my colleagues who, for me, on paper, I'm like, "Oh, you're the dream. You've been coding, you always knew you wanted to do this and you've done it the whole time." The fact that they still have that is just, it's our industry. You have to learn how to learn.
You have to figure out how you can learn because we have to be constantly learning, basically. That is our job and that's awesome, that's amazing. We're so privileged to be in this industry and to be able to constantly learn new things, but you also have to not be crippled and overwhelmed by that. There was a really good talk on the career track and he was talking about prioritization and I don't know if everyone went to it, but it was a very good point around making sure that you prioritize on things. I have my Trello learning board and it had 50 things and I was like, "Oh, and today I'm going to figure out trees." At some point, I realized that you have to pick your battles slowly, a little bit at a time, and keep chipping away at things and keep learning because we're all in the same boat. Some of us have to work to get some of that foundation, but it's more of shared learning boat thing together.
Onboarding
Rees: I want to stay on that point a little bit about learning to learn learning. There were some questions about how were you expecting to be trained and onboarded when you joined the first team? Were your expectations met? In terms of people trying to bring people outside of that comp sci background in, do you have any tips for helping people get on board, giving them results that they can use to learn and bootstrap themselves once they've actually started work?
Fereday: At ThoughtWorks, they have 50% of their, I don't want to say I'm a grad, I'm a bit older than that, but 50% of entry-level people coming in are actually career changes. I'd say they've done quite a good job in their onboarding of creating a bit of a culture of making sure that people working at the company are aware of this and are supportive. I definitely feel very fortunate to be working somewhere where I do feel very much supported by my colleagues.
We will pair together, but I've also had people offer to rake time out of work to sit through something and we'll go through it in a bit more detail together. I think that's really key, that sort of encouraging the sort of culture of learning. Something that I would love to have would be dedicated hours in my workday, so say I could take two hours in the morning and I could put that towards my own learning time, I would love to have that. As it stands, that is something that I do myself outside of work.
I think there's something to be said for getting this work-life balance. I have found that I've needed to do some additional toy projects and things, but I've also wanted to do it outside of work, and I've found that's really helped me to ick up my technical skills more quickly. That's not a good choice, for everyone.
Finding ways that people can learn on the job but also have protected time within the job to learn. In the end, people can't tell you everything, you need to figure out what is it that you don't know. Get feedback, keep getting feedback to figure out what areas to work on. In the end, we all have to come up with our own learning plan essentially.
Key Points
Rees: Do you have any key points? Final thoughts around can you learn.
Ogura: For me, this shift of frame of mind, everything you don't know is actually the opportunity for you to, "Look, I learned this and I know this and I can explain this to other people now." At least for me, that's the way I handle impostor syndrome or, that's how I keep my motivation really.
Fowler: I'm going to be a little bit hard here. I think it's wrong for us to suggest that the people who've done computer science somehow have an unfair advantage. I think it's a very fair advantage, they did three, four years of hard study that we didn't do, it's an advantage and it's fair. I think it's really down to you to get up to speed, if you're going to enter a profession without vocational training in it or a degree, it's your responsibility to learn. I don't think we can expect our companies to solve that gap in our learning for us, our employers. It's down to the individual, there can be some stuff at work, but just spend some time in the bedroom reading stuff all night. That's how you learn, hard.
Byrne: I'm going to completely counter that seeing as I no longer work at the Guardian and I work at a well-funded startup. Take your company's money and go and do workshops and conferences because it's an investment in you. You always need to learn, I'm not saying you should go and do a "Hello, World!" thing, but I did that. I've now developed a specialism at Deliveroo for functional programming. Even though I don't write Scala at my job, I run a Scala study group for other people that do so that I can be beneficial in reviewing PRs and help others.
There is a company benefit to you becoming better at certain things. You are right, they have a fair advantage, they shouldn't teach you a computer science from the ground up, but if you do want to support them, lower the bar. Don't make them come and ask for that, let them know what they can ask for and then they will do it. It's a lot harder when it’s like, "Oh, I'm being outrageous” than by just saying “I feel like this is going to really improve my understanding," whereas I went away, specialized in functional programming due to a week-long workshop, and now I'm learning Go for the first time but I'm able to mentor a more junior engineer who has never switched to another language before and doesn't understand programming theory even though they did a few years in boot camps and I'm able to share that understanding.
There is company benefit to it, and pair. Oh my God, build a pairing culture in your company, that is the best thing. I spent my first week pairing, writing Cloud formation, writing functional code. Unfortunately, I didn't understand that that was hard, so I wish someone had benchmarked it with, "Oh, the other engineers are pairing on JavaScript. You're pairing with some really horrible stuff." It’s ok that your head feels like it's going to explode. Pair, give them money, and make it easy for them.
See more presentations with transcripts
