Soft Skills Engineering - Episode 409: Fancy title to IC and CRUD is crud

Episode Date: May 20, 2024

In this episode, Dave and Jamison answer these questions: Listener Shayne asks, ‌ I’m about to start a new gig after 8+ years at a company. I was an early employee at the current company and have accumulated a lot of responsibility, influence, and a fancy title. I’ll be an IC at my new company (also very early stage) but the most senior engineer second only to the CTO. What are some tips for this transition? How can I onboard well? How do I live up to my “seniorness” in the midst of learning a new code base, tech stack, and product sector? I managed to stay close to the code despite adding managerial responsibilities in my current role, so I’m not worried about the IC work. I really want to make sure that I gel with my new teammates, that I’m able to add valuable contributions ASAP, and that folks learn that they can rely on my judgement when making tradeoffs in the code or the product. Halp! I got into software development to become a game developer. Once I became a software developer, I found out I really enjoyed the work. My wife and I joined a game jam (lasting 10 days) over the weekend. I very quickly have realized how passionate and excited I get about game development again! But this has led to a problem - I would much rather be doing that. I find myself moving buttons around or making another CRUD end point a means to an end now, thinking about how I much rather be creating exciting experiences. How can I handle this? Quitting my job to pursue a pipe dream just isn’t feasible.

it takes more than creating a new programming language named 10x to be the first real 10x developer to be a great engineer this is soft skills engineering episode 409 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers who are looking for cheat codes to become the first 10x developer I thought a 10x developer was one who used only x's for all their variable names because when you have 10 x's in a row you know you've achieved something yeah yeah this is this is the 10th variable in the program so it is 10 x's all right I want to thank our patrons thank you to these people or institutions or concepts

who are contributing at the level where we shout them out every week thank you so much to Chewy, Ted Timbrel Testing is documenting but my co-workers don't test The Soft Skills Engineering Podcast Hmm BecomeASeniorEngineer.com Unsalted French fries are morally objectionable Dan from DroneDeploy, Chase W. Norton

Level up your TypeScript with TypeHero.dev Never is not just a crater on Mars Flamingo emoji, I like chicken I like liver, meowmix, meowmix, please deliver TrashPanda, TheComputerScienceBook.com Kyle Boss, Ken C. Dodds, Jenny Kim, Ong Shardle Craig Motlin, TheStochasticParrot, Patreon.com we're hiring ira chan question mark jonathan king zenai beautiful functional user documentation

williamangel.net backslash book ragnar travis braden canes john grant q29kesbtzwhs did i just swear in base 64 or something thank you thank you so much to these things thank you we appreciate your support you help keep the going and if you want to join them and get us to say words that have frankly grown more abstract over time which we love you can go to softskills.audio and click support us on patreon and any amount will get you an invite to our slack team and an amount above whatever it says on there will get you a weekly shout out for you or maybe a beloved parent a beloved co-worker we could shout out your child everybody knows that toddlers love shout outs from niche workplace

podcasts um oh you got me a shout out on a mainstream podcast lame you know a shout out on a niche workplace podcast when you were young i did a thing that i knew would impact your life forever i'm just waiting for someone to do a marriage proposal in their patreon name that's true they gotta you gotta line it up right so if you and your your neighbor in the list i mean if your spouse is a listener and you want us to say your proposal it'll just cost you the 20 patreon membership that's all that's great that's true by the way i cracked the code on the last thing the last name what is it you were right it is base 64 and i'm just gonna leave it as an exercise to the listener to decode that. Okay. Cool. Dave, do you want to read our first

question? Yes, I do. This comes from a listener named Shane who says, I'm about to start a new gig after eight plus years at a company. I was an early employee at my current company and have accumulated a lot of responsibility, influence, and a fancy title. I'll be an individual contributor at my new company, which is also very early stage, but the most senior engineer second only to the CTO. What are some tips for this transition? How can I onboard well? How do I live up to my seniorness in the midst of learning a new code base, tech stack, and product sector? I managed to stay close to the code despite adding managerial responsibilities in my current role, so I'm not worried about the IC work. I really want to make sure that I gel with my new teammates,

