NOEL: Hello and welcome to Episode 51 of the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. 

On this episode, we're talking about being a senior engineer. When you first become a senior engineer, you suddenly have new job responsibilities that aren't coding and they aren't management. It's not clear how to balance your time or evaluate your success. Our guest this week is Jamey Hampton, a panelist on the Greater Than Code podcast and a Senior Engineer at Agrilyst. We talk about how to handle the changing responsibilities and perspective that comes from being promoted even when you're still the same person that you were the previous week. We also talk specifically about hiring as a non-coding responsibility. Was there something in your career that came with new responsibilities that you didn't feel prepared for? Let us know at TechDoneRight.io/51 or on Twitter @tech_done_right. 

Before we start the show, I have one message. Table XI is now offering training for developer and product teams. If you want me to come to your place of business and run a workshop on testing or Legacy code, or Rails in JavaScript, or Agile teams, that is a thing that can happen. Also, if you are in the Chicago area, be on the lookout for monthly public workshops that should be starting in January 2019. For more information, email us at Workshops@TableXI.com or hit the website at http://TableXI.com/Workshops.

And now, here's my conversation with Jamey. Jamey, would you like to introduce yourself?

JAMEY: Hi. I'm really happy to be on the show. I am a Senior Software Engineer at Agrilyst. Agrilyst is an indoor agriculture industry tech startup in Brooklyn that I work for. I'm a panelist on Greater Than Code. I don't know, I do a lot of things.

NOEL: I guess what we are here to talk about is that you do a lot of things.

JAMEY: True.

NOEL: Because what we want to talk about is the new responsibilities that you've taken on as a senior developer that are not actually coding but also not what we would normally think of as a management role. So, would you like to start by elaborating on that just a little bit?

JAMEY: That is exactly what I want to talk about and I think that it's a struggle that I wasn't necessarily...not that I wasn't ready for it but that I wasn't expecting. When I got promoted to senior developer, I was really excited. But I guess I didn't realize how different my job would end up being over time from before. And so, one of the big things is just like the kind of architectural and code responsibility that you have. Like now when I'm working on projects, I feel like so much of the work is theoretical and I'll have whole days when all I'm doing is like thinking about our code base. And going from writing code to thinking about code, not that I didn't think about my code before. But thinking so actively about it so much of the time makes me feel very unproductive because I feel like writing code and how much code did I write, how many lines of code did I commit today, how green is my little box on GitHub today, was such a benchmark of my productivity for so long that now I feel like I'm not doing anything ever. I'm very busy but I feel like I'm not doing anything, and it's hard.

NOEL: Let me ask a couple questions to put a little bit of background on this, because I think that there's some difference in this kind of thing depending on your organization. How many developers are on your team at Agrilyst?

JAMEY: We are small. We have five developers right now.

NOEL: On paper, what kind of new responsibilities came with being a senior developer?

JAMEY: That's kind of a deceptive question in some ways because when I first got promoted, we were even smaller. And so, I don't think this is a good or bad thing necessarily either way. I think it's just how it is. But I think in other and bigger organizations, there's more of a laid-out, like this is what a junior developer does and this is what a mid-level developer does, and this is what a senior does, and it's kind of there are categories more in that way. And as we're growing, we're trying to move towards that. But when I actually first got promoted to senior, I was the only developer briefly.

NOEL: Well then, senior, junior like, are you not the only senior?

JAMEY: I'm not the only senior now. But I was the only person writing code at all at that point. So I felt kind of like people were like, "Oh, you got promoted to senior. And in fact, you got promoted to senior pretty young. Congratulations." And I was like, "Thanks." I mean, I feel like I won the Hunger Games because I'm the only one left right now.

And so, my responsibilities didn't actually change at all at that point. It was like, "You're going to be the only developer for a few months and then we're going to hire some more people. We understand that that's a hard position for someone to be in and we understand that you're taking on responsibility because of that, so we're going to promote you." But a lot of the responsibilities that you see a senior developer taking on, like overseeing projects and mentoring and stuff, didn't happen to me until later because there was none of that stuff to even do at first.

NOEL: I think that there's a whole separate issue about suddenly finding yourself...I guess you became the only developer because other people left.

JAMEY: Yeah. We had been down to two just because we were very small. We are an early stage startup. We still are. And then my boss left for another opportunity and obviously, they're like, "We're going to hire to replace him as soon as possible. But it takes time."

