NOEL:  Hello! Welcome to the Tech Done Right podcast, published by Table XI. I'm Noel Rappin. 
	Each episode of Tech Done Right focuses on people in tech talking about interesting problems. Today, we're talking about careers and career growth. 
	Our panel today includes Pete Brooks, a software developer at Table XI and Brandon Hays who asked me to introduce him as 'my friend'. My friend, Brandon Hays. 
[Laughter]
BRANDON:  Then it sounds like I have friends. 
NOEL:  That's good. Friend's fair. We're friends. 
[Laughter]
NOEL:  I like you. You like me, right? We're friends. 
BRANDON:  Yeah, of course. Yes, hi. 
NOEL:  The more I explain it, the faker and faker it sounds. 
BRANDON:  No, we're good. At what point have I ever wished you specific harm?
[Laughter]
NOEL:  That's good to know. Pete, do you want to say a little bit about yourself and how you got to be at Table XI?
PETE:  Yes. Now, I've been at Table XI for two years which is crazy. It went by really fast. This was my first development job. Before that, I was in college studying philosophy and I did dev boot camp for 18 weeks or whatever that is and luckily, ended up here. And it's been great. 
NOEL:  And Brandon, what are you doing these days?
BRANDON:  I am working at a startup. Until recently, I ran a software consultancy and kind of got burned out, left that. And now, I'm just working as a line level developer in a startup which means that that's not really what you do, you wind up trying to get the company off the ground with a bunch of people. And I really like kind of doing the barn raising phase of companies, so I've been there about three weeks. The company is called OJO and it's based here in Austin. It's been a lot of fun, so far, to kind of pick something up that's pretty new and try to grow it. 
	So, from being a business owner to just being a member of a team where somebody else owns the business is both really gratifying, it's fun, and also it's a little like a vacation after running a business. 
PETE:  [Inaudible] feel like a vacation.
BRANDON:  No, that doesn't last forever. That's probably the honeymoon phase. But it's a lot of fun. It's a good company and I'm really digging it. 
NOEL:  I wanted to talk to you guys together. Brandon has done a couple of great blog posts and conference talks about career growth, being a senior developer, and related topics. And Pete also has really interesting insight about what it's like to be a new developer and how you go about growing your skills and transitioning from being a new developer to being a more experienced developer and what that actually means. 
	I guess let me start by talking about -- we have this kind of weird level of distinctions. We talk about junior developers and senior developers or mid-level developers or mid-level seniors or who knows how fine they cut that apple. I have come to really hate the term 'junior developer', am I developing in a rationale distaste of it? What do you see is the distinction between -- like what makes somebody a junior developer or a senior developer? Like I see job listings that say 'senior developer with four years of experience' and that makes me wonder. I've got 18 years of experience and that makes me kind of wonder what I am, ancient?
PETE:  Super senior. 
NOEL:  Ancient superannuated. I don't know. Brandon, where do you see the distinction there?
BRANDON:  That's a good question. It's a sucky question. And I think the problem with being a software developer -- Pete, you've now been in both fields where you wind up chopping words up to the point where they're meaningless. I view software development and philosophy as related in this way that your job is to take a word and ring all the meaning out of it until words are just like completely meaningless pieces of sound that come out of people's mouths. 
PETE:  That sounds like a lot of philosophy at least. 
BRANDON:  [Laughs] And software unfortunately has the same thing. You wind up turning on the words, you wind up hating every word that you use because they wind up becoming so overloaded. 
	What I would like to try to focus on is we can keep poking at these definitions but the goal is not to define the words themselves or the terms, but to define the concepts and then we can kind of decide what terms work best for you in those cases, which is not the clearest way to communicate but we have hopefully a little bit of time to be able to do that. 
NOEL:  So what's the meaningful concept then?
BRANDON:  Like you had said earlier. Pete, how would you classify yourself? If somebody said, "Hey, I need to hire a person to do a job and that job involves software," do you have a sense of what you would classify that as?
PETE:  I'm not sure what I would say. I don't know. I feel like there are a lot of jobs that I would be able to do independently and feel confident. I certainly am not a senior developer; I'm not an entry level developer anymore. I don't know if junior comes after entry level or if those mean the same thing. So, I'm not sure. 
BRANDON:  Yeah. 
NOEL:  We can just decide. I think Pete is going for adjectiveless software developer. 
[Laughter]
PETE:  Which is really going to get me hired. 
BRANDON:  Yeah, if you're willing to accept the definition of software developer which even that could be contested. There's nothing that we use as terminology that is nailed down well enough to last forever. I mean, we're arguing over whether what we do is engineering. So software developer is a pretty safe little harbor there where we can say, "Hey, we're all software developers. We all generally do most of the same things in a broadly defined way. " 	
	And so, when you define things this broadly, it causes you to sort of define things sort of broadly. So, because what we do is such a broad set of skills, it makes it really difficult to put definition around. 