that I'm able to add valuable contributions ASAP, and that folks learn that they can rely on my judgment when making trade-offs in the code or the product. Help. Oh no, help. I almost read that wrong. That is HALP. Oh, interesting. This is awesome. I mean, as soon as I read this question, well, before I finished reading the question, my thoughts immediately go to all the things you can do to ramp up technically quickly,

you know, like how to get good at a new code base, how to navigate new processes and deployment systems and infrastructure and all that stuff and how to figure all that out quickly. And then the question asker said, I'm not worried about any of that. i want to build trust i want to make people confident in my judgment i want to help contribute to the product okay all right i think the more senior you are as a leader when you enter a role the more careful you need to be to communicate that you are not arrogant when you show up and that you are willing to listen and learn and take in local context instead of just slap your preferred style on top of things yes some of the worst professional

experiences i've had have been with leaders who showed up and took a look around and said it's all wrong it's all wrong you're doing it all wrong and then without really knowing what it was yeah and a lot of times i don't know that you just from reading the question it doesn't sound like you are the type to do that but you kind of have to signal the opposite you have to signal like i am here to learn and contribute not to tell you all the things you're doing wrong and one way you can signal that is by saying i am here to learn and contribute not to tell you all the things you're doing wrong you can actually say those words yeah yeah it's surprising how direct you can be about this. And guaranteed there are things here that you will scratch your head at

and say, it cannot possibly be the right way to do it this way. And probably like half the time, you will be incorrect about that. And it actually is the right way to do it. But half the time, you'll be correct. And it's really bad if you just pull the trigger on that really early. if you show up and say what you have two databases no one ever needs more than one and then like it turns out you do and that's pretty common i actually had this experience when i you know i had i had deeply adopted this mentality that you are describing jameson you know the humble i am an outsider you are all probably amazing and anything that i don't understand or that looks weird to me or wrong to me is probably because of my own ineptitude i bow to you you

And so I came to this new company, this was 12 years ago, and they were using, I guess I'll just say the names of the technologies. They were using S3FS for production, read and write of actual files that needed to be served to users. I had used S3FS before, and I had very much taken seriously the author's warnings that this is not production ready. It was like the first line on the github readme do not use this in a production context this is just for fun uh you know do not and i was like huh okay so i showed up you can't tell me what to do i mean they took that as a challenge i believe them i'm like i'm not i'm not gonna mess around with that like that's crazy you built a file system on top of s3 it's like these are these are not the same concept anyway i showed

up at the company and i saw oh wow they're using s3fs to read and write from s3 and just treating it like a file system and i asked the senior engineer on the team i said wow s3fs is that working for you and the senior engineer said oh yeah it's great i was like huh well what do you know that that s3fs author must have been overly cautious you know maybe it's one of those things where they're they're the humble open source contributor who doesn't want to get in trouble when this thing messes up but actually it's this amazing code that never fails well come to find out a couple months later i learned the very hard way actually our whole company learned the very hard way that s3fs was dropping information irrecoverably in i don't know maybe five to ten

percent of the time including a demo that one of our product managers did from the top of mount Kilimanjaro recorded a video and we lost it. I was like, oh my gosh. Then I realized that things sometimes look like they're working fine because you're not actually looking at them. And you know what? I kind of have changed my attitude a little bit on this super duper humility angle where I come in and I'll say, instead of saying just how is that working? when they say well i say okay instead i say oh how do you know then when they go i don't know i think it just is i'm like okay it's not actually working yeah anyway by how many pages i get about it which is zero yeah i've never been paged about this yeah yeah that's a good point i mean you

don't want to over index on like you can do this too much such that you show up and don't make very much impact at all you're just you're you're tentative and scared already perfect yeah but yeah i guess i'm over emphasizing the the i think it's easier to screw up by do i think this by throwing everything out and potentially yeah i think too much i think you'll just do that naturally so if if you if if you're an experienced engineer who has been in a leadership role, I think it is more likely that you can afford to pull yourself a little bit more towards learning because you'll be willing to speak up when you actually care and when you think it's important. Yeah. I think that's right. And frankly, it's not in my nature, and I know it's