NOEL: Right. There's a whole separate thing about being the people left behind after other people leave, which can be challenging all by itself. I was once in a sort of an early stage startup that went from a team of like 25 developers with 60 people overall at one point. And eventually, it was eight. It was not a healthy early stage startup. And that has all sorts of other, in addition to just having to pick up roles. It's just weird psychologically.

JAMEY: It is weird. And now, we have been doing really well and we've been hiring a lot again. We have a lot of new people and we have this whole new team that's great. But it's very weird being the only person that overlapped from kind of like the old team.

NOEL: Yeah, you could say anything really.

JAMEY: I could.

NOEL: Yeah. "This is how we used to do it."

JAMEY: I should start making stuff up, that's a great idea. But also there are people...we've hired people more senior than me from a job title, like experience in the industry kind of perspective. But there is no one at our company more senior than me from a 'I've been here a long time and I understand this code base better than anyone else' perspective which is also a weird position to be in.

NOEL: Yeah, I can see that. There's a couple of things here. One of which is like being in an organization that is small enough that you kind of have to be the 'whoever's closest with the broom picks up the broom to sweep the floor' kind of organization. So what kinds of things...let me go back and talk about what you were saying about your productivity because I suspect that this is something that a lot of people kind of deal with as they move up into being senior. The idea that it's harder to evaluate your productivity because you don't have that code metric, you're not writing code, and so you're not doing the thing that can be easily evaluated. Were you expecting that and how have you adjusted to it over the time that you've been a senior developer?

JAMEY: I guess I just didn't think about it. I agree with you that I think this is something that affects a lot of people. I think that as developers, we have a lot of baggage in general about how much code do you write. And I see that at all levels all the time with a lot of people, like there's this real push. I was joking about how green is your little box but was I really joking? Because people really post screenshots of their little boxes on Twitter and brag about it, like people care about that kind of thing.

NOEL: Well that being like a really common anti-pattern doesn't...

JAMEY: Yeah, exactly. Logically I can say I know this doesn't matter. I know how many followers on...like how many followers do you have on Twitter? It doesn't matter but kind of matters because I've been told that it matters. Even though logically I can say that it doesn't, I still emotionally feel that way about it a little bit.

NOEL: What have you sort of done to help to manage the feeling?

JAYME: I'm still struggling with it. We were talking before the show about like, "How am I going to tell people the answer when I don't know? It's still hard." But I think I'm very communicative with my co-workers, kind of not just about what I'm doing but about how I'm feeling about it which I think depends on your organization, like how much people are open to talking about their feelings or whatever. But I really like talking about my feelings because I think that your feelings about what you're working on really affects how you're doing with that essentially. I think it's hard to separate if I am feeling negative about this project because of XYZ or anything that's affecting my work and my productivity on the project. And so, it's been really helpful to be able to say, "Hey, I've been working on this stuff. I feel like I haven't gotten a lot done. But here is what I have been getting done," and being able to kind of have a conversation with my co-workers and my friends and say, "Well, what you've been thinking about here is really important. And I think it's going to help with the project." I'm still fairly new at this so I'm still kind of like building up this backlog of successes in my mind, I guess, but I do think about that a lot. When I was writing more code, one of the things that I thought about a lot was if I started working on a piece of code and I didn't know how to do it, I would get very overwhelmed and I would try to remember back, last time you tried to work on something and you felt overwhelmed because you didn't know how to do it and you felt like it was impossible. Was it really impossible or did you figure it out? And 99% of the time, I figured it out and it was fine. So maybe this time, I'll also be fine. And so, I'm kind of trying to work on putting together a backlog of successes in that same way like, last time you spent several days just thinking about how this architecture might work and you felt like you were wasting time. Was that actually helpful when it came time to work on the project with everyone else and was everyone really relieved that you had done that? Yes. Maybe it's going to be the same this time.

NOEL: I think one of the things that happens is that you start having to see your victories at sort of a more abstract level.

JAMEY: Yeah.

NOEL: And this is a little bit sort of the pyramid of moving toward senior developer. As a junior developer, you're very focused on the individual feature and you're very much writing code. But as you become more senior, you get more and more responsibility over the project as a whole.

JAMEY: Right.