NOEL:  I look for jobs that just say 'person with a laptop.'
BRANDON:  I can type code that executes sometimes. 
NOEL:  And wordsÉI type words and code. 
BRANDON:  Now what I do is I configure webpack all day. And so, I don't know if that counts. I'm a junior webpack engineer. 
NOEL:  How may job sites could I go and find junior webpack engineer as an actual list and that people are looking for?
BRANDON:  Probably an upsetting amount. 
[Laughter]
BRANDON:  But Pete said something that I want to call back to because I think that there was a lot of value to what you said, was working independently. I feel like working independently is the only anchor concept -- and when I say 'independently', even that crap, even that is malleable, but the ability to take the lead on something and the ability to produce a result without requiring a ton of guidance. And so to me, that is an incline where you're able to do more and more independent work. That doesn't mean solo work, but independent in that you require less input and you're able to provide more input. 
	As a person -- I would say broadly defined in our industry -- as a person is able to produce output whether that's features or documentation, the idea is to be able to work somewhat independently where you require guidance. And so, I started putting definitions around how frequently and intense does this person require guidance is where we kind of broadly drew the strokes of 'here's what a junior is, here's what mid-level is, and here's what senior is'. And to us -- when I say 'us', I mean when I was at Frontside and making these hiring decisions and in the hiring decisions I make now, I define senior as the ability to work independently and to act on the supply side of this feedback where they're providing feedback to other people. 
	And so, it's not a smooth incline because there are some areas where you're going to have more ability to provide insight and there's going to be areas where you need more input. But broadly speaking, over the course of weeks and months, I think I had previously said if a person requires input in order to get their job done multiple times per day, that's probably a person you could pretty easily classify as relatively junior in a position or relatively -- I don't know. I don't have a better word than junior right now. So maybe we can define that. 
NOEL:  I don't have a better word for it either but I hate it. And I don't think entry level is any better. It's one of those things where every new word suddenly becomes more and more pejorative, the more it gets used. I don't know.  
BRANDON:  Yeah, it winds up becoming the tool sort of for 'you build the word to be a shortcut and then you use the shortcut to stop thinking'. 
NOEL:  Right. Can we throw a couple of juniors at that?
BRANDON:  Yeah. If you work in a consultancy, throwing a couple of junior at something is definitely a rough thing to hear because it's dismissive as to what we do for everyday and the people who are going to do it. 
NOEL:  It's what you can win-win if you're in the consultancy. 
[Laughter]
PETE:  When you bring that up 'throw a couple of juniors at', that sounds to me like that's an accounting word. 
NOEL:  Yeah, it's kind of an HR word. There's this weird interface where Brandon knows what he wants as the owner of Frontside or the person making the hiring decisions and that gets filtered, especially in a larger company, through some sort of HR process where they have to have a bucket because they have to know especially if there's some non-technical person filtering resumes, you have to set some sort of requirement. And it's kind of hard to put on a resume I only need guidance twice a day. I was able to make it through Tuesday without asking for help. 
[Laughter]
BRANDON:  I guess that's just the measurement I use as mentor, broadly speaking, but yes. When you try to translate that to HR, the weird thing is you try to look for metrics as a way to measure a progress. But as soon as you use it as a reward tool, people will learn to gain that. 
NOEL:  That's a long standing social science. The more weight gets put on a particular metric, the less represented it is and what it's trying to measure. Like that applies to all kinds of different things because people then [inaudible], it becomes strong. 
BRANDON:  What I want to do as an industry in kind of two parts is can we start to put some definition around what it means to progress. And can we give people a little bit of a map so that they understand where they are in that progress. 
	If I can tell a little bit of a story, I told this story in the conference talk. But luckily, statistically, zero people watch conference talks. In the grand scheme of things, I get to repeat this. 
	I recently met a guy named Allen Wirfs-Brock. He is a legendary class developer. He basically wrote the ES2015 spec. He was one of the first implementers of Smalltalk. He was a 45-year veteran of the industry and a really cool guy, amiable guy, and really happy in the way that his career has shaped up. And he makes industry-changing work as a result of what he does, and he helped kind of reset my expectations as to what that means for developers. 
	The first thing I want to do in order to have this conversation is perform a perspective reset. You've got to hit the reset button on the perspective because I've fallen into this trap. Every person I've hired has fallen into this trap. Almost every senior developer with 10 or 15 years of experience has fallen into this. And it is the idea that I have been in this industry now for 5 or 10 years. I should have had world-changing work by now. The impact I was going to have as a software developer, I should have already had or I have failed, and it's because we're holding ourselves up in comparison to people that have had only 5 or 10 years of experience and are making world-changing pieces of software like you see in Yehuda Katz or Dan Abramov in the JavaScript community, or people that create software that at a young age that winds up having a very large impact on the industry as a whole. 
	Because that's visible and because we have access to them via Twitter, I think, we wind up having this direct comparison deal where we think that we should have accomplished that by now. And there's a lack of access to people that had 25/30/40/45 years of experience in our typical work environments. So, it becomes this self-fulfilling prophecy of thinking, "I don't see people that do this for 40 years; therefore, this must not be a thing you do for 40 years." 