also not in yours, Jameson, to show up and be like, listen, for the sake of my ego, we will replace everything here with something that I endorse. But Dave, that's the same thing. Yeah, this time I endorsed it. So we're going to rewrite it. There are a lot of decisions that I didn't make here. Let's change that. And I totally get that. And when I joined my current team about a year and a half ago, I joined them and I explicitly sat down and told them, hey, everybody, for the first at least 30 days, but probably more like 90 days, I'm going to be in observation mode, primarily just learning and understanding. And I'll have a lot of questions for you, but I do not anticipate coming in and making any sweeping changes because from what I

can tell from the interview process and what I've learned about the company, things are generally working well here. And with my current company, that was the right approach. I did not make any sweeping changes. And the team is actually excellent. They did a great job with stuff. And I had just helped them optimize and refine. And it was great. However, I applied the same approach with my last company, the company prior to the one I'm with. And that was actually a mistake. Honestly, it took me about a year, a year and a half before I realized, oh my gosh, we must rewrite this entire front end. There is nothing redeemable about it. It is a bug machine and no one that I've been able to hire can work effectively in this thing. And no one's willing

to complain loudly because they're all trying to be good citizens. And so I can definitely go the wrong way on that. And I think that the key here is that learn the things you need to learn as fast as possible. Don't ignore anything. Try to create an environment where people can tell you what they really think. Like, is this working? Talk to the other developers. Like, what's the best part about working here? What's the worst part about working here? And then also be careful with how you rank their opinion on it because sometimes they'll be like, this is wonderful. And it's like, okay, how many other places have you worked at? Like, this is my first job. It's like the only thing I know. And sometimes you got to go, okay, I'm going to take that opinion and maybe set it

aside a little bit because you don't have a basis for comparison and it could be terrible. And that was exactly what happened to me in my at my previous company where no one was complaining because they did they just thought oh i guess this is programming you know and then come to find out slowly stupidly slowly on my part that it was actually really really bad and we eventually did have to rewrite it but now we had to rewrite it with even more code that had been contributed in the interim so i guess like everything we say you know it can be applied too little or too much and i've done both yeah i do think i mean how do you gel with them probably especially if you're remote take some time one-on-one to meet all your co-workers that can help a lot if you just jump

into team meetings and kind of meet people ad hoc you might go a long time without just having a one-on-one conversation with somebody i think if you're in a very senior ic role you really need to be able to talk that's going to be a lot of your job is talking and picking up subtle things and i don't know yeah i agree 100 let them get to know you on a personal level especially since i'm reading here this is a very early stage startup so that to me says the team is probably pretty small i'm going to guess there's like five or fewer engineers of the team so it's totally tractable to form a personal relationship with each one of those people yeah you have enough free space on your skin to tattoo all of the names of your co-workers just think about that

i'll leave you with that do with it what you will this won't scale but that's not your problem today yeah just solve the problem to beat the team no one body part worth of tattoos team that's the new metaphor what's the standard tattoo point size for the font for your team members names I don't know. It probably depends. I mean, that's like asking what the standard pizza size is. There's a place by me called Box Bites, and they make these little tiny circle pizzas. Well, I guess all pizzas are circle when I say it like that.

They're like three inches wide, and they're delicious. Yeah. Two pizza team. It's like less than one person. Yeah, exactly. A two pizza team is like my four-year-old. oh my goodness all right have we answered the question well no i think not quite i i think um i have another suggestion when you get into the code and the system design and the architecture

of this new company you're going to see things that trouble you undoubtedly this just happens they'll give you concern for example at my current company i showed up and the deployment process i think i've talked about this on the show before but the deployment process that we use is different from anywhere that I've seen it before. And the process we use carries with it a risk. And I won't go into the details of what that risk is, but it definitely carries a risk. And I got a little bit fixated on that at the beginning. But it also carries with it some really cool benefits that are very helpful that I didn't immediately acknowledge until I actually sat down and worked in the process myself by contributing code, which that's a natural

thing that's going to happen here. And once I did that, I had a clear picture of both the good and the bad. And so I actually decided to write a document describing the current process and then describing a few alternatives. And then I stacked them up against each other in like a pros and cons list where we could clearly look at that as a team and say, hey, do we want to change this? Here are the pros and here are the cons of three different approaches, one of which we're currently using. And do we accept these? And I think that that kind of cold reasoning helps you earn the trust of your engineering teammates because they see that you are not an emotional decision maker when it comes to engineering processes, which a lot of people