NOEL: The smooth running or turbulence in the project as a whole becomes your responsibility, so you have to sort of take...it's weird because you sort of have to take pride in things that don't happen.

JAMEY: I never thought about it like that.

NOEL: And it is very hard to see like, "Oh, we picked a JavaScript framework and we did not spend two weeks arguing with it because we made the wrong choice." Things just went smoothly. And my experience is that a lot of that kind of intervention, you have to sort of take pride in the lack of crisis, if that makes sense.

JAMEY: That totally makes sense. 

NOEL: And it's kind of hard to see, to think about in the way that really good management is hard to tell. It is hard to get a sense of how good a good manager is until you have a bad manager. You sort of have to take pride in things that didn't happen and things that happen, things that were boring because they went so smoothly. I don't know if that makes sense.

JAMEY: I think that does make total sense to me. I think that when I was earlier in my career and I was writing code, it's not necessarily that the code itself was much less complex. But I felt like oftentimes, I'd be like, "Okay, I'm going to do this task and I understand what's happening in this individual small task. Therefore, I can work in this little piece of the code." And now I feel like increasingly when I'm working on a piece of the code, it's like I have to keep track of all these thoughts because I need to have a more comprehensive understanding of how it fits in with everything else.

NOEL: You don't have a backstop. As a senior person if you don't keep that in your head, nobody is going to.

JAMEY: Right. I've been working on...this is something that had been happening at work recently. I had been writing some code for a project that I wasn't actually leading on but I was still kind of helping a lot with the architecture and the thought with it. I wrote some code and then I realized, "I don't understand why I'm writing this. I don't understand what this is being used for." And I'm at a point where I can't write something without understanding what it's going to be used for because I'm rightfully expected to be able to think for myself and not necessarily code exactly what it says on the task card, in Pivotal. They're expecting me to give them code that makes sense and works with our feature. And I can't do that if I don't understand why it's happening.

NOEL: Right. You have to understand the project goals in a different way.

JAMEY: Yeah, exactly. And so, I was feeling very overwhelmed because I'm like, "I don't think my code is good. I don't think it's going to be usable in the way that it needs to be usable. And I don't know how to make it that way because I don't understand the use case, why we're changing the architecture in this way essentially." What I did was I got on a call with the other people who were working on the project. It was like, "Listen, I don't have a thorough enough understanding of what we're doing and why, and I cannot continue until someone goes through it with me, until I understand it. We can't stop having this conversation until I'm on the right page." And that's a hard thing to do because I felt like why am I wasting everyone's time on this project by not understanding it but it's like a sunk cost fallacy thing. If you can't admit that you're not on the right page then you're never going to be able to get there. 

NOEL: And as a senior person, you're admitting that you're not on the right page makes it easier for the other people to admit it.

JAMEY: That's a good point.

NOEL: That they are not on the right page which is a very good thing.

JAMEY: Essentially what I think about a lot is the day I got "promoted" or whatever. I didn't become smarter on that day. I didn't become better at what I did on that day. If I had questions when I was a mid-level engineer and now I'm still going to have the same questions and I didn't automatically learn all that stuff I didn't know. Nobody knows everything. But there's baggage about feeling like I should know it now, I think, that I have.

NOEL: I can see that. That makes sense. You don't change but suddenly, you're in a different context and you have different problems.

JAMEY: There's like an impostor syndrome around it. 

NOEL: And I think that no matter how you came into the field, whether you came in from a computer science program or you were self-taught or whether you came in from a boot camp, that training involves coding. 

JAMEY: True.

NOEL: And you don't really get trained to be a team lead in any meaningful way. Even if you continue in a CS Degree and start taking more advanced, even software engineering classes, those are, trust me, like super academic and not very applicable to the kinds of things that you would do in a real world project. I had a weird career where my first job out of grad school, I really was hired to be a senior engineer even though I was coming right out of grad school.

JAMEY: Interesting.

NOEL: And immediately wound up in all of these kind of project level things that I had no real compass or bearing on how to do and made a lot of mistakes. It was a weird project. There were mistakes to go around.

JAMEY: That sounds really hard.

NOEL: It was. I didn't have anything to compare it to, I don't think.

JAMEY: That was what I was going to say. It sounds really hard because I mean, I haven't necessarily been trained in a meaningful way in a lot of the stuff that I'm doing now either but I have watched other people do it above me in my career. And so, if anything to fall back on, it's like, "Okay, I had a manager that did things this way and I thought it was good." So I can emulate them in that way.