NOEL:  As somebody who is climbing up to 20 years of experience, depending on how you [xx] on this field, the relative lack of people with 25 and 30 years of experience is starting to feel kind of eerie to me, honestly. 
BRANDON:  You're the last man standing, Noel. What is that? Why is there a lack?
NOEL:  It's a really good question and I don't know the answer. The stereotype is that all programmers become bad managers. And then they're no longer senior programmers, they become bad managers. I don't know that that's really true anymore. I don't really have a clear sense of what actually goes on there. Ask me again in five years when I'm a bad manager. 
BRANDON:  There's the Occam's Razor [inaudible] too which is what's the simplest explanation to why people aren't here. Allen is the person that brought me up into the idea that it could be partly a self-fulfilling prophecy because I asked him this question, "Why do you think there aren't more people with your level of experience still doing this every day?" Why aren't there more people like Kent Beck and Ward Cunningham and Allen? People that stay in the technical side of this industry? Where are they going, first off, and why? As you know, the stereotype is that they kind of retire into management positions. 
	The simple explanation is always look at what is rewarded. So, what is the reward cycle like for a developer? And there's this logarithmic curve of -- I think there's a couple of things that happen. And I've talked to people enough that I feel pretty confident in both of them. There's a logarithmic salary curve to what we do because the value that you produce as a software developer continues to go up as you progress in this industry. You are able to save days of development and weeks of development and then potentially, millions of dollars and years of effort by making intelligent, wise, knowledge-work choices at certain stage of software projects. 
	I think most software developers with a lot of experience know that the knowledge they acquire has the ability to make huge lasting differences on software projects which run into the millions of dollars, and often much more, hundreds of millions of dollars in the case of healthcare.gov. You have clear examples of how experienced software developers and well-practiced process can save tens, hundreds of millions of dollars. 
	And so, you know that the value that you can produce is very high, but it also can be sort of difficult to quantify. But for some reason, the salary curve tends to level off as soon as you pay developers enough to not have to talk about money because we hate that stuff. We hate talking about money. So as soon as your boss can get you to stop asking for raises, then you'll not have to do that anymore. Whereas for sales people, that curve stays real tight with the value that they know they produce. Maybe partially because sales is so unpleasant that they go, "Hey, I did this much." But they're also sales people. 
NOEL:  Sales is very quantifiable in a way that 'I saved you hundreds of millions of dollars by making a good decision' is no joke. One thousand dollars to draw the X, $25,000 for the expertise to know where to draw the X. I'll just give the punch line to it [inaudible]. 
[Laughter]
NOEL:  And that's a hard value to see. 
BRANDON:  So, it is more difficult to quantify. The quantification would have to happen from people who don't like quantifying things. And we feel pretty lucky to be doing software development for a living because this is a pretty fun job some days. Other days, not so much. 
[Laughter]
PETE:  As a junior webpack [inaudible].
BRANDON:  There are days where there may not be enough money to pay me to do some of that stuff. But we don't talk about money where in sales circles and marketing circles, money and currency is sort of like when I run a business, I talk to people like it's like being a doctor and not being afraid of blood. You can't be afraid about talking about money and run a business. Your business will die, just like you can't be afraid of blood. That's the stuff you've got to keep inside the body. It's just stuff. And money is a taboo topic, I think, for a lot of software developers. And I don't want to get into the social -- even though I have beliefs about this -- there are social justice aspects to this about whether who's engineering that or whatever, I don't think it's a grandeur experience. I just think it winds up being that we don't like talking about money and that winds up on the whole creating a logarithmic salary curve that levels off after a while where we don't, as an industry, know how to quantify additional value provided above a certain level. 
	And so you go, "Well, I know how to quantify value produced by somebody who manages a team of a hundred people," because that's an easy multiplier to make. If you can make a hundred software developers more effective, as a manager, I can quantify that and I can pay you no longer on a logarithmic scale where it levels off, but at least on a vernier scale. 