are. A lot of people will say, I just don't like that, or it doesn't feel good to me. But if you can sit down and you can completely articulate all the pros and all the cons of each approach, write them down and sit down and bring the team together and build consensus around it. And then say together, we accept these cons, because we think the pros are worth it. That kind of behavior produces confidence in people in you, meaning they are confident in you, and they will trust you. And so anyway, I love that process where you're like, look, I just want to show you that I'm a clear thinker. And I'm comprehensive, you know, I'm not just going to get fixated on some silly idea and go crazy with it.

i love it i'm convinced i did it i convinced jameson yes okay should i read our next question yes let's do it this is from an anonymous listener who asks i got into software development to become a game developer once i became a software developer i found out i really enjoyed the work my wife and i joined a game jam lasting 10 days over the weekend i very quickly have realized how passionate and excited i get about game development again but this has led to a problem i would much rather be doing that i find myself moving buttons around or making another crud endpoint as a means to an end now thinking about how i would much rather be creating exciting experiences how can i handle this quitting my job to pursue a pipe dream just isn't feasible

oh i know this feeling was it with game development no i i just know the feeling of another crud user interface another crud api you know it's like that's all this does is read and write entries to a database and return lists of things you know i know that feeling it gets boring yeah i mean let's examine this quitting my job to pursue a pipe dream just isn't feasible my impression of game development especially indie game development is that it is because like most things that are hobbyist in nature, 99.99% of people that do it do not make a living from it. And so your chances of earning a great living out of it are very small, but maybe you're the exception. Maybe there's that tiny chance it'll still work.

And won't you be filled with regret if you don't even try though? i don't know i so i am not filled with desire to build video games i think it'd be cool but there's a lot of things i think would be cool and i don't do any of those so i don't have this particular problem but i do know the feeling of like man i wish i was doing this other wildly more exciting thing which happens periodically and frankly i think you're dealing with it in an okay way like doing a game jam sounds awesome that sounds like a great way to get into it what is a game jam i haven't heard of this it's sort of like a hackathon but for building a video game there's typically a topic like uh i don't know fungus or something there's

some kind of abstract topic and then you just sit down and build a game from scratch around that topic and you submit it and there are kind of judges and okay winners and the goal is to go from nothing to a working game so the games are always pretty janky or small in scope if you're not just an absolute pro at putting them together yeah but they're also yeah it's like a hackathon there's there's always wildly creative things that come out of it yeah so it's it's kind of intense time boxed experience yeah yeah i get it yeah there are a lot of production games that have come out of game jam ideas oh yeah that's cool yep i also have not really been sucked into the or enticed by the idea of being a game developer,

but I totally get the feeling of, oh my gosh, I'm creating another CRUD endpoint. Like this is the same thing over and over. And this has led me to work at companies where CRUD endpoints are not the core business. And trust me, there are plenty of companies for whom CRUD API endpoints and CRUD user interfaces are the core business.

I have gravitated toward companies where it's more of a distributed systems problem or like an application that's not CRUD-like, for example, like streaming video or like distributed signal processing and stuff like that. Really fun stuff. And it could very well be

that you will be able to scratch your itch here with something that's shaped like a game, but isn't a game. And maybe it could be more, and there's plenty more opportunities for things like that. Like there are a lot of software development positions that are not just creating and reading

and updating entries in a database yeah maybe you could find something like that that has a better economic profile for you than a broke indie game developer yeah but which isn't broke indie game developer yeah hmm i feel like i'm just crapping on your dreams but you started it quitting my job to pursue a pipe dream just isn't feasible that's how you ended the question so it's not my fault if i'm telling you yeah give up you said you couldn't do it yeah i think if you can find ways to still do it as a hobby there are people who love skiing right and and the whole work week they're just pumped for the weekend when they can go skiing and yeah they're probably not going to be professional skiers but you can structure your life as a grown-up around a pretty intense hobby

especially if you don't have kids or if you make them like your hobby wait you're saying you can a family indie game studio is that what you're saying yeah yeah what if what if the crunch time involved child labor it's so wouldn't that be nice you need to raise an artist a sound studio production kid and yeah maybe a coder and then you can be the one that goes to jail for child labor law violations the fall guy that's your job yeah what was my point yeah so i think if you can i don't know if this is realistic or feasible but people do it for for other hobbies you could do it for this one where you do find a way to spend a a significant fraction of time working on this thing and good news if it takes

