Hello, everyone. It is so great to be here presenting at You Got This. I'm such a fan of all these events. And thank you, Kevin, for inviting me to talk. Today, I want to talk a bit about taking different paths. And oftentimes in life there can be multiple paths that one can approach, and some of those paths are more trodden than other paths, and I think the path I've taken a bit in my professional life might be seen as a bit of less travelled. So, I started my professional career as a Rabbi, a congressional leader both in synagogues and on university campuses. I did that for about a decade throughout the United States. And about five years ago, I decided to pivot my career and I became a software developer. I went to a boot camp, did the whole boot camp process, and found my first job. Since then have had a couple of roles in different software companies.
And I say that my path feels a bit unconventional, but I actually think if we take a moment to really think about the trends today, the path that I went on from one career to another career happened to be from Rabbi to developer. It could be anything. It's becoming increasingly more conventional. More and more people, especially as second careers, a bit older in life, are deciding to change jobs. And they're doing that for a variety of reasons. And it's happening a lot. And, in fact, the pandemic itself, this past period of time, has in many ways ask set rated this process. Last month, Harvard Business Review put out a study that showed somewhere between 20% increase from 2020 to now people in the ages of 30 to 45 resigning from their careers. Not only that, people in that age bracket, which captures my age brackets, are the greatest age of resignation among any age bracket, people who are switching careers. It's a huge sector. People are doing it maybe because they're looking for something new. I switched into software because it provided me with curiosity, a chance to build something, to exercise a part of my brain I wasn't really exercising before, and a lot of people are in that process.
You know, as of last month as well, "Business Insider" said something like 66% of Americans, and this is Americans, but one can extrapolate to others as well, are keen to switch their jobs. And as I said, they're doing it because they are interested in new opportunities, because they're curious, because they want to try something exciting and new, and there's also another really fundamental reason, which is according to the latest data we have, software developers earn on average three times more annual salary than anyone else. So, at the most basic fundamental level, becoming a software developer in today's economic landscape is a great way to earn a living for yourself, to support your family, if to support your loved ones, to lift yourself up out of difficult financial situations. It offers economic security in a time of a lot of economic insecurity.
So, there's a lot of appeal, a lot of attractiveness to switching into this field and becoming an early developer, even when you're a bit older and had another professional life. And yet, doing so is very different than perhaps the experience might feel like. You know, when I was going through the process initially and searching for my first job, it felt very much like I was that square peg or that triangle peg trying to fit into that circle hole and looking all around me and seeing everyone else, at least that's how I perceived it, gliding through their paths. Maybe they went to uni and had a CS degree and just went right over to their first job, their first internship or whatever. They were coding from the time they were 2 years old, they were in diapers, and now they're a senior staff developer at the age of 12. It just felt like everyone else was having it so easy. Those of us from non-traditional backgrounds were trying to fit ourselves in despite all the challenges. I firmly believe this quote from Dr. Seuss is utterly correct. That when something is awful, something is wrong, when there's deep issues, it's incumbent upon us to help make it better. Not only for ourselves, but for everyone else who's also coming up to this process as well. That we can improve both the condition for us as individuals, for any of us who are early career developers trying to make it, and be doing so, we also at the same time improve the condition for those who are gonna come right behind us. In this field, that could just be tomorrow. It could be an hour from now.
There are new developers coming up through the pipeline every day, practically. So, we have to really think about ways in which we can improve the situation, and I want to do it through two lenses. I want to look first at challenges and opportunities for the IC, the individual contributor, which is the employee, which is employee and you and many of you who are looking for the job, applying for a job, navigating recruiters and hiring managers. And I want to talk a bit about that. And then the second phase, we're gonna talk about what the manager and the recruiter and the hiring manager specifically can do to help rectify the situation, because they ultimately hold and wield a lot of power in this dynamic. So, from the perspective of the individual contributor, you know, when you enter this space as an early career dev a bit later in life, there's a lot of oddities you experience. First of all, there is the privilege of having to take a pay cut. And I say it's the privilege because not everyone can do this, and it's incredibly challenging and difficult. You know that if you are coming from one professional life where you've built up a career and you know that the software trajectory is going to yield eventually a very lucrative place for you and your family, but in that interim period when you're working yourself up professionally, you're taking .. for many of us .. you're taking a dive down economically. That is an incredibly challenging perspective to be in and requires a lot of privilege, which a lot of people don't have.
Then on top of that, there is also this weird situation where you are, in many cases, at the same time simultaneously the most experienced person, and so you're deemed overqualified for a lot of jobs because you may be applying for roles called junior developer, entry-level developer, and people parsing through the CVs are looking through and saying, well, this person has all this professional experience. They clearly are overqualified. While at the same time, you by definition are one of the least qualified people in the room and people who are 10, 15 years younger than you know much more about this specific domain than you do. So, you're in this interesting and odd place where you're both under-qualified and overqualified at the exact same time, and it can really feel quite awkward and quite weird in many situations being in that place, where you don't really know .. you know, you're sometimes too qualified and sometimes you're not qualified enough. So I think the first thing we need to say to help address that and take this as an active affirmation that I'm saying for myself and everyone else here, is that your experience in your other professional life, it matters and it counts. What you did before you became a developer has intrinsic value that you can bring to the teams that you will be joining. And that your rèsumè, your CV, despite what people tell you, despite how it can feel so often, is not a liability. Your CV with all that professional experience doesn't have to be an experience trap that keeps you from opportunities. Now, the question is, is what do you do about that rèsumè? Because it can often be .. for a lot of recruiters .. they're trying to Wade their way through hundreds of CVs for a job opening. Your rèsumè can often feel like this odd thing and they push it aside. So, I think what's required of us, what we can do to help ourselves kind of stand out a bit is to focus more on what we did in the roles that we previously held and focus less on the titles that we held in those roles.
What do I mean by that? So, let me give you a couple examples. So, let's say you were previously called a high school English teacher, or you were called a bartender or you were like me, a member of the clergy. All those titles don't sound incredibly welcoming to the role of a junior software developer or a software developer in general, but what did you do in those roles? So, as a high school English teacher, perhaps you created deliverable, measurable project sprints for 30 students every quarter. As a bartender, maybe you managed ongoing client relationships. As a member of the clergy, you had managed a diverse team of paid staff and volunteers and the skills to motivate and incentivize people who are not getting paid, ie volunteers, doing work. That's an incredible skill set you can bring to any team or any work that you're doing subsequently. So, thinking more about the tasks. These are just a couple of examples. Thinking more about the tasks and less on the titles you hold and focusing on them in your CV and highlighting them can be a real good way to lift your rèsumè up a bit and not scare away the recruiters who say, oh, you're overqualified because you were X, Y, or Z in your previous professional life.
At the same time, while you bring a lot to the table, it's also really important. This is something I had to learn, and I think a lot have to learn is, you know, if you're coming into this role from a previous career where you built and you've gone up, quote, unquote, the ladder and you built your professional career up already and you're entering in here, you're no longer, as we said, the most experienced or even near the most experienced. You're now one of the least experienced. And to learn to embrace that humility, learn to embrace the fact that what you know, you don't know a lot. And to internalize you don't know a lot and to look up to the mentors who all around you can help you. Mentors who may be 10, 15 years younger than you. That's totally cool, totally okay. To look to them and help them guide you and be okay and be willing to, you know, go through the internal work that one needs to do to be a bit more humble in your work.
But also remember, while you are practicing the art of humility that humility is not a doormat. And I think a lot of people conflate humility on one hand and meekness on the other. Humility and meekness are not synonyms. You can be humble and you can also not be meek. Humble means you know what you know and you know what you don't know and you act accordingly within your limits. Meekness is a step beyond that. You don't have to accept abuse from people who think, you know, it's odd that you're this older early developer. You don't have to accept insults. You can stand up for yourself and you can also recognize that you can bring a lot to the table based on other life experiences that other people in the room or in your team might not necessarily have, while at the same time recognizing that you have quite a bit to learn from everyone else.
When I try and think about how to manage this kind of challenging, difficult situation, I think of this quote from an ethicist, 19th century ethicist who advised his students that they should keep two pieces of paper in their pocket at all times. And on one piece of paper they are to write, "I am a speck of dust," and on the other they are to write, "the world was created for me."
So, on one hand, I am nothing, I am less than nothing, and the other hand, I am everything. The world was created for me. I am the pinnacle. So, keeping those two extreme polarities in tension in a conversation with each other is a great way to keep the balance going forward and to modulate the sort of that dichotomy of humility and of knowledge. Of humility and confidence at the same time. So, you may not have to keep two literal pieces of paper in your pocket. I don't keep two literal pieces of paper in my pocket, but constantly being aware of that tension that you have a lot and you also have a lot still to learn. And to learn and to accept that you don't need to undersell yourself. You have a lot of value. You have a lot of skills. You don't need to hide what you did previously. You can scout about it. You can be proud of it. Just phrase it, repackage it, reformulate it in a way that highlights the skills that are crossing over that have applicability to working in teams, working in context of collaborative sprints and being part of dynamic kind of workplaces. And I think it will go a long way.
The other area which can be very challenging for new developers is .. especially for older developers I would say .. is what do you learn? You know, one of the things that attracted me most to software is that it's a constant learning adventure. You never stop learning new technologies, new frameworks, new skills, but at the same time, if you're someone starting out, you know, in your late 30s or older, you might already have, let's say, a mortgage, might have children, might have a family, might have older parents to help take care of, and you feel this internal pressure to jump and accelerate because you can't afford to take too long to jump ahead in your career because you have so many responsibilities that maybe .. of course this is generalization. Other people who are younger might also have more responsibilities, but generally as you get older, you start accumulating debts and bills and family and older parents and all of those other situations, and so you feel that pressure. In fact, in this field, that pressure feels very, very real.
Do I focus as a new developer on JavaScript? What about being a Python dev? There is all this talk about Rust and Elixir. Maybe I should look at Rust. I hear Rust is really cool. Typescript languages. That's really interesting. Front end developer, backend developer, full stack, whatever that means. This pressure cooker to try and accelerate myself. So, when I think about that question, the way that I approach is it is to weigh the idea of applied concepts.
If I were to stop you on a street and ask you to explain this in plain English, what would you say? I got that intellectual exercise from the time I was in seminary and our teachers would be teaching us archaic tests from the second century in ancient Babylon and full of technical jargon and language. He would interrupt us and say if I was walking with you on Fifth Avenue and someone said explain this without any JPMorgan, any technical terminology, in spill English, could you do that? Could you look at this piece of code in Ruby and explain the basics of project-oriented programming. Creating attributes. What is an instantiation of a class and the variable that holds it? Could you explain those ideas in plain English? If you do it in Ruby, could you also do it in JavaScript? Could you do it in in Python? Could you look at a piece of code in C†# and do the same thing. Learning the basics, learning the fundamentals that come and appear over and over again in different programming languages, the syntax changes, the style changes, but the idea is a data structure.
You can talk about an array or talk about a hash across languages. You can learn the syntax and pick that up depending on what the job specifications might be, once you have some of those fundamental programming concepts and ideas more deeply rooted in your knowledge base. So, I think that's really a fundamentally important thing to do. So, on the topic of the IV, the individual contributor, to recap what I think are some of the fundamental areas. First of all, your rèsumè, your CV, it's not a liability. It is an asset. It's a strength. It brings with it a lot of experience. It's a question of packaging and focusing more on what you did and less on what you were called. And similarly, there is a constant tension between being humble, recognizes what you don't know, which is a lot. At the same time, understanding that you're not a doormat. And that you do bring a lot of skills to the table and you can bring what you can bring while also recognizing what you don't know and being gracious and accepting the advice and the wisdom of people who have been in this field for longer than you and have a lot to teach you.
As far as what it comes to need to learn, focusing more on the concepts and applying those concepts than a deep dive into one particular language. Learning multiplicity of languages and learning the ability to navigate those languages, review the code, write code in those languages, while applying learning the concepts that can be applied in those languages I think is a better bet when you have that kind of pressure cooker moment when you're an older developer, you know, jumping into this career and you have maybe a lot of responsibilities you're trying to navigate at that same time.
Now, when it comes to the manager, now, that's a whole different arena. The manager, the hiring manager, the recruiters as well, they wield a lot of power in this process, and it's .. and the more power one yields, the more responsibility they have to address and to fix the system. So, let's talk about the manager. So, I think it all begins when you think about managerial roles. It all begins from the orientation that the manager takes in the way in which they conduct themselves as a manager. And I'm really moved by this quote from Nelson Mandela, that it's better to lead from behind and put others in front. That if a manager's general orientation to their managerial philosophy is that I will stand behind my reports, I will support them, I will lift them up, I will be there for them when they fall, and I will celebrate their victories because my victories, my success is inextricably bound up in their success. The more they succeed, the more I succeed through them, and the more the organization succeeds writ large. And I often thing that gives a great summation of what we often call servant leadership, which is to lift others up. Not see your job as a manager through your lens, but to see it through the lens of those who report to you.
Now, that's not specifically about older second career developers. That could be about anyone. Could be about anyone they're managing at all. And that's just a general shift, a paradigm shift in the managerial orientation, which I think can be so fundamentally important to the way in which a manager conducts themselves, which is really, really integral. The area I also think is equally important is, you know, it happens to be that when a lot of people rise up, and often managers are promoted to the role as manager. They may have been an individual contributor themselves. That itself is a question of whether somebody should be promoted to managerial roles. Is that really part of the pipeline? Someone should probably select that they want to help lead and to mentor and to guide people. It shouldn't be seen as, like, a path from IC to manager, but bracketing that whole problematic equation and putting it aside, when someone occupies that role, they sometimes develop a bit of an inflated ego. I don't know if anyone's ever seen it before. You might have seen it. I'm not sure. That ego can be obstructionist, can get in the way of recognizing that the more diversity you bring to the table, the broader your team and representation of orientations and of genders and of race and ethnicity and religion and non-religion backgrounds. Of age. The more experience you bring to the table, the more broad your perspective will be in crafting the projects you're working on. And the more broad and more deep your projects are, the better they will represent the customers and the users that they are seeking to .. they're seeking to enlist. And so it's actually not only just a question of ethics. It's not even just a question of, you know, it's the ethical thing to be diverse. It's an interest to the profit motive of the company. Companies that want to succeed will create diverse teams.
That means they need to think beyond themselves and make room in their own headspace to be able to create teams across genders, across races, across ethnicities and across ages. That's fundamentally important. The other area managers can focus on is the question of what their pipeline looks like. You know, there is a hiring pipeline out there, and that hiring pipeline is deeply problematic. And recruiters who are sourcing candidates and hiring managers who are looking through that sourcing have an unusual and inordinate amount of power in the hiring by looking at that pipeline. There's often two paths when one imagines the pipeline for hiring. The first path kind of looks like, did you start coding when you were 8 years old? If you started coding when you were 8 years old, then, sure, we can fast forward, and congratulations, you now have a job, you're amazing, great, you got the job! The other path involves a couple more steps. Did you go to college? Oh, that's great. You went to college. Did you happen to graduate with a computer science degree? Oh, you did? That's marvelous. Do you like living and sleeping in the office? Do you like spending every moment of your life in this office? You do? That's amazing. Great, you got a job. I'm so happy. Welcome to the team! These two paths are exclusive to people who come from backgrounds, A, maybe they didn't go to college or if they went to college, they graduated with a CS degree. It's incredibly exclusivist. These paths are incredible common in the sourcing of candidates. Who you source is who rises up to the hiring manager. Really, you have to nip it in the bud at the pipeline itself. And that pipeline is fundamentally, intrinsically, indisputably broken, and you, managers, and if you're listening to this and you're not a manager, you may one day be a manager, you may have been a manager, you may be a manager again, you can help fix it. You can fix it by thinking all the time what doors are you opening? And always asking yourself, when I'm recruiting, the doors I open for recruiting are these following doors. By opening these doors, what doors am I keeping closed? And why are those doors closed? How can I open the most amount of doors in in my pipeline? Because I can't hire people from non.
Traditional backgrounds if I don't know they exist. I no they exist by opening the door for them to walk through. It's really, really important. So, to recap from the perspective of the manager, it's about coming to the role with an orientation of a servant leader. It's understanding that a diverse team of people who are old or second career developers across all spectrums of diversity, including older developers, is not only a good thing to do, the ethic, it's a good thing to do for your profit motive. It creates a better product. It creates better work. Your ego, your ability to see beyond yourself, can be obstructing to that process of creating a more diverse team. The way in which you create that more diverse team is to start at the very beginning, which is your hiring pipeline. Open as many door as you possibly can to bring in as many people.
This can seem like a lot. It's a lot of work to do. It seems like it's neverending, and I really do believe it's a lot of work to do, but I'm very moved by the idea that just because it's a lot of work to do doesn't mean it's not incumbent on us to get involved and do what we can. Whether we are entering the field, whether we are managing the field, whether we entered already and now we have some credentials, some leverage to exert on the field, every time we make it better, make it better in the organizations we're in, make it better for ourselves, we are ipso facto making it better for ourselves. Changing careers en masse, maybe one of the greatest career switching in modern times, it is really deeply important that we exert that effort to make it better for everyone because we'll make our teams, companies and the organizations we work for all the better for it. Thank you so much. I would love to stay in touch. You can find me on Twitter or you can email me. It's been great. Thank you.