NOEL:  Yeah, that's the route. 
BRANDON:  Often as management, for other people they say they don't want to do that and they go start a business. 
NOEL:  It reminds me a little bit. I know people who are teachers. And one of the interesting things about being a teacher is if you are an ambitious teacher, you have a long-term career. If you're really ambitious and you want to the best teacher, there's a limit to your value until you stop being a teacher. There's a limit to your perceived value. It's a tricky thing. 
	I kind of see a lot of career delimits to that lengths. If you're a software developer, at some point because the value is hard to see, it becomes constraining over time. Being a software developer, of course, is being a manager or running a business or all of those other different things. 
BRANDON:  The good news is I don't have to fight this particular battle. I will leave this in the more capable hands of somebody like Patrick McKenzie, if you know @patio11 on Twitter. He's really into the hacker news community. I've had a couple of really nice conversations with him, and he's very sharp and he's very into helping developers realize the value that they provide and start thinking about pricing as if they were running their career like a business. 
	My only recommendation there is I think that people should listen carefully to what he has to say, he will point you to other resources. I don't need to fight that battle. That's not really the one that I'm after. I just want people to recognize this is a part of the problem where people are starting to bail out of the industry, and it is solvable. It's a solvable problem. If we are willing to start talking about money, the people that want to stay in this industry for 30 or 40 years will have the opportunity to do that. You can continue to increase the value that you provide. 
NOEL:  But there's another access to this which I was going to say fulfillment. What do think? You said there were two accesses to this. We talked about money. So, the other one isÉ?
BRANDON:  The other one I think is technological in nature and it's our approach to technology. And it's kind of the confluence of technology and product where we've gone into this 18-month cycle of like Silicon Valley startup 18-month cycle of, "Okay, your value is to help me get a product to market so I can start learning things as soon as possible. And then maybe we'll scale it if things go well." But you wind up torching a team every 18 months and you burn them right out. 
NOEL:  I'm actually staring at a book right now because I'm using it as a microphone stand which explicitly suggests that that's what a management team -- we'll talk about that a little bit later. But it explicitly suggests that that's how companies should align themselves. 
BRANDON:  If your goal is to make money with a company that you're starting, how am I to fault that? But one of the knock-on effects of that mentality is that every 18 months, we get to start a new code base from scratch. And there's very little value in maintaining something for multiple years. That's not our predominant Silicon Valley mentality that we own and maintain the things that we build. 
	And so, we've created a little bit of a cult of the new. I don't fault this, I like new stuff and I like working and I like learning. Whenever I've exhibited any kind of problem with this, you probably notice this Pete, where people are like, "What's your problem with learning?" So, I'll ask you this. Have you yet felt overwhelmed by the amount of stuff you have to learn?
PETE:  No. That's why I wanted to do this. 
BRANDON:  No, I'm interested and excited to hear this because I want to hear what your take is on this and Noel's take as well. 
NOEL:  I want to focus this on Pete a little more because Pete and I, I remember very clearly, having a discussion with Pete maybe about a year and a half ago where Pete was specifically trying to decide whether he wanted to learn Ruby in-depth or whether he wanted to branch out and learn a bunch of things like less in-depth. Am I correct there? Am I saying that correctly?
PETE:  Yeah. 
NOEL:  You want to talk about that dilemma or what you decided on that? How you came into that thought and where you decided to go from there?
PETE:  I think I kind of ended up doing both. But I don't remember deciding that. I suddenly can't hold myself. I'm the kind of person, I like to work and learning new things is entertaining for me. That's what I like to come home and do for several hours at the end of the day. So, I wasn't making a decision in those terms. 
	I'm kind of an idealist which makes the whole conversation that we were having before about thinking about my career in the business field really fun to me, and probably to a lot of developers, yeah. 