NOEL: It's going to sound really obvious when I say it or it's going to sound really dumb, but I was not prepared for client meetings. I came into a consulting shop or in your case, like product meetings. 

JAMEY: I worked in a consulting shop before I worked at Agrilyst and client meetings were very hard. I agree.

NOEL: And I was not prepared. I was not prepared in two ways, I think, looking back on it. I was not prepared, number one, in the sense that I had no idea what I was trying to get out of these meetings and what information that I could seek out or ask for that was going to be valuable or less valuable. And I also had no...like suddenly, people are asking me questions about whether things are feasible or how long they are going to take or what the best way to do something is. And I just had no frame of reference that was meaningful, and that was challenging. It also took me a while to control a little bit of a temper in client meetings.

JAMEY: I completely have the same problem. And I'm pretty sure that that's just something that I'm not very good at. People are so uncomfortable when you say that you're not good at something. They want to be like, "No, I'm sure you're fine with it." And I'm like, "No, I'm admitting that I'm not so good at this. Please just accept that I know this about myself."

NOEL: It was really weird for me looking back on it because I don't normally think of myself as a person with a temper exactly. But there were particular ways that I got challenged in client meetings early on, especially early on, that I was not prepared for at all. And to have clients like challenge my expertise in ways that I was not... I guess, I'd still get annoyed by it but I'd kind of laugh it off now, I think.

JAMEY: Talking to non-technical clients is just wild in my experience because I find that when I was doing client work, it was frustrating but also I agree, it was so absurd sometimes that it made me feel like, "Okay. Well now, I just have to laugh about this." Because clients will ask for crazy stuff that's literally impossible and be like, "Can you just do this real fast?" And I'm like, "Oh my God, you have no idea what you're asking for." But then they'll ask for something really trivial and be like, "Do you think it's possible." And I'm like, "Sure, I did it in five seconds." They're like, "Oh, it's magic. I can't believe it." And it's just so interesting. If you're not technical, of course you don't know the difference between something that's really trivial and something that's really hard but that was always really pointed to me when that happens. 

NOEL: And it's definitely one of the skills of client work to be able to articulate when something is complicated and when something is easy. I once snapped at a client that it was easy for them to make that request because they weren't the ones that were going to be up at midnight doing it. And they made me apologize for that one.

JAMEY: Another thing I just was thinking about when I was talking about admitting when you're not good at something, I think that a real talent of managing a team that I've watched my manager do, is having people do what they're good at which also sounds really obvious and dumb. But I don't do client work now. We do have customers and only occasionally to someone from the product, from our product team have to talk directly to customers or at least an engineer from our product team has to talk directly to our customers. And I was in a situation recently where a customer really wanted to talk to me and I was super stressed out about it. And I was like, "I guess I'll talk to them," because it's part of my job and I should suck it up. But I obviously didn't want to do it and I was stressed out about it. And then my boss had someone else do it. And I felt baggage about that. I felt like I whined so hard about one part of my job that it was 'take it away from me because I can't be trusted to not whine about it', and I felt bad. And I expressed this to my boss. And he was like, "No, I just think that someone else would be better at it than you, not in a mean way. But you have admitted that you're not very good at this. This kind of like talking professionally to clients, you don't like doing it. You were stressed out about it. You were having anxiety. You were miserable about it. Someone else could just do it and do a better job and not be stressed out about it, so why wouldn't I just have him do it instead?" And that was really kind of eye opening for me because of course, he's totally right. Why should I be the one to do something I'm bad at that I don't want to do and someone else can just do it? 

NOEL: Where it gets tricky, I think, is when you want people to get better at the thing. We want people to grow. You want people to take on things. But it is tricky because there's going to be a point where they're not going to be good at it or they're going to be uncomfortable with it. And putting people in a situation where they can be sort of incrementally successful at a new thing is very challenging.

JAMEY: We moved everybody's responsibilities around recently and it's just better. We just matched better, people with things that they enjoy and are good at. I used to do deploy. I was in charge of the deploy process for a long time. And then that got taken away from me and actually it got given to someone that I was mentoring. So I was really torn because I'm really happy and proud of my mentee for taking on this new responsibility. But then part of me was also like, "Was I doing a bad job at it?" When you get a responsibility taken away from you, it's like a little bit anxiety inducing. But then I got put on hiring and I've been really enjoying doing hiring. And the person who used to do hiring has expressed to me, "I am so glad that I don't have to deal with that anymore." And that was also kind of eye opening. It made me realize there's a real skill to giving people responsibilities that they're well-suited for.

