 Good afternoon everybody. This is the last talk before we adjourn to lightning talks. Is there anybody here that has a lightning talk that they are giving? That is a awesome, okay. I'm excited to see your lightning talks. They are better because they are less intense to prepare. So I would like to talk to y'all about your careers. Who here has one? A career. Okay. You may have more than one. That's okay too. I think we're actually not going to define career today. Thank you for the suggestion. That's a terrible idea. I have an eight-year-old boy at home. I was struggling to come up with a theme for my slides and one night heading up the stairs to bed, I stumbled directly onto an idea. So I should probably note that five years ago I basically told the me of today not to do this. So we'll just try to get this together and see how it goes. I very nearly retitled this talk, the five existential crises of a senior developer. But recent world events had my heart pretty busted up so I just want you to know that this is actually very hopeful before I start playing on your fears. Okay? All right. Okay. Let's talk a little about me first though. I'm Brandon Hayes. Here's a conference speaker pro tip. You have to start by establishing your bona fide. So I'm here to talk to career stuff to you. So the thing I need to do is dazzle you with my flashy job title. So I want to thank the front side. Before I left there, they graciously paid for my trip out here. They're an amazing front end consultancy specializing in JavaScript heavy client side applications like EmberJS apps, React Native, stuff like that. So I don't know if I was good or bad at my last job. I love the front side but I realized one day that I literally couldn't do my job anymore. So the thing is running a company doesn't mean you have one job, it means you have like 100. So leaving a CEO job, the good news is I get to write an incredible journey medium post. So I'm looking forward to that and telling you all about my incredible journey. But that's not what we're here to do today. And it doesn't really tell the whole story. I haven't even had just one career. I've had a series of them. So let me show you my impressive job history. Super awesome, right? So I don't know what you would call this. So these are careers. I had a friend correct me and say, well what you say, what you're talking about isn't a career. It's a collection of careers. I was like, okay, name that for me. Meta career. If somebody has a name for that I would love to hear it. But I actually think maybe language is failing us a little bit here because this is such a modern concept that people do this this much now. So we're going to talk about five existential crises. And existential crisis is basically where you wonder about the point of your present situation right down to the level of your very existence. And if you've never felt one of these, I'm so happy for you. I'm scared for you because it's going to happen sooner or later. It's going to be rough. It's going to be happening. It's going to happen at stupidest time. But before I do, I want to note that we as an industry and as individuals have some seriously broken assumptions that go into calculating what constitutes our value and purpose as software developers. I'm going to talk about a lot of these existential crises and how they're caused by our broken calculators giving us a distorted picture of what our careers should look like. But before we go into the reasons this happens, let's dive into each crisis chronologically. So I got to spend a week teaching at Turing School about a month ago. And my friend Tom dialed in at the end of the week to speak to the students to tell them about software in the front end. During the Q&A, one student got up and said, hey, question, what recommendations do you have for people trying to break into the industry? And Tom was sort of taking it back for a moment, and he could only reply, it sucks and I'm sorry. And that's been my advice to people for a while. It just isn't much fun when you're trying to get that first programming job. There's very few job postings that are looking for junior level devs. Job postings say you need 10 years of react experience and a PhD in computer science to even bother applying to a junior level position. And the natural response of a rational human being is, well, that's bananas. I don't qualify for that. And they move on. But the hyper-confident people who are not rational, they come out and they push on that door a little bit, and they realize it can't open for them under certain circumstances, which we'll get to a little bit later. Then when something does look good to you, you apply. And maybe you get that interview. For me, this was a remote pairing session with a VP at Pivotal Labs. And I was trying to get my first dev job. After about 40 minutes trying to build a set class in Java, which is like, I don't know, trying to build a house with chopsticks, the interviewer said, well, that's going to be a no for us. So keep at it or whatever. And I couldn't really tell, but I really imagined the guy was really irritated with me for wasting his time. So I went home. I cried my eyes out. I talked to my friend Dave Brady, who was delighted. And I was really mad. I was like, why are you laughing? He let me know this is a normal, even critical part of the horrible, horrible process of becoming a software developer. So I don't have a ton of tips for getting that first job. But confidence, I guess, is key. So if you can, borrow some confidence from the future version of yourself that knows how to do this job. And if you survive this and you hustle and hustle, you come and you get to show up in your first job. And way to go, it's going to be amazing. Right up until you hit that next existential crisis. And if you come from bootcamp or college, it's pretty jarring to learn that you were basically stranded in the woods, given a pocket knife and told, see you in production. And you're like, wait a minute. No one is going to help me take charge of my own growth. Am I really on my own? Why is your most senior developer someone who's just a few years ahead of you? Where the heck are all the 20 and 30 year developers? But it's just one of life mysteries like where the socks go in the laundry. So no time to worry about that. We got code to shit. And then you run headlong into your next existential crisis. Man, can you even get a break? It's just like you look around and you're participating in these communities now. And you see these amazing accomplished people. And you think, that person has a podcast. This one's running a conference. This one's a world-class speaker. What am I doing with my life? How am I ever supposed to catch up to these people? How many people here are familiar with why the lucky stiff? Please be a majority. Okay, thank God. Okay, so if you're not, he was a very early proponent of Ruby and sort of this mad artist slash developer. And in 2006, I actually took a snippet of a talk from his from 2006 in my RailsConf talk this year. And I'm taking a different snippet from the same insane presentation this year. This is why the lucky stiff and the thirsty cups. Can I just take a quick poll of the audience? Has anybody ever felt like that? Have you ever felt like, am I a real programmer? I'm gonna save me. It doesn't help that there's not even a real definition of what senior developer means. And we just kind of slather, when we hire, we slather culture fit all over that to patch up all the places where we're making it up. So I'm gonna take a big detour into this in a few minutes. But the problem remains, we don't even know what we're trying to accomplish. We don't know how long it's supposed to take. We don't know how to tell when we've achieved it. It's like these definitions are specially formulated to inflame your imposter syndrome. So the reasons for this are, again, part of that broken calculator, which we'll come back to. But we just keep coding. We keep solving problems. We learn the new technology. And then at some point, we take a job tile that has senior in it and mission accomplished, right? For a while, it is great. You take the job, you level up at the technology. But after about 18 months or so, you start noticing that the pace of learning is slowing down. And that kicks off this job cycle. So let's check in on your job tenure while we're doing audience participation. How many people here have been in their job longer than 15 years? An overwhelming majority. Just kidding. Basically nobody, just you. Okay, what about 10 years? Who's been here at their job longer than 10 years? Okay, that's, all right. What about five years? Who's been longer than five years? All right, we're getting a few more hands. Who has been in their job less than 18 months? All right, so obviously that's a vast majority. The reasons for that are varied. But from talking to a lot of developers, the cycle of diminishing returns, it's a major contributing factor to burning out in each individual job and then between jobs. Again, another broken function inside of our calculator. And after a few trips on this merry-go-round, it becomes harder and harder to derive satisfaction from your job. Come on, come on, come on. Okay, nope, oh, oh, hey, you can do it. Nope, come on, no. This is the rest of the talk, by the way. All right, we're just going to wait for this rocket to finish and then we're going to go. All right, let's just move on. So the last existential crisis shouldn't really be happening at all. The one that involves a total existential meltdown, but it's the cumulative effect of doing this over and over again in all the prior ones, plus a bunch of other stuff. And that is the total existential meltdown. This is the person that gets so fed up with this cycle with a lack of foresight, having their experience under value that they bail and move to a farm. Those of you who are sort of new to programming may be chuckle, but those of you with a couple decades are like, oh my gosh, that sounds... So you get to a point where your spirit is crushed, your soul is tired, you just want to go home. All in the industry that you joined because programming for our living was your dream job. What the hell happened here? So I mentioned that our calculators are broken. We're calculating our purpose and our value in this industry improperly. These calculators are broken because we're feeding them some bad assumptions, and that throws off our formulas about where our value lies. So let's take a look at some of those. The first broken formula in our calculator is the compressed timeframe we use to measure ourselves. There are a ton of reasons behind this, but it lends a sense of pretty extreme urgency to what we feel like we have to accomplish. It starts with, hey, I don't see any role models, they don't see any people here that have been here 15, 30 years in this industry, maybe it only lasts for 10 or 15 years. Since I'm only in it for 15 years, I better get good fast. Hey, everybody else is getting better faster than me. I have kids and I don't have time for the second job managing open source. I can't really keep up anymore. Hmm, maybe I don't even have a place here. I'm out of time, I'm out of runway, and there's a manager job opening, I'm taking it. And after 10 or 15 years, you bail out. And then the next person comes along and says, hmm, people only seem to manage 10 or 15 years in this industry. So there's nothing fundamentally wrong of leaving the technical track to be a manager. It actually is kind of aligned with my preferences. But I've seen many developers look at that as their only way forward past that 15 or 20 year mark. We seem to have developed a career track that's like looking for elite athletes, like Olympic gymnast that burns them out at about the same rate instead of marathoners that can be competitive their whole lives. And the reasons for this are actually tied to a couple other broken functions in our calculator. So the second broken formula in our calculators is the hero problem. In the absence of concrete evaluation, we only have others to compare ourselves to. And we start comparing ourselves to the most visible people in our communities, our heroes. It's become fashionable to hate on the idea of our programming heroes. The problem isn't the idea of heroes, it's the measurements that we use to determine what makes somebody a hero. So they wrote a framework that gained wide adoption or they spend every waking hour working on open source. They had a successful exit in their business. Those are definitely visible metrics, but they may not be healthy to call heroics because they're not attributes that we can easily emulate. And many of them are impossible for people without copious amounts of spare time. I mean, we can't all have the commit graphs of this prolific shower. I believe that if having kids or being a single parent or having obligations to take up a person's spare time wrecks your ability to perform heroic programming feats, then we have failed to properly define that term. The third broken formula is about technology adoption. It's a big part of that Groundhog Day feeling and the existential crisis and the feeling of exhaustion the JavaScript community loves to talk about. But all of our communities actually suffer from. So one day Paul Graham descended from the heavens to give us a fashion magazine for the software developer and startup communities. So what's in, what's out, what is so last framework? And when you have startups with an 18 month window to launch or big or be shut down, this dramatically shortens your attention span of Silicon Valley. So you need to take every advantage that you can with that short runway. This creates an increased sense of importance about what's in fashion. So we need our fashion magazines, our businesses may depend on them. Alan Kay is one of the parents of much of what we know about computer science and he holds that programming is a pop culture which means we feel compelled to stay up on trends and use words like idiomatic. It also means we have a tendency to throw the baby out with the bathwater and reinvent solutions that have already existed. I know a fair number of developers who burn out so badly on just this aspect of programming that they're ready to walk away from day to day development or the industry altogether. So I don't necessarily know that we've got a shot at changing that about programming but we can develop some coping mechanisms. The fourth and final broken formula I want to speak to is the idea that senior developer is the terminus of your career. One thing that I learned running a business is that it's made me fascinated about how money flows through our businesses. If you follow the money, it's pretty easy to see one big reason people leave. Individuals in a company create and capture value. When we hire salespeople, managers, executives and so on there's a calculation that occurs about their salary or commission structure that allows the company to make enough margin on that to be profitable. So the first question is well, do programmers create value at an increasing rate over their career? I think so because we don't need more 80 hour a week 10X programmers solving the wrong problems 10X faster. We need folks that know which nine of the 10 problems don't need to be solved in the first place. That and the things they can teach the rest of the team is what makes super experienced developers so damn valuable and we need more of them. They obviously can and should be paid more, commensurate with that increase in value. But a weird thing happens to that value curve. Partly because programmers hate talking about money and as a business owner, I love that about programmers. It's extremely common that as soon as they're paid enough to not have to talk about money, they stop thinking about value. They get to not have the uncomfortable conversation and their company gets to keep all of that additional value for the rest of their tenure. So there are some notable exceptions to this. For example, at Netflix managers are tasked with researching the market salaries for their people every year and paying at top of that market value. But companies like that aside, this is a pretty widespread problem. The short-term thinking and the loss of respect for history, the lack of need to increase pay after about year five or 10. It starts looking pretty bad for folks into the second or third decade of their dev careers. It creates a culture that worships the new, eats the youth of our people and spits out experienced folks and leaves them wondering where they belong. So our broken calculators have a strong bias toward valuing things that only young, single, childless folks have time and tolerance for. It's seeped into so much of our culture that people are literally getting plastic surgery to try to be allowed to stay in this industry. We often assume older people just can't keep up with the pace of change when the pace of change itself may be a symptom of not having enough experienced people. For instance, I found out last night that Evan Phoenix and I are the exact same age. Look at him, look at me. That guy has had work done. So when the money curve flattens for technical contribution, many companies offer to promote us into higher pay scales in the management track that don't buy us against us because of our age. And so that's the easiest way out. If you have 10, 15, 20, 30 years of experience or you plan to at any point in the future, your teams desperately need you to set the standards for quality work, choose the right problems, educate people and generally help folks avoid huge, costly, time-wasting mistakes. If you want to stay close to technical work, your experience and your temperament are crucial and we need you on the team. So maybe this habit we have of turning senior devs into junior managers instead of creating a longer technical track is counterproductive, especially for those that move into management simply out of frustration or a lack of runway. And it may take some tough love to fight for reinstating the distinguished developer track at our companies, but I think it's a fight worth having. So I'm not here to fix the whole industry. I'm here to help you as an individual come up with a plan to mitigate the effects of these problems and create a space that you're happy to occupy for the next 30 or 40 years. Maybe cumulatively, if we work together, we can do something about the systemic problems, but let's talk about you for a minute. I have a six-point plan for building a track to help you grow in capability and income for as long as you care to stick it out. So as part of this, we've got to fix our calculators so we understand how to calculate, increase and capture the value, whether or not we choose to stay on the technical track. Fixing our broken calculator starts by stopping and reevaluating some of our base assumptions. First, we need to stop and catch our breath and get some perspective. For me, this happened recently when I had an amazing perspective shifting talk with this guy. This is Alan Worsbrock. He's a 45-year veteran of the industry. He's worked for big and small companies. He's founded them. He's worked in high-level positions at Microsoft and Mozilla. He was one of the earliest implementers of small talk and he wrote the ES6 language specification for JavaScript. Now he consults and teaches people how to use history to protect the future of this volatile industry. He's basically like a programming James Bond. You wouldn't know it by looking at him, but he's a badass. And he told me that as he sees it, one of the biggest problems in our industry is that we're all racing to try to have the biggest impact we can in a 15-year career and that timescale is totally out of whack. It breeds an urgency and makes us feel like we're constantly behind. It takes 20 years to become a master level developer, but we feel like crap if we haven't written a world-changing piece of software by our 10-year mark. He said it's exceptional if people are able to have industry-wide impact before decade four or five. For me, this conversation helped create a perspective shift from a 15-year race to a 45-year fun run. When you think on this timescale, it takes the pressure off. There's plenty of time to have an impact, to contribute, to learn more. There's time to develop the version of yourself that can have that big impact 30 years from now. So step two is to find your board of advisors. You need people that you deeply trust and that can help you reach clarity and think about what you really want. These moments in clarity and purpose are difficult and impossible to achieve by yourself. They may happen in solitude, but they don't happen in a vacuum. When I was just getting started as a developer six years ago, I adopted a mantra, paid to code, paid to code. Somebody just hire me, get paid to code. I want to get paid to code. Later at a start-up meetup, I went with a friend of mine and there was a talk by the CEO of the company that owned the building that we were meeting in. My friend JT elbowed me and said, hey, didn't you say you wanted to get paid to code? This guy just said they hire Ruby developers here. Go up and talk to him. And I was like dressed in a hoodie and I was like, I don't know. I felt like I looked like a schlub and I was embarrassed, but I went up and talked to the guy and said, hey, you don't know me, but I'm looking for a job as a developer and he's like, oh, we'll get back to you. But sure enough, they did get back to me and that was my first paying developer gig. A second story. A few years ago, I went to a breakfast with a bunch of people including Sarah May and she won't remember this, but I was describing how I was getting super burned out and I was using building robots to teach kids how to code as sort of a coping mechanism for that burnout. And everybody else at the table was like, cool, you could actually maybe get a job doing robots and Sarah cut right through that and was like, you seem happiest when you are teaching people. And I was like, huh, I never thought about that before in my entire life. I was kind of taking it back, but these are the moments that stick with me. I've also learned exactly what I do and don't want to do, being brutally honest in my one-on-ones with my business partner, Charles. And I realized I didn't want to play the role of small company CEO anymore. He and the rest of the wonderful people at Frontside since that was beyond burnout and they supported me when it was time for me to move on. So the third step is to design your career map. This is where I want to spend some time elaborating because our industry is just terrible at this. So I want to declare upfront that the blueprint I'm about to offer is kind of a straw map. I thought very deeply on it, I researched it as much as I can, but it's just my take. So you're welcome to beat it up, customize it, tear it up, start over, but I want you to think about how we can start coming to an agreement amongst our various companies on the definitions of what it is to be senior and building tracks for people to progress there and beyond. So last year at RubyConf, I got up and embarrassed myself by playing guitar very poorly before showing this map. I talked about three tracks that developers can follow, but today I want to focus on the engineering track. If you want to leave the developer track, as you can see you have a lot of options, but for a bunch of reasons, most of our smaller companies don't have access to a solid developer track. Now in researching this, I've talked to a bunch of big companies and most of their career track sheets look like this. And when Alan told me about his first shop, he told me about the fact they gave him a sheet that unfolded into this giant broad sheet and it had a 30 year plan for his role as a technical contributor. And it looked like this, but it had more expectations in rows and a little more detail in columns. And he looked at the 30 year plus column for distinguished engineer and it had requirements like has created industry impacting software and things like that and wondered how he could ever achieve that. So naming things is hard and this track is tough to name. The industry shorthand right now is individual contributor or IC. I'm not a huge fan of the implication that the engineering track is not as much of a team sport as things like management. I think it kind of reeks of that lone genius developer myth, but collaborative contributor it may be a little too on the nose. So I've been calling this the distinguished developer track, but I'd love to hear what other people are calling it. So let's follow this distinguished developer track to find out what we need to do to build our own path to get there. So here's a statement I'm willing to stand by. There is no senior Phoenix developers out there. If you think you are, you're wrong. There are no senior React developers out there. If you think you are, you're wrong. And here's another. The thing is senior developer is not technology specific. That is a sure tip off that somebody has missed defining senior. So I've written about this before, but to me seniority is just the amount of direction a person can provide versus the amount of direction that they require in order to perform their jobs. It's about how much of the problem you can own independently. Now that's kind of a gross oversimplification. So let's dig in. So historically we've gone with wildly differing definitions and got reactions to determine what constitutes senior. I want to get a little prescriptive here for a sake of argument. So I picked 12 traits that to me add up to the kind of independent work that defines where a developer is on the track of being senior. So I'm giving each of these traits my own definition, which means they may not match yours, which is okay. We can talk about it later after I've had a nap and maybe some cider. So the 12 traits I'm presenting fit into three categories, which form this Venn diagram that adds up to a developer that can work and lead projects independently. It's still all mushy and gut feelings unless you can look for evidence that demonstrates one of these traits that a person has actually got experience and time and energy invested into each of them. So the evidence does exist though because if you're working on a trait and you care hard enough about something, the artifacts of this developed trait, concrete examples would just naturally fall out or artifacts if you're using the Queen's English, but I'm not British. I'm a citizen of the Republic of Texas and we say artifacts. So let's dive into these traits and their artifacts. The idea here is to look for how much a person has worked these muscles, not whether they simply like the concept of these traits. For instance, with curiosity. It's not the question of how curious is this person. It's how much does this person exercise their curiosity muscle? There'll be evidence of that exercise. Make sense? Okay, let's dive in. The first one is technical capability. Technical capability is what you think it is. It's the ability to tackle difficult technical problems and see them through the end. The four traits I want to highlight here are curiosity, rigor, fearlessness and propensity to ship. Otherwise known as shippiness, which is a real thing probably. So let's talk about each trait and highlight a person from our community that exhibits this at a level well beyond senior. One more thing, the ranking of each of these from junior to beyond senior is relative to that specific muscle. So a person can be junior in one area and senior in another. And in fact, that's the most likely scenario. So let's start with curiosity. Curiosity is the ability to be fascinated by the world around them and the way things work. So a junior just needs to know enough to ship. If they're a junior at this trait, they just want to know enough to ship. At mid-level, they will have done deep exploration in their primary tool or language and maybe started some exploration in an adjacent or one other. So maybe they're a Vim user and they've explored a little Emacs or have a hobby language on the side. Senior level, routinely transplants ideas from multiple tools or languages into their current task. And to go well beyond that, they will use patterns from mastering many languages to advance the state of the art. An example for this would be like Josef Aleem in creating Elixir. So rigor is the ability to know which foot to put forward and a willingness to walk that path. So we'll use testing as an example. At a junior level, they know the right thing to do but they don't know how to push forward and so they give up. So there's no tests. A mid-level exercises the discipline and tries and pushes through even when it may not be a good idea so you get crappy tests. A senior level knows the pain, the discipline, the pain the discipline is there to solve and is able to explain and enforce it among a team. And so you get decent tests. And beyond that, they can see industry-wide patterns and spot where the discipline is required or being incorrectly applied. And like we need a new approach to testing. Sandy Matz is a great example of that and talked about this on the change log recently. Fearlessness is an unwillingness to be intimidated by problems that don't have a clear solution. At a junior level, they're too scared to attack problems for fear of failing and needs a clear path in order to be willing to start. A mid-level developer knows they're likely to be able to get through. They may actually mimic fearlessness by being ignorant of the consequences. A senior level assumes or knows basically anything's possible and knows which problems to attack and which ones to leave alone. And beyond that, they can attack problems on an industry-wide scale. Like, hey, let's design a framework or, better yet, let's improve the framework we already have. Aaron Patterson, I would consider a really great example of this. Fearlessness is not just jumping into the unknown. Bye. It's about knowing that failure is an outcome that could end up turning out okay. And so being willing to try anyway. So, propensity to ship is the desire and ability to get work out in public repeatedly and rapidly. So it finishes what fearlessness starts. So at a junior level, maybe you have 90% complete projects all over the place and few, if any, to point at at all. At a mid-level, you may have lots of started, published, and abandoned work. At a senior level, you put work into maintaining a few projects that are getting some usage and you know what it is to maintain and own shipping software. And beyond that, you'll have work that's recognized and had impact at an industry level. So Mitchell Hashimoto could be a great example of that. Somebody that just keeps shipping. The second idea is leadership. The second area of traits. The net result of somebody who has exercised the muscles of leadership is they'll typically be labeled a really excellent contributor. So the traits I wanna highlight are owner's mindset, communication, and persuasion skills, purpose, and the ability to focus on the next right thing. In an owner's mindset, you can own larger portions of the problem closer and closer to the core business problem. And they range everywhere from junior where I just wanna solve the problem at hand to being able to point to more specific cases of ownership of a business problem. At a senior level, you would probably be able to say, I've sacrificed these technology preferences to solve this business problem. Beyond that, you probably have started, run, failed, crashed, cried, and succeeded in business at some level. To me, Lea Silver is a really great model of somebody that exhibits this trait. Communication and persuasion is the ability to bring people together to a shared understanding, resolve conflicts, and inspire people. At a junior level, you have a basic understanding of the importance of communication. At a mid-level, you may have developed some active listening skills. At a senior level, you can explain some touch situations they've diffused and prevented by changing communication patterns. And beyond that, they exhibit industry-level influence in writing, public speaking, and other media. And I'm loath to say this, but I think maybe Justin Searles is an example of somebody that does that really well. I'm kidding, he's a friend of mine. He's a total thought leader. I guess you could call that thought leadership. So, purpose is the ability to connect to you and work toward a clear vision of a desired outcome. A junior just wants to work toward a larger purpose, but isn't sure what that is yet. A mid-level can kind of describe how their work aligns with the larger purpose of the company. A senior level probably has their own purpose and is able to explain how their purpose aligns with their work. And beyond that, they probably have a group of people around them, helping them to achieve a compelling vision. Saran Yabarak is a great example of somebody who's gathered a community of people around them. Or is she? What's really going on? Hashtag code maybe. Is it a friendly community or a dangerous cult? No, that's probably pretty nice. So, the ability to focus on the next right thing is the ability to break large problems down so that you know the next appropriate task. Junior level needs somebody to break that problem down for them. Mid-level would be unintimidated by a blank page or an empty code base. More seniors would be unintimidated by a messy page or a messy code base. And beyond that, a person will have used to this sort of like superpower of time, right thing leverage and the tortoise-hair consistency to have accomplished an inhuman-seeming amount. To me, Yuhuda Katz is a great example of somebody that does this really well. The third area is connectedness. And the idea here is to see other people as humans and include their needs in their work. And somebody asked me, why didn't you call this empathy? And the answer is, I got to make up the word connectedness. So, the traits that I wanna explore here are community-mindedness, mentorship, empathetic work and courageous honesty. So, Webster's dictionary defines community-orientedness as a thing I just made up. So, I define it as how much of your work and influence you share with others versus how much you keep to yourself. At a junior level, there's little to no community work. At a mid-level, you do more, maybe speak at meetups. At a senior level, maybe you're speaking at conferences or organizing things or maintaining an active blog at work. Beyond that, you may have industry-wide recognition for your community work. Sarah Allen for her Bridge Foundry Work or Improving Our Government's Technology Outreach at 18F would be a good example to me. Mentorship is the ability to share what you've learned with people in a way that impacts their behavior. So, at junior level, they like the idea of mentorship, but they're really looking to be mentored. At a mid-level, they maybe have a couple people that will call them a mentor. At a senior level, there would be lots of people that would say, I owe some of my career to them. And beyond that, they're recognized for large groups of people as a direct influence on their growth. I think Julia Evans, if you've never seen her programming zines, I highly recommend you check them out. Empathetic work is the ability and willingness to project the impact of your work on the lives of the people that are affected by that. And I use documentation to basically measure this almost entirely. So, basically, it is user experience and documentation. How much do you care and invest in the people that are going to use and maintain your software? So that's basically the rank of junior to senior there. I think beyond senior there would be widely recognized for helping entire teams to work more harmoniously in ways that improve the lives of users and maintainers. Sarah May is known for doing this in person and after a couple of whiskeys on Twitter. Courageous honesty is the last one. It's the willingness and ability to have a hard conversation that you know needs to happen. At a junior level, you just wanna go with a flow and preserve relationships or maybe you're needlessly combated. At a mid-level, you've studied and practiced skills for having these crucial conversations. At a senior level, you probably alter the course of somebody's business and certainly your personal relationships by having direct, kind, honest feedback. And beyond that, you'll know where these patterns of conversations are likely to be and teach people to put processes in place for them. I had to reach outside of our community to think of the best example for this, but you should watch Brene Brown speak and read her books. She's phenomenal. So I can't tell if this person is seriously junior or seriously senior on the courageous honesty scale. I've had job interviews that are very like this. So when you take all these together and you look for evidence of these traits, you can start to map out an average experience level across them and decide what you want to classify as generally junior, generally mid-level, generally senior and so on. Some people, probably most of us, are likely to be senior in some areas and junior in others. It's not an exact science, but the idea is to get a sense of what areas of improvement a person needs to work more on to be able to do more independent work. It also allows us to recognize that people from non-traditional backgrounds bring a lot to the table, even though they're maybe junior on the technical capability side. So again, you're not gonna be world-changingly amazing in all 12 of these, so it's important to discover your strengths and play to them. Once you've assessed those strengths, your map is gonna pretty much look like a list of the areas that you wanna grow in. It'll be challenging to map out, but it'll be more fun to cultivate than exercises, some latitude in determining technical objectives of assignment. Completed work is reviewed for desired results. So with that map in hand, the one that you design, you'll know what you want to get out of your job. You can work with your management team to talk about exactly what you want to learn and work and grow in and what the boundaries of that job are, where it maybe ends. That's where you pitch your manager on your career track as part of a more concrete system. You almost certainly wanna adapt a huge portion of this to fit your team. The only thing I ask is if you do take some of these ideas and publish how you do it so that other people can see your improvements, because I want to see an open source style thinking take hold and be applied to this problem. So with your map in hand, you'll have a long-term sense of what your goals are. You should know where that road at that job likely ends and I hope you're in a position to be able to be honest with them about it. If you're not, it's not ideal, but it's okay. It's super counterintuitive to think that a workplace would rather have you lie to them about your plans to work there forever, but maybe that's just me. So, and at some point it will be time to move on. And naturally these plans are going to change and adapt as you learn more about your preferences. For instance, when I was 24, my goals were not what they are now. In case you're wondering, that's today me goals. So, let's dive back into the scary world of those five existential crises, except now you have a new inventory. You're armed with a 45 year perspective, a group of advisors that want to see you succeed, a map of your path and your preferences, buy in from your company to help push you along this path, knowledge of what you want to accomplish and when you need to move on and the ability to adapt your plan. So at the first crisis you can pick your mantra, decide not to give up and lean on your board of advisors. Get paid to code. At the second you can realize you're in charge of your learning, your education, your growth and that's okay. You have a network of people to help guide and help you stitch together a mentorship program. On the third one, I hope you inferred that the why song was, the point was the question is absurd. You already are a real developer. You can work with your company to start understanding how independently you can work along that path. On the fourth one, once you start being able to assert your value as a senior developer, you're able to help craft a distinguished developer track at your workplace that rewards and recognizes the things you bring to the table as a more experienced developer. That goes a long way toward breaking that cycle and avoiding burnout. And the hope is if enough of us pull together and create cultures that value deep experience, we can keep more of the senior developers that are bailing out to jump into other career tracks or leaving tech all together. So I'd like to explore one theory why we burnout, a loss of a purpose to our work. So if you're familiar with Maslow's hierarchy of needs, in essence it's a layer cake of getting our needs fulfilled, one atop the other. As programmers, most of us live in the top two, striving for acceptance and internal fulfillment. It's a position of extreme privilege. Yet many of us hit these crises instead of fulfillment and happiness. Well, all these existential crises center on one key supposition, that happiness and fulfillment lie one more rung up the ladder, another salary increase, the next job, the next technology, another industry. Happiness is obviously found in more money, more prestige, more recognition, more impact, right? Climb the ladder, it's gotta be up there somewhere. But happiness isn't a layer cake. It's a swirl cake. The skills to dig in and mine for happiness and contentment are the same at basically any layer. So why am I telling you this? Well, many of our existential crises center around this stretching upward instead of inward for purpose. So the stretching is not a bad thing. It causes us to do crazy counterintuitive things like open source our code and suffer panic attacks at three in the morning, writing a conference talk. The six point plan, such as it is, is just a small micro framework, small focused micro framework. See, I don't do enough JavaScript anymore. I should be able to say that roll up right off the tongue for reminding you that you're right where you need to be on your own personal path. So last thing I'll say, I recently reread Zen in the art of motorcycle maintenance for the first time in about 20 years. And it was very different this time around. To some, this book is a heartwarming father-son tale to others, it's an interesting interpretation of Zen in our modern lives. To yet others, it's a philosophical journey into the definition of quality. It also has a sort of frightening subplot about mental illness and the loss of identity. But to me, it wound up being a book about the purpose of our work and our lives. So to explain what I mean, you just need to know that in graph theory, there's nodes and edges, the dots and lines on a graph. I wanna talk in terms of nodes and edges. This is you, you're an adorable, durable little node. So here's a thing you made, is it a quality thing? Does this node possess quality? Robert Persig defines quality as the relationship between a person and an object. He thought so deeply on this topic that it literally caused a complete mental breakdown. But I wanna use this graph to try looking at quality from a different angle. Imagine the thing that I have is a hammer made of Belgian chocolate. Is that a quality item? Well, it depends on the purpose. So let's define quality as fit for purpose. So that just pushes the heavy lifting into defining purpose, which again, exists as the relationship between a person and a thing. So that chocolate hammers quality depends on its purpose. If my relationship to it is that I have a nail to drive, it is a low quality item. If I'm hungry, it is a high quality item. One of my friends, one of my closest friends, Kyle Simpson, is a deep thinker about software. And he talks about this delusion program that we sometimes have that we're engineering things that are gonna stand for all time. He calls us architects of sand castles. Our sand castles are so ephemeral that we can see them evaporate many times over the course of our career. It can become disheartening to think that we're just architecting sand castles for the waves to reclaim. But that's missing the point of building these sand castles because this isn't about you. It's not about me. The purpose of a thing really takes hold when it starts fulfilling a purpose for another person and we get to serve a purpose for other people and they to us. And over time, you make more of these connections by creating more work that serves a purpose for more people by connecting other people directly to you and being a friend or mentor to them. Purpose is not in the nose, purpose is the edges. As we grow our impact and our sense of purpose by creating more of them and at higher quality, which again means how much it helps the person on the other end of that relationship. So when we create work that fulfills a purpose for somebody, when we do work that helps somebody else, that's when we feel most connected to our purpose. The sand castles we built and the work that we put in bring somebody joy, ease their pain or improve their lives in some way. And I'm gonna go out in the furthest limb I've ever done publicly and state that I think the purpose of my life is to facilitate these connections, to improve conditions for as many people as I can, directly or through my work, starting with the relationships that matter the most to me. That's a scary thing to say and it's a scarier thing to attempt. So how am I supposed to accomplish all that? Well, one foot in front of the other, 45 years later, you'll be astonished at what you can accomplish. Do not overestimate what you can do in the short term. Do not underestimate what you can do by making small improvements over a long period of time. And if we're willing to take the 45 year view, we don't need to burn ourselves out keeping up and comparing ourselves to others. If we're spending our days making steady progress on understanding and achieving our purpose, if we're using our work and our lives to improve things for those around us, we're mining for the happiness under our feet instead of trying to reach one rung higher. I've met those people. I wanna be one of them. I want you to be one of them. Study what it means to do great work, find people that bring that out in you and put one foot in front of the other. I love you and I believe in you and I'm here to help. Thanks. I'm Tiviking on Twitter. Come find me anytime here on the social media for virtual hugs.