NOEL:  It does to a lot of developers. 
BRANDON:  That's a great point. 
NOEL:  I want to push back here a little bit because I'm kind of curious about this. So, you learned a bunch of things early on. When you learned a bunch of things on that boot camp and you came here for your first job, and you discovered probably not to your surprise that you still had a bunch of more things to learn. What was that? Was there a moment early on where you were like, "I had no idea what I was getting into. This is what I expected to get into." What did that feel like in the first couple of months?
PETE:  The first couple of months, I don't think they were so overwhelming because of the number of new things that I had to learn. I don't know. You get the impostor syndrome. Did I fool somebody into giving me this job? And it takes a little bit to feel okay about that and to figure out what your role is and what your style of working is. 
	There are a lot of other skills too that I feel like you have to learn starting off that are not just technical skills. 
NOEL:  So, like?
BRANDON:  I want to come back to that in a little bit. But before I jump into some of that stuff, I want to poke and prod at that little bit when you say other skills. What other skills and what is the purpose of learning them to your job?
PETE:  Learning, for instance, agile [inaudible] or whatever you want to call them because agile is a little bit of a [inaudible]. Thinking about, okay, I have this feature that I need to build and 123 go and then I'm like, "Wow, wait! I don't know how to build this thing." What do you about that? And how do you make incremental progress when you're doing something that's actually new to you. And how do you break things down into concepts that are manageable. Skills like that then it becomes possible to then do the development. 
NOEL:  And that's the kind of thing you're getting on boot camp because you're not normally working on projects that are large enough to have to break them down. 
PETE:  Right. And you also are only working on projects where you produced all of the code. 
NOEL:  And usually, you're on the requirements too. Chicago DBC is the biggest project you own your requirements.
PETE:  Right. You don't have a great concept of maintainable code either because you haven't run into a big code base that you have to maintain. 
BRANDON:  I want to say that I'm glad that you get to be idealistic about this. And I need to be careful when I position this stuff. 
NOEL:  Brandon already had the idealism [inaudible]. 
BRANDON:  I have. I was exactly where you are three years ago. And I want to caution you to protect that. 
PETE:  Yeah. [Chuckles]
NOEL:  I can confirm that because I knew Brandon and that was when I met Brandon. 
BRANDON:  That's true. Noel met me when I was still in the process of, I think, either trying to get my first job or I'd just gotten my first job as a developer. And so, you haven't yet encountered, in fact, I think you got to skip the first existential crisis. 
	Part of my talk is talking about these five existential crises and one of them is trying to break into the industry, which is unbelievably difficult. Most people struggle mightily with this. If this was not -- I don't know. It sounds like you and [inaudible] DBC got to kind of connect with Table XI pretty quickly. That's good. I'm glad to hear that. 
PETE:  Yeah, pretty quickly. But it always feels like a long time because I think for most people, jobs are just grueling. It feels like it's never going to end, it's never going to work out. But actually in retrospect, it worked out pretty quickly and smoothly. 
	You were saying in a blog post of yours, I think you said something about your first job or two are not going to be the things you like. They're not going to be the perfect fit for you. In my experience, I kind of have a charmed experience. I was really lucky I ended up with this job in this community of people that I actually do really like and suits my style and interests really well. So for me, I feel like the harder question is, "Well then, when is the time to move on?" If I'm actually really happy doing what I'm doing. 
BRANDON:  Okay. So, I want to come back to that. I want to hold on to that thought for a second. When is it time to move on because it's actually that is a subset of a larger question which is 'where am I going'. And you're not going to know that yet. 
	So, I want to put one last bow on the conversation about this sort of being a semi-pessimistic view because I don't believe it's pessimistic. But by default, I am an optimist. I'm very optimistic about stuff but I think I have talked to too many people that started off where you are and then 14 or 15 years from now are like, "What now? Because my salary has leveled off, my opportunities actually seemed narrower." And the thing that kills developers that are 10 years ahead of you is this thing where you're like 'I love learning new things', you actually aren't learning new things. You are learning the same thing in new languages and frameworks over and over again. And that becomes very frustrating where you see you're trying to get a community of people in this sort of 'cult of the new' to adopt things that you knew. 
	Let's say you were in Smalltalk and you're trying to get Java people to adopt TDD. And then you go, "Okay, I move to Ruby. I'm going to try to get Ruby people to adopt TDD. I'm going to move on to Node and get Node people to adopt TDD." 
NOEL:  Stop there. Don't do that. [Laughs]
BRANDON:  So, I work in Node everyday now too. 
	So, there comes a place where you start feeling like I am now, instead of learning new things, I am learning the same thing in new ways. I've talked to at least a dozen developers at 15, 20, 25 years of experience who are burning out on the technical aspect of the 'learning new things doesn't feel new anymore'. 