NOEL: And excited about. I think it makes a big deal when people are excited to do the things that you are asking them to do. 

JAMEY: Definitely.

NOEL: Okay. So, tell me about hiring. I've also spent some time running hiring. What were you expecting it to be like and then what did it turn out to be?

JAMEY: I guess I didn't know what I was expecting it to be like at all but I really enjoy doing it. And the reason that I enjoy doing it is because I really like being the first person from my company that somebody talks to.

NOEL: I completely get that. That was easily my favorite part about running hiring. 

JAMEY: I get very anxious about a lot of things. I'm just like a very anxious person and interviewing is hugely anxiety-inducing from when you are looking for a job. I'm aware of this. And so, it's been kind of cool to be in this position where I'm like, "Hey, don't worry. It's pretty casual. I'm just casual about it. We can both be casual about it. I'm nervous too," because giving interviews is not my favorite part of hiring but I've been getting a lot better at it. At first, I was like, "They're going to know that I'm nervous. Okay, does it matter if they know that I'm nervous?" But I actually found that when the person I'm interviewing realizes that I'm a little bit nervous, it's calming for them.

NOEL: I think it was very important and satisfying for me to be able to have people we were interviewing come through and have them genuinely believe that they were the most important person in our office for the day. And to try and make this really stressful process less stressful. Like, "Can I get you coffee? Can I get you water? Can I bus your lunch dishes? Anything I can do to make this easier for you, I'm going to do," because that's the environment we want to have. One thing I did find about it though is that it's really time consuming. I don't know if that's also your experience.

JAMEY: Yes. Getting back to kind of what I was saying about feeling unproductive. When I first started doing hiring, I felt like I was taking so long and it felt like I was wasting time. I felt like I would go into resumes and then look at them and be doing stuff. And then an hour later, I would look at the clock, it's been an hour. And I'm like, "What did I just do for an hour?" 

NOEL: Yeah. Evaluating resumes, writing responses to people, all of that kind of administrative stuff, if you wind up being the person doing it, it is very hard to meaningfully automate.

JAMEY: Yeah.

NOEL: And therefore, it's very time consuming.

JAMEY: I was worried that people would be like, "What is Jamey even doing today?" And again, I guess this is the kind of thing that I feel like if you just let it fester in you, it will rot and you'll just have this -- maybe it's just me -- but this crazy anxiety about it. I'm sure it's not just me. Actually, I take that back. And so I was like, "Look, I'm trying to do hiring. It's taking all this time and I still feel like I'm falling behind on it." And it feels like a waste of time. Other people at my company were like, "Oh my God, please don't think you're wasting time by doing this very important thing." And hearing someone else say that, I think, is really important. It sounds silly but I also work remote, and so all of our hiring is also remote. And I've worked remote for a long time and I'm very comfortable with it but I do feel like there's this fear that if people aren't looking at me, they think I'm slacking off even if I'm not. And I'm sure nobody feels that way about me but I still have that fear. And so I was having that fear about hiring. I would fall into resumés for a while and then no one would hear from me and be like, "What's Jamey doing?" But I don't think that's true. And I think the only way to internalize that that's not true is to have people tell me it's not.

NOEL: I don't normally work remote but I do definitely appreciate the idea of: will people see this as a valuable time? Am I spending the right amount of time on this? Am I spending too much time on each résumé? Am I spending not enough time on each resume? I don't know. This is turning into more of a hiring thing. But you look at a resume, at least from us, we would get patterns of unsuitable resumes. It was just clear that somebody had gone into Glassdoor or something and was like hitting all of the five star companies in Chicago, whatever they did. So we would get resumes from people who wanted to do Enterprise Java stuff. We don't do that at all.

JAMEY: Right.

NOEL: But then you kind of feel bad for rejecting a résumé out of hand even though it's completely unsuitable. At least in my case, one of the tricky parts about hiring was dealing with the fact that you had to, for the good of the organization, not be a soft touch about letting people through the process.

JAMEY: That's totally true. And I think that it's like an uncomfortable power differential to be like, "I have power over someone else's life and career." And that feels like a lot of responsibility.