off then you can do it even more yeah and that that was going to be my next suggestion is that game dev on the side might very well work for you and maybe you need to find a crud job that's so easy that you can get it done in like 20 hours a week and and your employer's okay with that and then that leaves you plenty of time to live the rest of your life and be an indie game developer yeah for funsies yeah i mean contracting is an interesting pathway here because you do get to just carve out time to do a thing. There is another option here, which if you are willing to work a lot of hours and work in a high risk scenario and a high pressure scenario, you can join a big game development studio. And I've actually known a few people who have worked

in these studios and they describe it exactly as I just did. Lots of hours, lots of pressure, sometimes windfalls of money you know big huge bonuses that arrive when you ship a title sometimes layoffs you know and sometimes let's just say marital dissatisfaction due to the demands placed on your life by your employer but i don't think they're all like that all the time i think many are most of the time and so if you're willing to really go in that hard on it you can find a job that does that and it will definitely pay the bills you just have to accept some of the risks and some of the cons that come with it yeah yeah it's like do you want to work 60 hours a week because you work 40 hours a week at a day job and 20 hours a week on the side on your on your indie

game or do you want to work i guess 60 is not very many in game dev hours do you want to work 80 hours a week because you work 40 hours at a normal job and 40 hours at your side gig or do you want to work 80 hours a week as a game dev that is my outsider's perspective also there is another pro of working at one of these big, high-pressure game studios, it will cure you of your desire to work on games anymore. Yeah. My impression of it is it feels like sort of like if you were really excited by JavaScript,

you just loved building things in the browser, and then you went to work at Google, just somewhere in their team of, I don't know, 100,000 engineers, however many they have. like yeah i mean they're kind of similar but you're going to be a little tiny piece of a big giant machine and it'll it'll be much different from building a thing that you own and yeah i guess we're just now giving advice on stuff we don't know anything about which is game development right feels less useful it's also kind of the theme of our podcast though that's true

at least we're being open about it and we're transparently uninformed i play a lot of video games therefore actually i don't i play a small number of video games a lot therefore i am highly qualified to talk all about what it's like have you talked to any of the developers of those video games hmm not really some of them i i know of online so you know as usual we don't have a ton of context into the life of this person we don't really understand why quitting their job is not feasible to pursue a dream for maybe even a short period of time. Although I can imagine quitting your job to pursue a pipe dream that has no income for two years is not feasible for pretty much everybody. So I get that. But what I really do believe is that most software engineers who I'm

acquainted with have the option to add software development on the side. If you're interested in game dev, it could be game dev or whatever else. It is feasible. I'm not saying it's easy. And if you're just doing this for fun, it might not fit the bill for that. But I would say that if you roll the dice for enough years, doing enough hours of game development on your own, there's a good chance that you will eventually get one that is economically viable to quit your job for. Maybe it'll happen in the first five years, but maybe it'll happen in the 20th year. you know and if that idea is appealing to you to just keep going for that long because you love it then i would say by all means pick that up as a side hustle and like doesn't it doesn't mean you

have to work 10 hours every week for the rest of your life on game dev maybe it's 10 hours this week and maybe it's zero hours the next week just because it didn't work out for you that week and that's the one of the beauties of having a side project that's just yours where you're not doing it because you signed a contract you're not doing it because someone's paying you yeah yeah all right have we answered this question i think so good luck i i would love to hear that later you decided to form a little indie studio of your own and you cranked out a title that made 17 on steam yeah i want you to make a game about building crud endpoints and moving buttons around oh yes enterprise web developer simulator simulator sim web dev yeah

Oh, what can people do if they want their own questions answered, Dave? Go to softskills.audio and click the Ask a Question button. Thereupon, you can fill out our form that requests but does not require your contact info. And you can give us your anonymous info. You can make up a name. We actually love it when people make up names that we can read. It kind of makes us feel like Dear Abby. And tell us everything you'd like to tell us about your life.

And, you know, listen, some of you just, I can tell, just really need to get some stuff off your chest in that form. and that's okay. We'll read it. We'll love it. We love everything you send in. Please keep them coming and thank you. Thank you. Thank you. We do appreciate it. And we will catch you next week.