NOEL:  I can talk to that a little bit, actually. My career set up is a little bit weird. I came out of grad school and threw somewhat bizarre set of circumstances basically walked into a senior level position right out of grad school because it was 2000 and it was a web boom and the company was run by lovely people who had no idea how software was built. To prove that they had no idea how software was built, they hired somebody out of grad school and thought that that would give them credibility as a software shop. 
	It worked out great for all of us, at least for a couple of years until I learned enough to understand that they really didn't know what they were doing. And I spent kind of a long time not being able to get back to do the level of job that I had already held because of the amount of experience that I kind of had on paper which was weird. 
	But I have been in the last several years, I really did use to change, learn new programming languages very often professionally because I was using new languages professionally every year or every couple of years for most of my career and I haven't really done that in a while. It's fair to say that I stagnated technically or whether it's fair to be -- I think it's more accurate to say that I've kind of pushed that impulse into other things. I tried to get better at architecture or dealing with legacy systems or things like that but I don't feel like I'm learning a new language or learning a new technique or getting better at running a software team.
BRANDON:  Didn't you do HR for a while?
NOEL:  Yeah, I did HR for a while and that didn't work out as well. But I do sometimes feel weird. It does sometimes feel weird to me that I've gone a very long time without becoming professionally proficient in a new language, and that feels kind of strange to me. 
BRANDON:  I think that actually is probably the optimal case. I think what you're describing to me is a healthy career, from everything I can tell. Because what I see from people that I see that are frustrated is often they feel that it's incumbent upon them to pick up the new thing. And that the people who have been doing this for one to two years who haven't burned out on that yet are the people that are actually more advantageously positioned. 
NOEL:  I also haven't looked for a job in a while. Let's see what happens if I ever wind up having to do that. The last time I looked for a job which was 4 years ago now, I was getting into this situation where I was too expensive for some places to hire. Otherwise, they would have been interested because they know which is another way, I think, that money filters people out of the top end. And it felt so [inaudible] a little bit too. 
BRANDON:  Anyway, Pete, this is not by way of beating the optimism out of you. I'm saying there's some arming that people need to do. They need to arm themselves against this eventuality that this merry go round is really fun and grab it and ride it for all that it will take you, but recognize at some point, and the things that you will learn in the first five to 10 years of your career -- and this is actually what Allen said -- the first 15 years of his career was learning how to program. And so, enjoy that. That's a really enjoyable ride. 
	I think what happens is a lot of people hit that point where they go, "Okay, I've learned how to program, now what?" And what happens with companies is they go, "I don't really know what to do with you other than to put you in the same room with the other programmers and pay you about what you were making five years ago, because I don't know how to quantify that." 
	And so, I want people to arm themselves financially to have that conversation. But more importantly, I think I want people to arm themselves with the knowledge of where they want to go. 
	And so the other thing Allen told me that was kind of transformative to me that this -- not even a metaphor, it's literal -- they would be handed this big broad sheet when they showed up at this big companies 30 or 40 years ago and it would say 'your career at XYZ Corp'. And it has this career track list of 'here is what the software development track is' or 'the software engineering track at XYZ Corp'. 
NOEL:  I worked at Motorola about 10 years ago and they had something very similar.
BRANDON:  Some people will define that very clearly. Here are the requirements. Here they are categorized in rows and then leveled in columns, and as you traverse these levels. 
PETE:  I'm just curious. In your example, what does that career path look like? If you're a developer, you get paid X. You're still a developer, you get paid more. Later, you're a manager. 
NOEL:  The Motorola version was something like there's something like 12 grades on employees or something like that. And what it was was in order to move from grade 5 to grade 6, you have to have [inaudible] and whatever, a recommendation from a manager. Once you get in there, you're eligible for this salary range and whatever. 
	I will say that every small company that I've seen that have tried to do that and almost every small company I've seen has tried to put something like that together, it always turned out to be a colossal waste of time. 