NOEL: Yes. Generally, it took a while to be comfortable with it if I ever got really comfortable with it. And my tendency, especially when I first started doing resumé stuff, was like I am going to err on the side of bringing people in. We do a terrible job of evaluating resumes. You can't really evaluate people from resumes.

JAMEY: Right.

NOEL: And the first part of our process is just like having somebody do a quick phone screen or come in for lunch, like it's very low impact. So I would be a very soft touch for that and in a reasonably soft touch for the next part which would be like a code sample. But eventually, other people have to evaluate the code samples or other people have to start doing these lunch meetings. And if I started having too many of them that people were questioning, and people would come back to me and be like, "You have to stop pushing this many people through the process. We just don't have the bandwidth to deal with it." And at one point, I had enough people come to...Right when I first started taking over hiring, we were hiring for an entry level position and I had enough people go through full day interviews, that I'd pushed through the process to a full day interview that I started to get almost open rebellion about how much time people were spending doing interviews.

JAMEY: That makes sense. An entry level position, I think, is even harder from that perspective because there's so many people that could probably be good at it but it's hard to look at someone who is brand-new to the industry's resumé and know what kind of experience they have or what it's going to be like to work with them or what their code is going to be like. It's definitely hard. And I found out like we were saying earlier about training, I took over hiring like I've never had any training in how to do hiring. I think that I'm pretty good at it and I think that part of the reason I'm pretty good at it is that I just like people. I'm an extroverted person and I like chatting with people. And we do pairing interviews which are really fun actually. I really like doing them particularly with kind of more junior people. We've been using the terms junior and mid-level and senior a lot in this. I don't know. Those terms are so, like loaded and hard. I'm using them because people use them when there's some sort of meaning attached to them. But I feel like I can't keep using them without making some sort of comment about what does junior versus mid-level even mean.

NOEL: We stopped using junior internally.

JAMEY: That's good, I think.

NOEL: The levels here are associate consultant, consultant, and senior consultant which I don't know whether that's better or not, but that's what we do.

JAMEY: But anyway, what I was saying is like I didn't have any training at doing hiring. And when I first started doing it, we have a process that we kind of came up with together and I actually feel pretty confident with our process. I've gotten some good feedback from people I've interviewed about it which feels like job satisfaction central or whatever. But one thing that had been happening at first was that we made it all the way through the process of people and made them an offer and then they turned down an offer which is something that happens because not everybody takes every job offer they get. I know this logically. It happened enough times in a row that I was feeling like, "What am I doing wrong that we are unable to hire anyone under my supervision?" And I think that partially, it was me projecting things that I can't control about people's decisions on to myself as like a personal failure. And I think that it was partially the timing thing. When I was struggling with the process, when I still first learning it and it wasn't efficient, it takes someone so long to go through the process, maybe they're losing interest or maybe they're having second thoughts about our process at our company or maybe they found another opportunity. And by the time we got finished with the process, they've already taken another offer, et cetera, et cetera, et cetera.

And so becoming more efficient will definitely help. I was definitely feeling very low about it there for a while because I was like, "I got this new responsibility and I was told that they thought I would be good at it and that's why I was given it. And I liked doing it. I don't want them to take it away from me. But I feel like I'm not doing a good job." And that's really kind of hard to grapple with.

NOEL: Yeah, I totally see that. It took a fairly long time to hire for our first associate position for a couple of different reasons. And it definitely involves being invested in a bunch of things you can't control, including the reactions of the other people at my own company. When I would get really excited about a candidate who other people were not excited about, that's challenging too.

All right. So, you're spending all this time hiring. You spend time in meetings or doing architecture. Something that I've seen in myself and I've certainly seen in other people that get in that situation is they start to wonder whether they're keeping up with current coding stuff, whether they're going to be able to keep up with new things.

JAMEY: I definitely have anxiety about that. I feel like I worry that I'm losing my edge. And I think it's partially because I'm just not in the code as high of a percentage of time that I used to be. But I think it's also that I'm working on harder stuff. I used to feel like, "I'm a software engineer and I'm pretty good at my job and I do a good job with my code. I figure out problems and I solve them and I write code that's pretty elegant," or whatever, however you want to benchmark writing good code. And now I feel sometimes like, "Oh my, I don't know about my code. I'm worried about it." And I think it's because I'm doing kind of like what I was getting at earlier, like I can't really work unless I understand everything about it. I'm doing stuff that's really hard. And because of it, I don't get that immediate gratification of like, "I wrote this and I did a good job," in the same way as when I was writing stuff that was easier. And because it just doesn't feel the same way, I don't feel as good at what I'm doing as I used to. And I have to remind myself, "Well, do you think that you suddenly got worse at your job? Or do you think that when you're leveling up and learning new things, it gets harder logically?" I talk a lot about logically, I know that this is true. But emotionally, I still have baggage about it which is kind of like the core of all of this in some way.

NOEL: It's hard to let go of skills that you very personally identify with.

JAMEY: That's a great point.

NOEL: At one point, I would have considered myself a professional level Java programmer. But I haven't done it in a long time and I'd probably not any more, at least not without a few weeks of refreshing. And yeah, you have to kind of remind yourself that you're doing something new with that time and with the same basic skill set.

JAMEY: I saw a talk one time by Kerri Miller and she was talking about when you learn a new language, this curve of how much longer it takes you to do stuff and it sounds obvious and you say it, "Because you're doing it in a new language, like duh?" But when you're learning something new and you're so used to being extremely proficient, it can be hard emotionally to just be less proficient. There's a quote from Adventure Time: "Sucking at something is the first step to being sort of good at something."

NOEL: I think that's true. I think there's like a whole Ira Glass paragraph-level rant about how hard it is to have taste and try to pick up something new, when you have the taste to recognize if it's something good. This is not just coding but in anything, to recognize what something good looks like but not quite the skill to produce something good, that can be really discouraging.

JAMEY: What I like so much about the quote is that it's not that like sucking at something is the first step to being great. You're still only sort of good at something at the end, which is of course, there's steps and then you suck less and then you suck a little less and then you feel like you're getting pretty good and then you get better.

NOEL: Then you're sort of good and then you're sort of better. Yeah, I totally recognize that. I have this terrifying...didn't they do a thing with Mark Zuckerberg where they set up a thing where he was going to commit something to the Facebook codebase for, like, press and he didn't know what he was doing? It had evolved...

JAMEY: I don't know about this but I believe it.

NOEL: It's too good to check, right?

JAMEY: Yeah.

NOEL: Some sort of story where they had set up a press event where he was going to commit something to the codebase and the tools had evolved to a point where he didn't know what to do. 

JAMEY: That's a wildly bad press event anyway.

NOEL: Sure.

JAMEY: I don't know who thought that was a good idea.

NOEL: We're going to watch Mark Zuckerberg push a button. [Crosstalk] It's going to be very upsetting.

JAMEY: And push some code.

NOEL: Stand back, everybody. 

NOEL: Jamey, we are, unfortunately, I think to the edge of time here. Jamey, where can people reach you online if they want to talk more about the new things that they're trying in their jobs?

JAMEY: You can find me on Twitter @jameybash. Actually people think that bash is my last name, I've gotten mail for Jamey Bash before. It's also not because I'm really good at bash stuff, so don't ask me about that. JameyBash.com is my website. I post articles there. I actually do comics reviews. So if you like comics, just check out my website. And it has videos of my conference talks.

NOEL: I would definitely go check that out. And of course, the Greater Than Code podcast.

JAMEY: Yes, of course.

NOEL: And I'll plug the Greater Than Code Patreons so that you can be on their excellent Slack community too.

JAMEY: That would be great. We have really good conversations there.

NOEL: It is true. I think that's it. That's everything. Thank you for being on the show.

JAMEY: Thank you so much for having me. It was really great.

NOEL: Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. The podcast is edited by Mandy Moore. You can find Table XI on Twitter @tablexi. You can find Mandy @therubyrep and you can find me @noelrap. Tech Done Right can be found at TechDoneRight.io or downloaded wherever you get your podcasts. You can send us feedback or ideas on Twitter @Tech_Done_Right. Of course, if you like the show, tell a friend, tell a colleague, tell your social media network, tell me, all of those things would be very, very helpful, as would review on Apple Podcast, which helps people find the show. 

Table XI is a UX design and software development company in Chicago, with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to story brands. Find us at TableXI.com where you can learn more about working with us or working for us and we'll be back in a couple of weeks with the next episode of Tech Done Right.