BRANDON:  I just pasted something in the chat that you can put in the show notes. But it's basically what Allen pointed me to. And it's an example of something and I've seen the actual paper work. 
	I did a fair bit of research for the talk and I got to talk to people from a lot of different companies. And the ones that don't explicitly reject the idea of leveling like Netflix where you just show up and you get paid well and you do your work and that's the end of it. The companies that have leveling to it all kind of do it similarly. It looks like this grid that you can see in the notes is so specific in terms of like 'here are the levels and this is what we expect to be at those levels'. But then you actually read them and they read like works under general supervision, follows established procedures, work is reviewed for soundness of technical judgment, overall adequacy and accuracy. 
	It's a pretty rough definition that leaves still a big air gap between somebody's opinion and what you actually level somebody up as. But at least it's the beginnings of a guide to say, "Hey, this is something that you could work on and if you got better at this, you're likely to qualify as a next level of developer." 
	And so, I'm not saying that these things are great. I'm saying they used to get people a sense of context as to where they are on their road map as a developer and they could kind of measure themselves against something. What I'm hoping people will do and if I've had like one big next community project, that would be creating a toolkit for people to develop this for themselves to say, "Hey, here are the broad categories." And this is why when you look back at my post about 12 traits of the developer, those 12 traits are the things that certainly running a consultancy wound up being the things that matter the most. And I would like to see a broader definition like when you said breaking problems down into smaller chunks, that's a critical piece of the puzzle that I don't think was represented well in those 12 traits. 
	So, seeing something that is more generally applicable, that people can create a toolkit and say, "Here is what I want to pursue, at least right now in my career, here's what I want to get better at." And this is approximately -- so you asked the question earlier, how do I know when it's time to bounce out? You can actually sit down with Noel and have this negotiation and say, "Here's where I want to go. Where does the road run out here?" And he may say, "I honestly can tell you we can get you here, and that could take you 10 years. You could actually have a really amazing 10 year plus career here or you can be here for the rest of your life. We have a road that leads all way there." 
	Or it might be like we had at Frontside where I knew where somebody was going and I knew that the road ended for them 18 months from now. Like, "Hey, you've got about an 18-month clock here." 
NOEL:  We've had those conversations with people, not so much the development but we've had those kinds of conversations here where it's like, "Yes, the thing you're growing into is not something that we have a role for. Let's see if we can help you with what the next piece of that will be." It's bittersweet at best.
BRANDON:  But it's better than having people there that are quietly frustrated and not able to put a voice to that frustration. 
NOEL:  Quietly frustrated. I'd rather have loudly frustrated than quietly frustrated, honestly. 
BRANDON:  Yes, absolutely! I mean, you all are really good at handling one-on-ones and keeping communication going and in setting this kind of goals. I think the company that you work with is sort of unique in this. Most companies don't put this much thought into this process or to put those definitions around it for people or defining those goals.
	Pete, I have to imagine, you don't get no unless you are the person with two years of experience that has the most amazing ability to see the future. Is it safe to say you don't really know where this will all take you yet, or do you have a sense of what that is? 
PETE:  No, not at all. 
BRANDON:  In your first couple of years, when people were like, "Where do you see yourself five years from now," that question is stupid. But when you get to Noel's stage, that question becomes relevant because you're starting to thinking in terms of how much career you have left. 
[Laughter]
PETE:  That's a really tragic phrase, Brandon. 
NOEL:  I still hate that question, honestly. I have no idea where I'm going to be in five years. But I probably would be better off if I had a good idea. But everything great that's happened in my career has happened by surprise and accident. 
BRANDON:  It's serendipity in large part.
NOEL:  And there's a certain amount of design serendipity. You put yourself in the situation to hope that something good happens and eventually something might. 
BRANDON:  Yeah. 
NOEL:  What would be something like relatively kind of create that you would suggest that Pete or anybody who might hear this who's in like their first few years in programming? What kinds of things should they be trying to do?
BRANDON:  When I wrote down the 12 traits, these were like 12 relatively concrete things and I don't want to go over all of them. 
NOEL:  It will be in the show notes. 
BRANDON:  Yeah. I will just say the ones that get neglected the most are the ways that you can have an outsized impact on your organization. I think what most people think about when they think about the traits of what qualifies somebody as a senior developer, they think in terms of technical capability. And that is great, like staying curious, adopting new technologies and not being afraid to explore new things, not being afraid to tackle really hard problems and break them down, the ability to actually execute and get something shipped. All of those things are great.
	They're also the same field that everybody is competing in. If you're trying to kind of stand out and move forward in your career in a field that people are all kind of focused on the same thing, you can pick a different area and focus.
	My experience is that people that round themselves out with skills that don't appear to be directly technical are ones that can produce value that you can start quantifying pretty quickly. Where people are really good at documentation, and if people put extra focus on, -- "Hey, I'm going to focus on documentation." 
	The person on my team at Frontside, Alex, put a ton of focus this year into improving the quality of pull requests for our team. He's starting to go around and evangelizing this idea of 'here's what a quality pull request looks like'. That is a platform he can actually use to help improve teams across the industry. And he's a really technical person. He's brilliant technically, but some of the biggest impacts he's had on our team is getting us to think more critically about the way that we share code and ask for feedback with each other. 
NOEL:  That's kind of like same as the way to become a 10x engineer is to make five other people 2x engineers. 
BRANDON:  Yeah. It's the only formula I can -- there are people that can code 10 times as fast as other people. But that's like saying there are people that could run at Olympic levels. I will never be the Usain Bolt of code. I have to be like --
PETE:  I'm going back and have your career introduction to say, "We have on the panel Brandon Hays, the Usain Bolt of Code.
BRANDON:  That's not going to be me, unless I start doping somehow. I don't know what that would be. Just too much caffeine and then I have to [inaudible].
PETE:  Programmers dope with caffeine, right?
BRANDON:  I just get shaky at a certain point. I would say it depends on things you kind of lean toward already like the things that you find fascinating in addition to the technical aspects of things. And this stuff will emerge naturally. The first five to 10 years of your career, if you just focus on the technical aspects of things and that's what fascinates you, far be it for me to take that away. But you can add additional value if you're thinking in terms of other things that fascinate you. If things around owning larger and larger chunks of a piece of a product like, "Hey, I'd actually like to work more directly with the product owner here and the designers, and start owning larger and larger chunks of product work and see if I can deliver and kind of take the lead on something." And if that tickles your fancy, maybe that you lean towards the leadership track and you have leadership things that can enhance you as a developer. Maybe some people really just don't like that kind of stuff but they do like collaborating with other people and they wind up acting in a team lead capacity where they want to take a crack at getting a team to pull together toward a common goal or just being a good listener.
	There are lots of different things that people can work on. I tried to break them into 12 traits but those are just the 12 that seem to matter to me as the owner of a consultancy the most. I think each business should look at the things that matter to them and sit down and talk with people that are at the newer end of the spectrum and try to come up with what they could develop that would make them more uniquely valuable, not just within that organization but beyond that. So, I have 12 starter ideas. I would love to see more get thrown into the mix. 
NOEL:  And that seems like we're kind of at our time more or less here. And I wanted to see people leave with another resource for people to check out or concrete suggestions that people can take away and apply the stuff. Brandon, do you have a resource or any concrete suggestion?
BRANDON:  I would say that it's sad this is the best I can do. But I would say that there is a really great couple of blog posts out there about this that's pretty well known about what constitutes a senior developer. It's a different take than mine but it's just as valid, if not more so. It's really good. 
	I would say the other thing is to please befriend, find and befriend a software developer with 20 to 25 or more years of experience. Do whatever you can to reach out to somebody with that level of experience because after I had worked in this industry for six or seven years, I had a completely perspective altering conversation over the course of a 45-minute conversation with somebody with 45 years of experience. If you can have that one meaningful conversation with somebody with that much more experience than you, I feel like you're going to have lots of access to people within your zone of proximal development. That's great. But finding somebody that's wildly more experienced that you is more rare and more difficult and it's worth seeking out. 
NOEL:  Pete, do you have some place to point somebody or something that you would recommend that people do? Something that you did that you found really helpful?
PETE:  I feel like that's a really hard question. 
NOEL:  This is like my standard set up for the end of this thing and I did have a really hard time coming up with -- I think that's almost a symptom of a problem is that we're all having a really hard time coming up with places for people to look. 
PETE:  Right, because like I was saying. I feel like so far, what I've done is keep following my interest and things that I'm attracted to. And up until this point, that's worked out really well for me. So, I don't think it's quite good advice to say, "Yeah, I do that and keep feeling like that's going to turn out really well." But that's all I got. 
NOEL:  Okay. Well, thank you guys for being on the show. The Tech Done Right podcast is brought to you by Table XI, a UX design and software development company in Chicago. We are 35 meticulous and curious minds with a 15 year history of building websites, mobile applications, and custom digital experiences for everyone from startups to storied brands. Let's work together. Find us at TableXI.com where you can learn more about working with us or working for us. 
	Thanks to Pete and Brandon for talking with me today. And we will be back in a couple of weeks with another episode of the Tech Done Right podcast. Thanks.
PETE:  Thanks, Noel. 
BRANDON:  Bye! Thank you.